¿Cuánta revisión humana necesita el código asistido por IA?

La IA puede acortar el tiempo necesario para redactar un cambio, pero no reduce la lista de cosas que pueden salir mal en producción. La revisión humana debe crecer según el alcance del daño del cambio, la sensibilidad del código y la solidez de las pruebas adjuntas a la solicitud de cambios. La cantidad de texto que escribió una IA es casi irrelevante.

Yo uso cuatro niveles de revisión. Un cambio pequeño y reversible en un componente aislado puede requerir un revisor competente y pruebas específicas. Un cambio que afecta a identidad, dinero, datos sanitarios, permisos, despliegue o una dependencia compartida necesita revisores independientes que entiendan ese ámbito, pruebas más amplias, evidencia de seguridad y una decisión explícita de publicación. Esto no es desconfianza hacia la IA. Es el control normal de ingeniería aplicado a una fuente que puede producir código convincente más rápido de lo que un equipo puede inspeccionarlo.

La política útil cabe en un repositorio, se ejecuta en integración continua y dice a los autores qué evidencia deben aportar. Una política que afirma que cada cambio con IA necesita un cuidado especial acabará convertida en una aprobación de casilla. Una política que relaciona hechos observables con controles concretos puede resistir un día de publicación con mucho trabajo.

Revisa la consecuencia, no al autor

El nivel de revisión correcto depende de lo que el cambio pueda afectar, no de si una persona lo escribió, copió, generó o revisó después de generarlo. La procedencia sigue importando porque los revisores deben saber qué se verificó de forma independiente. No sustituye la clasificación del riesgo.

Empieza con dos ejes: tamaño del cambio y sensibilidad del código. El tamaño incluye más que las líneas modificadas. Cuenta el número de componentes atravesados, las interfaces públicas alteradas, las migraciones de datos introducidas, los archivos generados reemplazados, los ámbitos de configuración cambiados y las rutas de ejecución afectadas. Un cambio de doce líneas en autorización puede suponer más riesgo que dos mil líneas de datos de prueba. El tamaño del diff orienta la asignación, pero no mide la seguridad.

La sensibilidad pregunta qué autoridad tiene el código y qué daño podría causar un error. Considera sensibles la autenticación, la autorización, la criptografía, los secretos, la facturación, los datos personales, los flujos clínicos, los permisos de infraestructura, las canalizaciones de compilación, los manifiestos de dependencias y las operaciones destructivas sobre datos. Añade áreas propias del producto, como las reglas de derechos o los límites de seguridad. Mantén esta lista bajo control de versiones para que un autor no pueda reinterpretarla en silencio cuando apriete una fecha de entrega.

La reversibilidad es el tercer dato que cambia la respuesta. Una etiqueta incorrecta en una página detrás de una función controlada puede desactivarse en minutos. Una migración que elimina columnas, un evento publicado para consumidores externos o una credencial expuesta en un registro no pueden retirarse limpiamente. Eleva el nivel cuando la reversión dependa de restaurar datos, coordinar a otro equipo o pedir a los clientes que actúen.

Un clasificador práctico registra estos datos en la solicitud de cambios en vez de pedir una valoración imprecisa del riesgo:

• ¿Qué servicios, almacenes de datos e interfaces públicas cambian?
• ¿El código toma o aplica una decisión de seguridad o de negocio?
• ¿Puede el equipo revertirlo sin perder ni reprocesar datos?
• ¿Modifica dependencias, instrucciones de compilación o permisos de despliegue?
• ¿Qué evidencia demuestra que el comportamiento modificado funciona y que el anterior sigue funcionando?

No dejes que los autores elijan un nivel bajo solo por intuición. Las reglas del repositorio pueden elevar un cambio automáticamente cuando aparecen rutas protegidas, carpetas de migraciones, manifiestos de paquetes, archivos de infraestructura o un diff grande. Un revisor también puede elevarlo después de leer el diseño. Bajar el nivel debe exigir una razón registrada y el nombre de quien la aprobó.

Cuatro niveles hacen utilizable la política

Cuatro niveles bastan para la mayoría de los equipos. Más categorías crean discusiones sobre etiquetas, mientras que menos obligan a que el trabajo rutinario y el peligroso pasen por el mismo control. Los nombres importan menos que las condiciones de entrada y la evidencia exigida.

