Cómo convertir la aprobación de agentes de IA en control

Un agente con acceso de escritura debe ganarse la aprobación para un efecto concreto, no recibir una bendición para un plan general. El punto de control útil se encuentra después de que el agente haya convertido su intención en objetivos y parámetros exactos, pero antes de que el primer sistema externo acepte un cambio. Cualquier momento anterior pide a una persona que apruebe una conjetura. Cualquier momento posterior convierte la aprobación en revisión de incidentes.

La idea parece sencilla hasta que una tarea se expande a cuarenta llamadas de API, el estado de producción cambia mientras el diálogo de aprobación sigue abierto o la supuesta reversión no puede reconstruir lo que se sobrescribió. Un control significativo necesita cuatro propiedades: el revisor ve el efecto propuesto, la acción aprobada no puede mutar en silencio, el sistema registra lo que ocurrió y el operador tiene una ruta de recuperación probada. Algunos efectos no superan esa prueba y deben seguir siendo manuales.

Trato el acceso de escritura como una colección de capacidades limitadas, no como un único permiso. Crear un registro en borrador y publicarlo son capacidades diferentes. Preparar una migración de base de datos y aplicarla también lo son. Cuando existen esos límites, el paso de aprobación puede proteger la operación que acarrea las consecuencias sin interrumpir cada cálculo inofensivo.

Coloca la aprobación junto al efecto

La barrera de aprobación debe estar justo antes del componente capaz de confirmar la escritura. Deja que el agente lea, razone, calcule un parche, ejecute validaciones y produzca el resultado de una simulación sin interrupciones. Detenlo cuando pida a la capa de ejecución de confianza que convierta la propuesta en un efecto externo. El ejecutor, no el modelo, debe imponer la parada.

Aprobar en el momento del prompt es demasiado pronto. Una petición como «limpia los registros de clientes duplicados» no dice qué registros se fusionarán, qué valores prevalecerán ni cuántas referencias posteriores se moverán. Aprobar después de elegir la herramienta también suele ser prematuro, porque los argumentos pueden contener una consulta amplia. La persona debe ver el conjunto resuelto de objetivos y el efecto sobre cada uno.

La barrera también tiene que estar dentro del límite de autorización. Si el agente puede llamar directamente a la API de producción y una interfaz separada se limita a pedir consentimiento, el diálogo es teatro. Da al agente credenciales capaces de preparar una acción y obliga después al ejecutor a canjear un token de aprobación por la capacidad más potente y de corta duración que permite confirmarla. Vincula ese token a un resumen criptográfico de la carga útil canónica. Un cambio de objetivo, parámetro o precondición genera un resumen nuevo y necesita otra aprobación.

Para un lote, aprueba el lote acotado en vez de un objetivo impreciso. Muestra la cantidad, enumera los objetivos cuando la lista sea razonablemente pequeña y ofrece un adjunto legible por máquina cuando sea grande. Define en la política un número máximo y un coste máximo. Si la fase de descubrimiento encuentra más trabajo del aprobado, el ejecutor debe parar en vez de considerar la respuesta anterior como permiso para continuar.

La prueba práctica es directa: después de pulsar Aprobar, ¿puede el revisor decir exactamente qué sistema cambiará, qué objetos se modificarán y qué invariante debe seguir cumpliéndose? Si alguna parte sigue sin conocerse, la propuesta no está lista para aprobarse.

Muestra al revisor la acción resuelta

El revisor debe ver una representación orientada al efecto, creada a partir de la misma carga útil canónica que consumirá el ejecutor. No le pidas que interprete razonamientos internos, una transcripción de chat o una promesa redactada por el modelo. Esos materiales pueden aportar contexto, pero no son el contrato. El contrato es la acción normalizada.

