Gobernar antes de codear: quién responde cuando la IA escribe el código vulnerable

Resumen ejecutivo

1. De autocompletar a hacer commit

La adopción de IA en el desarrollo de software recorrió cinco etapas en muy poco tiempo. Primero fue código manual. Después, autocompletado: la herramienta terminaba la línea. Luego llegaron los copilotos, asistentes contextuales dentro del editor. Más tarde, la IA generativa capaz de proponer módulos completos. Y hoy, agentes autónomos que actúan y deciden dentro del ciclo entero.

Ese último salto es el que cambia la naturaleza del problema. Un agente actual puede generar y modificar código, instalar dependencias y gestionar el árbol del proyecto, ejecutar scripts y comandos del sistema, aplicar cambios en entornos cloud y en pipelines de CI/CD, hacer commits, abrir ramas y pull requests, e integrarse con APIs externas por su cuenta. Dejó de ser una herramienta de consulta para convertirse en un actor dentro del ciclo de desarrollo.

Y un actor que actúa plantea de inmediato una pregunta de responsabilidad que la industria todavía esquiva.

2. El problema: la pregunta incómoda

Barrera la formula sin rodeos en la clase: si una IA escribe código vulnerable y ese código llega a producción, ¿quién es responsable? ¿El desarrollador? ¿El proveedor de IA? ¿El equipo de seguridad? ¿La organización? La pregunta es incómoda porque cada respuesta parcial deja un hueco por donde se escapa la rendición de cuentas.

La clase la resuelve separando cuatro cosas que solemos confundir en una sola:

• Ejecución — la IA genera, modifica o ejecuta según las instrucciones que recibe.
• Decisión — el humano decide qué tarea encarga, con qué herramienta y en qué contexto.
• Aprobación — alguien revisa y aprueba el resultado antes de que entre en producción.
• Responsabilidad — la organización, y las personas en sus roles, responden por el uso de IA y sus consecuencias.

De ahí sale la frase que ordena todo el curso: delegar una tarea no significa delegar la responsabilidad. El modelo ejecuta; la organización responde. No hay figura jurídica ni contractual que traslade la culpa a un modelo estadístico.

Un incidente sin culpables

El caso que se discute en clase es deliberadamente banal. Un desarrollador otorga acceso completo al repositorio a un agente. El agente refactoriza de forma autónoma una función crítica de autenticación. Agrega una librería de terceros sin evaluación de seguridad. Ejecuta las pruebas, que pasan —la vulnerabilidad no está cubierta por los tests existentes—. Hace el commit. El desarrollador revisa brevemente y aprueba. Días después, alguien la explota.

3. El mapa de riesgos: tres frentes, no uno

El error más común es reducir el riesgo del desarrollo con IA a la calidad del código generado. Son tres frentes distintos, y solo uno es técnico.

3.1 El código que produce

La IA hereda de sus datos de entrenamiento los patrones que allí abundan, y allí abundan tanto los buenos como los inseguros. En la práctica aparecen vulnerabilidades conocidas —inyección SQL, XSS, SSRF, IDOR—, errores lógicos que no lanzan ninguna excepción pero producen comportamiento incorrecto, librerías desactualizadas introducidas sin evaluación, configuraciones por defecto inseguras copiadas sin adaptar, y el más silencioso de todos: código que el desarrollador no comprende del todo y aprueba igual.

3.2 La información que sale

Cada prompt es una transferencia de información a un sistema externo. La pregunta que casi nunca se hace, dice Barrera, no es si enviamos demasiado, sino qué estamos enviando exactamente: código propietario y arquitectura interna, secretos que viajan sin querer dentro de un fragmento pegado, datos personales en ejemplos reales o en estructuras de base de datos, documentación interna de diseño.

El caso de Samsung es el recordatorio más citado: empleados subieron código sensible y contenido de reuniones a un asistente público y esa información salió del perímetro de la empresa. No hubo ataque. Hubo uso cotidiano sin reglas.

3.3 La autonomía que crece

El riesgo escala con la autonomía. Con la IA como asistente el flujo es usuario → prompt → IA → código → el usuario revisa y decide: el humano mantiene el control en cada paso. Con la IA como agente el flujo es objetivo → planifica → modifica → ejecuta → prueba → itera → resultado: el humano solo ve el final, a menudo sin visibilidad del proceso.

