Aplicaciones que negocio crea con IA sin pasar por ingeniería

En un cliente vi cómo negocio construía sus propias aplicaciones con IA y cómo, después, aparecían problemas de gobierno y seguridad.

Lo que negocio construye con un agente es software, aunque nadie lo llame así, y se gobierna como el software: con controles dentro de la plataforma donde se construye, una revisión que depende de los datos que toca y un dueño que sigue ahí cuando su autor cambia de puesto. Montar eso le toca a ingeniería, y cuanto antes, mejor.

Cuánto se construye ya fuera de ingeniería

A esta forma de trabajar se le llama vibe coding: describir en lenguaje natural lo que quieres, dejar que un agente escriba el código y quedarte con lo que funciona sin leerlo. Empezó entre desarrolladores con prisa y ya lo usan personas que nunca han programado.

Retool, que vende una plataforma para crear herramientas internas, preguntó a finales de 2025 a 817 personas que construyen software en sus empresas. El 60 % había construido algo fuera de la supervisión de TI en el último año, y un 25 % lo hace a menudo. Solo el 36 % se identificaba como ingeniero o desarrollador; el resto venía de operaciones, producto, datos, marketing, finanzas y otras áreas. Y el 51 % ya tenía en producción algo que usa su equipo.

El porcentaje exacto importa menos que la dirección: en muchas empresas, producto y operaciones ya construyen, con permiso o sin él, y lo que construyen se queda en uso.

Hemos acabado usando estas soluciones de dos maneras: como spikes, prototipos que después ingeniería refactoriza, o proporcionando herramientas transversales que dan el harness (el contexto en el que trabaja la IA) a esas soluciones.

Qué cambia frente al shadow AI de siempre

En julio escribimos sobre el shadow AI: personas que usan herramientas de IA sin que tecnología lo sepa. El riesgo principal eran los datos que salen de la empresa por una conversación. Con el vibe coding aparece otra cosa: una aplicación que se ejecuta, se conecta a datos de la empresa y sigue funcionando cuando su autor ya está con otro tema.

La Cloud Security Alliance lo describe en una nota de junio de 2026. Una aplicación hecha a base de instrucciones puede existir solo como un servicio desplegado, sin código fuente que se pueda recuperar, sin inventario de dependencias (las librerías de terceros que usa) y sin registro de qué modelo ni qué instrucción la generaron. Cuando aparece un fallo, el arreglo pasa por volver a pedírselo a la IA, porque falta el código propio que un equipo parchearía.

Escape.tech, una empresa de seguridad, analizó en 2025 más de 5.600 aplicaciones públicas hechas con plataformas de vibe coding. Encontró más de 2.000 vulnerabilidades, más de 400 secretos expuestos (claves de acceso y credenciales que deberían estar ocultas) y 175 casos de datos personales a la vista. El análisis fue pasivo, desde fuera y sin romper nada, y los autores presentan sus cifras como un mínimo.

Las aplicaciones ya existen. La pregunta útil para un CTO es qué pone su equipo debajo de ellas para que la siguiente nazca con controles y la que ya funciona tenga un dueño.

Las cuatro barreras, por este orden

Lenny Zeltser, especialista en seguridad, escribía en marzo de 2026 que las aprobaciones previas fallan cuando quien construye no pasa por los flujos de trabajo de ingeniería. Su propuesta y la de la nota de la CSA coinciden en lo básico: controles dentro de las herramientas que la gente ya usa, y visibilidad para ver lo que se escapa. Ordenadas por lo que hace falta primero, quedan así:

El inventario, antes que cualquier norma

Sin inventario, el resto de barreras llega tarde. Zeltser propone que recoja qué datos usa cada herramienta, dónde se ejecuta, qué permisos tiene y quién es su dueño, y que el descubrimiento sea automático: esperar a que cada persona registre su aplicación deja fuera justo las que más preocupan. La CSA añade un registro ligero y sin castigo, pensado para saber qué hay antes de decidir nada.

El primer inventario puede salir de las plataformas que la empresa ya tiene contratadas: la nota sugiere empezar por sus paneles de gobierno, que listan aplicaciones, autores y conexiones a datos. Lo que no se ve desde ahí suelen ser las integraciones que alguien conecta por su cuenta, el mismo problema que dan los servidores MCP dentro de los equipos de desarrollo.

La revisión, por niveles de datos

La segunda barrera evita el error más frecuente: revisar igual todo lo que hace alguien de fuera de ingeniería, que acaba en una cola larga que la gente aprende a saltarse. La nota de la CSA propone tres niveles. Lo que proponemos para cada uno es un ejemplo para adaptar a cada empresa:

• Herramientas internas con datos no sensibles: registro en el inventario y comprobaciones automáticas, sin revisión manual.
• Aplicaciones con datos personales o regulados: además, una revisión de seguridad antes de abrirlas a más personas.
• Aplicaciones que llaman a servicios de IA o actúan solas, como un agente que envía correos o cambia registros: revisión de ingeniería y permisos reducidos a lo imprescindible.

El nivel lo marcan los datos y los permisos de la aplicación. Una hoja de cálculo que alguien de finanzas convierte en aplicación puede ser inofensiva o puede leer las nóminas, y saber quién la hizo no ayuda a distinguirlo.

Las comprobaciones, dentro de la plataforma