Para un cambio de archivo, muestra el repositorio, la revisión, las rutas, el diff, los archivos generados y las comprobaciones ejecutadas. Para SQL, muestra la identidad de la base de datos, la sentencia o el resumen de la migración, el modo de transacción, la estimación de filas afectadas obtenida de un plan seguro y las posibles consecuencias de bloqueo. Para un mensaje, muestra destinatarios, contenido visible, adjuntos y si el envío puede activar otro sistema. Para infraestructura en la nube, representa el plan de recursos e identifica por separado las sustituciones y eliminaciones.

La pantalla de aprobación debe responder cuatro preguntas sin necesidad de ampliar nada:

• ¿Qué estado exacto cambiará?
• ¿Por qué eligió el agente esos objetivos?
• ¿Qué comprobaciones pasaron y cuáles no se ejecutaron?
• ¿Qué operación de recuperación existe si el resultado es incorrecto?

Mantén separada la explicación del agente de los hechos medidos por herramientas. «La suite de pruebas pasó» debe proceder del ejecutor de pruebas junto con su código de salida y el resumen del artefacto. «Este cambio tiene poco riesgo» es una valoración, y la interfaz debe marcarla como tal. He visto revisores confiar en explicaciones fluidas mientras pasaban por alto una opción destructiva en los argumentos reales. Pon primero los argumentos.

La aprobación también debe tener una duración. Incluye la revisión base, versión del registro, ETag, versión del esquema u otra precondición que demuestre que el mundo revisado todavía existe. Un parche de archivo de hace diez minutos puede seguir siendo seguro con una comprobación limpia de la revisión. Una decisión de hace diez minutos para cancelar un pago o rotar un secreto de producción puede haber caducado. El vencimiento debe ajustarse a la operación, no a un temporizador universal.

No dejes que el agente apruebe su propia representación. Construye la vista con código de confianza a partir de un esquema de acción tipado, escapa el texto no fiable y haz visibles los campos omitidos. Un campo de destinatario vacío debe aparecer vacío, no desaparecer de la tarjeta. Los valores predeterminados ocultos también son parámetros y deben formar parte del resumen de la carga útil.

Clasifica las acciones antes de automatizarlas

Una política útil clasifica las operaciones por consecuencias y reversibilidad antes de que ningún agente las solicite. El modelo puede sugerir una clase, pero el código de confianza asigna cada tipo de acción registrado a su política. De otro modo, una descripción persuasiva podría rebajar la categoría de una operación peligrosa.

Uso cuatro clases prácticas. El trabajo de solo lectura no necesita aprobación, salvo que la lectura revele datos muy restringidos. Las escrituras en borrador pueden ejecutarse automáticamente dentro de un espacio aislado. Las escrituras externas reversibles necesitan aprobación en el momento de confirmarse. Las operaciones irreversibles o que modifican la autoridad siguen siendo manuales y, a menudo, requieren una segunda persona según el sistema que las rodea.

Una política compacta puede tener este aspecto:

actions:
  repo.patch:
    mode: approve_at_commit
    require: [base_revision, diff_digest, test_run_id]
    expires_in: 30m
    rollback: revert_commit
  customer.merge:
    mode: approve_at_commit
    require: [source_ids, winner_id, snapshot_id]
    max_targets: 20
    expires_in: 5m
    rollback: restore_snapshot
  signing_key.destroy:
    mode: human_only
  audit_log.delete:
    mode: forbidden

La distinción entre human_only y forbidden importa. Una persona puede destruir una clave de firma retirada desde la consola de gestión de claves después del procedimiento normal de la organización. Ni el agente ni su ejecutor deben tener esa capacidad. Eliminar el registro de auditoría que explicaría el comportamiento del propio agente no tiene un lugar legítimo en esta ruta de automatización, aunque una persona pulse un botón.

Mantén también fuera de la ejecución autónoma varias operaciones más: desactivar los controles que supervisan al agente, ampliar sus propios permisos, cambiar la política de aprobación, borrar copias de seguridad, eliminar la última copia de recuperación y emitir un compromiso jurídico o financiero irrevocable. La lista exacta depende del negocio, pero el patrón no cambia. Un agente no debe alterar las pruebas, la autoridad ni los mecanismos de recuperación que lo limitan.

