Código IA sin control: cómo gestionar el shadow IT del C-suite sin quemarte en el intento

El problema que nadie quiere decir en voz alta

Imagina la escena: el COO te manda un archivo HTML de varios miles de líneas. Te dice que lo ha generado con IA, que ya funciona en su navegador y que quiere que lo revises antes de expandirlo. Abres el fichero. JavaScript inline sin formato, librerías cargadas desde CDNs externos sin versión fijada, ninguna separación de responsabilidades, y un scroll horizontal que no termina. Un prototipo que, de alguna forma, ha llegado a considerarse candidato a producción.

El dilema no es técnico. Técnicamente, la respuesta es clara: esto no puede ir a producción tal cual. El dilema es político. Porque quien te lo envía no es un compañero de equipo, es el COO. Y decirle directamente que su trabajo es un desastre no es una opción si quieres seguir trabajando allí.

Este artículo no va de cómo rechazar al COO. Va de cómo convertir esa conversación en una oportunidad para establecer gobernanza real sobre el uso de IA en la empresa, proteger tu posición, y evitar heredar una deuda técnica que se volverá insostenible.

Por qué el código generado por IA sin supervisión es un riesgo real

Antes de entrar en estrategia, vale la pena entender exactamente qué riesgos hay sobre la mesa, porque necesitarás articularlos en términos de negocio, no en términos técnicos.

Seguridad y RGPD

Un dashboard que carga librerías desde CDNs externos sin versión fijada tiene una superficie de ataque que muchos equipos de seguridad no aceptarían jamás. Si ese script externo se ve comprometido, cualquier dato que procese el dashboard queda expuesto. Si el dashboard maneja datos de clientes o empleados — y muchos lo hacen — estás ante un riesgo de compliance con el RGPD que puede materializarse en sanciones concretas. No es una amenaza teórica.

Deuda técnica: el coste que no aparece en ningún presupuesto

El llamado vibe coding — código generado sin estándares, sin arquitectura, sin documentación — tiene un ciclo de vida predecible. Durante los primeros meses funciona. Luego empiezan los bugs difíciles de reproducir. Luego nadie se atreve a tocar nada porque no hay tests y cualquier cambio puede romper algo inesperado. En entornos de 10 a 50 personas, ese momento llega antes de lo que parece, y el coste de rehacerlo desde cero supera con creces lo que hubiera costado hacerlo bien desde el principio.

Reglamento de IA de la UE

La normativa europea sobre IA introduce requisitos de trazabilidad y documentación para sistemas usados en decisiones de negocio. Un dashboard sin arquitectura definida, sin control de versiones, sin auditoría de las librerías que usa, no cumple ese estándar. Esto no es algo que afecte solo a grandes corporaciones — cualquier empresa que use herramientas de IA en procesos con impacto real necesita poder demostrar cómo funcionan esas herramientas.

La estrategia: ni confrontación ni rendición

La comunidad técnica que ha vivido situaciones similares converge en un enfoque que funciona bien: no rechaces el trabajo del COO, reencuadralo. La diferencia es enorme.

Reframe: de solución a prototipo

El primer movimiento es cambiar cómo se nombra el artefacto. En vez de entrar en una conversación sobre si el código es bueno o malo, empieza desde el reconocimiento: es un prototipo muy útil que deja claro exactamente qué necesita el negocio. Eso no es condescendencia, es verdad. Un mockup funcional generado en horas tiene valor real como especificación de requisitos. El problema no es que exista — el problema es confundirlo con una solución de producción.

Con ese reencuadre, la conversación pasa de 'tu código está mal' a 'tenemos un punto de partida sólido, ahora necesitamos construir la arquitectura que lo soporte'. Eso es muy diferente de cara a quien lo generó.

Usa IA para revisar código generado por IA

Uno de los enfoques más efectivos que ha emergido en equipos que gestionan este tipo de situaciones es utilizar herramientas de análisis automático de código para hacer la revisión. La lógica es sencilla: si la crítica viene de un análisis automatizado, deja de ser personal. No es que tú digas que hay problemas — es que el análisis técnico los ha identificado.

Herramientas de revisión estática, linters, escáneres de dependencias — cualquiera de ellos puede generar un informe objetivo sobre vulnerabilidades conocidas, dependencias sin versión fijada, o patrones de código que suponen riesgo de mantenimiento. Ese informe es tu argumento. No lo fabricaste tú: es el resultado del proceso de validación que se supone que debes hacer.

Documenta por escrito, siempre

Este punto no es opcional. En cuanto hayas hecho la revisión, envía un resumen escrito — un correo, un documento, lo que use tu empresa — con los riesgos identificados y tus recomendaciones. No para confrontar, sino para protegerte.

