AI code review: política para revisar código generado por IA

Una política de AI code review impone una regla innegociable al equipo: la IA puede escribir y examinar código, pero una persona identificada responde por el merge. Todo cambio asistido por IA debe declarar cómo se utilizó, superar controles deterministas y recibir una revisión humana acorde con el daño que podría causar.

Hoy esa separación es crucial. El 17 de agosto de 2026, Wiz reveló una vulnerabilidad crítica de inyección en GitHub Actions dentro de un repositorio público de Snowflake. El commit squash final reconocía a Copilot Autofix como coautor y la revisión de seguridad asistida por IA de GitHub dio el cambio por seguro. Wiz aclaró expresamente que se desconoce si la modificación del código contó con asistencia de IA. Cinco días después de que la vulnerabilidad llegara a producción, un agente de seguridad autónomo la encontró y la explotó durante una prueba autorizada.

Las cifras del negocio explican por qué los equipos siguen queriendo automatizar. Un equipo que procesa 50 pull requests por semana y dedica 30 minutos a una primera revisión humana consume 25 horas de ingeniería. Con un costo total ilustrativo de $120 por hora, son $3,000 semanales antes de una revisión más profunda. GitHub estima actualmente que una revisión de Copilot cuesta entre $0.05 y $1 en créditos de IA con el nivel Lite, o entre $0.25 y $5 con Balanced, más los minutos de GitHub Actions. La primera pasada se está abaratando. La autoridad para aprobar, no.

Qué hace en la práctica una política de AI code review

Una buena política regula el tránsito del código; no prohíbe la IA. Indica a los autores qué deben declarar, define qué debe bloquear la automatización y establece cuándo es obligatorio un segundo par de ojos humanos.

Imagine cada pull request como una carga que entra en un puerto. Las pruebas y los escáneres inspeccionan el contenedor. Un revisor de IA lee el manifiesto y señala elementos sospechosos. Aun así, un funcionario humano decide si la carga cruza la frontera. Entregar al instrumento de inspección el sello del funcionario anula el control.

Este puede ser el núcleo de la política:

El código creado o modificado de forma sustancial con una herramienta de programación basada en IA solo puede incorporarse mediante un pull request. El autor sigue siendo responsable de entender el cambio y debe identificar la herramienta, el alcance de la asistencia de IA, las pruebas ejecutadas y al responsable humano. Las pruebas y los controles de seguridad obligatorios deben superarse antes de la aprobación. La revisión de IA es orientativa y nunca cuenta como una aprobación humana obligatoria. Los archivos sensibles requieren un responsable del código. Los cambios críticos exigen un segundo aprobador independiente y un plan de reversión. Cada commit nuevo invalida la aprobación anterior y activa otra revisión.

La política se basa en las consecuencias, no en detectar la autoría. Un desarrollador no debería tener que demostrar qué líneas concretas proceden del autocompletado. Debe declarar toda asistencia sustancial de IA y asumir la responsabilidad por el diff completo. Eso aporta más que discutir un porcentaje que ninguna herramienta puede convertir en una decisión de aprobación.

Use tres niveles de revisión

El nivel Crítico es costoso a propósito. Debería abarcar solo una pequeña parte de los cambios. La idea es concentrar la escasa atención de los perfiles sénior allí donde un error que parece plausible puede exponer credenciales, corromper datos o modificar quién tiene acceso.

Cómo funciona, sin jerga

El flujo tiene seis controles. Cada uno produce evidencia que el siguiente revisor puede inspeccionar.