Algunos equipos sostienen que una segunda aprobación vuelve segura cualquier acción. No es cierto. Dos personas pueden aprobar una petición ilegible y ambas pueden pasar por alto el mismo valor predeterminado oculto. Varios aprobadores ayudan a separar funciones, pero no reparan un mal contrato de acción.

Registra cada acción como un sobre verificable

Guarda un sobre duradero para cada acción propuesta y añade transiciones de estado a medida que avanza por la aprobación y la ejecución. Una transcripción de chat puede servir como prueba complementaria, pero es un registro de auditoría deficiente: mezcla deliberación e instrucciones, puede omitir valores predeterminados de las herramientas y rara vez demuestra qué bytes llegaron al sistema de destino.

El control AU-3 de NIST SP 800-53 dice que los registros de auditoría deben establecer qué ocurrió, cuándo, dónde, cuál fue la fuente, el resultado y la identidad asociada al suceso. Es un mínimo razonable, pero el ejecutor de un agente necesita más porque la propuesta y el efecto confirmado pueden divergir. Registra tanto la intención como el resultado observado y vincúlalos con identificadores estables.

Esta es la forma que espero de un evento de ejecución:

{
  "action_id": "act_01J...",
  "run_id": "run_01J...",
  "action_type": "repo.patch",
  "actor": {"agent_id": "migration-agent", "model_release": "approved-release"},
  "requester": {"user_id": "u_1842", "session_id": "s_9031"},
  "target": {"repository": "billing", "base_revision": "4b2c..."},
  "intent_digest": "sha256:9f3a...",
  "policy": {"version": "2026-08-14.3", "decision": "approval_required"},
  "approval": {"approver_id": "u_771", "payload_digest": "sha256:9f3a...", "at": "2026-08-14T09:31:22Z"},
  "execution": {"started_at": "2026-08-14T09:31:24Z", "executor_id": "exec-prod-2", "attempt": 1},
  "result": {"status": "committed", "revision": "51ad...", "changed_files": 7},
  "recovery": {"kind": "revert_commit", "handle": "51ad..."}
}

El evento real también debe incluir los parámetros canónicos o una referencia a ellos resistente a manipulaciones, versiones de herramientas y conectores, entradas de la política, resultados de precondiciones, artefactos de validación, códigos de error y el recibo o identificador de solicitud del sistema de destino. Registra los intentos por separado. Si un tiempo de espera de red deja el resultado sin conocer, escribe unknown, compáralo con el destino y no repitas a ciegas una operación no idempotente.

Protege el registro del actor al que registra. NIST AU-9 cubre la protección de información y herramientas de auditoría. La consecuencia operativa es que la credencial de escritura del agente no debe editar ni borrar su pista de auditoría. Envía los eventos a un almacén orientado a anexos, con administración restringida, reglas de retención, sincronización de relojes y comprobaciones de integridad. Oculta los secretos antes de almacenarlos, pero no conviertas la ocultación en omisión: registra que existía un campo sensible y almacena un resumen con clave o una referencia protegida si una investigación puede necesitar correlacionarlo.

Diseña la reversibilidad para cada operación

Un cambio solo es reversible si puedes nombrar la operación inversa, conservar los datos que necesita y demostrar que sigue funcionando después de la acción de ida. Una marca genérica de «deshacer disponible» no prueba nada. Cada sistema requiere un diseño de recuperación diferente.

El control de versiones proporciona un commit de reversión, pero revertir un despliegue quizá no revierta una escritura de base de datos que ya realizó el código publicado. Una transacción de base de datos permite una reversión limpia solo hasta el commit. Después, la restauración puede requerir una transacción compensatoria o recuperación a un punto en el tiempo, y ambas podrían sobrescribir trabajo legítimo que llegó más tarde. Un correo enviado no puede deshacerse en los sistemas que ya lo recibieron. Una corrección es una compensación, no una reversión.

