Checklist de auditoría de código generado por IA para 2026: seis secciones, imprimible y con plantilla gratuita

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

El código de Cursor, Claude Code, Copilot o Codex parece terminado. Compila, las pruebas que escribió el modelo pasan y el pull request se lee bien. La guía de MetaCTO de julio de 2026 sobre estándares de revisión para código generado por IA lo llama la "trampa de la revisión": código plausible que omite un requisito, inventa una API o se salta una comprobación de autorización, y pasa una revisión que solo buscaba estilo.

Las cifras no son humo de proveedor. El informe GenAI Code Security 2025 de Veracode pasó 80 tareas de programación seleccionadas por más de 100 modelos de lenguaje y encontró que introducían una vulnerabilidad de seguridad en el 45 por ciento de los casos. Java falló por encima del 70 por ciento; Python, C# y JavaScript quedaron entre el 38 y el 45 por ciento. El cross-site scripting quedó abierto en el 86 por ciento de los casos y la inyección en logs en el 88 por ciento.

Las dependencias son un problema más nuevo. Un estudio de USENIX Security 2025 de Spracklen y colegas probó 16 modelos en unas 576.000 muestras de código generado y encontró que el 19,7 por ciento de los paquetes que recomendaban no existía. Los atacantes ahora registran esos nombres inventados, una práctica llamada slopsquatting. Una revisión convencional nunca comprobaba si un paquete era real, porque hasta hace poco siempre lo era.

Así que una auditoría de código IA no es una revisión normal hecha con más cuidado. Añade comprobaciones sin equivalente en código humano y mueve el esfuerzo humano a donde un error con aspecto convincente cuesta más.

Los tres motores de 2026

Los MVP "vibe-coded" están llegando a clientes. Los fundadores lanzan productos construidos en gran parte por agentes, a menudo por una persona en pocas semanas. La auditoría es la primera vez que alguien lee el código como un todo. Las firmas que publican lo que encuentran en estas bases de código describen el mismo patrón: pantallas de administración protegidas en la interfaz pero no en la API, sin límites de tasa, seguridad a nivel de fila ausente o mal configurada, secretos en el repositorio.

Diligencia debida para SOC 2. Bajo los criterios de gestión de cambios (CC8 en los Trust Services Criteria del AICPA) la pregunta del auditor es si cada cambio significativo fue revisado, aprobado y probado antes de producción. Ni SOC 2 ni ISO 27001 nombran la "revisión de código" como control, pero ambos esperan que la gestión de cambios se aplique y sea verificable. Un pull request escrito por un agente y aprobado por la persona que lo promptó es una respuesta débil; una auditoría documentada con revisores nombrados es una respuesta fuerte.

La Ley de IA de la UE. Las obligaciones para modelos de IA de propósito general aplican desde el 2 de agosto de 2025, y la Ley pasó a ser aplicable en general el 2 de agosto de 2026. El Ómnibus de IA (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026) trasladó las obligaciones de alto riesgo independientes del Anexo III al 2 de diciembre de 2027 y las de productos integrados al 2 de agosto de 2028. Si vendes a casos de uso de empleo, educación, crédito o infraestructura crítica, "lo escribió un agente y no lo comprobamos" no es una entrada defendible en la documentación técnica.

El checklist, sección por sección

Imprímelo o copia la plantilla de checklist de auditoría de código en tu espacio de trabajo. Marca cada punto, anota la evidencia (enlace a un resultado de escaneo, una prueba, un commit) y nombra a la persona que lo comprobó.

1. Inventario y mapa de arquitectura

• Lista cada repositorio, servicio, tarea programada y definición de infraestructura en alcance.
• Marca qué archivos o módulos fueron generados por IA, asistidos por IA o escritos a mano. Git blame más los mensajes de commit suelen decirlo; si el equipo no lo sabe, dilo en el informe.
• Dibuja la ruta de la petición: puntos de entrada, capa de autenticación, almacenes de datos, llamadas a terceros, workers en segundo plano.
• Anota las versiones de runtime y el destino de despliegue.
• Lista cada lugar donde se almacenan o transitan datos personales, de pago o credenciales.

Sin esta sección el resto de la auditoría muestrea al azar.

2. Análisis estático (SAST) y escaneo de secretos

