¿Cuándo resulta inaceptable el riesgo de programar con IA?

La asistencia de IA para programar se vuelve inaceptable cuando un error plausible puede cruzar un límite de producción antes de que una persona cualificada demuestre que el cambio es seguro. El riesgo no depende de si un modelo escribió diez líneas o diez mil. Depende de si el cambio puede alterar identidades, mover dinero, reconfigurar infraestructura compartida, influir en decisiones clínicas, reescribir datos persistentes o debilitar un control de seguridad.

Trato esas áreas como zonas rojas. La IA puede seguir ayudando dentro de ellas, pero no puede aportar el juicio final, aprobar su propio trabajo ni convertir una petición imprecisa en un cambio de producción. Cada zona roja necesita un responsable humano identificado, pruebas adaptadas al tipo de fallo y una puerta de aprobación que el proceso de entrega haga cumplir. Una política en una wiki no es una puerta.

Esta distinción importa porque el resultado de la IA suele parecer más completo de lo que es. Un cambio generado puede compilar, seguir las convenciones locales e incluir pruebas mientras da por válido, sin avisar, un límite de confianza equivocado. Los revisores concentran entonces su atención en la sintaxis y el estilo porque el código parece conocido. Los controles siguientes devuelven la atención a las consecuencias.

El riesgo depende de la autoridad, no de las líneas de código

El riesgo en producción de la asistencia de IA para programar depende de la autoridad que obtiene un cambio tras desplegarse. Una modificación de tres líneas en la autorización puede exponer a todos los clientes. Un gran conjunto de datos de prueba generado quizá nunca salga del equipo de un desarrollador. Contar líneas, archivos o instrucciones generadas mide actividad, no peligro.

Clasifique un cambio preguntando qué puede hacer si está mal y quién puede detectar el fallo antes de que el daño se extienda. Uso cuatro niveles prácticos:

• Los cambios verdes no alcanzan datos de producción ni alteran una decisión, como los datos de prueba aislados y la documentación interna.
• Los cambios amarillos afectan al comportamiento normal de la aplicación, pero tienen un impacto limitado y una reversión rápida, como la lógica de presentación detrás de una función con indicador y pruebas.
• Los cambios rojos tocan un límite con consecuencias graves: autenticación, pagos, infraestructura, lógica clínica, migraciones o controles de seguridad.
• Los cambios negros combinan un límite de zona roja con una recuperación deficiente, poca observabilidad o un radio de impacto imposible de revisar. Exigen otro diseño, no una aprobación más valiente.

La categoría negra impide un abuso habitual de las puntuaciones de riesgo. A veces los equipos etiquetan una migración peligrosa como de "alto riesgo", asignan un revisor adicional y siguen adelante aunque no puedan restaurar los datos. Ningún revisor puede aprobar que no exista una vía de recuperación. El trabajo debe cambiar hasta que haya una reversión, una contención o una recuperación ensayada de verdad.

El mismo cambio puede pasar de un nivel a otro cuando cambia su contexto. Un adaptador de pagos generado dentro de un entorno desechable es amarillo porque no puede cobrar a nadie. Conectarlo a credenciales de producción lo vuelve rojo. Permitirle emitir reembolsos para todos los comercios sin límite por transacción ni interruptor de emergencia puede volverlo negro. Clasifique la capacidad desplegada, no la tarea de desarrollo.

Esto también aclara la diferencia entre revisión y aprobación. La revisión encuentra defectos y mejora el código. La aprobación acepta un riesgo residual definido en nombre del negocio o de la operación clínica. Un ingeniero sénior puede hacer ambas cosas con código rutinario, pero las zonas rojas necesitan un aprobador identificado por función y dominio. Conocer el lenguaje de programación no cualifica a alguien para aceptar una consecuencia clínica o financiera.

Los cambios de autenticación necesitan un responsable de identidad

Cualquier cambio asistido por IA que cree, pruebe, vincule, recupere o revoque una identidad pertenece a la zona roja de autenticación. Esto incluye controladores de inicio de sesión, creación de sesiones, restablecimiento de contraseñas, alta de factores múltiples, vinculación de cuentas, atributos de inicio de sesión único, credenciales de servicio y comprobaciones de autorización que deciden qué identidad puede actuar sobre qué recurso.