Antes de la aprobación, el contrato de acción debe nombrar uno de estos modos de recuperación:

• Reversión de transacción, cuando el sistema puede abortar antes de exponer el cambio.
• Restauración de versión, cuando el objeto anterior y su versión siguen disponibles.
• Acción compensatoria, donde un evento nuevo compensa semánticamente el primero.
• Reparación hacia delante, donde los operadores despliegan un cambio corregido porque revertir dañaría el estado más reciente.
• Sin reversión, lo que eleva la clase de aprobación o mantiene la acción manual.

Captura el estado anterior de manera selectiva. Una instantánea de los registros afectados puede permitir recuperar una fusión de clientes, pero copiar una base de datos restringida entera al espacio de trabajo del agente crea un problema peor. Guarda las instantáneas en el sistema de recuperación protegido del destino, cífralas con acceso separado, asigna una retención y coloca solo el identificador de recuperación en el registro de acción.

Prueba la recuperación con la misma seriedad que la ruta de ida. Para cada acción de escritura registrada, pasa un conjunto de prueba por preparación, aprobación, confirmación y recuperación, y compara el resultado. Comprueba los efectos secundarios en colas, cachés, índices de búsqueda, webhooks y libros auxiliares. Si la prueba solo verifica la tabla principal, únicamente demuestra que esa tabla puede restaurarse.

La idempotencia está relacionada, pero es distinta. Una clave de idempotencia impide que un reintento aplique dos veces la misma operación lógica. No revierte una operación equivocada. Usa ambas cosas: identificadores de acción estables para reintentar con seguridad e identificadores de recuperación explícitos para corregir.

Una aprobación obsoleta incumple una precondición

Una aprobación autoriza una carga útil frente a un estado conocido. Si cualquiera cambia, el ejecutor debe rechazarla y pedir una propuesta nueva. Es control de concurrencia optimista aplicado al juicio humano, y cierra una brecha que muchos flujos de aprobación dejan abierta.

Vincula las acciones de archivo a un hash de commit, las actualizaciones de API a un ETag o una versión de registro, el trabajo de base de datos a una versión de esquema y un predicado limitado, y los planes de infraestructura al resumen del plan más el número de estado del proveedor cuando exista. Evalúa las precondiciones dentro del ejecutor justo antes del commit. No permitas que el agente se limite a afirmar que ya las comprobó.

Un fallo parcial del lote necesita una regla expresa. Los lotes atómicos deben revertir todos los elementos cuando falle uno. Los lotes no atómicos deben registrar un resultado para cada objetivo y detenerse cuando se supere el umbral de errores aprobado. La interfaz debe explicar al revisor qué comportamiento se aplica. Continuar en silencio después de varios fallos convierte una aprobación acotada en un experimento sobre producción.

El trabajo prolongado debe separar la aprobación del plan de la aprobación de cada fase peligrosa. Una persona puede aprobar la generación de mil modificaciones candidatas en una rama aislada. La promoción todavía necesita una barrera nueva basada en el diff final y la revisión base actual. Reutilizar la aprobación de planificación para el despliegue mezcla dos decisiones distintas.

Los tokens de aprobación deben ser de un solo uso. Si la ejecución falla antes del commit, el sistema puede emitir una solicitud nueva que haga referencia a la acción anterior y muestre qué cambió. Repetir el mismo token tras una respuesta ambigua puede duplicar un efecto o aplicar una decisión vieja a un estado nuevo.

Da al ejecutor menos autoridad que producción

El ejecutor de confianza debe tener solo las capacidades registradas en la política de acciones, no una credencial general de administrador de producción. Sacar la clave de escritura del proceso del agente sirve de poco si el ejecutor puede convertir cualquier cadena generada por el modelo en una llamada de API, un comando de shell o una sentencia SQL arbitrarios. El límite necesita operaciones tipadas con validación estricta de parámetros.