Cuatro preguntas permiten dimensionar cualquier agente antes de soltarlo: a qué recursos puede llegar (acceso), cuántas decisiones toma solo (autonomía), qué puede modificar o ejecutar (privilegios) y cuál es el peor escenario si algo sale mal (impacto).

4. Dos normas que no se pisan

Aquí es donde la clase deja de describir el problema y propone estructura. ISO/IEC 42001 define los requisitos para establecer y mejorar un Sistema de Gestión de Inteligencia Artificial (AIMS): políticas, roles, riesgos, impactos, controles, supervisión y mejora continua. ISO/IEC 27001 define el Sistema de Gestión de Seguridad de la Información: confidencialidad, integridad y disponibilidad.

La confusión habitual es creer que se solapan. No lo hacen: preguntan cosas distintas sobre el mismo hecho.

Un detalle que conviene subrayar: 42001 incorpora la evaluación de impacto de IA, que no equivale a la evaluación de riesgos clásica. Una pregunta qué puede fallar; la otra, qué efectos tendría sobre las personas, los procesos y los datos si falla. Es el requisito que más diferencia a esta norma de otros marcos de gestión de riesgo.

La otra buena noticia es práctica: 42001 sigue la estructura de alto nivel común a todas las normas ISO de gestión, así que una organización que ya opera un SGSI no parte de cero —contexto, liderazgo y planificación ya están escritos.

5. Generated ≠ Trusted

Una de las láminas más citadas de la clase se titula «el código generado por IA no es código confiable». Barrera reconoce la provocación: «el título es deliberadamente provocador y lo asumo». La idea que defiende no es que la IA escriba mal, sino que que compile y que las pruebas pasen no es evidencia de que sea seguro.

De ahí una cadena de validación mínima antes de que cualquier línea generada entre al repositorio: SAST (análisis estático sobre el código), SCA (análisis de composición sobre las dependencias), secret scanning (credenciales y tokens filtrados) y revisión humana que valide lógica, intención y riesgo. Cuatro pasos, ninguno opcional.

6. La propuesta: de la intención a la regla

El gobierno sin política es solo una declaración. La clase plantea que una política de desarrollo seguro con IA debe responder cinco preguntas concretas, y que si no las responde, no es una política.

1. ¿Quién puede usar IA? Roles autorizados, perfiles y niveles de acceso.
2. ¿Qué herramientas están autorizadas? Modelos, plataformas y agentes aprobados, con proveedor y versión.
3. ¿Qué información puede enviarse? Clasificación de datos por tipo de herramienta.
4. ¿Qué acciones requieren aprobación humana? Umbrales de autonomía y flujos de autorización.
5. ¿Cómo se registra el uso? Evidencia para auditoría e investigación de incidentes.

6.1 Clasificar antes de abrir el chat

El primer control no es técnico, es de criterio: si no sabes qué estás enviando, no deberías enviarlo. El marco mínimo que propone la clase distingue tres niveles. Permitido: código público o de ejemplo, datos sintéticos o anonimizados, documentación técnica pública. Condicionado: código interno, arquitectura, documentación técnica y proyectos activos —requiere autorización y condiciones definidas—. Prohibido: contraseñas, claves de API, tokens, credenciales de cualquier tipo y datos personales sensibles. Nunca en un prompt.

6.2 Supervisión proporcional, no uniforme

Pedir aprobación humana para todo es la forma más rápida de que nadie apruebe nada con atención. La clase propone tres niveles según el riesgo de la acción:

Y una lista corta de acciones que nunca deberían ejecutarse sin controles adicionales, sin importar quién las pida: cambios directos en producción, borrados masivos de datos, modificación de privilegios, acceso a secretos y cambios en infraestructura crítica.

6.3 Shadow AI: el control que se rompe solo

Toda herramienta fuera de la lista autorizada es Shadow AI. Pero el diagnóstico de la clase es más interesante que la definición: el Shadow AI aparece cuando las herramientas autorizadas son lentas, limitadas o desconocidas. Es decir, no es un problema de disciplina sino de diseño de la política. Una lista blanca que estorba se evade; una que habilita se respeta.

6.4 Quién hace qué, y quién responde

La clase entrega un RACI mínimo —adaptable, pero explícito— donde queda claro que el desarrollador ejecuta, el tech lead aprueba el uso, el responsable del AIMS lidera la evaluación de riesgos y la selección de herramientas, y el Product Owner responde por el paso a producción. La virtud del ejercicio no es la tabla: es que obliga a escribir nombres donde antes había un «alguien lo revisa».