Si en seis meses ese dashboard falla, expone datos, o se vuelve imposible de mantener, la pregunta será quién sabía qué y cuándo. Si tienes documentado que identificaste los riesgos y propusiste alternativas, tu posición es muy diferente a si simplemente dijiste 'vale' y miraste hacia otro lado. La documentación no es burocracia — es la diferencia entre ser el responsable del problema y ser quien lo anticipó.

Cómo presentar la alternativa técnica al C-suite

Una vez que tienes el reencuadre y la revisión documentada, necesitas proponer una alternativa concreta. Aquí es donde muchos técnicos fallan: presentan la alternativa en términos técnicos cuando debería presentarse en términos de negocio.

Traduce deuda técnica a coste real

No digas 'este código es difícil de mantener'. Di: 'cada vez que necesitemos añadir una funcionalidad a esto, necesitaremos entre X y Y horas de trabajo, porque no hay estructura que permita intervenir de forma aislada. Si refactorizamos ahora, esas intervenciones futuras se reducen significativamente.' Si tienes datos de proyectos anteriores para apoyarlo, mejor. Si no, el argumento lógico es suficientemente claro para quien gestiona presupuestos.

Propón con presupuesto y cronograma

La propuesta alternativa — sea migrar a una herramienta BI real, sea refactorizar el código en una arquitectura modular, sea cualquier camino que tenga sentido en tu contexto — necesita llegar con números y plazos. No 'deberíamos rehacer esto', sino 'con dos o tres jornadas de trabajo podemos tener una arquitectura que soporte el crecimiento que buscas, y aquí está lo que incluye'. Eso convierte tu propuesta en una decisión de negocio, no en un rechazo técnico.

Demuestra valor rápido

Si tienes margen para hacerlo, refactoriza una sección pequeña del dashboard antes de la conversación. No el todo — una parte. Muestra lado a lado cómo queda con estructura real versus cómo está ahora. Esa demostración hace tangible lo que de otra forma es abstracto. El COO no sabe lo que significa 'arquitectura modular', pero sí puede ver que una versión carga más rápido, es más fácil de modificar, y tiene mejor aspecto. El ROI de la experiencia técnica se vuelve visible.

El problema más grande: el shadow IT que viene después

Varios desarrolladores con experiencia en este tipo de situaciones señalan algo importante: este dashboard no es el problema real. Es el síntoma. Si un ejecutivo puede generar y desplegar herramientas críticas de negocio sin ningún proceso de validación, ese patrón se repetirá. Con más ejecutivos, con herramientas más complejas, con más datos implicados.

La oportunidad aquí no es solo resolver este caso concreto — es establecer un marco para todos los casos futuros. Eso significa proponer, mientras el tema está encima de la mesa, una política mínima: cualquier herramienta generada con IA que vaya a usarse en procesos de negocio pasa por revisión técnica antes de producción. No importa quién la haya generado.

El truco para que eso no suene como un bloqueo a la innovación es enmarcarlo exactamente al revés: el objetivo es que la IA pueda usarse con confianza, no limitar su uso. Sin un proceso de revisión, el riesgo de que algo falle de forma importante frena la adopción real. Con proceso, la empresa puede innovar más rápido porque hay un camino claro de validación.

Una política de IA que funcione en la práctica

No hace falta un documento de cincuenta páginas. Para una empresa de tamaño medio, una política de uso de IA generativa para herramientas internas puede reducirse a algunos principios claros:

• Todo código generado por IA que procese datos de negocio pasa por revisión técnica antes de producción. Sin excepciones por rango jerárquico.
• Las dependencias externas se fijan a versiones auditadas. No se carga nada desde CDNs públicos sin validación previa.
• Cualquier herramienta que procese datos personales pasa por evaluación de impacto. Esto no es opcional — es requisito del RGPD.
• Los prototipos generados con IA son bienvenidos como punto de partida. No como solución final.
• La revisión técnica no es un trámite burocrático — es parte del proceso de construcción. Se documenta y genera un informe.

Esa política, bien comunicada, no bloquea nada. Canaliza la energía creativa que herramientas como los generadores de código pueden aportar hacia un proceso que sea sostenible.

El momento de la conversación

Cuando llegue el momento de hablar con el COO, el mensaje central debería ser este: lo que has construido me da exactamente la información que necesitaba para entender qué quieres. Ahora déjame convertirlo en algo que no nos va a dar problemas en seis meses.

No es rechazo. Es apropiación constructiva. Y en el proceso, demuestras exactamente para qué sirve la experiencia técnica en un mundo donde cualquiera puede generar código funcional con una herramienta de IA: para saber qué hacer con ese código después.

Si tu empresa empieza a integrar IA en sus procesos internos — y si no lo está haciendo ya, lo hará pronto — la pregunta no es si habrá más casos como este. La pregunta es si tendrás un proceso para gestionarlos o lo irás resolviendo caso a caso, cada vez con más presión.