Crea un adaptador por tipo de acción. Un adaptador para el estado de un cliente podría aceptar su ID, la versión esperada del registro y un valor de una pequeña enumeración. No debería aceptar una URL sin procesar, cabeceras arbitrarias ni una consulta libre. Un adaptador de repositorio puede aplicar un parche validado a un único repositorio identificado sin ofrecer un shell. Supone más trabajo que exponer un conector genérico, y ese trabajo es lo que da sentido a la aprobación.

Limita al ejecutor tanto en el destino como en el código de la aplicación. Permite que su identidad de base de datos invoque procedimientos almacenados aprobados en lugar de escribir todas las tablas. Restringe los roles de nube a clases de recursos identificadas y operaciones permitidas. Limita las credenciales de repositorio por organización y repositorio. Usa una política de red que impida a un adaptador llegar a servicios ajenos incluso si un parámetro mal formado intenta redirigirlo.

Trata la salida de las herramientas como entrada no fiable. La descripción de un problema, un comentario del código fuente, un valor de base de datos o una respuesta web pueden contener texto que intente influir en el agente. Suele tratarse como inyección de prompt, pero la consecuencia para el control es más sencilla: el contenido leído de un destino nunca se convierte en autoridad para volver a escribir allí. Solo la política y un token de aprobación válido conceden autoridad. El ejecutor analiza campos tipados y rechaza instrucciones escondidas en campos de datos.

Los secretos requieren el mismo alcance limitado. El modelo rara vez necesita ver una credencial. Deja que el ejecutor resuelva una referencia después de la aprobación, la use para una operación registrada y mantenga el valor fuera de prompts, vistas previas, errores y registros. Cuando un destino requiera un secreto estático potente, coloca delante un intermediario capaz de emitir una credencial de corta duración y limitada a la acción. Si el destino no admite ese alcance, clasifica el adaptador según todo el poder de la credencial, no según la modesta intención de la solicitud actual.

El agente tampoco debe poder registrar un tipo de acción nuevo durante la ejecución. El código de los adaptadores, los esquemas, las representaciones, los controladores de recuperación y las asignaciones de políticas pertenecen al plano de control revisado. Actualizarlos es una versión de software con su propio proceso humano. De lo contrario, el agente puede sortear una operación prohibida inventando un nombre más amable y encaminando por él la misma llamada destructiva.

Por último, separa la identidad de ejecución de la persona que aprueba. El sistema de destino debe registrar que el ejecutor hizo la escritura en nombre de un solicitante identificado y bajo una aprobación identificada, en vez de suplantar al revisor. Así se conserva la responsabilidad sin enseñar a la gente que aprobar significa prestar al agente toda su sesión.

Mide si las personas pueden decidir

La calidad de la aprobación se puede observar. Si casi todas las solicitudes se aprueban en segundos, quizá el flujo contenga ruido de bajo riesgo o los revisores se hayan acostumbrado a pulsar sin leer. Si abren repetidamente registros sin procesar para entender una propuesta, falta información en la representación principal. Si las propuestas caducadas se vuelven a aprobar sin inspección, el requisito de actualidad se ha convertido en otro botón molesto.

Recoge medidas del proceso sin calificar a empleados concretos por velocidad. Las señales útiles incluyen tiempo hasta la decisión por clase de acción, motivos de rechazo, solicitudes devueltas por falta de contexto, cargas útiles cambiadas tras el rechazo, fallos de precondiciones obsoletas, uso de la vía de emergencia y recuperaciones ejecutadas. Compara estas señales por tipo de acción y versión de interfaz. Una sola tasa global de aprobación oculta el adaptador problemático.

