Auditabilidad y cumplimiento del desarrollo asistido por IA

Qué preguntará un auditor o un equipo de due diligence

En una technology due diligence, una auditoría SOC 2 o una revisión de board, estas preguntas aparecen se nombre o no la IA:

• Quién escribió este código y quién lo revisó, para cualquier commit dado.
• Qué tests existen y si pasaron antes de que este cambio llegara a producción.
• Qué datos salieron de la empresa, si alguna herramienta que tocó el código también envió datos a un modelo de terceros.
• Si existe una política escrita que gobierne el uso de IA, y si alguien puede demostrar que se cumple.

Evidencia que ya tienes si el harness es correcto

Un equipo con una práctica de ingeniería disciplinada, tests, CI, revisión de código, ya tiene la mayor parte del camino hecho hacia ser auditable sin trabajo extra, porque el mismo rastro que permite a un agente verificar su propio trabajo es el que quiere ver un auditor:

• Historial de commits y revisión de pull requests, mostrando quién aprobó cada cambio.
• Logs de CI, mostrando qué comprobaciones corrieron y pasaron antes del merge.
• Informes de cobertura de tests, mostrando qué se verifica de verdad, no solo lo que se afirma.

Evidencia que necesitas añadir

Aquí es donde la mayoría de equipos tiene un hueco, porque es específico del trabajo asistido por IA y rara vez existe por defecto:

• Una declaración de uso de IA: una marca en commits o pull requests, o un registro simple, que muestre dónde participó un agente.
• Un inventario de modelos y herramientas: qué agentes de código IA se usan, en qué cuentas, aprobados por quién.
• Clasificación de datos para prompts: un registro de qué categorías de datos pueden llegar a qué herramientas.
• Retención de las transcripciones del agente cuando tu contexto lo exige, por ejemplo por contrato con un cliente o por una obligación regulatoria.

Contextos regulados, en términos generales

Los detalles dependen de tu sector y jurisdicción, así que trata esto como un mapa de dónde mirar, no como asesoría legal. Para entidades financieras en la UE, DORA cubre el riesgo de TIC y las dependencias de terceros, lo que puede incluir herramientas de código IA según cómo se usen. El RGPD aplica siempre que los prompts contienen datos personales, sea cual sea la herramienta. El alcance del Reglamento de IA de la UE para herramientas internas de desarrollo es limitado en la mayoría de los casos, pero la clasificación depende del uso concreto, así que conviene comprobarlo específicamente en lugar de asumirlo. Confirma siempre las obligaciones vigentes con tu equipo legal y de cumplimiento contra los textos oficiales.

Una checklist mínima de auditoría

Diez puntos que cubren la mayor parte de lo que se pregunta:

• Existe una política de IA escrita y con fecha.
• Las herramientas y cuentas aprobadas están listadas y actualizadas.
• Todo cambio a producción tiene un revisor identificado.
• El CI ejecuta tests, linting y escaneo de seguridad en cada cambio.
• Los commits o PRs asistidos por IA son identificables en el historial.
• No aparecen secretos ni credenciales en prompts o ficheros de contexto del agente.
• Existen reglas de clasificación de datos para lo que puede llegar a una herramienta de IA.
• El escaneo de dependencias y licencias corre también sobre el código sugerido por IA.
• Una persona identificada revisa la política con una periodicidad fija.
• Los ingenieros pueden explicar, si se les pide, el código que hacen merge.

Cómo aparece esto en una technology due diligence

En una tech DD antes de una inversión o adquisición, esto ya no es una pregunta teórica. Los revisores preguntan directamente qué porcentaje de la base de código lo genera IA, qué proceso de revisión siguió y si la política y la práctica realmente coinciden. Los equipos que pueden responder con claridad y con evidencia cierran más rápido y levantan menos señales de alerta que los que tienen que adivinar.