1. Declare la asistencia. Añada al template del pull request los campos AI-assisted, tool, scope, human owner y tests run. El autor responde por cada línea, tanto si la IA escribió una función como si preparó el primer borrador completo.
2. Clasifique el riesgo. Un pequeño archivo de políticas asigna rutas y tipos de cambio a los niveles Rutinario, Sensible o Crítico. Un cambio en .github/workflows/ nunca debería compartir nivel con la corrección de un error tipográfico en la documentación.
3. Ejecute primero los controles deterministas. Determinista significa que la misma entrada siempre produce el mismo aprobado o rechazado. Compile, compruebe tipos, ejecute el linter y las pruebas, busque secretos, examine dependencias y realice análisis estático de seguridad antes de pedir una opinión a otro modelo. La propia guía de revisión de GitHub sitúa primero las pruebas automatizadas y el análisis estático.
4. Use la IA como crítica. Pídale que busque casos omitidos, incompatibilidades arquitectónicas, pruebas eliminadas, API inventadas, paquetes sospechosos y cambios de permisos. Aplique una revisión más exhaustiva al trabajo sensible para la seguridad o que atraviesa varios servicios. La autorrevisión del agente que escribió el código no debe bastar para superar el control.
5. Haga que una persona emita el veredicto. El revisor confirma la intención, prueba el comportamiento arriesgado, cuestiona las dependencias nuevas y decide si el diff debe formar parte del sistema. Los comentarios de la IA son pistas, no hallazgos, hasta que los confirme una persona o una herramienta determinista.
6. Reinicie el proceso tras cada push. Descarte aprobaciones obsoletas, vuelva a ejecutar los controles obligatorios y solicite otra revisión cuando lleguen commits nuevos. GitHub señala que la revisión automática de Copilot suele ejecutarse una sola vez, salvo que se active la revisión en cada push.

La política debe incluir otros dos controles menos evidentes. Primero, los archivos de dependencias necesitan un escáner propio porque la revisión de código de GitHub Copilot excluye archivos como package.json y Gemfile.lock. Segundo, los cambios en archivos de instrucciones para IA requieren revisión crítica. Copilot lee las instrucciones del repositorio, las instrucciones de agentes y las skills desde la rama de origen del pull request; por tanto, el cambio propuesto puede alterar las instrucciones con las que se revisa a sí mismo.

Siete contextos donde esta política genera valor primero

1. Equipos de plataforma que operan agentes de programación en muchos repositorios

Los equipos de ingeniería de plataforma son los que más ganan, porque una sola política puede gobernar miles de cambios futuros. Coloque el mapa de riesgos en un template compartido, exija los mismos campos de declaración y publique un único control de estado que todas las ramas protegidas entiendan. El beneficio es un control centralizado sin obligar a cada equipo de producto a diseñar su propio ritual. Los equipos que comparen los mejores agentes de programación con IA para empresas podrán cambiar de herramienta sin reconstruir el modelo de aprobación.

2. Equipos de SaaS que protegen autenticación, facturación y datos de clientes

El responsable de ingeniería de un SaaS puede marcar como Críticos la autenticación, los controles de permisos, el código de pagos y las rutas de exportación de datos. Un agente puede redactar una corrección y un revisor de IA puede cuestionarla, pero deben aprobarla el responsable de identidad o pagos y otra persona. El beneficio es el enfoque: los revisores sénior dejan de dedicar el mismo tiempo a todos los archivos y se concentran en cambios con un radio de impacto real.

3. Equipos DevOps que mantienen flujos de CI/CD

Trate los archivos de workflow como infraestructura de producción ejecutable. Envíe cada cambio a un responsable DevOps, busque interpolaciones directas de contenido no confiable procedente de issues o pull requests, verifique los permisos de tokens y exija un plan de reversión. El caso de Wiz concreta el beneficio: el título de un issue público llegó a un comando de shell y el token expuesto podía leer proyectos internos de Jira. La política detecta esa clase de error antes de que alguien discuta si el autor original fue una persona o una IA.

4. Líderes de ingeniería que despliegan Copilot, Codex o Claude Code

El responsable del despliegue puede separar el permiso para usar la herramienta del permiso para hacer merge. Los desarrolladores obtienen generación rápida y una primera revisión, mientras las reglas de las ramas siguen exigiendo aprobación humana, workflows correctos y revisión del responsable del código. El beneficio es una adopción respaldada por un sistema de control auditable. Un análisis de los modos de revisión local y en GitHub de Codex puede orientar la elección de herramienta, pero el mismo control humano debe sobrevivir a un cambio de proveedor.

5. Mantenedores de código abierto ante pull requests con poco contexto