Pide motivos de rechazo estructurados y ofrece texto libre opcional. Mantén corta la lista: objetivo equivocado, alcance inesperado, pruebas insuficientes, momento inseguro, recuperación poco creíble y conflicto con la política cubren la mayoría de decisiones técnicas. Devuelve esos motivos al esquema y la representación. Si se elige a menudo objetivo equivocado, sube la identidad y el entorno en la tarjeta. Si se repite recuperación poco creíble, deja de afirmar que la clase es reversible hasta que su controlador supere un simulacro.

Las colas necesitan propiedad y escalado. Una solicitud enviada a un canal amplio diluye la responsabilidad; todo el mundo supone que alguien más cercano al sistema la revisará. Enruta por sistema y clase de acción a un grupo pequeño de guardia, muestra quién asumió la revisión y libera la asignación si permanece inactiva. El solicitante debe ver que la propuesta espera, pero no debe poder presionar a la interfaz para que elija una aprobación predeterminada.

Diseña el diálogo para permitir el rechazo. El control Rechazar debe ser tan accesible como Aprobar, y cerrar el diálogo no puede equivaler a consentimiento. No preselecciones la aprobación, no uses presión con una cuenta atrás ni escondas detalles destructivos tras paneles plegados. Para diffs complejos, permite buscar y filtrar mientras el resumen canónico y su huella permanecen visibles. La accesibilidad forma parte del control de seguridad porque un revisor incapaz de operar la vista comparativa no puede examinar la acción.

Selecciona una muestra de acciones aprobadas para una revisión independiente. Compara la propuesta representada, la carga útil canónica, el recibo del destino y el resultado observado. Puede revelar campos ambiguos, adaptadores que añaden valores predeterminados en el destino y revisores asignados fuera de su competencia. Usa los hallazgos para cambiar políticas o interfaces, no solo para recordar a las personas que tengan cuidado.

La fatiga de aprobación suele ser un fallo de clasificación. Pasa las acciones previsibles y de pocas consecuencias a una política automática limitada, con topes y vigilancia. Combina cambios relacionados en un lote acotado cuando una decisión realmente los cubra. Conserva barreras individuales donde el contexto humano pueda cambiar el resultado. Unas pocas decisiones serias reciben más atención que una corriente de solicitudes ceremoniales.

Las reescrituras heredadas necesitan pruebas de paridad

En la reescritura de un sistema heredado, la aprobación debe asociarse a la promoción de un cambio de comportamiento verificado, no a cada archivo generado. Los agentes necesitan espacio para inspeccionar todo el árbol de fuentes, trazar dependencias, generar el código de destino y ejecutar pruebas de forma aislada. El momento con consecuencias llega cuando el nuevo servicio, cliente, esquema o núcleo numérico puede alcanzar tráfico o datos de producción.

Un diff de código fuente por sí solo es una prueba débil. Los revisores necesitan la revisión fuente, la revisión de destino generada, las decisiones de arquitectura con efectos operativos, los cambios de esquema y los resultados de paridad frente al comportamiento registrado en producción. También necesitan una lista clara de diferencias intencionadas. Una compilación correcta dice que el código nuevo compila. No dice que un cálculo de cierre mensual reescrito coincida con el programa que ha sostenido el negocio durante años.

CodeHero lee toda la base de código con sus distintos lenguajes y comprueba el comportamiento reescrito con un banco de paridad frente al tráfico de producción registrado. Esas pruebas deben aparecer junto a la solicitud de promoción, sin permitir que un resumen oculte las diferencias. En entornos regulados, sus modelos pueden ejecutarse sin conexión dentro del perímetro del cliente, aunque los controles de aprobación y auditoría del cliente siguen decidiendo quién puede promover el resultado.

Trata la migración de datos como una acción de escritura propia. Aprueba la versión exacta del esquema, el resumen de la transformación, el alcance de filas, las consultas de validación, las precondiciones del cambio y el punto de recuperación. Una aprobación para promocionar código no debe autorizar silenciosamente una carga retroactiva, ni la aprobación de esa carga debe autorizar la eliminación del almacén anterior. Las operaciones tienen distintos fallos y distintos tiempos de recuperación.

