Retool: 44% no sabe quién responde por una app con IA

El 44% de los líderes tech no sabe quién responde cuando una app creada con IA falla

Retool encuestó a 307 líderes senior de tecnología y seguridad —CTOs, CIOs y CISOs— y el resultado es incómodo: el 44% opera sin un responsable por defecto cuando una herramienta interna generada con IA provoca un incidente en producción. El dato importa porque el 90% de esos mismos líderes reporta presión creciente para habilitar el desarrollo con IA, y la mayoría lo considera una ganancia neta de productividad.

El desglose muestra la dispersión. Un 32% dice que responde el liderazgo de ingeniería o el CTO; un 23%, el equipo o la persona que construyó la herramienta; un 34% responde «depende de la situación»; y un 10% directamente no lo definió nunca.

La frase de un CITO encuestado resume el problema mejor que cualquier gráfico: «Cuando cualquiera puede publicar una herramienta en una tarde, nadie se anota para mantenerla. La podredumbre permanece invisible hasta que algo se rompe».

Por qué la mayoría no puede ni confirmar que tuvo un incidente

Hay un segundo hallazgo que suele pasar desapercibido: la mayoría de los líderes encuestados no pudo decir con confianza si habían tenido un incidente de producción causado por una herramienta generada con IA en el último año. No porque no haya ocurrido, sino porque no existe el monitoreo para confirmarlo en un sentido u otro.

Eso convierte el problema de gobernanza en un problema de visibilidad. Sin telemetría sobre qué se construyó, quién lo construyó y a qué recursos toca, la conversación sobre responsabilidad se vuelve teórica.

El problema de propiedad de las herramientas internas no es nuevo: siempre fue fácil construir y doloroso gestionar accesos y autenticación. Lo que cambia con la IA es el volumen y la velocidad. Un miembro del equipo de marketing puede pasar de un prompt a una herramienta en producción en una tarde, con una API key que nadie registró.

La gobernanza actual no está diseñada para este ritmo

El 78% de los líderes encuestados describe su gobernanza actual como mantenida manualmente o desigual entre equipos. La mayoría aplica controles herramienta por herramienta, a cargo de cada constructor individual, y solo el 7% respalda ese modelo.

La respuesta estándar a una brecha de gobernanza es más proceso: ciclos de revisión adicionales, políticas más claras, más capacitación. Ese enfoque tenía sentido cuando el desarrollo estaba centralizado y el volumen de herramientas nuevas era manejable. No encaja en un entorno donde una herramienta funcional puede ir del prompt a producción en el transcurso de una tarde.

Cuando el 55% de los líderes dice que la responsabilidad primaria de seguridad y control de accesos debería recaer en una plataforma centralizada por debajo de la app —que aplique sin importar cómo o quién la construyó—, está describiendo un cambio de modelo, no un ajuste de proceso.

Qué muestran otros estudios sobre la misma brecha

La encuesta de Retool no está sola. Un estudio de IBM publicado el 15 de octubre de 2026, con más de 3.200 ejecutivos senior de ocho países de Europa y Medio Oriente, encontró que ocho de cada diez vieron un incidente relacionado con IA llegar a su board o C-suite en el último año. Sin embargo, menos de la mitad (40%) reporta un cambio en su política o marco de gobernanza de IA como respuesta. Y el 56% reconoce que siguió adelante dentro de los límites de riesgo acordados en lugar de pausar el despliegue.

Ese mismo estudio señala que el 35% ya corre IA agéntica en producción, pero solo el 37% considera que su sistema de gobernanza está diseñado para escalar con agentes autónomos. La responsabilidad tampoco está clara: aunque el 98% asignó formalmente responsabilidad por riesgo de IA a nivel de board, el CIO o CTO fue el rol más citado como responsable de resultados adversos de agentes, con apenas un 17%.

Thoughtworks, por su parte, encuestó a 3.200 CIOs en diez países y encontró que el 91% en Norteamérica dice que la adopción de IA avanza más rápido de lo que la gobernanza puede adaptarse. El 92% coincide en que el área central de IT terminará siendo responsabilizada por brechas de seguridad causadas por herramientas de IA compradas de forma independiente por unidades de negocio.