• Ejecuta una herramienta SAST sobre toda la base de código (Semgrep, CodeQL, SonarQube o el equivalente del lenguaje) y conserva la salida sin procesar.
• Ejecuta un escáner de secretos (gitleaks, trufflehog o el escaneo integrado de tu proveedor) sobre todo el historial de git, no solo HEAD.
• Clasifica los hallazgos en verdadero positivo, falso positivo y riesgo aceptado, con una línea de justificación cada uno.
• Comprueba a mano las debilidades favoritas del modelo: codificación de salida en cada plantilla y respuesta de API (XSS), y entrada de usuario que llega a sentencias de log (inyección en logs).
• Confirma que el agente no relajó las comprobaciones de tipos ni las reglas de lint en CI para que pasara el build.

3. Autenticación, autorización y validación de entradas

• Cada ruta protegida comprueba la identidad en el servidor, no solo en la interfaz.
• Cada acceso a nivel de objeto (por id) comprueba que quien llama es dueño del objeto o puede verlo.
• Las funciones de administración están limitadas por rol, y el rol se lee de la sesión, no del cuerpo de la petición.
• Sesiones y tokens caducan, rotan al cambiar privilegios y se guardan con las banderas HttpOnly y Secure.
• Las contraseñas usan un hash actual (Argon2id, scrypt o bcrypt) sin criptografía propia.
• Toda entrada se valida en la frontera con un esquema (Zod, Pydantic, JSON Schema) y el acceso a base de datos está parametrizado.
• Hay límites de tasa en inicio de sesión, registro, recuperación de contraseña y cualquier endpoint que envíe email o SMS.
• Hay protección CSRF en las peticiones de navegador que cambian estado.

Aquí es donde las apps "vibe-coded" fallan más a menudo, y donde la salida del modelo es más convincente. Lee estos archivos línea por línea.

4. Auditoría de dependencias

• Cada paquete del lockfile existe en el registro público con ese nombre exacto y tiene un historial plausible (antigüedad, mantenedores, descargas).
• Cualquier paquete añadido por primera vez por una herramienta de IA fue comprobado por un humano en la página del registro.
• Ejecuta una herramienta de análisis de composición de software (npm audit, pip-audit, OSV-Scanner, Snyk, Dependabot) y registra los avisos abiertos.
• Las licencias son compatibles con tu forma de distribuir (cuidado con GPL en un SaaS de código cerrado).
• Versiones fijadas y lockfile en el repositorio.

5. Pruebas de lógica de negocio y requisitos

• Escribe los requisitos que el código debía cumplir. Si solo existen en prompts, recupéralos del historial de prompts y congélalos como línea base.
• Para cada requisito, nombra la prueba o comprobación manual que lo demuestra. Los huecos son hallazgos.
• Prueba los casos límite que el modelo tiende a saltarse: listas vacías, envíos duplicados, actualizaciones concurrentes, zonas horarias, redondeo de moneda, fallos parciales en operaciones de varios pasos.
• Comprueba que las pruebas que escribió el agente prueban comportamiento, no solo que una función devuelve sin lanzar error.
• Ejecuta la aplicación de extremo a extremo en un entorno limpio y sigue el dinero: pagar, recibir, reembolsar, facturar.

6. Revisión sénior y firma

• Un ingeniero sénior que no escribió el código lee cada archivo de la lista roja: autenticación, pagos, datos personales, migraciones, superficie de API pública, infraestructura.
• Cada hallazgo tiene severidad, evidencia, responsable y fecha objetivo.
• El revisor registra qué comprobó personalmente y qué muestreó.
• Una persona nombrada firma el informe, con la fecha y el hash del commit auditado.

Escala de severidad a usar

Mantén la escala corta. Cuatro niveles que todos usan valen más que diez en los que nadie coincide.

Cómo se comparan los marcos publicados

A octubre de 2026, las dos estructuras publicadas más citadas son:

Nuestras seis secciones siguen el orden de SolGuruz y toman de MetaCTO la regla de que quien promptó el código no puede ser la única persona que lo aprueba.

Ejecutar la auditoría en cinco pasos

1. Alcance y congelación. Acordad los repositorios, el hash del commit y la línea base de requisitos. Nada se fusiona en la rama auditada hasta que el informe esté firmado.
2. Automatizar primero. Ejecuta SAST, escaneo de secretos y escaneo de dependencias el primer día, para que los humanos dediquen su tiempo a clasificar y no a descubrir.
3. Leer la lista roja. Autenticación, pagos, datos personales, migraciones, API pública, infraestructura. Línea por línea, por alguien que no lo escribió.
4. Probar los requisitos. Asigna cada requisito congelado a una prueba o una comprobación manual. Registra lo que falta.
5. Escribir, firmar, seguir. Un informe, una tabla de severidad, un responsable por hallazgo y un tablero donde las correcciones sean visibles hasta cerrarse.