Añada a CONTRIBUTING.md una casilla sobre asistencia de IA y una lista de evidencias; después, permita que la automatización rechace contribuciones sin pasos para reproducir el problema, pruebas o un mantenedor responsable. La IA puede resumir y prefiltrar la cola. Las personas dedican su tiempo a la intención, la compatibilidad y a decidir si la contribución encaja en el proyecto. El beneficio es menos deuda de revisión sin rebajar silenciosamente el estándar para desconocidos.

6. Agencias que entregan software propiedad del cliente

Una agencia puede adjuntar a cada versión un comprobante de revisión con las herramientas utilizadas, los componentes afectados, los resultados de las pruebas, los hallazgos pendientes y los aprobadores identificados. Las rutas sensibles del cliente pasan por su responsable del código antes del lanzamiento. El beneficio es una rendición de cuentas más clara y un documento de entrega que perdura cuando el equipo se marcha.

7. Fundadores en solitario que publican con un agente de programación con IA

Un fundador sin equipo no dispone por defecto de un colega independiente, así que el flujo debe crear esa separación. Deje que un modelo redacte, ejecute controles deterministas, use una revisión distinta y después pruebe personalmente la ruta arriesgada antes del merge. Para pagos, autenticación o infraestructura de producción, recurra a un especialista externo. El beneficio es un primer filtro barato sin fingir que un segundo modelo equivale a una segunda persona responsable.

Qué productos se podrían construir a partir de esta política

El mercado ya paga por la revisión automatizada. La demanda en Google ronda las 1,600 búsquedas mensuales en Estados Unidos para "ai powered code review platform", 1,300 para "ai code review" y 590 para "ai code review tools". CodeRabbit cobra actualmente $24 por desarrollador al mes en los planes Pro anuales y $48 en Pro Plus. Qodo parte de $30 al mes. La oportunidad no consiste en lanzar otro bot que comente cada pull request, sino en crear una capa de control que determine qué revisión cuenta de verdad.

1. Control de pull requests con políticas como código: la oportunidad más sólida

Cree una GitHub App para responsables de ingeniería y seguridad que convierta un archivo breve de políticas en controles obligatorios. La aplicación lee las rutas modificadas, verifica la declaración de uso de IA, asigna un nivel de riesgo, solicita a los responsables del código adecuados, confirma que se ejecutaron los escáneres obligatorios, invalida aprobaciones obsoletas y genera un comprobante de auditoría.

La demanda respalda la categoría: "ai powered code review platform" recibe alrededor de 1,600 búsquedas mensuales en Estados Unidos, mientras "ai code review" obtiene 1,300 con un CPC de $63.85. La versión mínima vendible necesita una GitHub App, un archivo de políticas del repositorio, un control de estado, un servicio de asignación de revisores y una tabla de auditoría. El obstáculo es la fatiga de configuración. El producto solo triunfará si ofrece buenos valores predeterminados para stacks habituales y permite explicar fácilmente las excepciones.

2. Enrutador de revisores para archivos críticos

Cree una herramienta más específica para equipos de plataforma y AppSec. Vigila rutas como workflows, infraestructura, migraciones, autenticación y archivos de políticas; después eleva la exhaustividad de la revisión, convoca al responsable correcto y exige una nueva revisión tras cada push. Puede enviar el código rutinario a una revisión barata y reservar el razonamiento costoso y el tiempo humano para los diffs críticos.

"AI code review tools" recibe unas 590 búsquedas mensuales en Estados Unidos, tiene intención comercial y muestra una tendencia anual del 50% en el conjunto de datos de palabras clave. "Secure code review" aporta otras 170 búsquedas mensuales con un CPC de $50.19. El MVP consiste en reglas por rutas, integración con CODEOWNERS, una interfaz de ejecuciones de controles y enrutamiento de revisiones según el presupuesto. El riesgo es extenderse demasiado. Debe complementar SAST, el escaneo de secretos y el análisis de dependencias, no presentarse como sustituto.

3. Comprobante de procedencia de cambios realizados con IA

Cree una CLI ligera y un bot para pull requests dirigido a agencias y equipos regulados. Registra la herramienta declarada, el identificador de sesión, los archivos modificados, las pruebas ejecutadas, las decisiones de los revisores y al responsable humano final; luego emite un comprobante firmado para la versión. Debe demostrar el proceso, no intentar adivinar la autoría a partir del estilo del código.

