En un equipo que depende de agentes de codificación, estos abren una gran parte de las solicitudes de extracción (PR) que se implementan, y suelen ser buenos en la tarea visible: la función funciona, las pruebas pasan, las dependencias están actualizadas. Lo que un agente puede no tener en cuenta es si un cambio afecta a un control por el que se audita a tu empresa, porque esa obligación reside en tus marcos normativos y en tu contexto, no en el diff que se le pidió generar. Esa brecha es para lo que sirve una comprobación de cumplimiento para código generado por IA.
Las recopilaciones existentes de herramientas de cumplimiento para código de IA suelen referirse a una de tres cosas: análisis estático de errores, escaneo de dependencias y licencias, o detección de secretos. Estas son herramientas reales y valiosas. Sin embargo, ninguna de ellas está diseñada para evaluar un cambio frente a SOC 2, ISO 27001 o el GDPR a nivel de un control específico, lo cual es una pregunta diferente que se hace sobre la misma solicitud de extracción.
Qué significa cumplimiento aquí, a nivel de control
El cumplimiento para código generado por IA no es una comprobación de encabezados de licencia ni una puntuación de vulnerabilidades. Es la pregunta de si un cambio ha afectado a un control que estás obligado a mantener: un límite de acceso lógico, un registro de auditoría, un nivel mínimo de cifrado, un límite de retención. Esas obligaciones están definidas en los marcos normativos que tu empresa ha seleccionado, con un nivel de detalle que puedes verificar, por ejemplo, ISO 27001:2022 A.8.15 para el registro o GDPR Art. 5(1)(c) para la minimización de datos.
La razón por la que esto es una lectura separada es que un cambio relevante para el cumplimiento suele ser código correcto. Normalmente compila, es seguro, tiene la licencia adecuada y hace lo que el agente se le pidió. El problema no es un defecto en el cambio, sino que el cambio ha modificado silenciosamente algo que un auditor podría examinar más adelante. Una comprobación que solo busca defectos no está diseñada para señalar esto.
Un ejemplo práctico: un agente enriquece un perfil con más datos de los necesarios
Supongamos que a un agente se le pide que añada una insignia de nivel de fidelidad a la página de cuenta. Para calcular el nivel, añade una caché de user_profile y la rellena con datos del servicio de identidad. La forma más sencilla de hacerlo, y la que un agente optimizado para la tarea podría elegir, es copiar todo el registro de identidad en el nuevo almacenamiento: fecha de nacimiento, ID nacional, dirección, teléfono, junto con el nivel y el nombre para mostrar que la insignia realmente utiliza.
La migración es limpia y la función funciona a la primera. Pero el nuevo almacenamiento ahora contiene cuatro categorías de datos personales que la insignia de fidelidad no necesita. Esto es minimización de datos, GDPR Art. 5(1)(c): los datos personales deben ser adecuados, pertinentes y limitados a lo necesario para el propósito. La solución es una línea de intención: rellenar la caché solo con el nivel y el nombre para mostrar. Es más económico hacerlo en la solicitud de extracción que introdujo el almacenamiento, mientras el autor aún tiene el contexto. Si se deja así, se convierte en un nuevo almacenamiento que contiene datos personales innecesarios para su propósito declarado, descubierto meses después.
Por qué los escáneres de errores, vulnerabilidades y licencias no están diseñados para detectar esto
El cambio anterior no es el tipo de cosa que esos escáneres están diseñados para detectar: el código es correcto, así que un escáner de errores lo aprueba; no ha llegado ninguna dependencia nueva, así que un escáner de licencias lo aprueba; y un escáner de vulnerabilidades no está diseñado para leer una ampliación de la huella de datos personales como un hallazgo. Por lo tanto, los escáneres diseñados para encontrar esas cosas funcionan como está previsto cuando lo aprueban, porque un cambio relevante para el cumplimiento que por lo demás es correcto no es lo que están diseñados para leer. Esto no es una crítica hacia ellos; detectar errores, vulnerabilidades y desviaciones de licencia es realmente valioso, y la salida de un agente necesita todo eso.
Esto sí significa que una lectura de cumplimiento es una capa distinta, no una versión más fuerte del mismo escaneo. Lee el diff frente a los marcos normativos a los que estás sujeto y nombra el control que el cambio ha afectado, información que las otras herramientas no están diseñadas para producir. La postura sensata es ejecutar ambas cosas: los escáneres de calidad de código y seguridad para defectos, y una comprobación de cumplimiento para la desviación de controles, en la misma solicitud de extracción.
El cambio que hace que esto sea urgente
Dos cosas cambian cuando los agentes escriben una gran parte del código. Volumen: un agente abre más solicitudes de extracción de las que una lectura de cumplimiento humana cuidadosa puede seguir el ritmo, por lo que la lectura se convierte en un cuello de botella o se omite. Forma de fallo: un agente optimiza para la tarea visible, por lo que el código de control que se lee como fricción, una línea de registro, una comprobación de permisos, un límite de retención, es exactamente el tipo de cosa que un diff puede recortar o ampliar sin darse cuenta.
Independientemente de quién haya escrito un cambio, el auditor sigue evaluando si el control funcionó, por lo que el código escrito por IA se evalúa con el mismo estándar que el código humano. Lo que debe cambiar es que la lectura de cumplimiento ahora debe ejecutarse a velocidad de máquina para mantener el ritmo, lo que significa automatizar la primera pasada y reservar el juicio humano para los casos señalados.
Cómo añadir la comprobación
Una comprobación de cumplimiento para código generado por IA se ejecuta en la solicitud de extracción de la misma manera que tus otras comprobaciones: se activa cuando se abre o actualiza una PR, lee el diff frente a los marcos normativos que has seleccionado y el contexto de tu empresa, y publica los controles que un cambio afecta con la cláusula adjunta, como un comentario más un estado neutral. Cuando un agente abre la PR, la comprobación se encuentra con el código donde el agente ya lo ha puesto, sin pasos adicionales para el humano que debe aprobarlo.
heygrc está diseñado para ser esa comprobación como una aplicación de GitHub: instálalo, configura tus marcos normativos y contexto una vez (una única llamada REST que tu agente de codificación puede hacer por ti), y revisa cada solicitud de extracción en busca de impacto en el cumplimiento, citando el control en el diff. Publica un estado neutral de Checks más comentarios en línea, por lo que informa en lugar de bloquear, a menos que elijas exigirlo. Úsalo junto con tus escáneres de errores y seguridad, no en lugar de ellos.