Cómo revisar el código generado por IA con el mismo rigor que el código humano

La carta abierta sobre la defensa cibernética colectiva incluye una frase que muchos equipos de desarrollo aún no han traducido en procesos concretos:

“Eleva el nivel de seguridad de lo que compras, construyes y despliegas”, incluyendo código generado por IA.”

El problema no es que el código generado por IA sea intrínsecamente menos seguro que el código escrito por humanos (muchos estudios muestran tasas de vulnerabilidad comparables). El problema es que se revisa con menos rigor, porque crea una falsa sensación de que “el modelo ya lo ha validado”. Esta guía trata sobre cómo cerrar esa brecha en el proceso.

El sesgo que debes corregir primero

Cuando un desarrollador escribe código a mano, normalmente lo revisa mentalmente mientras lo escribe. Cuando un modelo genera código, este llega “completo” y con aspecto de terminado, lo que reduce la revisión crítica por parte del desarrollador que lo integra. El primer paso no es técnico, es cultural: trata todo el código generado por IA como el primer borrador de un desarrollador junior, nunca como código final.

Paso 1 — Revisar la lista de verificación específica para código generado por IA

Además de tu revisión estándar (lógica, estilo, pruebas), añade estas comprobaciones específicas:

• Dependencias alucinadas o inventadaslos modelos a veces sugieren paquetes que no existen, o que existen pero no son los que el desarrollador piensa (typosquatting de paquetes reales). Verifica cada importación con el registro oficial (npm, PyPI, crates.io) antes de fusionar.
• Secretos incrustados en el código: a veces los modelos generan ejemplos con claves de API o contraseñas de ejemplo que terminan copiándose literalmente en el código de producción.
• Validación de entrada faltante o insuficientees común que el código generado resuelva el “camino feliz” y omita la desinfección, especialmente en consultas SQL o deserialización.
• Permisos predeterminados demasiado ampliossi el código genera políticas de IAM, reglas de cortafuegos o configuraciones de acceso, comprueba que no utilice comodines ni roles de administrador “solo para hacerlo funcionar”.”
• Lógica de autenticación/autorización generada sin el contexto completo del sistemael modelo no conoce tu arquitectura de permisos existente, por lo que puede generar comprobaciones que contradigan o dupliquen la lógica que ya existe.

Paso 2: SAST/DAST adaptado, no solo la configuración estándar

Las herramientas de análisis estático (SAST) y dinámico (DAST) que ya utiliza siguen siendo válidas, pero ajuste la configuración:

• Aumentar la sensibilidad para la detección de secretos (herramientas como gitleaks, trufflehog) específicamente en PRs marcadas como asistidas por IA.
• Verificación automatizada de que los paquetes realmente existen en la canalización de CI, antes de instalar nuevas dependencias: una comprobación sencilla que previene los ataques de “slopsquatting” (paquetes maliciosos con nombres que los modelos alucinan frecuentemente).
• Fuzzing dirigido sobre funciones generadas por IA que manejan entradas externas, con más iteraciones que para el código con un historial de producción establecido.

Paso 3 — Etiquetar el origen del código en el proceso de PR

Para que la revisión adicional se aplique de manera consistente, es necesario saber qué código fue generado por IA:

• Convención de commits o etiqueta de PR (asistido por IA: verdadero) cuando una parte significativa del cambio provino de un asistente.
• Lista de verificación de PR que se activa automáticamente con esa etiqueta, añadiendo los puntos de revisión anteriores.
• Separar las métricas de “tiempo de detección de errores” entre código humano y asistido por IA, para calibrar si el proceso adicional está funcionando o es insuficiente.

Paso 4 — Casos de alta criticidad: escalar a un modelo de frontera

Volviendo al marco de arquitectura por niveles: el código relacionado con la autenticación, el manejo de datos sensibles o la infraestructura crítica no debe ser revisado únicamente por el mismo modelo (de bajo costo o de otro tipo) que lo generó. Para estos casos:

• Revisión cruzada con un modelo diferente al que generó el código (reduce el riesgo de que el mismo “punto ciego” del modelo pase desapercibido dos veces).
• Revisión humana obligatoria por un ingeniero sénior, sin excepciones, sin importar cuán pulido se vea el código generado.
• Pruebas de penetración dirigidas antes de la implantación en producción, no solo pruebas unitarias.

Ejemplo de una regla de CI simple

yaml

# .github/workflows/ai-code-review.yml (fragmento ilustrativo)
- nombre: Revisar PR asistido por IA
  si: contains(github.event.pull_request.labels.*.name, 'asistido por IA')
  correr: |
    gitleaks detect --source . --verbose
    ./scripts/verify-dependencies-exist.sh
    ./scripts/check-hardcoded-permissions.sh

Lista de verificación

• ☐ Establecer una convención para etiquetar los PR con código asistido por IA
• ☐ Verificar la existencia real de todas las nuevas dependencias antes de fusionar
• ☐ Escanear específicamente en busca de secretos hardcodeados en PRs etiquetados
• ☐ Auditar la lógica de permisos/autorización generada en relación con la arquitectura existente
• ☐ Exigir revisión humana sénior para código de alta criticidad, sin excepciones
• ☐ Medir la tasa de errores posteriores a la fusión en código asistido por IA frente a código humano para calibrar el proceso

Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa cibernética colectiva (Agosto de 2026). Volver a la guía completa.