El nivel 1 cubre cambios limitados y reversibles. Algunos ejemplos son textos, estilos aislados, datos de prueba, comentarios y pequeñas refactorizaciones internas que no cambian el comportamiento. Exige la compilación normal, el análisis de estilo, las pruebas unitarias pertinentes y un revisor que conozca el área o sea responsable de ella. La fusión automática puede ser aceptable después de la aprobación si la protección de la rama impide que el autor apruebe el cambio y todas las comprobaciones obligatorias terminan bien.

El nivel 2 cubre el comportamiento habitual de producción. Incluye lógica acotada de funciones, comportamiento de API que conserva el contrato, correcciones en código consolidado y cambios modestos de configuración. Exige un revisor independiente, pruebas específicas del comportamiento modificado, el conjunto completo de pruebas afectadas, análisis estático, búsqueda de secretos y una revisión limpia de dependencias. La solicitud debe explicar qué produjo la IA, qué cambió el autor después y qué afirmaciones verificó sin depender de la explicación generada.

El nivel 3 cubre cambios sensibles o amplios. Lleva aquí identidad, control de acceso, flujo de pagos, información sanitaria, migraciones, bibliotecas compartidas, políticas de despliegue, contratos públicos y cambios que abarcan varios componentes. Exige dos revisores, incluido un responsable del dominio; añade pruebas de integración o de extremo a extremo en el límite donde está el riesgo; ejecuta análisis de seguridad apropiados para el lenguaje; inspecciona los cambios de dependencias y archivos de bloqueo; y exige un plan de despliegue y reversión. El segundo revisor no debe repetir al primero. Asigna a uno el comportamiento y el diseño, y al otro la seguridad, los datos o las operaciones.

El nivel 4 cubre cambios con consecuencias graves o difíciles de revertir. Algunos ejemplos son el diseño criptográfico, los límites de privilegios, la transformación masiva de datos, las políticas de identidad en producción, la confianza en la compilación, el apoyo a decisiones clínicas y un nuevo intercambio externo de datos. Exige una revisión del diseño antes de implementar, responsables concretos de los dominios afectados, modelado de amenazas, pruebas contra usos indebidos y fallos, evidencia de publicación gradual y una persona explícita que acepte el riesgo residual. Algunos equipos también exigen un responsable de publicación o un comité de cambios. Úsalo solo cuando esa persona tenga el contexto y la autoridad para detener la publicación; una aprobación ceremonial añade demora sin aportar control.

Una política legible por máquinas mantiene visible la relación entre condiciones y niveles. Este ejemplo es sencillo a propósito para que cada equipo lo adapte a su sistema de CI:

review_tiers:
  tier_1:
    approvals: 1
    checks: [build, lint, unit]
  tier_2:
    approvals: 1
    checks: [build, unit, affected_suite, static_analysis, secrets, dependencies]
  tier_3:
    approvals: 2
    required_roles: [code_owner, domain_owner]
    checks: [tier_2, integration, security_scan, rollback_test]
  tier_4:
    approvals: 3
    required_roles: [code_owner, security_owner, release_owner]
    checks: [tier_3, threat_model, misuse_tests, staged_release]
protected_paths:
  tier_3: [auth/, billing/, migrations/, infra/, package-lock.json]
  tier_4: [crypto/, production/identity/, clinical/decision-support/]

Esto evita un fallo habitual: un autor etiqueta un cambio de permisos como pequeño porque el diff tiene ocho líneas, obtiene una aprobación rápida y publica una rama que concede acceso cuando falla una consulta. Una ruta protegida eleva el nivel antes de que alguien discuta el número de líneas. Después, las pruebas deben cubrir la denegación, los datos ausentes y el fallo del servicio, no solo la solicitud correcta.

Las pruebas deben demostrar la afirmación arriesgada

El número de pruebas dice poco sobre si un cambio está listo para revisión. La pregunta útil es si las pruebas fallarían ante los defectos plausibles que puede introducir ese cambio concreto. El código generado suele llegar con pruebas generadas que confirman la misma suposición equivocada. Un conjunto en verde puede mostrar coherencia interna entre dos artefactos erróneos.