Zeltser lo explica con una frase práctica: quien no es desarrollador no va a lanzar herramientas de seguridad por su cuenta, así que esas herramientas tienen que funcionar sin él. Para un equipo de ingeniería es terreno conocido. El escaneo de secretos, el análisis de dependencias y los permisos mínimos ya viven en su pipeline, la cadena automática que comprueba cada cambio antes de integrarlo. Lo nuevo es ponerlos en la plataforma donde construye negocio y, donde la plataforma no lo permite, pedírselo al proveedor por contrato, como recomienda la CSA.

Un ejemplo del mercado: JPMorganChase ha abierto Claude Code a equipos que no son de ingeniería, según publicó Anthropic el 9 de noviembre de 2026. Lo hace en entornos controlados sobre su propia infraestructura, con miles de pruebas automáticas y puertas de aprobación que revisan cada cambio, y con una regla explícita: «Claude can't sign off on its own work» (Claude no puede dar por bueno su propio trabajo). Los modelos nuevos pasan antes por su proceso interno de aprobación. Es un banco con recursos de banco, pero el orden sirve para cualquier tamaño: primero el entorno y las comprobaciones, después el acceso a más gente.

Las aplicaciones huérfanas

Zeltser también señala el problema que más tarda en verse: cuando quien hizo la aplicación cambia de puesto o se va, la aplicación se queda sin dueño. Su propuesta es sencilla. Registrar quién la construyó y cuándo se actualizó por última vez, para que alguien la herede o la retire.

Esta barrera es la que más se olvida, porque al principio todas las aplicaciones tienen autor. El problema aparece al año, con la primera reorganización. Una aplicación que lleva meses sin cambios y cuyo autor ya está en otro equipo es la primera candidata a revisar: sigue leyendo datos y nadie la mira.

Qué le toca al equipo de ingeniería

Yo creo que hacia donde hay que ir es a construir un harness y un contexto corporativos y ayudar a que negocio pueda hacerlo bien. Estamos ante el primer momento de la historia en que alinear negocio y TI es muy sencillo.

Si se mira la lista, las cuatro barreras piden algo que ingeniería ya sabe hacer: construir una plataforma con reglas escritas y comprobaciones automáticas, y mantenerla. Es lo mismo que necesita cuando el propio equipo trabaja con agentes de código, con los permisos y el contexto bien puestos. Cambia quién la usa.

Por eso conviene que el CTO no lo delegue como un asunto de cumplimiento normativo de otra área. Quien construye fuera de ingeniería necesita lo mismo que un desarrollador con un agente: un contexto con las reglas de la empresa y controles que paren lo que no debe entrar. Si ingeniería lo ofrece y es más rápido que montarlo por libre, la gente lo usa.

Con los equipos de desarrollo trabajamos así: entregamos con método y mejoramos con datos, sobre el contexto que tu equipo construye con nosotros: sus reglas, su conocimiento del producto y controles automáticos.

Preguntas frecuentes

¿Qué es el vibe coding?

Es construir software describiendo en lenguaje natural lo que se quiere y dejando que un agente de IA escriba el código, a menudo sin leerlo. Lo usan desarrolladores y, cada vez más, personas de producto, operaciones o finanzas que nunca han programado.

¿Cuántas personas construyen aplicaciones fuera de la supervisión de TI?

En una encuesta de Retool a 817 personas que construyen software en sus empresas, hecha a finales de 2025, el 60 % había construido algo fuera de la supervisión de TI en el último año y un 25 % lo hace a menudo. Retool vende una plataforma para crear herramientas internas.

¿Qué riesgos tienen las aplicaciones hechas con vibe coding?

Escape.tech analizó más de 5.600 aplicaciones públicas hechas con estas plataformas y encontró más de 2.000 vulnerabilidades, más de 400 secretos expuestos y 175 casos de datos personales a la vista. La Cloud Security Alliance añade que muchas no tienen código fuente recuperable ni registro del modelo que las generó.

¿Cómo se gobierna el vibe coding en una empresa?

Con cuatro barreras, por este orden: un inventario automático de qué aplicaciones existen y quién es su dueño, una revisión por niveles según los datos que toca cada aplicación, comprobaciones automáticas de secretos, dependencias y permisos dentro de la plataforma, y un plan para las aplicaciones que se quedan sin dueño.

¿Qué es una aplicación huérfana?

Es una aplicación que sigue en uso cuando la persona que la construyó ha cambiado de puesto o se ha ido. Sigue leyendo datos y nadie la mantiene, así que alguien tiene que heredarla o retirarla.

¿Qué papel tiene el equipo de ingeniería?

Construir y mantener la plataforma en la que construye el resto de la empresa: reglas escritas, comprobaciones automáticas y permisos acotados. Son los mismos elementos que necesita cuando el propio equipo trabaja con agentes de código.

Fuentes

• Kelsey McKeon (Retool), «The build vs. buy shift: how vibe coding and shadow IT have reshaped enterprise software», 17 de febrero de 2026.
• Cloud Security Alliance (AI Safety Initiative), «The Vibe Coding Governance Gap», nota de investigación, 2 de junio de 2026.
• Nohé Hinniger-Foray, Gwendal Mognier y Alexandra Charikova (Escape.tech), «Methodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms», 29 de octubre de 2025.
• Lenny Zeltser, «Security Governance at the Speed of Vibe Coding», 30 de marzo de 2026.
• Anthropic, «JPMorganChase expands Claude Code to more employees across the firm», 9 de noviembre de 2026 (caso publicado por el fabricante).