Unas 210 búsquedas mensuales en Estados Unidos corresponden a "ai generated code detector", con un CPC de $16.70. La demanda revela una inquietud real, pero la detección es una promesa de producto equivocada. La versión comercializable ofrece a los compradores evidencia de revisión y responsabilidad. El obstáculo es la participación: si los equipos pueden omitir la declaración, el comprobante se convierte en puro teatro. La protección de ramas y la integración de identidades son el producto, no extras opcionales.

También existe un vacío de fuentes citadas. La comprobación de citas de ChatGPT no encontró fuentes recurrentes para "ai code review tools". Un producto que publique un esquema de políticas riguroso y versionado, junto con controles transparentes, puede convertirse en la capa de referencia mientras vende el producto que aplica esas reglas.

Límites y una valoración honesta

La revisión de IA es un filtro útil, no una garantía de seguridad. GitHub advierte que la revisión de Copilot puede pasar problemas por alto y debe complementarse con revisión humana. También excluye algunos archivos, puede recurrir a un modo menos capaz cuando los runners no están disponibles y se detiene al agotarse el presupuesto de créditos de IA. Ninguna de esas circunstancias debería rebajar silenciosamente el estándar para hacer merge.

La corrección autónoma tiene el mismo límite. El sistema en vista previa pública de GitHub puede explorar un repositorio, proponer una corrección, volver a ejecutar CodeQL y abrir un pull request en borrador, a menudo en dos a cuatro minutos. GitHub también indica que funciona según el mejor esfuerzo, que no puede confirmar correcciones para algunas consultas personalizadas o ampliadas para seguridad y que no garantiza la calidad de las correcciones para alertas de terceros. Que una nueva ejecución aparezca en verde solo demuestra que un detector dejó de quejarse. No prueba que el comportamiento de negocio, el modelo de permisos o el workflow circundante sean seguros.

Esta política no resuelve la detección de autoría, las pruebas débiles, la falta de conocimiento arquitectónico ni una cultura que aprueba pull requests sin criterio. También resultará demasiado pesada si cada error tipográfico entra en el nivel Crítico. Mantenga barato el nivel Rutinario, mantenga pequeño el Crítico y nunca convierta a la herramienta que produjo un cambio en la única autoridad que puede aprobarlo.

La acción para el lunes

El lunes, un responsable de ingeniería debería añadir cinco campos al template del pull request: asistencia de IA, herramienta, alcance, responsable humano y pruebas ejecutadas. Después debe marcar .github/workflows/, autenticación, pagos, infraestructura de producción, secretos y migraciones destructivas como Críticos. Exija CI correcta, revisión del responsable del código, descarte de aprobaciones obsoletas y una segunda persona para esas rutas. Basta para convertir una opinión sobre el código generado por IA en una primera versión aplicable.

¿Debo revisar el código generado por IA?

Sí. Ejecute primero pruebas y escáneres deterministas, use la revisión de IA como una crítica adicional y haga que una persona identificada responda por el merge. La revisión de IA no debe satisfacer la regla de aprobación humana obligatoria.

¿Puede ChatGPT hacer una revisión de código?

Puede cuestionar un diff, pedir las pruebas que falten y señalar lógica sospechosa. No puede aplicar la protección de ramas, demostrar que la CI se ejecutó ni asumir las consecuencias en producción. Úselo dentro de la política, no en lugar de ella.

¿Cuál es la mejor IA para revisar código?

La mejor opción es la que entiende suficiente contexto del repositorio, se integra con los controles existentes, respeta las políticas de datos y deja un registro de auditoría claro. La calidad del modelo importa, pero importan más la integración con el control de merge y la responsabilidad humana.

¿Existe una herramienta gratuita para revisar código con IA?

Hay componentes gratuitos o incluidos. El Copilot Autofix clásico de GitHub no exige una suscripción a Copilot ni consume créditos de IA en los repositorios elegibles, y las herramientas de CI existentes pueden aplicar muchos controles deterministas. Una política completa sigue necesitando configuración y revisión humana.

Si quiere integrar este control de revisión en su flujo de ingeniería, consulte los sistemas de IA para producción.