Exige que el autor explique la afirmación arriesgada con palabras sencillas y la conecte después con evidencia. Para una comprobación de acceso, la afirmación podría ser que solo los profesionales clínicos asignados a un caso pueden ver su historial. La evidencia debe cubrir a un profesional asignado, otro no asignado, un usuario sin función clínica, una respuesta ausente del servicio de asignación y una sesión caducada. Una prueba que demuestra que el profesional asignado entra solo cubre el caso favorable.

Los revisores deben hacer una mutación mental o real en el código: cambiar && por ||, eliminar el filtro de inquilino, devolver éxito ante una excepción o hacer que pase una colección vacía. Si las pruebas propuestas siguen en verde, no protegen la decisión. Las herramientas de pruebas de mutación pueden automatizar una parte, pero una mutación manual de cinco minutos suele bastar para descubrir una prueba generada que solo repite la implementación.

Ejecuta las pruebas en el nivel más estrecho que pueda refutar la afirmación y añade pruebas de límites donde los componentes puedan discrepar. Las pruebas unitarias funcionan bien para ramas e invariantes. Las pruebas de contrato detectan supuestos incompatibles sobre solicitudes y respuestas. Las de integración exponen restricciones de base de datos, límites de transacciones, colas, cachés y middleware de identidad. Reserva las pruebas de extremo a extremo para un conjunto pequeño de recorridos cuyo fallo bloquearía la publicación. Obligar a todos los niveles a ejecutar todas esas pruebas desperdicia tiempo y enseña a los equipos a ignorar resultados lentos e inestables.

Revisa las pruebas con el mismo cuidado que el código de producción. Busca simulaciones que evitan la capa de permisos, datos de prueba sin valores nulos realistas, aserciones que solo comprueban códigos de estado, instantáneas que aceptan muchos cambios ajenos y reintentos que esconden condiciones de carrera. La IA produce con especial facilidad un volumen de pruebas impresionante alrededor de una interfaz que entendió mal.

El autor debe adjuntar los comandos exactos que usó cuando CI todavía no aplica una comprobación local. Un revisor puede reproducir una ejecución concreta y ver un resultado con esta forma:

$ npm test access-policy.test.ts
PASS access-policy.test.ts
  assigned clinician can read (18 ms)
  unassigned clinician is denied (7 ms)
  missing assignment response fails closed (9 ms)
Tests: 3 passed, 3 total

El resultado solo es evidencia si lo produjo el commit de la solicitud. Prefiere artefactos de CI ligados al commit frente a capturas pegadas. En los niveles 3 y 4, conserva informes de pruebas, resultados de análisis y registros de aprobaciones junto con la publicación para que quien investigue un incidente pueda reconstruir lo que sabía el equipo.

El código sensible necesita una mirada de seguridad independiente

Una revisión general de código y una revisión de seguridad responden a preguntas distintas. La primera pregunta si la implementación es correcta y mantenible. La segunda pregunta cómo un atacante, una dependencia comprometida, una entrada maliciosa o un actor interno con demasiados privilegios puede hacer que el sistema incumpla sus requisitos de seguridad. Reunir ambas en una sola casilla oculta la diferencia.

OWASP Application Security Verification Standard ofrece a los equipos un vocabulario útil para este trabajo. ASVS define niveles de verificación con un rigor creciente y agrupa requisitos en áreas como autenticación, control de acceso, validación, criptografía, registros, protección de datos, API y configuración. Yo no copiaría todo el estándar en cada solicitud. Relaciona las rutas sensibles del producto con los requisitos aplicables y muestra esos requisitos cuando un cambio las afecte.

NIST SP 800-218 plantea algo parecido en su Secure Software Development Framework. Su práctica de revisión del diseño pide una persona cualificada que no haya intervenido en el diseño, procesos automatizados dentro de las herramientas o ambas cosas, y solicita registrar los hallazgos como artefactos. La cualificación importa. Una segunda aprobación al azar no cumple la intención cuando ninguno de los revisores entiende el límite de confianza que cambia.