La misma separación se aplica a modernizar la arquitectura. Un agente puede proponer dividir un monolito o sustituir un archivo compartido por Postgres, pero la aprobación debe cubrir consecuencias observables: cambios de enrutamiento, propiedad de datos, comportamiento concurrente y reversión operativa. De lo contrario, se pide al revisor que apruebe una etiqueta de diseño en vez de un efecto del sistema.

Prueba el control intentando evitarlo

Un sistema de aprobación solo está listo cuando las pruebas demuestran que el agente no puede rodearlo. Un diálogo correcto en el caso esperado muestra que la interfaz funciona. No demuestra que toda escritura de producción atraviese el ejecutor ni que el token esté vinculado a la carga útil mostrada.

Ejecuta casos adversos contra el control:

1. Cambia un parámetro después de la aprobación y confirma que la comprobación del resumen rechaza la ejecución.
2. Cambia la versión del destino mientras el diálogo está abierto y confirma que falla la precondición.
3. Repite un token de aprobación y confirma que el ejecutor rechaza su segundo uso.
4. Quita un campo obligatorio y confirma que la representación muestra un error en lugar de aplicar un valor predeterminado.
5. Deniega la aprobación y confirma después que el agente no puede llamar al conector mediante otra credencial o herramienta.

Añade simulacros de recuperación, no solo pruebas unitarias. Elige una acción segura parecida a producción, ejecútala, invoca el identificador de recuperación registrado y verifica el estado posterior. Mide si los operadores pueden encontrar la acción por ID, identificar al aprobador, reconstruir la carga útil mostrada y saber si terminó la recuperación. Un control que solo existe en la documentación fallará justo cuando el sistema esté bajo presión.

Revisa las tasas de aprobación y excepciones para detectar problemas de diseño. Una aprobación casi universal puede significar que las solicitudes son lo bastante rutinarias para una política automática más estrecha, o que los revisores han dejado de leer. Los rechazos frecuentes por falta de contexto señalan un esquema de acción o una representación deficientes. No soluciones la fatiga enseñando a la gente a pulsar más deprisa. Elimina barreras de pocas consecuencias y mejora las restantes.

El acceso de emergencia debe dejar más pruebas

El acceso de emergencia puede acortar la ruta de aprobación, pero nunca debe borrar la identidad, el alcance ni el registro de auditoría. Defínelo antes de un incidente: quién puede invocarlo, qué acciones permite, cuánto dura la capacidad y quién revisa su uso después. Una credencial administrativa vaga de «romper el cristal», compartida por un equipo, es una vía de escape imposible de atribuir.

Usa una solicitud autenticada individualmente, una capacidad limitada y con vencimiento, un motivo capturado antes de la ejecución y una notificación inmediata a alguien distinto del solicitante. Conserva la misma carga útil canónica y el mismo sobre de resultados que en el funcionamiento normal. Si la urgencia impide la aprobación previa, exige una revisión retrospectiva rápida, pero no finjas que esa revisión fue una autorización. Llámala por su nombre.

El sistema debe cerrarse ante escrituras peligrosas cuando el servicio de aprobación no esté disponible. El trabajo de lectura y la preparación aislada pueden continuar. Las propuestas en cola pueden esperar. Permitir que el agente confirme porque el plano de control está caído vuelve el control menos eficaz durante una interrupción, justo cuando los operadores tienen menos atención disponible.

Una aprobación significativa es deliberadamente limitada: un actor conocido, una acción canónica, un estado actual, un efecto acotado y un resultado registrado. Sitúa ese contrato en el ejecutor, mantén autoridad y pruebas fuera del alcance del agente, y rechaza la automatización cuando no exista una ruta de recuperación sincera.