6.5 Trazabilidad y excepciones

La prueba de fuego del gobierno es una sola pregunta: si mañana ocurre un incidente, ¿podemos reconstruirlo? Eso exige registrar quién solicitó la acción, qué herramienta y versión del modelo se usó, qué cambio se generó, quién revisó y aprobó, y cuándo y dónde se desplegó.

Y como toda política se rompe alguna vez, hace falta un camino formal para romperla bien: solicitud de excepción con justificación, evaluación de riesgo, aprobación de las partes clave (CISO, DPO, tech lead), registro con alcance y controles compensatorios, y revisión periódica. Una excepción documentada es gobierno; una excepción silenciosa es una brecha esperando fecha.

6.6 Medir para poder mejorar

Cinco indicadores bastan para saber si el gobierno existe o solo está escrito: porcentaje de código generado por IA que pasa por revisión humana formal, número de incidentes atribuibles a IA, excepciones activas, cobertura de herramientas autorizadas y tiempo de respuesta ante incidentes.

7. El contexto regulatorio ya no es futuro

Nada de esto ocurre en el vacío. El EU AI Act introdujo el primer marco regulatorio integral basado en niveles de riesgo y exigencias de transparencia; el RGPD sigue aplicando cuando la IA trata datos personales; y en América Latina hay marcos emergentes que buscan equilibrar innovación y uso responsable —Chile, con su nueva ley de protección de datos, es un ejemplo cercano—. Las normas ISO no reemplazan a la ley, pero son el andamiaje que permite llegar al cumplimiento sin improvisar.

A eso se suman los riesgos de cadena de suministro que la clase señala explícitamente: envenenamiento de modelos y dependencia de modelos, librerías y servicios de terceros que introducen vulnerabilidades heredadas. La respuesta no es nueva: extender a los proveedores de IA los mismos controles de proveedores que ya exige ISO 27001.

8. Conclusiones

Tres ideas para llevarse. La primera: la responsabilidad no se delega. Por muy autónomo que sea el agente, hay una persona y una organización que responden, y eso obliga a que alguien decida, alguien apruebe y alguien firme. La segunda: el gobierno va antes, no después —gobierno, riesgo, política, controles y recién entonces desarrollo—; llegar con la política después del primer incidente es llegar a redactar el informe, no a evitarlo. La tercera: el objetivo no es frenar el Vibe Coding, es hacerlo gobernable. La velocidad es una virtud real; lo que la convierte en un problema es que no exista ningún punto del flujo donde alguien esté obligado a detenerse.

Para empezar sin un programa completo, la clase deja un checklist de bolsillo: ¿estoy usando una herramienta autorizada?, ¿los datos que comparto están clasificados?, ¿hay revisión humana planificada?, ¿estoy en un entorno de desarrollo y no en producción?, ¿consideré la propiedad intelectual del código generado?, ¿escaneé el resultado en busca de vulnerabilidades?, ¿estoy evitando compartir credenciales o datos personales? Siete preguntas antes de abrir el chat cuestan menos que un incidente.

Referencias

• Barrera Vidal, A. (2026). Gobernar antes de codear: ISO/IEC 42001 + ISO/IEC 27001 aplicadas al desarrollo asistido por IA y Vibe Coding [presentación]. Curso FVCS-101, Comunidad IA LATAM × 8.8 Academy.
• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. Organización Internacional de Normalización.
• ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems. Organización Internacional de Normalización.
• Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo — Ley de Inteligencia Artificial (EU AI Act).
• Casos citados en la clase: fuga de información de Samsung a través de ChatGPT (2023) · credenciales en código sugerido por GitHub Copilot · estudios sobre densidad de vulnerabilidades en código generado por IA.

Autoría

Mg. Alberto Barrera Vidal — Secretario y CISO de Comunidad IA LATAM. Especialista en seguridad de la información, gobierno de inteligencia artificial y cumplimiento normativo. Integra los marcos ISO/IEC 27001, 27005, 22301 e ISO/IEC 42001 con prácticas de auditoría, gestión de riesgos y ciberdefensa. Lead Auditor ISO/IEC 42001 y Lead Implementer ISO/IEC 27001 y 22301.

Artículo elaborado por Comunidad IA LATAM a partir de la presentación y la grabación de la clase. Las cinco clases del curso están abiertas en Academy IA LATAM.