La puerta de aprobación debe exigir un responsable de identidad o seguridad que no haya creado el cambio. Esa persona necesita pruebas de los casos reales de abuso, no una insignia verde de pruebas unitarias. Como mínimo, el cambio debe demostrar denegaciones entre clientes, invalidación de sesiones después de cambiar credenciales, resistencia a la repetición cuando se reutilizan tokens, recuperación segura y denegación predeterminada cuando faltan datos de identidad obligatorios.

OWASP Application Security Verification Standard separa autenticación, gestión de sesiones y control de acceso porque superar una parte no demuestra las demás. Aun así, los equipos las confunden. Un inicio de sesión correcto demuestra que el usuario presentó credenciales aceptables. No demuestra que la sesión resultante tenga la duración adecuada, que cerrar sesión la revoque ni que el usuario pueda leer un registro concreto. Mantenga esas pruebas separadas para que una ruta feliz generada no oculte un límite de autorización ausente.

Un artefacto útil para la puerta es una matriz de autorización guardada en el repositorio. Sitúa los roles a la izquierda, las acciones protegidas arriba y la decisión esperada de permitir o denegar en cada celda. El conjunto de pruebas debe recorrer cada celda de denegación que proteja a un cliente, una acción administrativa, una operación con credenciales o un registro sensible. Los revisores pueden ver así cuándo un cambio modifica una decisión en vez de descubrir la política leyendo condiciones anidadas.

Los flujos de recuperación merecen una revisión adversaria porque omiten a propósito la prueba normal de identidad. Compruebe si un atacante puede enumerar cuentas, redirigir un restablecimiento, reutilizar un enlace, conservar una sesión antigua tras recuperar la cuenta o sustituir un factor fuerte por uno débil. Los agentes de soporte y los administradores necesitan el mismo escrutinio. Un restablecimiento manual con privilegios sigue siendo un protocolo de autenticación, aunque se implemente mediante una pantalla de soporte y un procedimiento escrito.

No acepte "el modelo usó el middleware estándar del framework" como prueba. El middleware puede estar conectado a la ruta equivocada, ejecutarse después de cargar datos o confiar en un atributo que otro servicio nunca validó. Inspeccione todo el recorrido de la solicitud, desde la entrada no fiable hasta la acción protegida. Si una correspondencia de identidad cruza servicios, registre emisor, audiencia, correspondencia del sujeto, comportamiento del reloj y supuestos de revocación.

La puerta de despliegue también debe separar la aprobación del código del acceso a credenciales. El artefacto aprobado debe avanzar por el proceso sin entregar secretos de producción a la sesión del modelo, su agente o el entorno de instrucciones del desarrollador. Que una persona apruebe el código no sanea secretos ya expuestos a un servicio externo. Si una credencial entró en una instrucción o un registro visible para el modelo, considérela revelada y rótela.

El código de pagos debe demostrar invariantes monetarias

Los cambios de pagos asistidos por IA son rojos cuando pueden autorizar, capturar, reembolsar, liquidar, fijar precios, calcular impuestos, abonar o conciliar valor real. La puerta debe demostrar invariantes monetarias ante reintentos y fallos parciales, porque los defectos de pago más costosos suelen ser operaciones con aspecto válido ejecutadas dos veces o registradas en un solo sistema.

Empiece con invariantes explícitas en lenguaje corriente. Una solicitud de pago tiene un comercio, una moneda, un importe expresado en la unidad mínima admitida y una clave de idempotencia estable. Un reintento no puede crear un segundo cargo. Un reembolso no puede superar el importe capturado tras descontar reembolsos anteriores. Un estado local "pagado" no puede aparecer sin que la operación externa tenga una referencia persistente. Estas afirmaciones deben convertirse en pruebas y, cuando sea posible, en restricciones de base de datos.

El código de pagos generado suele gestionar la respuesta correcta y tratar cada error como un fallo limpio. Las redes de producción no se comportan así. Un cliente puede agotar el tiempo después de que el procesador acepte una solicitud. La aplicación tiene entonces un resultado desconocido, no un pago fallido. Reintentar con otra clave de idempotencia puede cobrar dos veces. Marque la operación como pendiente, consulte por la clave o referencia original y concilie antes de decidir qué ocurrió.