Un informe de AWS recogido por Help Net Security añade la capa de datos: una encuesta de Strand Partners para AWS encontró que más de la mitad de las pymes y grandes empresas usan IA, pero solo el 24% tiene un enfoque documentado de uso responsable y apenas el 10% cuenta con una estrategia de gobernanza de datos. Un líder entrevistado lo describió sin rodeos: los CIOs que pasaron años gestionando shadow IT ahora lidian con shadow AI a diez veces la escala.

Del lado del código, los números son igual de duros. Un reporte de Snyk citado por teiss encontró que el 38% del código generado por IA contiene fallas de seguridad. La encuesta State of Code Developer de Sonar indica que la IA ya representa el 42% del código que llega a los repositorios y proyecta el 65% para 2027. Un análisis de The Next Web sobre la plataforma de vibe coding Lovable recoge que entre el 40% y el 62% del código generado por IA contiene vulnerabilidades, según el estudio que se cite.

Cómo se ve la gobernanza a nivel de plataforma en la práctica

El caso que cita Retool es el de Pernod Ricard. Cuando Pierre-Yves Calloc’h gestionaba la transformación con IA de la compañía, trató la gobernanza como una restricción de diseño a resolver desde el inicio, no como algo a negociar después. Construir dentro de una plataforma gobernada, dijo, «dio a todos mucha confianza: el hecho de que existiera esa capa de seguridad que garantiza que nunca vas a borrar la base de datos de producción. Conseguimos autorización para ir muy rápido y hacer cosas rápidas y semi-sucias dentro de ese entorno».

La lógica es la misma que aplica cualquier equipo de plataforma: los estándares de seguridad se definen una vez y se aplican a cada app, en lugar de reescribirse cada vez que alguien construye algo.

Qué significa esto para tu startup

Si tu equipo ya usa asistentes de código o herramientas no-code para construir software interno, la brecha de gobernanza ya existe en tu empresa, la hayas medido o no. Estas son las acciones que puedes tomar esta semana:

• Nombra un responsable por defecto antes de necesitarlo. No hace falta una política de 20 páginas: define quién responde si una herramienta interna generada con IA rompe algo en producción. El 10% que no lo definió es el que más caro lo paga.
• Instrumenta antes de legislar. Si no puedes responder cuántas herramientas internas se crearon en los últimos 90 días, ni quién tiene las credenciales, empieza por ahí. La gobernanza sin visibilidad es una hoja de cálculo desactualizada.
• Mueve los controles de seguridad a la capa de plataforma. Autenticación, permisos y control de accesos deben aplicarse por defecto, sin depender de que cada constructor los configure bien. El 55% de los líderes encuestados ya apunta en esa dirección.
• Trata a los agentes como a un empleado nuevo. La recomendación del informe de AWS es empezar con aprobación humana y ampliar la autonomía solo después de que el agente demuestre ser confiable, manteniendo la opción de reducirla de nuevo. Los límites de seguridad deben fijarse fuera del agente, porque un agente puede malinterpretar o rodear reglas embebidas.
• Revisa el código generado con más rigor, no con menos. Los caminos críticos —autenticación, pagos, acceso a datos— no deberían saltear la revisión humana solo porque los escribió una máquina.

Conclusión

La productividad que promete la IA para construir software es real: el 90% de los líderes encuestados por Retool la reporta. El problema es que la estructura organizacional que decide quién es dueño de lo construido no se movió al mismo ritmo. Mientras la gobernanza siga aplicándose herramienta por herramienta y dependiendo de que cada constructor acierte, la deuda se acumula en producción, invisible hasta que algo se rompe.

La salida no es frenar la construcción. Es mover la gobernanza de las apps individuales a la plataforma que está debajo de ellas.

Fuentes

• VentureBeat: Anyone can build apps with AI. But who owns them? (fuente original)
• Help Net Security: AI tests the limits of enterprise security governance
• IBM Newsroom: IBM Study on AI incidents reaching the board
• Thoughtworks: 91% of North American CIOs say AI adoption is outpacing governance
• teiss: Vibe coding’s security debt
• The Next Web: Lovable and the vibe coding security crisis

Artículos relacionados:

Gobernanza en Startups: Guía para Fundadores LATAM Rubrik SAGE: IA que gobierna agentes autónomos en 2026 Agentes de IA en empresas: quién responde por sus acciones IA agéntica sin revisión humana: quién responde si falla Responsabilidad legal IA: quién responde cuando un chatbot recomienda mal