El análisis estático de seguridad de aplicaciones, la búsqueda de secretos y el análisis de dependencias son controles útiles, pero no pueden decidir si un enfermero debe ver el historial de un paciente concreto ni si una regla de reembolsos permite abusos. Las herramientas encuentran patrones. Las personas deben inspeccionar la autorización de negocio, el aislamiento entre inquilinos, el comportamiento ante fallos, el significado de la auditoría y la relación entre los datos recogidos y los realmente necesarios.

Para un cambio de seguridad de nivel 3, exige un caso de abuso breve junto al caso normal de aceptación. Un buen caso de abuso identifica a un actor, la capacidad que no debe tener, la ruta que podría probar y el control que lo detiene. Por ejemplo: un usuario de soporte cambia el identificador de cuenta en una solicitud; la autorización en el servidor rechaza la solicitud antes de consultar el registro; la entrada de auditoría guarda el intento denegado sin almacenar la carga sensible.

El nivel 4 necesita un modelo de amenazas antes de que modificar la implementación resulte caro. Hazlo concreto: activos, límites de confianza, puntos de entrada, capacidades del atacante, controles y decisiones pendientes. El responsable de seguridad debe revisar el modelo y el código, mientras que el responsable del servicio verifica supuestos operativos como la disponibilidad de identidad, el comportamiento del reloj, la conservación de datos y la reversión.

No apruebes código sensible porque la IA lo explica de forma convincente. Las explicaciones generadas pueden justificar la implementación recibida, incluso si está mal. Vincula cada afirmación de seguridad con una prueba, una configuración, una decisión de diseño revisada o un comportamiento observado de la plataforma.

Los cambios de dependencias incluyen código que no ves en el diff

Una modificación de una línea en un manifiesto puede añadir miles de líneas ejecutables mediante dependencias directas e indirectas. Por eso, los cambios de dependencias son una dimensión propia de la revisión, no una pequeña variante de la revisión de código fuente. Eleva cualquier dependencia nueva de ejecución y cualquier reescritura relevante del archivo de bloqueo al menos al nivel 2. Súbela más si el paquete se ejecuta durante la compilación, procesa datos no fiables, recibe secretos o se usa en un servicio sensible.

Una comprobación de dependencias debe responder qué paquetes se añadieron, eliminaron y actualizaron; si cambiaron paquetes indirectos; si existen vulnerabilidades conocidas aplicables; qué licencias entran en el producto; y si el registro y la identidad del paquete esperados coinciden. La revisión de dependencias de GitHub, por ejemplo, compara los cambios entre los commits base y final y puede aplicar un umbral de fallo en una solicitud. Otros sistemas de alojamiento tienen alternativas. El resultado de la política importa más que el proveedor.

No aceptes un diff enorme del archivo de bloqueo con la explicación de que lo creó el gestor de paquetes. Genéralo de nuevo a partir del manifiesto declarado con la versión fijada del gestor del repositorio y compara el resultado. Las URL de registro inesperadas, los scripts del ciclo de vida, los nombres de paquetes parecidos, los cambios de integridad y las actualizaciones ajenas merecen una investigación.

Las dependencias nuevas también necesitan una comprobación humana de necesidad. Los equipos suelen añadir un paquete porque el código generado lo importa y después solo revisan si tiene una vulnerabilidad publicada. Pregunta si la biblioteca estándar o una dependencia existente ya resuelve la tarea, si el paquete tiene mantenimiento activo, qué código ejecuta durante la instalación y cuánto costaría eliminarlo. Las bases de datos de vulnerabilidades informan de defectos conocidos; no pueden decirte que un paquete amplía la confianza sin necesidad.

Para publicaciones de nivel 3 y 4, conserva una lista de materiales de software cuando el sistema de compilación pueda producirla y guarda la procedencia del artefacto compilado. SLSA entiende la procedencia como información verificable sobre dónde, cuándo y cómo se produjo un artefacto. Eso no demuestra que el código sea seguro, pero permite al revisor conectar el artefacto desplegado con el código fuente y el proceso de compilación revisados.

Los aprobadores explícitos evitan firmas automáticas

Dos aprobaciones no ayudan si ambos revisores suponen que el otro comprobó seguridad, comportamiento de datos y despliegue. Cada aprobación obligatoria debe tener un aspecto asignado. Los responsables del código pueden dirigir un cambio hacia personas concretas, pero la plantilla de la solicitud debe decir a cada una qué decisión le corresponde.