Para un equipo de tres personas con una base de código de 20.000 líneas, presupuesta una semana laboral: un día para los pasos 1 y 2, dos o tres días para el paso 3, un día para cada uno de los pasos 4 y 5.

Dónde encaja Atrix, y dónde no

Atrix AI no escanea código fuente, no ejecuta análisis estático ni encuentra vulnerabilidades. Lo que hace su agente es una auditoría de requisitos: congelas una línea base de requisitos (desde una página de PRD o una ejecución Develop) y la auditoría informa qué requisitos están cubiertos por trabajo planificado o entregado, cuáles se han desviado y cuáles no tienen responsable. Eso corresponde a la sección 5 de este checklist y a nada más; la página de la función de auditoría de código deja clara esa frontera.

La auditoría de código humana es un servicio distinto. Atrix Digital, la agencia detrás del producto, realiza auditorías de código con personas leyendo el código; eso cubre las secciones 1 a 4 y 6. Dentro de Atrix los hallazgos se convierten en issues dentro de un ciclo, el informe vive como una página con enlace compartido para el cliente, y la plantilla del checklist es una base de datos de página que vas marcando. Es la configuración que usamos en nuestras propias auditorías.

Preguntas frecuentes

¿Qué es una auditoría de código IA?

Una revisión estructurada de código escrito en gran parte por herramientas de IA, que cubre inventario, análisis estático, autenticación y validación de entradas, dependencias, pruebas de lógica de negocio y una revisión sénior, con hallazgos clasificados por severidad y firmados por un revisor nombrado. Añade comprobaciones de paquetes inventados y de requisitos que el modelo descartó en silencio.

¿En qué se diferencia auditar código generado por IA de una revisión de código normal?

Cambian tres cosas. Verificas que las dependencias existen y son lo que dicen ser; recuperas los requisitos de los prompts y pruebas contra ellos, porque el modelo puede haber resuelto un problema ligeramente distinto; y mueves la atención humana a autenticación, pagos y rutas de datos, donde las pruebas de Veracode de 2025 muestran que los modelos fallan más.

¿Cuánto tarda una auditoría de código IA?

Para una base de código de menos de 20.000 líneas con uno o dos servicios, alrededor de una semana laboral de un ingeniero sénior. Las bases de código más grandes escalan con el tamaño de la lista roja, no con el total de líneas.

¿Necesito una auditoría para SOC 2?

SOC 2 no exige una auditoría con ese nombre, pero sus criterios de gestión de cambios esperan evidencia de que los cambios fueron revisados, aprobados y probados por alguien distinto del autor antes de producción. Un informe de auditoría firmado más revisión obligatoria de pull requests es evidencia sólida; un fundador en solitario aprobando la salida de su propio agente no lo es.

¿La Ley de IA de la UE me obliga a auditar código generado por IA?

No directamente. La Ley regula los sistemas de IA por su uso, no por cómo se escribió su código. Pero si tu producto es un sistema de alto riesgo bajo el Anexo III, las obligaciones de documentación técnica y gestión de riesgos, aplicables desde el 2 de diciembre de 2027, son mucho más fáciles de cumplir si puedes demostrar cómo se revisó y probó el código.

¿Puede Atrix AI auditar mi código?

No. Atrix AI audita requisitos contra una línea base congelada; no lee ni escanea código fuente. Para una auditoría de código humana, usa el servicio de la agencia Atrix Digital y haz seguimiento de los hallazgos en Atrix como issues.

Siguiente paso

Copia la plantilla de checklist de auditoría de código en una página, congela tu línea base de requisitos y recorre las seis secciones en orden. Si auditas una base de código que no escribiste, el artículo complementario sobre cómo auditar código generado por IA antes de lanzarlo explica el paso de la línea base con más detalle.

Fuentes

Datos comprobados en octubre de 2026: nota de prensa del informe GenAI Code Security 2025 de Veracode, MetaCTO, Establishing Code Review Standards for AI-Generated Code, SolGuruz, How to Audit AI-Generated Code in 2026, Comisión Europea, marco regulatorio y calendario de la Ley de IA, Spracklen et al., estudio sobre paquetes alucinados, resumido por Xygeni, AICPA Trust Services Criteria.