Los webhooks añaden otro límite de incertidumbre. Autentique al emisor, conserve el identificador original del evento, confirme la recepción solo después de guardarlo de forma persistente y permita repetir el procesamiento sin daño. No suponga que el orden de entrega coincide con el orden del negocio. Un aviso de reembolso puede llegar antes que un aviso de captura retrasado, y dos procesos pueden ver el mismo evento. El controlador debe registrar hechos y dejar que una máquina de estados explícita decida si se permite una transición.

La puerta de aprobación debe exigir un responsable de pagos y un ingeniero que entienda la transacción de almacenamiento. Necesitan una matriz de pruebas que cubra solicitudes duplicadas, tiempos agotados antes y después de la aceptación, callbacks fuera de orden, firmas no válidas, monedas distintas, límites de redondeo, reembolsos parciales y conciliación tras el fallo de un proceso. Use entornos de prueba del procesador para el protocolo, pero pruebe su propio estado persistente con fallos inyectados. Esos entornos rara vez reproducen todos los problemas de orden.

No deje que la IA invente reglas de pago a partir de nombres como available_balance o settled. Esas palabras tienen significados comerciales y contables que cambian entre sistemas. Escriba una tabla breve de transición de estados con cada transición permitida, el evento que la provoca, la prueba persistente requerida y si un operador puede revertirla. Rechace transiciones fuera de la tabla aunque el código propuesto parezca razonable.

La puerta de publicación debe limitar la exposición. Envíe una porción pequeña y observable por la nueva ruta, defina una condición de parada automática y mantenga disponible la ruta anterior hasta que la conciliación coincida. Un indicador de función no basta si al desactivarlo quedan callbacks aceptados sin procesar o una transacción se divide entre dos implementaciones. El plan de reversión debe cubrir dinero en curso, no solo binarios de la aplicación.

Los cambios de infraestructura exigen un radio de impacto limitado

La infraestructura entra en la zona roja cuando un cambio generado puede alterar identidad de producción, redes, cifrado, capacidad de cómputo, persistencia, copias de seguridad, registros o permisos de despliegue. La aprobación debe depender de un plan legible por máquinas, un objetivo limitado y una prueba de recuperación, no de que el archivo de configuración parezca convencional.

En infraestructura declarativa, conserve el plan exacto aprobado por los revisores y aplique ese artefacto sin regenerarlo con entradas distintas. La puerta debe fallar si la cuenta, región, espacio de trabajo o conjunto de recursos cambia entre la planificación y la aplicación. Los revisores deben ver por separado sustituciones, eliminaciones, ampliaciones de permisos, exposición pública y cambios en recursos que contienen datos.

La configuración generada tiene un patrón de fallo concreto: copia un ejemplo válido, pero omite las restricciones circundantes que lo hacían seguro. Una política de identidad amplia puede ser aceptable en una cuenta desechable y desastrosa en una cuenta compartida de producción. Una regla de red puede exponer un servicio porque el ejemplo presuponía otra capa de cortafuegos. El validador de sintaxis no puede ver esos supuestos ausentes.

Exija controles de política que respondan preguntas concretas. ¿Puede este plan crear un puerto público? ¿Puede conceder acciones comodín? ¿Puede desactivar cifrado o retención? ¿Puede destruir o sustituir un recurso con estado? ¿Puede cambiar el rol del proceso que aplica estos controles? Un cambio propuesto en la propia barrera nunca debe pasar porque la barrera revisada lo apruebe. Revise ese control mediante una ruta independiente.

Las pruebas de recuperación deben corresponder al recurso. Para cómputo sin estado, puede bastar con volver a desplegar una versión que funciona. Para una base de datos, cola, almacén de identidades o clave de cifrado, un comando de reversión no demuestra recuperación. Restaure una copia en un entorno aislado, verifique lecturas desde la aplicación y registre la duración de la recuperación y cualquier pérdida de datos sin inventar un objetivo tranquilizador.