Usa funciones que coincidan con el riesgo: responsable de implementación, de dominio, de seguridad, de datos y de publicación. Un cambio de nivel 2 puede necesitar solo un responsable de implementación. Una migración que cambie datos de pacientes podría necesitar que un responsable del dominio compruebe el significado, uno de datos verifique la migración y la recuperación, y uno de seguridad o privacidad revise la exposición. Una persona puede ocupar dos funciones si tiene la cualificación necesaria, pero el registro debe indicarlo.

El autor no puede aportar la aprobación independiente. Tampoco debe considerarse independiente a quien dio las instrucciones a la IA solo porque el modelo produjo el código. El autor responde del cambio: entenderlo, editarlo, probarlo y explicar sus límites. Si no puede explicar una rama o dependencia, la revisión debe detenerse hasta que pueda.

Los comentarios de aprobación deben registrar una decisión, no una muestra social de confianza. Una aprobación útil de nivel 3 podría decir: revisé el aislamiento de inquilinos en las capas de consulta y servicio; reproduje la denegación para un usuario de otro inquilino; comprobé la reversión de la migración con una copia de datos representativos; acepto el riesgo restante de que revertir exija una breve pausa de escritura. Esa nota aporta algo concreto al responsable de publicación y a quien investigue un incidente en el futuro.

Descarta las aprobaciones cuando el autor suba un cambio material después de la revisión. Define lo material de forma mecánica siempre que puedas: cambios en rutas protegidas, archivos de dependencias, migraciones, permisos o un diff mayor que el pequeño límite configurado. Corregir una errata en un comentario no debe reiniciar una revisión de tres personas, pero un nuevo manejador de errores en una ruta de autorización sí.

Evita la aprobación por agotamiento. Las solicitudes grandes generadas son difíciles de revisar porque el modelo puede producirlas rápido y el revisor sigue leyendo a velocidad humana. Fija un límite de tamaño revisable y exige al autor que separe los cambios independientes o aporte una secuencia de commits que distinga las ediciones mecánicas del comportamiento. No reduzcas el examen porque dividir el cambio resulte incómodo. Si el código no se puede separar, eleva el nivel y reserva tiempo de revisión concentrada.

Un equipo distribuido también necesita un traspaso claro. Registra qué comprobaciones faltan, quién puede aprobarlas y si el despliegue está bloqueado. SaaS Production usa ingenieros con experiencia para controlar su proceso de desarrollo asistido por IA, una división del trabajo acertada: la IA acelera la producción y las personas conservan las decisiones que exigen contexto y responsabilidad.

El resultado de la IA exige comprobar más que el diff

Los revisores deben inspeccionar los supuestos que rodean al código generado, no solo su sintaxis. La IA puede llamar a una API inexistente, usar una API real con la versión equivocada, inventar un campo de configuración, copiar un patrón de seguridad anticuado o ampliar en silencio el comportamiento solicitado. El código resultante puede compilar si las simulaciones o los tipos flexibles ocultan el error.

Pide al autor que declare el uso de IA en el nivel del cambio, no que enumere cada sugerencia aceptada. El registro útil indica qué archivos o funciones se generaron en buena medida, qué modelo aportó el borrador si la política exige ese dato, qué material externo entró en las instrucciones y qué comprobó el autor de forma independiente. No pegues instrucciones sensibles ni datos privados en la solicitud. La declaración sirve para dirigir la revisión y respaldar la procedencia, no para avergonzar al autor.

Comprueba las afirmaciones próximas al código en fuentes autorizadas. Si el código generado usa una opción de seguridad de un framework, lee el manual de la versión instalada e inspecciona el valor predeterminado. Si llama a un servicio en la nube, compara la solicitud y la respuesta con el esquema oficial de la API. Si implementa un protocolo, prueba el comportamiento pertinente del RFC. La memoria del modelo no es evidencia, y una referencia convincente que nadie abrió es peor que ninguna porque puede terminar la revisión antes de tiempo.

