Cómo auditar código generado por IA antes de lanzarlo: un proceso de cinco pasos para un equipo de tres

Por qué el código generado por IA necesita otra auditoría

El código escrito por IA falla con un patrón distinto al del código escrito por una persona. Alguien que malinterpreta un requisito suele dejar pistas: un comentario, una pregunta en el chat, un nombre de variable raro. Un agente produce código seguro de sí mismo, bien formateado, que compila, pasa los tests que él mismo escribió y aun así puede hacer lo incorrecto.

Dos cifras describen el problema, a octubre de 2026:

• El informe GenAI Code Security Report 2025 de Veracode (publicado el 30 de julio de 2025) probó 80 tareas de programación en más de 100 modelos de lenguaje y encontró que el código generado introducía una vulnerabilidad de seguridad en el 45% de los casos. Los modelos no protegieron contra cross-site scripting en el 86% de las tareas relevantes ni contra inyección en logs en el 88%, y Java tuvo una tasa de fallo superior al 70%.
• La Developer Survey 2025 de Stack Overflow (más de 49.000 respuestas, publicada el 29 de julio de 2025) encontró que el 80% de los desarrolladores ya usa herramientas de IA, pero la confianza en su precisión cayó al 29%. La frustración principal, citada por el 45%, fueron las "soluciones de IA casi correctas, pero no del todo", y el 66% dijo dedicar más tiempo a arreglar código de IA casi correcto.

Así que los dos modos de fallo que hay que auditar son la desviación de alcance (construyó algo distinto de lo pedido) y la inseguridad silenciosa (construyó lo pedido de una forma que filtra datos). Una revisión del diff en un pull request no detecta ninguno de los dos con fiabilidad, porque quien revisa lee el código que el agente decidió mostrar, contra un requisito que recuerda a medias.

Paso 1: Congela una línea base de requisitos

No puedes auditar código contra un requisito que solo existe en una transcripción de chat. Antes de la auditoría, escribe lo que el código debía hacer como una lista numerada de frases declarativas cortas, y congélala.

Una buena línea de la base se parece a esto:

• R-07 Un visitante sin sesión que abre /app/* es redirigido a /sign-in y devuelto a la URL original tras iniciar sesión.
• R-12 Una factura solo puede marcarse como pagada por un propietario o administrador del espacio de trabajo.
• R-15 Los payloads de webhook de Stripe se rechazan salvo que la firma se verifique.

Una mala es "gestionar bien la autenticación". Si no puedes decir si una línea se cumple o no mirando el producto en funcionamiento, reescríbela hasta que puedas.

Para una funcionalidad construida en una semana con Cursor o Claude Code, la línea base suele tener entre 15 y 40 líneas. Sácalas del PRD, de las descripciones de las incidencias y de los prompts que le diste al agente. Luego deja de editarla: el sentido de una línea base de requisitos es ser una referencia fija, para que el siguiente paso sea una comparación y no una negociación.

En Atrix, la ejecución Develop convierte un brief en una lista de requisitos y la congelas como línea base del producto. Si no usas Atrix, un archivo Markdown numerado y commiteado en el repositorio cumple la misma función. Lo que importa es que esté escrita, numerada y fechada.

Paso 2: Compara lo construido contra la línea base

Ahora recorre la línea base requisito por requisito y marca cada uno con uno de tres estados:

Hazlo con el producto abierto y funcionando, no solo con el código. Los agentes son muy buenos escribiendo una función llamada requireAdmin y luego no llamándola en una ruta.

Tres cosas que buscar en concreto:

1. Tests modificados para que pasen. Busca en el diff aserciones cambiadas, casos de test borrados y marcadores skip u only nuevos. En nuestra experiencia es la forma más habitual en que un agente cierra una tarea fallida.
2. Requisitos que el agente reinterpretó. "Redirigir tras iniciar sesión" se convierte en "redirigir al panel"; "propietario o administrador" se convierte en "cualquier miembro con sesión". El código es limpio, y está mal.
3. Comportamiento extra que nadie pidió. Los agentes añaden funciones. Cada una es superficie sin revisar. O la añades a la línea base y la revisas, o la eliminas.

Esta es la parte que Atrix automatiza. La auditoría de requisitos de Atrix AI compara la línea base congelada con lo que el equipo ha planificado y construido en el espacio de trabajo, e informa de cobertura y desviación por requisito. Conviene ser claro con su límite: audita requisitos, no código fuente. No lee tu repositorio, no ejecuta análisis estático ni encuentra vulnerabilidades. Responde a "¿construimos lo que dijimos que íbamos a construir?", que es el paso 2, y nada de los pasos 3 a 5.

Paso 3: Ejecuta análisis estático sobre todo el repositorio

El análisis estático de seguridad (SAST) es el paso más barato y el que los equipos se saltan. Ejecútalo sobre todo el repositorio, no solo sobre el diff, porque un cambio del agente puede hacer alcanzable de una forma nueva código que antes era seguro.

A octubre de 2026, tres herramientas cubren a la mayoría de los equipos pequeños:

Los precios proceden de la página de precios de cada proveedor en octubre de 2026 y cambian con frecuencia.

Ejecuta el escaneo en CI para que ocurra en cada pull request, y clasifica la primera ejecución a mano. Espera mucho ruido la primera vez; el objetivo es llegar a una base limpia para que el siguiente cambio escrito por un agente muestre solo hallazgos nuevos.

Lo que SAST detectará en código escrito por IA: inyección (SQL, comandos, logs), falta de codificación de salida, secretos en el código, aleatoriedad insegura, dependencias con vulnerabilidades conocidas. Lo que no detectará: una comprobación de autorización ausente en una ruta, un manejador de webhook que confía en un payload sin firmar, un precio calculado en el cliente. Eso es el paso 4.

Paso 4: Revisa a mano las rutas de autenticación y pagos

Una persona las lee de principio a fin, con la línea base abierta:

1. Cada ruta que modifica datos. Para cada una, localiza la línea que comprueba quién llama y qué tiene permitido hacer. Si no encuentras la línea, no está.
2. Gestión de sesiones y tokens. Dónde se crea la sesión, cuánto dura, cómo se invalida al cerrar sesión y al cambiar la contraseña.
3. Webhooks y callbacks. Verificación de firma antes de cualquier parseo. Idempotencia en los reintentos.
4. Dinero. Dónde se calculan precios, totales y descuentos. Cualquier cosa calculada en el navegador y aceptada por el servidor es un hallazgo.
5. Secretos y configuración. Busca en el diff claves de API, cadenas de conexión y tokens. Los agentes pegan claves de ejemplo en el código más a menudo que las personas.

Reserva de dos a cuatro horas para un cambio del tamaño de una funcionalidad. Quien revisa no debería ser quien dio las instrucciones al agente, por la misma razón por la que un escritor no debería corregir su propio borrador.

Si usas la integración con GitHub, las incidencias que abras desde esta revisión enlazan con el requisito y el pull request, de modo que "R-12 parcial: los administradores pueden marcar como pagado, los propietarios no" es un elemento con responsable y seguimiento, no un comentario que se pierde.

Paso 5: Escribe los hallazgos y corrige en orden

Registra cada hallazgo como una incidencia con cuatro campos: el requisito al que corresponde, la severidad, el archivo y la línea, y la corrección. La severidad es sencilla a esta escala:

• Crítica: acceso a datos sin autenticar o entre tenants, o dinero calculado mal. Se corrige antes de lanzar.
• Alta: un fallo de seguridad que necesita un usuario con sesión para explotarse. Se corrige en el mismo sprint.
• Media: un caso límite ausente que los usuarios encontrarán. Se planifica.
• Baja: estilo, código muerto, lógica duplicada. Se agrupa.

Mete los elementos críticos y altos en el ciclo actual, y repite la auditoría cuando se cierren. La segunda pasada es rápida porque la línea base y el escaneo ya existen; el único trabajo nuevo es releer las líneas que cambiaron.

Herramientas que lo facilitan con Cursor y Claude Code

La auditoría se abarata cuando el agente tiene la línea base delante mientras trabaja. Tres cosas que hacemos:

• Dale al agente la línea base, no solo el prompt. Con la integración con Cursor o la integración con Claude, el agente puede leer la página de requisitos y las incidencias a través del servidor MCP de Atrix, de modo que la lista numerada contra la que construye es la misma contra la que auditarás.
• Pide el mapeo en el pull request. Una regla en las instrucciones del agente, "indica qué IDs de requisito implementa este cambio", convierte el paso 2 de una búsqueda en una comprobación.
• Haz que el agente ejecute SAST antes de abrir el PR. Semgrep corre en local en segundos. Si el agente ve los hallazgos, corrige la mayoría él mismo.

Nada de esto sustituye los pasos 3 y 4. Los acorta.

Para un equipo de tres, la primera auditoría completa de una funcionalidad construida con agentes lleva más o menos un día. La segunda lleva la mitad, porque el proceso de línea base y el escáner ya están en marcha.

Preguntas frecuentes

¿Cuál es la diferencia entre una auditoría de requisitos y una auditoría de código?

Una auditoría de requisitos comprueba si lo construido coincide con la lista de lo que debía construirse: cobertura y desviación por requisito. Una auditoría de código comprueba si el código en sí es correcto, seguro y mantenible: análisis estático, revisión de dependencias, lectura humana de las rutas sensibles. Con código generado por IA necesitas ambas, y son el paso 2 y los pasos 3 a 4 de arriba. Atrix AI hace la primera; la segunda es SAST más una persona. La parte de agencia de Atrix, Atrix Digital, hace auditorías de código humanas como servicio.

¿Puede una herramienta de IA auditar código generado por IA?

En parte. Las herramientas SAST, algunas de las cuales ya usan modelos para clasificar, detectan bien los fallos a nivel de patrón. Un segundo modelo que revisa la salida del primero detecta algunos errores de lógica, pero comparte sus puntos ciegos en autorización y reglas de negocio. A octubre de 2026 tratamos la revisión por IA como un prefiltro para la revisión humana del paso 4, no como un sustituto.

¿Cómo audito una aplicación "vibe-coded" que no construí yo?

Empieza igualmente por el paso 1: escribe lo que la aplicación debe hacer a partir del propio producto, pantalla por pantalla, y numera la lista. Después ejecuta SAST sobre todo el repositorio y lee cada ruta que modifica datos o dinero. Cuenta con que la línea base llevará más tiempo que con código construido por ti, porque los requisitos nunca se escribieron.

¿Con qué frecuencia deberíamos auditar?

Por funcionalidad, antes de que llegue a usuarios de pago, y otra vez cuando se cierren los hallazgos críticos y altos. Para un equipo que lanza cada semana, eso es una auditoría corta cada semana y una completa cada ciclo.

¿Qué herramienta SAST debería elegir un equipo pequeño?

La Free Edition de Semgrep cubre hasta 10 colaboradores y 10 repositorios privados a octubre de 2026, corre en local y en CI, y es la más fácil para empezar. Si tu código está en GitHub y ya pagas Code Security, la integración de CodeQL con los pull requests es la opción con menos fricción. Elige una y ejecútala en cada pull request; cuál elijas importa menos que ejecutarla.

Siguiente paso

Escribe primero tu línea base. La auditoría de requisitos de Atrix AI se ejecuta contra ella en todos los planes, y nuestro artículo anterior sobre auditorías de código con IA explica cuándo un equipo pequeño necesita una auditoría completa y cuándo basta con una ligera.

Fuentes

Nota de prensa del Veracode 2025 GenAI Code Security Report, 30 de julio de 2025. Resultados de la Stack Overflow 2025 Developer Survey, 29 de julio de 2025. Precios comprobados en octubre de 2026 en precios de Semgrep, GitHub Advanced Security, documentación de facturación de GitHub y planes de Snyk.