Use despliegues progresivos para reducir la incertidumbre, pero no confunda una versión canaria con contención. Una política global de permisos, un cambio de esquema compartido o una operación destructiva de almacenamiento pueden afectar a todas las instancias aunque solo una réplica reciba tráfico. Determine el radio de impacto a partir del recurso modificado. Exija después un aprobador responsable de ese radio y un operador capaz de detener el despliegue.

La lógica clínica necesita trazabilidad y aprobación clínica

El software que influye en diagnóstico, triaje, medicación, dosis, alertas, rutas asistenciales o presentación de hechos clínicos pertenece a la zona roja clínica. Un profesional autorizado o un responsable clínico designado formalmente debe aprobar el comportamiento previsto, mientras ingeniería aprueba por separado la implementación y la operación. Ninguna aprobación sustituye a la otra.

La puerta empieza con una declaración exacta del uso previsto: quién usa el resultado, para qué pacientes, con qué entradas, en qué punto de la atención y en qué decisión puede influir. Sin ese límite, los revisores no pueden decidir si un fallo es una molestia o un peligro para el paciente. La IA tiende especialmente a rellenar huecos con supuestos plausibles, por lo que una petición ambigua debe detener el trabajo.

Cree trazabilidad desde cada requisito clínico hasta el código, los casos de prueba y el comportamiento mostrado. Si una regla indica que una alerta se activa bajo ciertas condiciones, las pruebas deben incluir valores límite, datos ausentes, datos contradictorios, unidades, tiempos, anulaciones y el texto mostrado al usuario. Un cálculo interno correcto aún puede causar daño si la interfaz oculta la incertidumbre o presenta como actual información atrasada.

La corrección clínica es distinta de la corrección del software. Las pruebas unitarias pueden demostrar que el código implementa una fórmula. No pueden demostrar que la fórmula sirva para la población prevista, que los datos de origen tengan el significado supuesto o que el flujo dé tiempo al profesional para actuar. El revisor clínico responde por esas preguntas. El ingeniero responde por la ejecución determinista, el origen de los datos, la gestión de fallos, los registros de auditoría y el comportamiento seguro cuando faltan entradas.

Para cambios generados por IA, guarde el requisito aprobado y las pruebas, no una instrucción sin procesar como sustituto. Las instrucciones son registros útiles de desarrollo, pero no definen la intención clínica con precisión suficiente para validar cambios futuros. Un revisor debe poder conectar un comportamiento de producción con un requisito controlado sin reproducir una conversación con un modelo.

La puerta de publicación necesita vigilancia vinculada a los peligros clínicos. Observe entradas ausentes, alertas suprimidas, rutas de anulación, datos atrasados, frecuencia inesperada de reglas y discrepancias entre valores mostrados y almacenados. Defina quién recibe cada señal y qué puede hacer. Si la única respuesta es "investigar más tarde", el sistema carece de control operativo.

Las migraciones solo son seguras cuando se demuestra la recuperación

Las migraciones de datos y esquemas se vuelven rojas cuando transforman registros persistentes de producción, cambian la compatibilidad entre versiones en ejecución, reconstruyen índices con impacto operativo o eliminan información. La puerta de aprobación debe demostrar compatibilidad hacia delante, reinicio seguro, conciliación y recuperación con datos parecidos a los de producción.

La recomendación popular de "hacer siempre reversibles las migraciones" se queda corta. Una migración descendente puede revertir una instrucción de esquema y perder los valores ya transformados o eliminados. También puede fallar después de que nuevas versiones escriban datos que el esquema anterior no representa. Necesita un plan de recuperación, que puede consistir en revertir, reparar hacia delante, restaurar o combinar opciones. Nombre la opción que usará de verdad.

Prefiera cambios de expansión y contracción cuando puedan ejecutarse varias versiones de la aplicación. Añada la estructura nueva sin quitar la anterior, despliegue código que tolere ambas, rellene los datos en lotes limitados, compare resultados, cambie las lecturas y quite la estructura antigua solo cuando se cierre la ventana de compatibilidad. Cada fase debe poder desplegarse y observarse por separado.

Una puerta de migración puede exigir un ensayo reproducible:

