¿Qué parte de su código escribió una IA? La pregunta ya no es técnica.
Asistentes de código en cada equipo, decenas de ramas y un repositorio que nadie conoce entero. Para la dirección técnica es un problema de control. Para Legal, de autoría y licencias. Para el auditor, de evidencia.
El repositorio que nadie conoce entero
Un repositorio de V-PROOF analizado en septiembre tenía 163 ramas y 446 commits de cuatro autores. No es un caso extremo. Es lo normal en cualquier equipo que lleva un año desarrollando.
Con esa escala, saber qué existe, quién lo cambió y por qué depende de la memoria de dos o tres personas. Y si a eso se suma que parte del código lo propone un asistente de IA, la pregunta de quién es el autor deja de ser académica.
Antes de la rama, no después
Verifiable AI Code Governance analiza cada cambio antes del pull request, contra las normas de desarrollo que la propia organización define, no contra reglas genéricas. Revisa cuatro cosas en cada análisis:
Credenciales en el código.
Claves y variables sensibles detectadas en cada cambio.
Licencias y vulnerabilidades.
Licencias permitidas o prohibidas y vulnerabilidades conocidas publicadas.
Autoría medida.
Qué parte de las líneas nuevas procede de commits con coautoría de IA.
Cobertura por área.
Ficheros de prueba frente a ficheros de código en cada parte del proyecto.
Cuando un cambio incumple una norma o expone un secreto, se señala y queda registrado como evidencia. Los controles observan; no bloquean el trabajo del equipo. Cada uno queda como implementado, parcial o no implementado, con las cifras que lo justifican, en el mismo registro de gobernanza que el resto de la IA.
La autoría, medida
La cifra de IA declarada es la que más conversaciones abre en dirección. Es el punto de partida para responder quién es el autor de un activo de software y qué licencias arrastra.
Con una advertencia que conviene decir alto: mide lo que los commits declaran. Un uso de IA que no consta en el commit no aparece. Por eso la política de declarar coautoría importa tanto como la herramienta.
Del commit a la evidencia
Un commit puede quedar sellado junto con su glosario y su historial: qué código había, qué hacía y quién lo cambió, fijado en un mismo instante con prueba criptográfica. Se verifica en el portal público y se exporta para un auditor o un cliente.
Para quien vende software en Europa, esto encaja con lo que pedirá el Cyber Resilience Act: saber qué componentes lleva un producto y poder demostrarlo.
Lo que no hace
Detectar secretos y vulnerabilidades no es un pentest. Los controles son autoevaluaciones que revisa una persona responsable. Y el análisis funcional lo escribe un modelo que elige la organización, con su propia cuenta; solo viajan resúmenes y mensajes de commit, nunca el código.
Si quiere ver cómo funciona la memoria técnica del proyecto, la contamos en Tu código ya tiene historia.
Cada commit, atribuido. Cada despliegue, demostrable.
Noventa segundos. Del commit a la evidencia.
Grabado sobre el Portal V-PROOF: auditoría del repositorio, ratio humano / IA y commit sellado.
Ver la demo