Los cambios generados necesitan una comprobación de alcance frente a la petición. Compara la tarea aceptada con el diff y enumera los comportamientos que el cambio añade fuera de esa tarea. Busca nuevos registros, telemetría, comportamientos alternativos, dependencias, configuración, llamadas de red y recuperación de errores. Estos extras suelen parecer útiles, pero pueden crear consecuencias de privacidad, coste y seguridad que nadie pidió aceptar.

Comprueba la exposición de datos en ambas direcciones. Revisa qué envió el autor al sistema de IA según las reglas de la organización y después qué envía en ejecución el código generado. Una función auxiliar aparentemente inocua puede serializar un objeto completo cuando la API solo necesita dos campos. Las pruebas deben afirmar la forma de los datos salientes y confirmar que registros, excepciones y analítica excluyen secretos y datos regulados.

Por último, exige responsabilidad sin pedir una reescritura manual de cara a la galería. Obligar a las personas a volver a escribir código generado no lo hace más seguro. Exigirles que expliquen invariantes, reproduzcan pruebas, verifiquen API, recorten alcance innecesario y respondan a la revisión sí lo hace. El estándar es comprensión respaldada por evidencia.

Las excepciones necesitan caducidad y un plan de recuperación

Los incidentes de producción a veces justifican fusionar cambios con evidencia incompleta, pero la urgencia no hace desaparecer el control ausente. Una excepción debe indicar el control fallido u omitido, el daño inmediato que evita el cambio, la persona que acepta el riesgo añadido, el límite de exposición, la condición para revertir y el momento en que se completará la revisión normal.

Mantén el cambio de emergencia lo más pequeño posible. Evita añadir dependencias, hacer refactorizaciones oportunistas, aplicar formatos masivos y sumar correcciones generadas ajenas. Usa una función controlada, un límite de tráfico, una configuración específica o un parche reversible cuando el sistema lo permita. Empareja al autor con quien dirige el incidente o es responsable del servicio, y guarda comandos y observaciones en el registro del incidente.

Algunos controles deben mantenerse incluso durante un incidente. El código debe proceder de un colaborador autenticado, la compilación debe identificar el commit, las pruebas básicas deben ejecutarse salvo que el propio sistema de pruebas esté roto, la búsqueda de secretos no debe informar de una credencial nueva y una persona concreta debe autorizar la producción. Si un control no puede ejecutarse, registra ese hecho y usa la mejor comprobación independiente disponible. El silencio no sustituye una prueba.

Define una caducidad en horas o días según el sistema, no una excepción sin final. La revisión posterior debe decidir si conserva, reemplaza o revierte el cambio de emergencia. También debe añadir la prueba ausente y estudiar por qué la ruta normal no pudo responder con suficiente rapidez. Registra ese trabajo como parte del incidente, con responsable y fecha límite.

Nunca crees un nivel bajo permanente para correcciones etiquetadas como urgentes. Esa etiqueta se extenderá al trabajo normal. Conserva una única ruta de excepción con un registro más estricto y revisión posterior, y mide con qué frecuencia la usan los equipos. Las excepciones frecuentes suelen indicar pruebas lentas, responsables no disponibles, políticas poco claras o despliegues demasiado difíciles de revertir.

Ajusta los niveles con evidencia de tus publicaciones

Una política de revisión debe cambiar cuando la evidencia de producción muestra que dirige mal el trabajo. Registra el nivel asignado, por qué se asignó, el tiempo de revisión, qué controles encontraron un problema, los cambios solicitados después de aprobar, los enlaces a reversiones o incidentes y si se usó una excepción. No conviertas esos registros en una competición por la velocidad del revisor.

Busca errores de asignación. Si los cambios de nivel 1 causan repetidamente correcciones en producción, las rutas protegidas o las condiciones de entrada son demasiado débiles. Si los de nivel 3 esperan durante días y los revisores no encuentran nada fuera del conjunto normal de pruebas, quizá el nivel exige al especialista equivocado o duplica una comprobación automatizada fiable. Si los análisis de seguridad informan una y otra vez del mismo patrón que no requiere actuar, ajusta la regla y documenta el motivo en vez de enseñar a los revisores a ignorar compilaciones en rojo.

Muestrea cambios aprobados además de los fallidos. Una revisión periódica de un ingeniero con experiencia puede comparar el diff, la evidencia, el nivel y el resultado en producción. El objetivo es encontrar confianza falsa: aprobaciones sin una decisión asignada, pruebas que no cubrían la afirmación arriesgada, revisiones de dependencias que omitieron cambios indirectos o planes de reversión que nunca pudieron ejecutarse.

