El Pentágono introduce 3 controles para cada fragmento de código generado por IA

Un agente de IA actualizó una biblioteca, corrigió la compilación y abrió una solicitud de fusión en un minuto. El parche parece limpio y, a primera vista, las pruebas están en verde. Pero ¿quién responde si el agente debilitó sin que nadie lo notara una comprobación de permisos de acceso? ¿Y se puede establecer, medio año después, qué modelo introdujo el cambio y quién autorizó su publicación?

La nueva instrucción 8430.01 del Departamento de Guerra de EE. UU. responde con dureza: el código creado o modificado por IA se considera no verificado hasta que el equipo confirme su calidad. Los desarrolladores siguen siendo responsables de la seguridad, el funcionamiento y la integridad del resultado. Las funciones críticas requieren la aprobación de una persona.

La norma se aplica a las organizaciones del departamento y a los programas de adquisición que incluyen software. Pero el enfoque es útil para cualquier empresa que ya deja entrar a agentes en sus repositorios: la velocidad de generación de código no sustituye las pruebas de que un cambio es seguro.

Qué hay que demostrar exactamente

La instrucción resume el trabajo con IA en tres requisitos prácticos.

Primero, la trazabilidad. El equipo debe saber dónde participó la IA, qué modelo y versión se usaron y qué acciones realizó el agente. Una simple etiqueta de «hecho con IA» no basta. El historial debe vincular el cambio con un proceso concreto y con la persona que lo lanzó.

Segundo, la verificación. El código del agente pasa las mismas pruebas, el mismo análisis de dependencias, la misma búsqueda de vulnerabilidades y las mismas reglas de aprobación que el código humano. En las funciones de las que dependen la seguridad del sistema o la vida de las personas, la decisión final la toma un especialista designado.

Tercero, los límites de los datos. Las consultas, el código fuente y la información no pública no deben enviarse a un modelo externo sin revisión. La organización debe definir de antemano los modelos permitidos, dónde se ejecutan y las reglas de conservación de datos.

Cómo se ve en un parche corriente

Supongamos que un agente propone actualizar una biblioteca de autorización. Un proceso normal es así: el agente crea una rama aparte y una solicitud de fusión; el registro anota su cuenta de servicio y al desarrollador que asignó la tarea; el pipeline ejecuta pruebas, análisis de dependencias y escaneo de seguridad. Como el cambio afecta a una zona protegida, el sistema exige la aprobación de un ingeniero responsable. El agente puede corregir un error detectado, pero no puede levantar por sí mismo el bloqueo ni enviar código a la rama principal.

Este orden no prohíbe la autonomía; fija sus límites. Se puede encargar al agente buscar actualizaciones, preparar un parche y relanzar las comprobaciones. El derecho a fusionar o publicar depende del riesgo: una corrección de documentación puede pasar automáticamente, mientras que un cambio de autorización solo puede hacerlo a través de una persona.

GitLab presenta su propia plataforma como una forma de cumplir estos requisitos: registros de auditoría, ramas protegidas, reglas de aprobación, escaneo de dependencias y una pasarela de modelos autoalojada. Es un ejemplo útil, pero la fuente sigue siendo material comercial. La instrucción describe requisitos y no obliga a usar GitLab; los mismos principios pueden construirse en GitHub, Azure DevOps o un sistema interno.

Qué cambiar en el proceso de desarrollo

Empiece no por elegir otra herramienta de IA, sino por un mapa de atribuciones. Registre a qué repositorios y datos tiene acceso el agente, qué acciones realiza por su cuenta y dónde debe detenerse. Identifique las ramas protegidas, los archivos críticos y las operaciones de publicación. Asígneles responsables y comprobaciones obligatorias.

Después, añada el origen de los cambios al registro de auditoría: el modelo, su versión, la cuenta de servicio del agente y la persona que lo inició. No se limite a un comentario en la solicitud de fusión: se pierde con facilidad y sirve poco para una investigación.

La conclusión principal es simple: la IA acelera la escritura de un parche, pero no traslada la responsabilidad del equipo al modelo. Si una empresa no puede mostrar quién lanzó al agente, qué se verificó exactamente y quién autorizó la publicación, aún no tiene un desarrollo con IA bajo control, sino un generador rápido de deuda técnica.