1. Restaure una copia reciente parecida a producción en un entorno aislado con los valores sensibles protegidos.
2. Ejecute la migración con el mismo artefacto, permisos, tiempos de espera y coordinación previstos para producción.
3. Interrúmpala en varios límites de lote, reiníciela y compruebe que repetir trabajo no corrompe resultados.
4. Compare recuentos, sumas o hashes adecuados para los datos, registros rechazados y lecturas de la aplicación antes y después.
5. Ejercite la vía de recuperación declarada y registre qué partes siguen siendo manuales.

Evite una sola suma de comprobación sobre una tabla mutable completa. Indica que algo difiere, pero no si la diferencia era esperada ni dónde empezar la reparación. La conciliación debe seguir particiones e invariantes del negocio: por cliente, día, moneda o tipo de registro. Conserve los registros rechazados con el motivo para que los operadores puedan repararlos sin volver a ejecutar a ciegas toda la transformación.

El código de migración generado merece atención especial en valores nulos, valores predeterminados, codificación de caracteres, zonas horarias, unidades, claves duplicadas y conversiones implícitas. Los modelos deducen el caso común por los nombres. Sus datos históricos contienen excepciones creadas por versiones antiguas, reparaciones manuales e integraciones que ya no existen. Tome muestras de esas excepciones a propósito.

No apruebe una fase final destructiva solo porque las anteriores funcionaron bien. La eliminación cambia las opciones de recuperación. Exija una aprobación separada después del periodo de observación, con pruebas de que ningún código admitido lee o escribe la representación antigua y de que las copias retenidas cubren la necesidad real de recuperación.

Los controles de seguridad no pueden aprobar su propio debilitamiento

Los cambios en políticas de autorización, tratamiento de secretos, cifrado, registro de auditoría, validación de entradas, controles de dependencias, vigilancia de seguridad o protecciones de entrega son rojos aunque no toquen una función del producto. Su puerta debe ser independiente del control modificado.

Esta regla de independencia es fácil de enunciar y fácil de incumplir. Suponga que un cambio generado por IA modifica la regla del proceso que bloquea hallazgos críticos en dependencias, y que la misma solicitud se aprueba porque la regla modificada ya no los bloquea. La marca verde no significa nada. El cambio usó su propia definición nueva de seguridad para aprobarse.

Proteja las definiciones de control con propiedad y aplicación separadas. Los cambios en protecciones de ramas, motores de políticas, umbrales de análisis, exclusiones de registros, roles privilegiados y puertas de despliegue deben requerir revisión del responsable de seguridad y aplicarse solo después de que el control anterior apruebe la transición. Cuando resulte imposible, use una ruta administrativa con registros explícitos y una segunda persona.

NIST Secure Software Development Framework trata la protección del software y la producción de versiones bien protegidas como prácticas continuas, no como un análisis final. Ese enfoque es correcto. Un cambio generado puede superar un analizador y aun así quitar un campo de registro necesario para responder a incidentes, ampliar un límite de confianza o convertir un fallo estricto en una advertencia ignorada. Las pruebas deben cubrir prevención, detección y recuperación pertinentes para el control modificado.

Rechace explicaciones como "esta excepción es temporal" salvo que la excepción tenga responsable, alcance reducido, vencimiento y una condición registrada para eliminarla. Una excepción permanente suele empezar como una salida por una fecha límite. La puerta debe imponer el vencimiento en vez de confiar en que alguien lo recuerde después de publicar.

Los secretos necesitan una regla separada. Nunca coloque secretos de producción, datos privados de pacientes, datos de pagos ni código fuente propietario fuera del límite aprobado para el modelo. La ocultación solo ayuda si el sistema reconoce los formatos y actúa antes de transmitir. Si datos sensibles llegan a un modelo o registro no aprobado, gestione el incidente de inmediato; borrar el chat no retira la revelación.

Las puertas de aprobación necesitan pruebas y separación

Una puerta útil para una zona roja es un contrato aplicable con cinco partes: alcance, pruebas, aprobador, restricción de despliegue y autoridad de recuperación. Si alguna parte es imprecisa, la puerta se vuelve una casilla ceremonial que los revisores aprenden a marcar.