Mantén sencilla la primera implementación. Guarda la tabla de niveles en el repositorio, protege las rutas sensibles, exige comprobaciones de estado, asigna responsables del código y añade campos para la afirmación arriesgada, la evidencia, la reversión y la verificación de IA. Después de varios ciclos de publicación, ajusta la relación con los fallos y retrasos observados.

La revisión humana es suficiente cuando una persona independiente con los conocimientos adecuados del dominio puede conectar cada afirmación material con evidencia y detener la publicación. Para un trabajo de consecuencias bajas, puede llevar minutos. Para código capaz de exponer historiales, mover dinero, conceder autoridad o corromper datos, el equipo debe a producción una decisión más lenta y explícita, sin importar lo rápido que apareciera el primer borrador.

Preguntas Frecuentes

¿Todo el código generado por IA necesita revisión humana?

Sí, el código de producción necesita una revisión humana responsable, pero no siempre con la misma profundidad. Trata de forma distinta una edición limitada y reversible y un cambio en permisos, pagos, datos sanitarios, despliegue o confianza de compilación.

¿Pueden las pruebas automatizadas sustituir a un revisor humano?

No. Las pruebas pueden demostrar comportamientos elegidos, mientras que un revisor comprueba si el comportamiento, el alcance, los supuestos y el riesgo elegidos son correctos. Una automatización sólida reduce la inspección rutinaria, pero una persona debe asumir la decisión de producción.

¿Cómo debe clasificar un equipo un cambio pequeño pero sensible?

La sensibilidad debe prevalecer sobre el número de líneas. Un cambio mínimo en autorización, criptografía, secretos, migraciones o identidad de producción pertenece a un nivel superior porque su consecuencia puede ser grande y difícil de revertir.

¿Los revisores deben saber qué código escribió la IA?

Deben saber qué partes se generaron en buena medida para poder inspeccionar los supuestos y la evidencia de verificación. La declaración debe dirigir la atención, no librar al autor de entender cada línea.

¿Cuántos aprobadores necesita un cambio de IA de alto riesgo?

Usa al menos dos revisores independientes para cambios sensibles o amplios, con responsabilidad concreta sobre los dominios afectados. Los cambios graves pueden necesitar responsables de seguridad, datos y publicación, pero añadir firmas sin experiencia pertinente aporta poco.

¿Qué análisis de seguridad deben ejecutarse sobre código asistido por IA?

Ejecuta como base para cambios normales de producción un análisis estático adecuado al lenguaje, búsqueda de secretos y comprobaciones de dependencias. Añade modelado de amenazas, pruebas de abuso y revisión manual de autorización y flujo de datos cuando el código afecte a un límite sensible.

¿Cómo deben revisarse las actualizaciones de dependencias generadas por IA?

Inspecciona cambios directos e indirectos, vulnerabilidades conocidas, licencias, identidad del registro, datos de integridad y scripts de instalación. Una persona también debe decidir si la dependencia nueva es necesaria porque los analizadores no juzgan una ampliación evitable de la confianza.

¿Puede una corrección urgente de producción saltarse los niveles?

Puede usar una ruta de excepción documentada, pero todavía necesita un autor autenticado, un commit identificado, evidencia básica, una persona concreta que apruebe producción y una condición de reversión. Pon fecha de caducidad a la excepción y completa la revisión que falta después del incidente.

¿Qué evidencia debe incluir una solicitud de código con IA?

Incluye la afirmación de comportamiento arriesgado, resultados de pruebas específicas ligados al commit, resultados de análisis obligatorios, cambios de dependencias y un plan de reversión cuando no sea trivial. Para código generado, añade las API y los supuestos que el autor verificó de forma independiente.

¿Con qué frecuencia deben actualizarse los niveles de revisión?

Revísalos tras suficientes publicaciones para detectar errores de asignación repetidos e inmediatamente después de que un fallo grave exponga una regla incorrecta. Usa hallazgos de pruebas, incidentes, excepciones y muestras de aprobaciones en vez de cambiar la política solo por opinión.