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 inherentemente más inseguro que el humano — muchos estudios muestran tasas de vulnerabilidades comparables. El problema es que se revisa con menos rigorporque genera una falsa sensación de "ya fue validado por el modelo". Esta guía es sobre cerrar esa brecha de proceso.
El sesgo que hay que corregir primero
Cuando un desarrollador escribe código a mano, típicamente lo revisa mentalmente mientras lo escribe. Cuando un modelo genera código, ese código llega "completo" y con apariencia de estar terminado — lo que reduce la revisión crítica del desarrollador que lo integra. El primer paso no es técnico, es cultural: tratar todo código generado por IA como first draft de un desarrollador junior, nunca como código final.
Paso 1: Checklist de revisión específica para código generado por IA
Además de tu revisión estándar (lógica, estilo, tests), agregá estos puntos específicos:
- Dependencias inventadas o "alucinadas":os modelos a veces sugieren paquetes que no existen o que existen pero no son los que el desarrollador cree (typosquatting de paquetes reales). Verificar cada import contra el registro oficial (npm, PyPI, crates.io) antes de mergear.
- Manejo de secretos hardcodeados:los modelos a veces generan ejemplos con API keys o passwords de muestra que terminan copiados literalmente al código de producción.
- Validación de input ausente o insuficiente:es común que el código generado resuelva el "happy path" y omita sanitización, especialmente en queries SQL o deserialización.
- Permisos por defecto demasiado amplios:si el código genera políticas IAM, reglas de firewall o configuraciones de acceso, revisar que no use wildcards o roles de admin "para que funcione".
- Lógica de autenticación/autorización generada sin contexto completo del sistema:el modelo no conoce tu arquitectura de permisos existente, así que puede generar checks que contradicen o duplican lógica ya existente.
Paso 2: SAST/DAST adaptado, no solo el estándar
Las herramientas de análisis estático (SAST) y dinámico (DAST) que ya usás siguen siendo válidas, pero ajustá la configuración:
- Aumentar sensibilidad en detección de secrets (herramientas como
gitleaks,trufflehog) específicamente en PRs marcadas como asistidas por IA. - Verificación automática de existencia de paquetes en el pipeline de CI antes de instalar dependencias nuevas — un chequeo simple que previene ataques de "slopsquatting" (paquetes maliciosos con nombres que los modelos alucinan con frecuencia).
- Fuzzing dirigido a funciones generadas por IA que manejan input externo, con más iteraciones que en código con historial de producción probado.
Paso 3: Etiquetar el origen del código en el proceso de PR
Para que la revisión adicional se aplique de forma consistente, necesitás saber qué código fue generado por IA:
- Convención de commit o etiqueta de PR (
ai-assisted: true) cuando una porción significativa del cambio vino de un asistente. - Checklist de PR que se activa automáticamente con esa etiqueta, agregando los puntos de revisión de arriba.
- Métricas separadas de "tiempo hasta detección de bug" entre código humano y asistido, para calibrar si el proceso extra está funcionando o es insuficiente.
Paso 4: Casos de alta criticidad: escalar a modelo de frontera
Retomando el framework de arquitectura por capas: código que toca autenticación, manejo de datos sensibles, o infraestructura crítica no debería revisarse solo con el mismo modelo (económico o no) que lo generó. Para estos casos:
- Revisión cruzada con un modelo distinto 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 de un ingeniero senior, sin excepción, independientemente de qué tan bien se vea el código generado.
- Test de penetración dirigido antes de deploy a producción, no solo tests unitarios.
Ejemplo de regla de CI simple
yaml
# .github/workflows/ai-code-review.yml (fragmento ilustrativo)
- name: Check AI-assisted PR
si: contains(github.event.pull_request.labels.*.name, 'ai-assisted')
run: |
gitleaks detect --source . --verbose
./scripts/verify-dependencies-exist.sh
./scripts/check-hardcoded-permissions.shChecklist
- ☐ Establecer convención para etiquetar PRs con código asistido por IA
- ☐ Verificar existencia real de todas las dependencias nuevas antes de mergear
- ☐ Escanear específicamente por secretos hardcodeados en PRs etiquetados
- ☐ Auditar lógica de permisos/autorización generada contra la arquitectura existente
- ☐ Exigir revisión humana senior para código de alta criticidad, sin excepción
- ☐ Medir tasa de bugs post-merge en código asistido vs. 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 colectiva en ciberseguridad (Agosto de 2026). Volver a la guía completa.