El alcance identifica rutas, recursos, clasificaciones de datos y cambios semánticos que activan la puerta. Las rutas de archivos por sí solas son débiles porque las bibliotecas compartidas y la configuración generada pueden alterar indirectamente una zona roja. Combine reglas de rutas con metadatos de propiedad, análisis del plan de infraestructura, detección de operaciones de base de datos y una declaración en la solicitud de cambios que los revisores puedan cuestionar.

Permita que los desarrolladores discutan una clasificación automática, pero nunca que el autor la rebaje en silencio. La objeción debe nombrar la zona propuesta, explicar la consecuencia limitada y recibir aprobación del responsable de la zona original. Así los falsos positivos no convierten la política en ruido y queda registrado por qué no se aplicó la puerta. Revise periódicamente esas excepciones para encontrar patrones repetidos que deban convertirse en mejores reglas de clasificación.

Las pruebas deben corresponder al fallo. La autenticación necesita casos de denegación y pruebas de sesión. Los pagos necesitan reintentos, conciliación y pruebas de invariantes. La infraestructura necesita un plan revisado y pruebas de recuperación. La lógica clínica necesita requisitos controlados y validación clínica. Las migraciones necesitan ensayo y conciliación. Los controles de seguridad necesitan aprobación independiente. Un porcentaje genérico de cobertura no sustituye nada de ello.

Los aprobadores deben ser funciones con miembros actuales identificados, no cualquier persona que resulte sénior. Exija al menos un aprobador de dominio independiente del autor para cada cambio en zona roja. Para comportamiento clínico o reglas financieras importantes, añada al responsable operativo designado. Impida que el agente de IA, la cuenta de servicio o el autor satisfagan la aprobación mediante una identidad automatizada.

Las restricciones de despliegue limitan lo que ocurre después de aprobar. Vincule la aprobación a un commit y al resumen criptográfico del artefacto para que una regeneración posterior no se cuele. Separe las credenciales de producción del entorno de programación. Use exposición por fases cuando limite de verdad el impacto, defina condiciones de parada y permita que la persona de guardia detenga el despliegue sin esperar al autor.

La autoridad de recuperación identifica a la persona que puede desactivar, revertir, restaurar o reparar hacia delante y le entrega el acceso necesario antes de publicar. Un incidente es el peor momento para descubrir que solo un administrador ausente puede restaurar una copia. Ensaye el acceso además de los comandos.

Este fragmento de política muestra el registro mínimo que espero que aplique un sistema de entrega:

zone: payments
change_digest: "sha256:<artifact-digest>"
required_approvals:
  - role: payments_owner
    independent_of_author: true
evidence:
  - retry_matrix
  - reconciliation_report
deployment:
  max_exposure_percent: 5
  stop_condition: "duplicate_or_unreconciled_transaction"
recovery_owner: "on_call_payments"

La sintaxis exacta no importa. El fragmento evita que la aprobación se separe del artefacto y que se acepte riesgo sin pruebas ni un responsable. Guarde este registro con la versión para que quien revise un incidente pueda reconstruir qué se sabía y quién aceptó el riesgo restante.

La intervención humana debe significar control responsable

La intervención humana solo reduce el riesgo de la asistencia de IA para programar cuando la persona tiene competencia, información, tiempo, autoridad e independencia para detener el cambio. Un revisor cansado que aprueba un gran cambio generado aporta presencia humana, no control humano.

Mantenga los cambios generados lo bastante pequeños como para razonar sobre ellos. Pida un comportamiento limitado, exija que el modelo o desarrollador declare los supuestos y rechace limpiezas no relacionadas dentro de un cambio de zona roja. Ejecute formateadores y analizadores deterministas, pero haga que el autor explique con sus propias palabras los límites de confianza, estados de fallo y recuperación. Si la explicación no resiste preguntas, el código no está listo.

Mida la puerta por resultados que revelen su estado. Registre con qué frecuencia los revisores piden cambios sustanciales, faltan pruebas, vencen las excepciones de emergencia, funciona la recuperación ensayada o una persona aprueba reiteradamente dominios que no conoce. No premie solo la velocidad de aprobación. Una aprobación rápida puede indicar un cambio claro o que nadie miró.

