English
En algún lugar de tu empresa, en este momento, alguien que no es desarrollador acaba de construir algo con IA. Puede ser un dashboard que muestra en un solo lugar cifras que antes estaban dispersas por todos lados. Puede ser una automatización que conecta dos herramientas que nunca estuvieron pensadas para hablar entre sí. Puede ser un pequeño agente que responde una pregunta que antes su equipo tenía que hacerle a IT y esperar tres días para obtener respuesta.
Y de verdad entusiasma. Por primera vez, construir algo no depende de pedírselo al equipo de ingeniería y esperar a que encuentre un lugar en su próximo sprint. Es un proceso de creación compartida, y a la gente le gusta: a cualquiera le gusta hacer algo que antes le resultaba imposible. Eso no es el problema. Esa es, en el fondo, la verdadera promesa de llevar por fin la IA al trabajo de todos los días.
El problema aparece después, y lo hace en dos frentes distintos que suelen tratarse como uno solo.
Dos problemas distintos bajo una sola etiqueta
El primero es de integración y seguridad. Ese dashboard no está conectado a los sistemas centrales. Esa automatización trasladó datos a un lugar que nadie registró. Nadie del equipo de seguridad o infraestructura lo revisó, porque nadie sabía que existía hasta que ya estaba en uso. Esta es la parte que la mayoría de las empresas termina notando, normalmente cuando algo falla o un cliente pregunta qué pasó con sus datos.
El segundo es de priorización, y rara vez quienes hablan de este problema son también quienes están construyendo estas soluciones. Aunque nada se rompa, aunque la herramienta funcione exactamente como se esperaba, queda una pregunta que nunca se hizo: ¿era realmente el mejor uso del tiempo de esa persona? Que algo sea fácil de construir no significa que genere valor. Que algo haya sido divertido de hacer no significa que debiera haber sido lo primero en construirse, ni que tuviera que construirse así, ni que esa fuera la persona indicada para hacerlo.
Vale la pena detenerse en esto, porque la respuesta honesta no es “dejen de construir”. Los dos tipos de trabajo con IA son legítimos:
- Automatizar trabajo manual es valioso cuando elimina un cuello de botella real, sobre todo cuando el volumen de trabajo obligaría a contratar más gente solo para mantener el ritmo. Si una tarea está bloqueando el flujo, automatizarla no es un lujo: es capacidad que se recupera de inmediato.
- Construir algo realmente nuevo, una forma distinta de atender a un cliente, una decisión que el equipo antes no podía tomar, es otro tipo de victoria, y muchas veces una más grande.
Las dos cosas valen la pena. Lo que falta en la mayoría de las organizaciones no es la voluntad de construir, sino un backlog y una manera de comparar las distintas opciones antes de empezar. Sin eso, los equipos terminan construyendo lo que resulta más divertido o más visible en una reunión, no lo que más impacta al negocio. Un dashboard bien diseñado que impresiona en la reunión del lunes puede acabar costando más que el proceso manual que vino a reemplazar, entre el riesgo no gestionado y el esfuerzo mal dirigido.
Por qué llamarlo solo “shadow AI” se queda corto
Ya existe un nombre para el primer problema: shadow AI, el uso de herramientas de IA sin control de IT. Es un patrón real, creciente y bien documentado. La encuesta de Gartner a líderes de ciberseguridad de noviembre de 2025 encontró que el 69% de las organizaciones ya sospecha o tiene evidencia de que sus empleados usan herramientas de IA generativa no autorizadas, y la consultora proyecta que más del 40% de las empresas enfrentará un incidente de seguridad o cumplimiento vinculado al uso no autorizado de IA para 2030.
El costo de esa brecha ya es medible. El informe de IBM sobre el costo de una filtración de datos 2025 encontró que el shadow AI fue un factor en el 20% de las filtraciones, y que las organizaciones con niveles altos de shadow AI pagaron, en promedio, 670.000 dólares más por incidente que aquellas con una gobernanza de IA sólida.
Casi toda esa conversación viene de proveedores de seguridad, y casi siempre llega a la misma conclusión: detectarlo, gobernarlo, asegurarlo. Es necesario, pero trata todo el problema como si fuera solo una falta de visibilidad, y no lo es. Puedes tener visibilidad total sobre cada herramienta de IA en tu empresa, aprobarlas todas, proteger cada canal, y seguir construyendo las cosas equivocadas en el orden equivocado. La seguridad responde “¿esto es seguro?”. No responde “¿deberíamos estar construyendo esto, ahora, de esta forma?”.
Esa segunda pregunta es, en el fondo, la que la gobernanza está pensada para responder. Y también explica por qué la brecha sigue creciendo: la misma investigación de IBM encontró que el 63% de las organizaciones estudiadas no tiene ninguna política de gobernanza de IA. Es decir, la mayoría de las empresas no solo carece de visibilidad sobre el shadow AI: tampoco tiene todavía una estructura capaz de responder la pregunta de priorización, aun si esa visibilidad existiera.
Qué significa realmente la gobernanza
No es un control al final del proceso. No es un formulario de cumplimiento que alguien completa después de que la herramienta ya está en producción. La gobernanza es una estructura de decisión: quién decide qué vale la pena construir, cómo se conecta con lo que ya existe y quién es responsable una vez que está en funcionamiento.
Aplicada al desarrollo, esa estructura se traduce en responsabilidades concretas dentro del propio proceso de construcción, no en una revisión que ocurre cuando algo ya está en producción. De eso trata, en el fondo, este artículo.
No es casualidad que esto se acerque a lo que pide ISO/IEC 42001, el estándar internacional para sistemas de gestión de IA. No solo pregunta si existe una política de seguridad. Pide demostrar supervisión y responsabilidad a lo largo de todo el ciclo de vida de un sistema de IA, desde la decisión de construirlo hasta el diseño, el despliegue y el monitoreo continuo. Dicho en términos más formales, plantea exactamente la pregunta que el shadow AI deja sin responder: quién era responsable en cada etapa y si esa responsabilidad puede demostrarse.
Cómo lo incorporamos en la práctica: ExoCode
No diseñamos ExoCode, nuestro framework de desarrollo asistido por IA, como un documento de gobernanza. Lo diseñamos como la forma en que construimos software. La gobernanza surge de la estructura misma, no de una revisión que se agrega después.
ExoCode articula siete etapas conectadas. Descubrimiento, Análisis, Diseño e Implementación sientan las bases para las etapas de Pruebas, Despliegue y Mantenimiento. Es en las dos primeras etapas, Descubrimiento y Análisis, donde realmente se responde la pregunta de priorización, antes de que exista una sola línea de código. ¿Vale la pena construir esto? ¿Resuelve un cuello de botella real o solo busca impresionar en una demo? ¿Se conecta con lo que ya existe, o se convierte en una herramienta más, desconectada, de la que en seis meses nadie se hará cargo?
En el centro de las siete etapas hay siempre una misma persona: un ingeniero cuyo trabajo, en cada etapa, es verificar, decidir y validar. Esa supervisión humana continua responde al principio conocido en la industria como human-in-the-loop, y es la parte que más importa aquí. No es una aprobación final antes del lanzamiento. Es una persona responsable en cada una de las etapas del proceso, no solo en las que una revisión de seguridad llega a detectar.
Esa estructura produce cuatro resultados concretos, no abstracciones:
- Visibilidad constante, con reportes y métricas en tiempo real sobre lo que realmente está pasando, no una actualización de estado una vez por trimestre.
- Calidad antes de producción, con pruebas automatizadas y validación rigurosa antes de que algo llegue a un entorno productivo.
- Trazabilidad completa, con cada decisión y cada cambio registrado, de modo que “quién decidió esto y por qué” tenga una respuesta real.
- Acompañamiento continuo, porque seguimos involucrados después de la entrega. Una gobernanza que termina en el lanzamiento no es gobernanza.
El resultado, en la práctica: un desarrollo aproximadamente tres veces más rápido que el tradicional, con validación humana en cada etapa en lugar de una sola, métricas reales en lugar de una sensación sobre el avance, e IA gobernada con los principios de ISO 42001 incorporados desde el diseño, no añadidos a posteriori cuando llega el momento de demostrar cumplimiento.
La solución real
La solución no es decirle a la gente que deje de construir, ni comprar una herramienta de detección que marque cada prompt no autorizado. Las dos opciones tratan el entusiasmo como si fuera el problema. No lo es. El entusiasmo es lo mejor que está pasando hoy en tu empresa.
La solución es darle a ese entusiasmo una dirección y una estructura: un espacio donde construir siga siendo rápido y realmente divertido, pero también esté conectado con lo que ya existe, protegido desde el inicio y orientado al ítem del backlog que de verdad importa, no solo al que quedó mejor en una demo. Eso no es una limitación a la innovación. Es lo que hace que la innovación se acumule en lugar de convertirse en cincuenta pilotos desconectados de los que nadie rinde cuentas.
Ese es el valor que aporta un socio con experiencia en este momento: no un “no”, sino una forma de convertir ese “sí” en algo seguro, conectado y que realmente justifique el tiempo dedicado a construirlo.
Preguntas que conviene responder directamente
¿Qué es shadow AI? Shadow AI es el uso de herramientas, modelos o aplicaciones de IA dentro de una empresa sin aprobación ni visibilidad del equipo de IT o de seguridad. Incluye desde un empleado que pega datos de la empresa en un chatbot público hasta un departamento entero que usa un dashboard o una automatización construida con IA que nadie más conoce.
¿El shadow AI es solo un problema de seguridad? No. La seguridad es la mitad visible. La mitad menos visible es la priorización: incluso una herramienta construida con IA que es perfectamente segura puede representar tiempo invertido en lo equivocado, si se construyó sin revisar si era el uso de mayor valor de ese esfuerzo o si estaba conectada con lo que el resto de la empresa ya tenía en marcha.
¿Qué exige realmente ISO/IEC 42001? ISO/IEC 42001 es el estándar internacional para sistemas de gestión de IA. Exige demostrar supervisión y responsabilidad a lo largo de todo el ciclo de vida de un sistema de IA, desde la decisión de construirlo hasta el diseño, el despliegue y el monitoreo continuo, no solo una política de seguridad o una revisión puntual.
¿Qué es la gobernanza aplicada al desarrollo? Es la responsabilidad que vive dentro del propio proceso de construcción, verificada por una persona en cada etapa, en lugar de una revisión de cumplimiento que ocurre después de que el sistema ya está en producción.