La IA puede ser útil antes de la puerta. Puede enumerar casos límite, redactar pruebas, comparar un cambio con una tabla de estados y señalar incoherencias. Trate esos resultados como pistas. El mismo modelo que creó un defecto puede generar con confianza una prueba que confirme su propio supuesto equivocado, por lo que siguen haciendo falta requisitos independientes y juicio humano.

SaaS Production usa IA con ingenieros experimentados y un enfoque Human-in-the-Loop para acortar la entrega sin perder el control humano. En trabajos de zona roja, ese enfoque debe verse en el rastro de artefactos: quién fijó el límite, qué pruebas inspeccionó, qué exposición aceptó y cómo puede recuperarse el equipo.

No existe un porcentaje responsable de código que la IA pueda escribir para cualquier sistema. Defina las zonas rojas según las consecuencias, incorpore las puertas a las herramientas de entrega y rechace el despliegue cuando la recuperación solo sea una frase en una tarea. Si un equipo no puede identificar a la persona autorizada para detener un cambio peligroso, el cambio no está listo para producción.

Preguntas Frecuentes

¿Puede la IA escribir código para sistemas de autenticación?

Sí, pero el código de autenticación pertenece a una zona roja. Un responsable independiente de identidad o seguridad debe aprobarlo tras probar denegaciones, sesiones, recuperación y límites de autorización.

¿Qué hace peligroso el código de pagos generado por IA?

Los reintentos, callbacks retrasados y fallos parciales pueden crear transacciones duplicadas o sin conciliar aunque la ruta feliz parezca correcta. La puerta debe demostrar idempotencia, transiciones de estado, invariantes de importe y moneda y recuperación ante resultados desconocidos.

¿Deben los agentes de IA recibir credenciales de producción?

No. Mantenga las credenciales fuera del modelo y del entorno del agente, y deje que un artefacto aprobado avance por un proceso de entrega separado. Si un secreto entra en una instrucción o registro visible para el modelo, considérelo revelado y rótelo.

¿Basta la revisión humana para código generado por IA?

Solo si el revisor tiene la competencia de dominio, pruebas, tiempo y autoridad necesarios para detener la publicación. Las zonas rojas también necesitan restricciones de despliegue aplicadas y un responsable de recuperación.

¿Cómo deben clasificar los equipos el riesgo de programar con IA?

Clasifique la autoridad y las consecuencias desplegadas, no la cantidad de código generado. Un cambio pequeño es rojo si puede alterar identidad, dinero, infraestructura compartida, decisiones clínicas, datos persistentes o un control de seguridad.

¿Qué pruebas debe incluir una aprobación de infraestructura?

Revise el plan exacto legible por máquinas que se aplicará, con cuenta objetivo y alcance de recursos fijados. Señale eliminaciones, sustituciones, exposición pública, ampliación de permisos, recursos con estado y pruebas de recuperación.

¿Puede ser insegura una migración reversible?

Sí. Una migración descendente puede revertir el esquema y perder datos transformados o rechazar valores escritos por la aplicación nueva. Exija un plan de recuperación ensayado, lotes reiniciables, compatibilidad y conciliación del negocio.

¿Quién aprueba lógica clínica asistida por IA?

Un responsable clínico designado aprueba el comportamiento y las consecuencias clínicas, mientras ingeniería aprueba implementación y operación. La publicación también necesita trazabilidad desde requisitos controlados hasta pruebas y comportamiento visible.

¿Cómo se evita que los controles de seguridad se aprueben solos?

Use propiedad separada y una ruta de aplicación independiente para políticas, umbrales de análisis, roles privilegiados, exclusiones de registros y puertas de entrega. Siempre que sea posible, el control anterior debe aprobar la transición.

¿Cuándo debe bloquearse por completo un cambio asistido por IA?

Bloquéelo cuando el radio de impacto no esté limitado, la recuperación no se haya demostrado, falten pruebas obligatorias o ningún responsable cualificado acepte el riesgo residual. Son fallos de diseño, no razones para añadir otro revisor apresurado.