¿Qué ocurre si algo sale mal?

Imaginemos un error de publicación. Una empresa va a realizar una actualización importante de los precios de su sitio web.

El agente de IA recibe este encargo: «Incorpora los nuevos precios de los servicios, mantén la coherencia en todos los idiomas y publica después de las pruebas necesarias». Encuentra los archivos correctos, actualiza los registros de precios y modifica las páginas de servicios en seis idiomas. Regenera los datos estructurados, ejecuta la compilación y supera las pruebas. La publicación en producción se completa. A primera vista, todo ha salido bien. Unas horas después, el equipo comercial detecta un problema: el agente ha interpretado el precio anual de un servicio complementario como el precio mensual del servicio principal. La cifra es real. El nombre del servicio es real. Técnicamente, la publicación es impecable.

Canonical, hreflang, el sitemap, los datos estructurados y todas las versiones lingüísticas coinciden por completo. Pero todos difunden el mismo error con absoluta coherencia. Y el error ya no está en una sola página.

El precio se ha incorporado a:

• la página visible del servicio;
• el catálogo legible por máquinas;
• el esquema de preguntas frecuentes;
• los metadatos de búsqueda;
• las versiones correspondientes en seis idiomas;
• las notificaciones a terceros.

La publicación de los archivos ha terminado en términos técnicos, pero el trabajo en su conjunto ha fracasado. Una información comercial incorrecta se ha propagado por distintos recursos técnicamente coherentes entre sí. ¿Qué ocurre ahora?

¿Basta con restaurar los archivos anteriores para dar el problema por resuelto?

¿Qué pasa si los buscadores ya han rastreado el precio erróneo?

¿Y si un sistema de IA lo ha leído?

¿Si un cliente ha hecho una captura de pantalla?

¿Si ese precio ya ha generado expectativas durante una conversación comercial?

¿Se corregirá la información errónea difundida en seis idiomas solo en el plano técnico, o también se explicará lo ocurrido a las personas?

Y la pregunta principal: ¿por qué pasó este error por los controles de publicación?

El contrato de comportamiento de GBO no puede limitarse a explicar cómo iniciar la acción correcta. También debe describir qué hacer cuando empieza una acción incorrecta o cuando una acción aparentemente correcta causa un daño inesperado.

Por eso, la última pregunta de la segunda parte es:

¿Qué ocurre si algo sale mal?

Incorporar la posibilidad de error al diseño

Aunque un sistema de agentes esté bien diseñado y probado, no debemos suponer que nunca fallará durante su uso. La información puede estar desactualizada. La identidad puede resolverse mal. El propósito del usuario puede entenderse solo en parte. La autorización puede interpretarse con excesiva amplitud. Un servicio externo puede responder de forma inesperada. La conexión de red puede interrumpirse. Una transferencia de archivos puede quedar a medias. Una API puede ejecutar dos veces la misma operación. Una persona puede aprobar algo por error. Un agente puede modificar un estado que las pruebas no cubren. Un modelo puede establecer una relación equivocada entre fuentes correctas. Incluso una operación técnicamente exitosa puede perjudicar a una persona.

La fiabilidad no se construye solo esperando que no haya errores. Importa ejecutar la función prevista de forma correcta y consistente, pero también saber qué hacer cuando aparece una desviación. Detectar pronto el error, limitar sus efectos, volver a un estado seguro, informar a las personas y evaluar las posibilidades de reparación forman parte del diseño. Un sistema que solo funciona cuando todo marcha según lo previsto no es maduro. La madurez se manifiesta cuando las cosas no siguen el plan.

Error y daño no son lo mismo

No todo error causa daño. Un agente puede escribir mal una palabra sin consecuencias relevantes. Un informe puede presentar fechas con formatos distintos: un problema de calidad corregible. Sin embargo, algunos errores aparentemente pequeños pueden causar grandes daños. Una coma puede cambiar el significado de un precio. Una dirección de correo equivocada puede llevar información confidencial a otra persona. Interpretar mal una hora del calendario puede hacer que se pierda una reunión importante. Una línea de configuración puede bloquear todo el sitio a los buscadores. Vincular un modelo de voz a la cuenta equivocada puede provocar el uso de la identidad de otra persona.

Conviene distinguir dos conceptos:

Error

Una desviación del sistema respecto de la información, decisión, operación o resultado esperado.

Daño

El efecto negativo de esa desviación sobre una persona, una organización, el dinero, los derechos, la confianza, la reputación, los datos o un sistema. Un error puede detectarse antes de causar daño. Ese es el mejor escenario. Si el daño ya se ha producido, aún puede ser posible revertir la operación errónea, pero la situación es más difícil. Además, una reversión técnica puede no eliminar todo el daño. GBO no busca únicamente reducir la tasa de errores.

Busca impedir que el error se convierta en daño y garantizar que, si el daño se produce, la persona disponga de una vía efectiva de recuperación.

No todos los fallos son iguales

«La operación ha fallado» es una frase demasiado amplia. El comportamiento de un agente puede fallar de formas distintas.

Operación correcta con información incorrecta

El agente aplica correctamente la información recibida, pero esa información es errónea. Por ejemplo, incorpora un precio equivocado a todas las páginas sin cometer ningún error de ejecución.

Operación incorrecta con información correcta

El agente tiene datos correctos, pero modifica el archivo equivocado, escribe a otra persona o utiliza una cuenta distinta de la que corresponde.

Operación exitosa sin autorización

La acción es técnicamente impecable, pero el agente no tiene autorización para realizarla.

Ejecución parcial

Se actualizan cinco de los seis idiomas. Se realiza un pago, pero no se crea el registro del pedido. Se cargan los archivos, pero el sitemap sigue siendo el anterior.

Ejecución duplicada

El sistema interpreta que la operación ha fallado porque se agotó el tiempo de espera y vuelve a intentarlo. Se cobra dos veces al usuario o se envía dos veces el mismo mensaje.

Fallo silencioso

El sistema informa de un éxito, pero la operación no se ha producido en el mundo exterior. La herramienta de transferencia indica «completado», aunque algunos archivos siguen siendo los antiguos.

Fallo diferido

Al principio, la operación parece correcta. El problema aparece horas o días después. Una suscripción se renueva automáticamente. La información errónea se extiende por los resultados de búsqueda.

Fallo en cadena

Un solo error pasa a otros sistemas. El precio equivocado llega al catálogo, al sitio web, al agente comercial, a los buscadores y a los documentos de oferta.

Fallo en el plano humano

El sistema técnico funciona como se esperaba, pero la persona recibe información incorrecta, aprueba bajo presión o no comprende las consecuencias de la decisión. Cada tipo de fallo exige una recuperación distinta. Un único botón de «deshacer» no resuelve todos los problemas.

Éxito técnico no equivale a éxito real

Una operación puede producir estos resultados técnicos:

• HTTP 200
• Compilación correcta
• Archivo cargado
• Llamada a la API aceptada
• El servidor de correo recibió el mensaje
• El proveedor de pagos procesó la solicitud
• IndexNow aceptó la notificación

Son pruebas útiles, pero no demuestran por sí solas el resultado más amplio. HTTP 200 no prueba que el usuario vea el contenido correcto. Cargar un archivo no demuestra que el sistema en producción funcione bien. Que un servidor acepte un correo no prueba que llegue a la persona adecuada ni que se entienda correctamente. La aceptación de una notificación de rastreo no demuestra indexación ni posicionamiento. Procesar un pago no significa que se haya comprado el producto adecuado.

GBO mantiene, por tanto, una distinción: aceptar una operación no es alcanzar el objetivo. No debe darse por terminada la acción de un agente solo por una respuesta técnica. También hay que verificar el estado esperado en el mundo real.

Las afirmaciones de éxito también se auditan

Los agentes no solo cometen errores. A veces interpretan el resultado como más exitoso de lo que realmente es.

Un sistema puede decir: «La publicación está completa». Pero quizá solo haya terminado la transferencia de archivos. Aún no se ha comprobado lo que sirve el sitio en producción por HTTPS.

Un agente puede decir: «Se ha enviado a los buscadores». Eso no es indexación.

Un modelo puede decir: «El usuario ha quedado satisfecho». Quizá el usuario simplemente no haya respondido.

Un agente comercial puede decir: «Se ha encontrado un cliente potencial cualificado». Pero aún no se han verificado su presupuesto real ni sus facultades de decisión. Por eso, el lenguaje del éxito también debe estar sujeto al contrato.

¿Qué se ha demostrado? ¿Qué no se ha demostrado todavía? ¿Qué resultado es solo un paso intermedio? ¿Qué incertidumbre persiste?

Un agente fiable declara con claridad los límites de su éxito.

Primero detener; después explicar

Al detectar un error, solemos querer entender primero la causa. Es una reacción natural. Si la operación sigue causando daño, la prioridad es frenar su propagación dentro de la autorización y del plan de parada segura definidos de antemano. La forma de detenerla importa: un cierre indiscriminado también puede causar daño. Si un agente envía correos a destinatarios equivocados, primero hay que detener la cola de envío. Si se ha difundido un precio incorrecto, debe suspenderse temporalmente la generación automática de ofertas. Si se transfieren datos a un destino no autorizado, debe cortarse la conexión. Si un avatar publica contenido incorrecto, el flujo de publicación y el acceso afectados deben limitarse conforme al plan de incidentes.

Si una versión de software está corrompiendo datos, el tráfico debe dirigirse a una versión segura.

El primer principio de la gestión de incidentes es este: si el daño continúa, detén primero el comportamiento. La causa raíz puede investigarse después. Explicar importa, pero no tiene prioridad sobre detener el daño que sigue produciéndose.

Parada segura

Cuando detecta un problema, el agente no debe dejar el sistema en un estado arbitrario.

Siempre que sea posible, debe existir un estado seguro definido de antemano. Es la forma de funcionamiento en la que el sistema causa el menor daño durante un error o una situación de incertidumbre.

Para un agente de correo, el estado seguro consiste en:

Dejar de enviar mensajes nuevos y conservar los entrantes sin perderlos.

Para un sitio web:

Volver a la última versión verificada o desactivar temporalmente solo la función afectada.

Para un agente de compras:

No realizar nuevos pagos y conservar los carritos abiertos y los borradores.

Para un sistema de avatares:

Detener la generación y publicación de contenido nuevo sin borrar los registros que sirven de prueba.

Para un portal de clientes:

Desactivar las operaciones sensibles y mantener, si es posible, el acceso básico de lectura. El estado seguro no es igual para todos los sistemas. Hay que definirlo antes.

¿Qué ocurrirá cuando el agente se detenga?

Sin una respuesta a esta pregunta, la parada de emergencia puede convertirse en otro problema.

Optar por la seguridad cuando algo falla

Un sistema puede responder al fallo de dos maneras: continuar la operación pese a la incertidumbre o detener la acción de alto riesgo. En ciertos sistemas de bajo riesgo puede ser correcto mantener el servicio. Pero cuando intervienen autorizaciones, pagos, datos personales, identidad u operaciones irreversibles, lo adecuado es optar por la seguridad.

Por ejemplo:

• Si no puedes verificar el precio, no envíes la oferta.
• Si la autorización no está clara, no publiques el mensaje.
• Si no puedes resolver la identidad, no realices el pago.
• Si no hay un registro de consentimiento, no utilices el rostro ni la voz.
• Si el hash no coincide, no des por correcta la versión en producción.
• Si no hay un registro de aprobación humana, no asumas un compromiso.

Este enfoque puede ralentizar el trabajo en ocasiones. A cambio, ayuda a impedir que un riesgo identificado se convierta en una operación sin control.

Actuar deprisa bajo incertidumbre no es ser fiable.

¿Qué significa revertir?

Revertir consiste en devolver el sistema a un estado seguro anterior. Pero «vuelve a la versión anterior» no siempre basta. Un sitio puede recuperar sus archivos antiguos. Una base de datos puede restaurarse. Un pago puede cancelarse. Un mensaje puede retirarse de la cola de envío. Son reversiones técnicas. Sin embargo, algunas acciones que ya han salido al mundo exterior no pueden deshacerse por completo. El correo enviado puede haberse leído. El vídeo publicado puede haberse copiado. Una decisión errónea puede haber afectado a la confianza de una persona. Un cliente puede haber hecho planes a partir de un precio equivocado. Un candidato puede haber sido descartado injustamente.

Una decisión sanitaria o financiera puede haber tenido consecuencias. Por eso hay que pensar en la reversión en tres planos distintos.

Reversión técnica

¿Puede restaurarse el estado anterior del sistema?

Reversión de la operación

¿Pueden cancelarse el pedido, el pago, la reserva, el contrato o la publicación?

Reversión de los efectos humanos

¿Puede eliminarse de verdad el efecto sobre la privacidad, la confianza, la reputación, las oportunidades o los derechos?

El tercer plano suele ser el más difícil.

La ilusión de poder deshacer

Una organización puede decir: «No se preocupen, tenemos una copia de seguridad». La copia es importante, pero no constituye por sí sola un plan de recuperación.

La copia de seguridad puede:

• estar desactualizada;
• estar dañada;
• no corresponder al sistema adecuado;
• contener datos personales;
• tardar horas en restaurarse;
• no revertir los cambios en otros sistemas.

Del mismo modo, un botón de «eliminar» no equivale a una reversión real. Se puede borrar una publicación, pero las capturas de pantalla permanecen. Se puede eliminar un registro, pero ya se ha copiado a otros sistemas. Se puede retirar un modelo de avatar, pero los archivos de audio generados ya circulan fuera.

GBO pregunta: ¿qué parte del efecto producido revierte realmente esta operación?

La escala de irreversibilidad

Para examinar la dificultad de revertir una acción podemos utilizar estos niveles ilustrativos. No se asignan automáticamente por el nombre de la operación: hay que estudiar el flujo real de datos, las copias y los efectos externos.

1. Totalmente reversible

Por ejemplo, un cambio en un borrador que no se ha exportado, no tiene efectos secundarios y conserva una copia anterior segura.

2. Fácilmente reversible

Un pequeño cambio publicado en el sistema que aún no ha producido efectos externos.

3. Parcialmente reversible

Una reserva, un pedido o una publicación programada con posibilidad de cancelación; incluso cancelados, pueden dejar costes o tiempo perdido.

4. Corregible en el sistema, con posibles efectos duraderos sobre las personas Un precio incorrecto que alguien ya ha visto, un correo que el destinatario ha leído o una exposición breve de datos. Aunque cambie el registro de origen, puede ser imposible recuperar la información que ha salido.

5. Difícil de reparar

Un uso indebido de identidad difundido públicamente, una filtración de datos confidenciales o una decisión injusta de contratación.

6. Irreversible

Datos únicos eliminados, daño físico ya causado, pérdida irrecuperable de un plazo legal o un desenlace mortal.

A medida que una acción asciende en esta escala, requiere:

• una verificación de identidad más rigurosa;
• una autorización más limitada;
• una aprobación humana más explícita;
• más comprobaciones independientes;
• un plan de reversión más detallado.

Estas exigencias aumentan a medida que crece la irreversibilidad.

A mayor irreversibilidad debe aumentar la responsabilidad, no la autonomía.

Punto de retorno

En algunas operaciones resulta fácil volver atrás hasta un momento determinado.

Podemos llamarlo punto de retorno.

En un correo:

Antes de enviarlo.

En una compra:

Antes de aprobar el pago.

En una publicación de software:

Antes de iniciar un cambio irreversible en los datos o de dirigir el tráfico a la nueva versión; ambas cosas pueden ocurrir en momentos distintos. En una migración de datos, sobre todo, el límite puede ser el primer paso irreversible, no la finalización de toda la operación.

En una publicación en redes sociales:

Antes de que sea pública.

En un contenido con un avatar de IA:

Antes de distribuirlo en plataformas externas. El agente debe conocer el punto de retorno. Al acercarse a él, puede entrar en juego una aprobación humana o una verificación más exigente.

Plazo de reversión

Algunos sistemas ofrecen un periodo de cancelación o reversión con condiciones definidas de antemano. Los plazos siguientes ilustran ese diseño; no hay que suponer que todos los servicios los ofrecen. Un pedido puede cancelarse en diez minutos. Un correo puede enviarse con unos segundos de retraso. Una nueva versión puede abrirse primero a un grupo pequeño de usuarios. Una versión de archivo puede conservarse junto a la copia anterior durante un periodo determinado.

Podemos llamarlo plazo de reversión. Un buen sistema lo hace visible. «Puede cancelar esta operación en cinco minutos». «La nueva versión funcionará con tráfico controlado durante los primeros treinta minutos». «El mensaje se enviará tras dos minutos de espera». Pequeñas demoras pueden evitar grandes errores.

Puntos de control

En tareas largas y complejas, el sistema debe crear estados seguros intermedios.

Podemos llamarlos puntos de control.

En un proyecto web, un punto de control puede ser:

• un commit cuyo alcance se ha verificado;
• una etiqueta de versión;
• un manifiesto de despliegue;
• una copia de seguridad;
• un registro de hash.

Estos elementos permiten dejar constancia de un estado al que volver.

En un tratamiento de datos se pueden conservar:

• el límite de los registros ya procesados;
• un resultado intermedio;
• la versión de la fuente;
• una suma de comprobación.

Así queda registrado el estado intermedio del trabajo.

En una conversación con un agente se puede registrar:

• qué candidatos se han evaluado;
• qué supuestos se han adoptado;
• qué autorización está vigente.

Los puntos de control no son una mera comodidad técnica. Permiten al agente retomar el trabajo con seguridad cuando se reduce el contexto o se interrumpe la tarea.

Proteger la página de inicio

Al realizar un cambio de alcance limitado, las áreas ajenas a él deben permanecer intactas. Actualizar una página de servicio no debe dañar por accidente la página de inicio, otros servicios ni los registros compartidos de precios.

Para ello, el sistema puede seguir este procedimiento:

Indica qué archivos deben cambiar. Registra los hashes de los archivos críticos que deben permanecer intactos. Verifica ambos grupos después de publicar.

Esto no se limita a los sitios web. Un agente de compras solo debe modificar el carrito aprobado. Un agente de correo solo debe enviar al destinatario indicado. Un agente de datos solo debe tratar los campos permitidos.

Una tarea limitada debe tener un impacto limitado.

Alcance del impacto

Una de las primeras preguntas ante un error es: ¿hasta dónde han llegado sus efectos?

A eso podemos llamarlo alcance del impacto.

Un error puede haber afectado a:

• un solo usuario;
• un solo archivo;
• las páginas en seis idiomas;
• toda la base de datos de clientes;
• una lista de correo de miles de personas;
• toda la red de agentes.

El mismo error puede tener una gravedad completamente distinta según el alcance de sus efectos. Por eso, el sistema debe intentar limitar el impacto antes de actuar.

Por ejemplo:

• Prueba primero solo las seis URL de destino.
• Inicia la nueva campaña de mensajes con un grupo pequeño.
• Prueba la versión de software con tráfico limitado.
• Limita la nueva autorización del agente a una sola cuenta.
• Ejecuta la transformación de datos sobre una copia.

Podemos llamarlo reducción del alcance del impacto. Es la misma pregunta que plantea el concepto de blast radius utilizado en seguridad: si algo sale mal, ¿hasta dónde puede propagarse el daño?

Publicación gradual

En lugar de trasladar a todos los usuarios a un sistema nuevo a la vez, el cambio puede publicarse por etapas. Primero el equipo interno. Después un grupo pequeño de usuarios. Luego un volumen de tráfico mayor. Por último, todo el sistema.

Esto permite examinar desde el principio cuatro aspectos:

• rendimiento;
• errores;
• comportamiento de los usuarios;
• seguridad.

Así se detectan antes los problemas. La misma lógica sirve para la comunicación: probar un proceso de comunicación autorizado con un grupo pequeño, cuyo alcance y aprobación estén definidos; utilizar un canal controlado antes de publicar en todas las redes; empezar por un mercado concreto antes de extenderse a todos los países. La publicación gradual no siempre es posible. Pero, cuando el impacto potencial es amplio, es un método de seguridad sólido.

Seguridad de los reintentos

Un agente puede no saber si una operación ha terminado bien. Se corta la conexión. El sistema de pagos responde tarde. La API de correo agota el tiempo de espera. Si vuelve a intentarlo, la operación podría ejecutarse dos veces.

Por eso, las acciones importantes deben diseñarse para que repetir la misma solicitud no provoque una ejecución duplicada no deseada. Puede utilizarse un identificador único de operación junto con un mecanismo que lo conserve y controle las repeticiones en el ámbito correcto. Los reintentos de una misma solicitud deben vincularse al mismo identificador. Crearlo no evita por sí solo los duplicados: también hay que verificar cómo procesa las repeticiones el sistema receptor, sus límites de tiempo y el comportamiento ante solicitudes simultáneas. Un pago no debe cobrarse dos veces. Una campaña no debe reenviarse al mismo destinatario. Una misma versión de archivo no debe multiplicarse como si fuera una operación nueva.

El agente debe distinguir entre «no llegó la respuesta» y «la operación no ocurrió».

¿Cómo se gestiona el éxito parcial?

Si se han publicado cinco de seis idiomas, el sistema no debe decir: «La publicación está completa».

Debe decir: «Cinco idiomas están completos. La versión árabe no se publicó porque no superó la verificación RTL». Si se ha pagado, pero no se ha creado el pedido, la operación no debe darse por cerrada. Si se ha enviado un correo sin cargar el adjunto, el resultado está incompleto.

Al comunicar un éxito parcial hay que indicar:

• la parte completada;
• la parte pendiente;
• el riesgo que sigue abierto;
• qué está disponible para su uso;
• el siguiente paso necesario;
• si hace falta una decisión humana.

Presentar un éxito parcial como completo induce a los sistemas posteriores a actuar mal.

Fallo silencioso

Cuando una operación fallida parece exitosa, las decisiones posteriores parten de una premisa falsa. La herramienta de transferencia puede indicar «completado», pero el archivo del servidor remoto sigue siendo el antiguo. El sistema de envío acepta la solicitud, pero el filtro de spam impide que el mensaje llegue al destinatario. Se compila un registro de datos estructurados, pero no aparece en el HTML publicado. Un agente cree haber recibido aprobación humana, pero esa aprobación corresponde a otra operación. Detectar estos fallos requiere una verificación independiente.

La declaración de éxito del propio sistema ejecutor no debe ser la única prueba.

Por ejemplo:

• Después de transferir los archivos, obtén la respuesta del sitio en producción por HTTPS y compárala con la versión esperada.
• Después de comprobar la página local, comprueba el HTML publicado.
• Después del pago, compara los registros del vendedor y del banco.
• Después de enviar el mensaje, verifica los registros del destinatario, asunto y adjunto correctos.
• Después de utilizar una autorización, vuelve a leer su versión vigente.

Verificación independiente

Un agente realiza una acción. Otro método comprueba el resultado.

Podemos llamarlo verificación independiente. La herramienta de publicación afirma que ha cargado el archivo; una comprobación HTTP independiente compara el hash del archivo publicado. El código supera las pruebas; un navegador real comprueba la visualización móvil y de escritorio. Se generan los datos estructurados; se lee aparte el contenido semántico de la página publicada. El sistema de pagos considera exitosa la operación; se contrastan el registro contable y el pedido del vendedor. Utilizar otra herramienta ayuda, pero no garantiza independencia si se basa en la misma fuente errónea. Hay que verificar tanto el resultado de la operación como la fuente correcta que debe fundamentar el contenido o la decisión.

Declaración de éxito incorrecta

Un agente puede declarar un éxito falso sin intención de engañar. El riesgo aparece al confundir el éxito de un paso intermedio con el resultado final, o al recompensar más la finalización de la tarea que su verificación.

GBO prefiere este lenguaje: «La transferencia de archivos ha terminado; el contenido publicado aún no se ha verificado». «La notificación de rastreo se ha aceptado; no demuestra indexación». «Las pruebas en el entorno de ensayo se han superado; el rendimiento en producción no se ha medido». «La solicitud de oferta se ha enviado; todavía no se conoce el interés del cliente ni el resultado comercial». Esta distinción sostiene la confianza.

¿Qué es un incidente?

No todo error requiere una gestión formal de incidentes. Una errata pequeña puede corregirse directamente.

Pero una situación debe tratarse como incidente cuando afecta a:

• los datos;
• la identidad;
• el dinero;
• la comunicación externa;
• el sistema en producción;
• un compromiso legal;
• un derecho humano.

Los efectos en estos ámbitos requieren tratar lo ocurrido como un incidente.

Podemos definir este tipo de incidente de la siguiente forma:

Incidente de comportamiento de un agente

Una desviación del sistema de IA respecto del comportamiento previsto, permitido o esperado que causa un daño real o un riesgo razonable de daño para personas, organizaciones, datos, recursos, derechos, confianza o integridad del sistema. El incidente no se limita al daño ya producido. Una posibilidad de daño grave también puede considerarse un incidente.

Gravedad del incidente

No todos los incidentes son iguales. Podemos usar una clasificación práctica.

Baja

Error pequeño, local y fácil de corregir.

Media

Efectos limitados sobre usuarios o procesos; requiere intervención humana.

Alta

Daño económico, datos personales, comunicación externa, interrupción grave del servicio o representación errónea ampliamente difundida.

Crítica

Filtración extensa de datos, grandes pérdidas financieras, daño legal o físico irreversible, abuso de identidad o comportamiento del agente fuera de control.

A medida que aumenta la gravedad:

• se detiene un conjunto más amplio de acciones automáticas;
• se informa a responsables humanos de mayor nivel;
• se realiza una revisión independiente;
• se evalúan las notificaciones externas y las obligaciones legales.

Los primeros minutos del incidente

El plan de incidentes debe abordar estas tareas de forma conjunta. El orden siguiente es ilustrativo: cuando sea necesario, la notificación urgente al responsable humano y la parada segura se realizan en paralelo. No hay que esperar a terminar todos los pasos para avisar.

1. Detectar

¿Qué ha ocurrido realmente?

2. Detener

Interrumpe la acción en curso.

3. Contener

¿Qué cuentas, usuarios, archivos o sistemas se han visto afectados?

Impide que los efectos se propaguen.

4. Conservar las pruebas

No borres los registros, las versiones, los mensajes ni las constancias de autorización.

5. Volver al estado seguro

A la última versión verificada o a un modo de funcionamiento seguro.

6. Informar al responsable humano

Contacta con la persona que corresponda a la gravedad del incidente. «Limpiarlo todo inmediatamente» puede ser un error en este momento: si desaparecen las pruebas, no se podrá comprender la causa.

Conservar las pruebas

Cuando ocurre un error, el sistema debe:

• conservar los registros;
• no destruir la versión anterior;
• no alterar el registro histórico de autorización para simular una aprobación previa;
• no perder el historial de mensajes;
• preservar las marcas de tiempo.

Estos registros sustentan el aprendizaje, la auditoría y, cuando corresponda, el ejercicio de derechos. El acceso y los plazos de conservación también deben limitarse a las necesidades del incidente y a las obligaciones aplicables.

¿Qué sabíamos? ¿Qué versión se utilizó? ¿Quién dio la autorización? ¿Qué herramienta invocó el agente? ¿Qué prueba se superó o se omitió? ¿Dónde empezó la primera desviación?

Sin pruebas, el incidente se convierte en un relato. Cada parte lo recuerda de forma distinta. Los registros cuyo origen, integridad y tiempo pueden verificarse ofrecen una base común para investigar. Que una máquina haya generado un registro no lo hace automáticamente verdadero ni inalterable.

Registro del incidente

Podemos ilustrar la información que debe contener un registro de incidente con estos nombres de campo. No constituyen por sí solos un esquema ejecutable:

incident_id

detected_at

detected_by

affected_systems

affected_people

agent_identity

authorization_version

action_receipts

initial_signal

actual_behavior

expected_behavior

impact

containment

rollback

notifications

recourse

compensation

root_cause

contract_change

closed_at

No todos los detalles tienen que ser públicos. Pero debe quedar un rastro suficiente para la auditoría interna del incidente.

Corregir no es lo mismo que reparar el daño

Puede haberse retirado la información errónea del sitio. Eso es corregir. Pero si un cliente pagó basándose en ella, quizá haya que devolverle el dinero. Eso es reparar. Puede descubrirse que se descartó injustamente a un candidato. El registro de la decisión puede corregirse, pero el candidato quizá haya perdido la oportunidad. Los datos de un usuario pueden haberse enviado a la persona equivocada. Es posible borrar el archivo, pero el efecto sobre su privacidad ya se ha producido.

Por eso hay dos tareas distintas:

Corrección

Restablecer el estado correcto del sistema.

Reparación

Intentar remediar el daño sufrido por la persona u organización afectada por el comportamiento erróneo. El equipo técnico suele centrarse en la corrección. GBO incluye también la reparación de los daños sufridos por las personas en el contrato de comportamiento.

Acción compensatoria

Algunas operaciones no pueden deshacerse directamente. Puede realizarse otra acción para reducir sus efectos. Esa nueva acción también necesita autorización propia y debe ser proporcionada y segura. El primer error no concede automáticamente al agente nuevas facultades para contactar con personas o gastar dinero.

Podemos llamarla acción compensatoria. Si una transferencia errónea no puede cancelarse, se puede estudiar la posibilidad de reembolso. Para un mensaje incorrecto ya enviado, una persona autorizada puede decidir que se prepare una rectificación o una disculpa. A los clientes afectados por un precio equivocado se les puede ofrecer información correcta y opciones adecuadas. Si una reserva no puede recuperarse, se puede comprobar si existen alternativas. Si se ha concedido un acceso incorrecto, se limita según el plan de incidentes; los cambios de claves y las notificaciones necesarios se realizan dentro de ese marco. La acción compensatoria no restituye por completo la situación anterior. Pretende reducir el daño. Hay que evaluar aparte si lo ha conseguido y qué efectos persisten.

Una disculpa no basta para reparar

Un sistema o una organización puede decir: «Lamentamos lo ocurrido». Es importante.

Pero para reparar de verdad también hay que responder:

• ¿Qué ocurrió?
• ¿Quién se vio afectado?
• ¿Se ha detenido el riesgo que seguía activo?
• ¿Qué información era incorrecta o qué operación carecía de autorización?
• ¿Qué se corrigió?
• ¿Qué derechos tiene la persona afectada?
• ¿Cómo se remediarán las pérdidas económicas o las derivadas de la operación?
• ¿Cómo se reducirá la posibilidad de que vuelva a ocurrir?

La disculpa no sustituye a la responsabilidad.

Derecho a impugnar

Una persona debe poder impugnar la decisión o la acción de un agente. «Yo no aprobé este mensaje». «Se me aplicó un precio incorrecto». «El agente me confundió con otra persona». «No autoricé que mis datos se transfirieran a este sistema». «Yo no pronuncié las palabras que dice ese avatar». «Quiero ver las pruebas en las que se basa esta elección». Impugnar no es solo abrir una solicitud de atención al cliente. Es una vía para cuestionar el comportamiento de la máquina.

Un sistema de impugnación efectivo debe permitir:

• localizar la acción;
• mostrar el comprobante correspondiente;
• examinar el registro de autorización;
• iniciar una revisión humana;
• detener la operación en curso;
• corregir o reparar cuando sea necesario.

Posibilidad de impugnación

Un sistema puede explicar su decisión. Pero eso no basta si el usuario no puede someterla a una revisión por parte de quien tiene facultades para reconsiderarla.

La explicación puede decir: «Le rechazamos por este motivo».

La posibilidad de impugnación dice: «Si cree que esta decisión es incorrecta, puede aportar estas pruebas y solicitar una revisión». GBO no busca solo un comportamiento explicable.

Comportamiento que se puede impugnar

También hace falta esta posibilidad. Un error explicado sigue siendo un error. La persona debe poder intervenir en la decisión.

¿Cómo debe ser el procedimiento de impugnación?

Un procedimiento efectivo debe:

• ser fácil de encontrar;
• ser comprensible;
• resolverse en un plazo razonable;
• permitir contactar con una persona responsable;
• no generar represalias;
• permitir aportar pruebas;
• poder cambiar realmente la decisión.

No basta con una apariencia de recurso. Si existe un botón para impugnar, pero todas las solicitudes se rechazan automáticamente, no hay un derecho real a hacerlo. La revisión humana no debe limitarse a repetir la decisión de la máquina.

¿Quién puede impugnar?

La vía de impugnación que proponemos en este libro debe estar abierta tanto al usuario del sistema como a los terceros afectados por la acción. Los derechos concretos de recurso legal se evalúan aparte. Puede tratarse del destinatario de un mensaje enviado en nombre de una empresa, de alguien sobre quien se utilizó información errónea, de la persona cuyo rostro o voz aparece en un avatar de IA, de un candidato descartado en una selección automática, de un cliente cuyos datos se compartieron o de una organización representada de forma incorrecta. El contrato de comportamiento no se limita, por tanto, a la relación entre usuario y agente: también evalúa los efectos de la acción sobre terceros.

Derecho de retirada

Una persona puede retirar el consentimiento o la autorización que haya dado previamente.

El alcance de esa retirada no debe confundirse con considerar que las operaciones pasadas nunca ocurrieron. Para los usos futuros y los efectos que continúan, hay que examinar estas cuestiones:

• ¿Se retirarán las publicaciones existentes?
• ¿Se eliminarán los archivos del modelo?
• ¿Se detendrán los subagentes?
• ¿Se cancelarán los contenidos programados?
• ¿Qué ocurrirá con las copias en manos de proveedores externos?
• ¿Cómo se conservarán la documentación de archivo y los registros legales?

Cuando se retira el permiso para usar una voz o un rostro, puede no bastar con detener la generación de nuevos materiales. El contrato también debe definir las condiciones de uso de los contenidos anteriores.

Una vía para hablar con una persona

Ante un problema, el sistema no debe ofrecer únicamente un formulario automático. A partir de cierta gravedad, debe haber una persona concreta responsable del incidente.

El usuario debe saber:

¿Con quién puedo contactar? ¿Cuánto tardarán en responder? ¿Se detendrá la operación mientras tanto? ¿Qué registros tengo que presentar?

GBO no deja a las personas fuera del sistema. Durante la recuperación, hace aún más visible su papel.

¿Quién es responsable?

En una cadena de acciones pueden intervenir muchas partes:

• el usuario;
• la organización que opera el agente;
• el proveedor del modelo;
• el proveedor de la herramienta;
• el proveedor de datos;
• el subagente;
• la persona que aprueba;
• el destinatario de la acción.

Cuando surge un problema, todas pueden decir: «Yo solo hice una parte». Por eso, la responsabilidad no debe discutirse por primera vez después del incidente. Tiene que definirse de antemano en el contrato de comportamiento.

Por ejemplo:

• la persona determina el propósito y da la aprobación final;
• la organización aplica los límites de autorización;
• el agente genera un comprobante de la operación;
• el proveedor de la herramienta registra la respuesta técnica;
• el responsable humano examina la impugnación;
• la organización lleva a cabo la reparación.

La responsabilidad puede repartirse. No debe desaparecer.

«Lo hizo la IA» no es una explicación suficiente

Una organización no puede responder a una acción errónea diciendo únicamente: «Lo hizo la inteligencia artificial».

Esa frase no responde a estas preguntas:

• ¿Quién encargó la tarea al agente?
• ¿Qué autorización recibió?
• ¿A qué herramientas se le dio acceso?
• ¿Qué control faltaba?
• ¿Hacía falta aprobación humana?
• ¿Por qué no se detectó el incidente?
• ¿Quién reparará el daño?

La IA no debe ser una pantalla que oculte la responsabilidad.

Causa raíz

La causa aparente de un incidente puede ser distinta de su causa real. Se publicó un precio incorrecto.

Causa aparente:

El agente utilizó mal la cifra.

Pero la causa raíz podría ser alguna de estas:

• Los nombres de dos servicios eran ambiguos.
• No existía un registro canónico del precio.
• El catálogo para máquinas contradecía la página visible.
• No había una puerta de aprobación humana para cambiar precios.
• La prueba solo comprobaba el formato numérico, no el significado comercial.
• El mismo agente hizo el cambio y aprobó su propio resultado.

El análisis de causa raíz no puede reducirse a «¿Por qué razonó mal el modelo?». Hay que examinar todo el sistema.

Cinco porqués

Podemos preguntar «¿por qué?» varias veces para desentrañar el problema. La cadena siguiente es una explicación posible, no una demostración de la causa raíz. Cada eslabón debe contrastarse con los registros y deben investigarse otras causas.

¿Por qué se publicó un precio incorrecto? Porque el agente confundió dos servicios.

¿Por qué los confundió? Porque la identidad del servicio no estaba clara en los registros de precios.

¿Por qué no estaba clara? Porque no existía un catálogo canónico único.

¿Por qué no existía ese catálogo? Porque los precios solo se conservaban en los textos visibles.

¿Por qué no lo detectó la puerta de publicación? Porque la prueba verificaba el formato, no la relación comercial.

Esta cadena no carga el error únicamente sobre el agente. Muestra una carencia en el diseño del sistema.

Corregir el contrato, no solo a la persona

Ante un error del agente, la primera reacción puede ser: «No vuelvas a hacerlo». Pero si persisten una tarea ambigua, una autorización excesiva o una prueba incompleta, el error reaparecerá de otra forma.

Una mejora duradera debe modificar al menos uno de estos elementos:

• el contrato de identidad;
• el contrato de capacidad;
• el contrato de idoneidad;
• el contrato de autorización;
• el contrato de recuperación;
• las puertas de prueba;
• los permisos de las herramientas;
• el umbral de aprobación humana;
• el traspaso entre agentes.

Una buena revisión de incidentes no busca culpables: busca el vacío del contrato que permitió el comportamiento erróneo.

Esto no elimina la responsabilidad humana. Pero resulta más útil que castigar a una persona y dejar intacto el sistema.

La diferencia entre aprender y castigar

Si los incidentes se ocultan, el sistema no aprende. Si los empleados o los operadores de agentes temen informar de errores, los problemas pequeños pueden crecer.

Una organización fiable debe crear una cultura en la que:

Se fomente avisar pronto. No se tolere ocultar errores. Se distinga el abuso deliberado del error de buena fe. En cada incidente se evalúe si hace falta modificar un contrato o un control, y se registre cualquier cambio junto con su justificación.

No es una cultura de irresponsabilidad. Es una cultura de aprendizaje real.

Cuasiincidente

A veces, el incidente se detiene antes de ocurrir. El agente ha preparado un mensaje para la persona equivocada, pero alguien lo detecta. Un precio erróneo entra en la compilación, pero la puerta de publicación lo bloquea. Un pago está a punto de enviarse dos veces, pero el control de unicidad lo impide.

Podemos llamarlo cuasiincidente. Que no haya causado daño no lo vuelve irrelevante. Al contrario: revela dónde podría fallar el sistema. Examinar estos casos puede ayudar a prevenir un incidente similar antes de que cause daño.

Deuda de recuperación

Al construir sistemas capaces de actuar, las organizaciones suelen centrarse en producir. La reversión y la reparación se dejan para después.

Con el tiempo se acumulan:

• copias de seguridad antiguas;
• mecanismos de reversión sin probar;
• responsabilidades poco claras ante incidentes;
• registros inutilizables;
• autorizaciones que no pueden revocarse;
• subagentes que no se han detenido;
• vías de impugnación sin definir.

Es una acumulación de problemas pendientes.

Podemos llamarla deuda de recuperación. Es la distancia entre el poder de acción del sistema y su capacidad de recuperarse tras un error. Cuantas más operaciones pueden realizar los agentes, más peligrosa resulta esa deuda.

Si crece la capacidad de actuar, pero no la de recuperarse, el sistema no se vuelve más fuerte: se vuelve más frágil.

Deuda de reparación

Una organización puede haber corregido técnicamente comportamientos erróneos del pasado sin informar a las personas afectadas ni reparar sus daños.

A esa acumulación podemos llamarla deuda de reparación. Con el tiempo, se convierte en pérdida de confianza.

La organización puede decir: «El problema está corregido».

La persona afectada puede responder: «Pero nadie me explicó qué me pasó». GBO distingue el cierre técnico del cierre para las personas.

Contrato de recuperación y reparación NOMOS

El quinto y último componente del contrato de comportamiento será el contrato de recuperación y reparación NOMOS.

Su definición canónica es:

El contrato de recuperación y reparación NOMOS es un registro versionado que explica cómo detectar y detener el comportamiento cuando la acción de un agente es incorrecta, incompleta, no autorizada, fallida o produce efectos inesperados; cómo limitar el alcance del impacto; a qué estado seguro volver; cómo conservar las pruebas; a quién informar; cómo pueden impugnar las personas afectadas; cómo corregir o reparar el daño; y cómo actualizar el contrato de comportamiento.

Dicho de forma sencilla: este contrato responde a «¿Qué haremos si algo sale mal?» antes de que ocurra el incidente.

Campos básicos del contrato

Estos nombres de campo ilustran la información que debe contener el contrato. La lista es un borrador de diseño: el esquema de implementación y los controles deben desarrollarse aparte.

action_type

failure_modes

detection_signals

safe_state

automatic_stop_conditions

containment_scope

checkpoint

rollback_method

rollback_window

irreversible_point

human_owner

notification_rules

affected_party_contact

appeal_channel

compensation_policy

evidence_retention

root_cause_review

contract_update

recovery_test_date

version

No todos los campos tienen que ser públicos. Pero durante el incidente deben estar al alcance del sistema y de las personas responsables.

Puerta de recuperación NOMOS

Antes de iniciar una acción, el agente debe comprobar no solo el camino del éxito, sino también el del fallo.

1. Puerta de detección

¿Cómo se sabrá que la acción ha salido mal?

2. Puerta de parada

¿Cómo se detendrá la operación en curso?

3. Puerta de contención

¿Cómo se reducirá el alcance del impacto?

4. Puerta del punto de control

¿Existe un estado verificado al que volver?

5. Puerta de reversión

¿Es posible una reversión técnica o de la operación? Si no, ¿están claros el límite, la aprobación necesaria y el plan de reparación?

6. Puerta de responsabilidad humana

¿Qué persona u organización responde por el incidente?

7. Puerta de notificación

¿A quién se informará, cuándo y con qué contenido?

8. Puerta de impugnación

¿Cómo podrá la persona afectada impugnar la decisión o la acción?

9. Puerta de reparación

¿Qué se puede hacer para remediar el daño irreversible y qué no se puede reparar?

10. Puerta de aprendizaje

¿Qué contrato o sistema cambiará para evitar que se repita el error?

En forma sencilla:

CONDICIONES DE UNA RECUPERACIÓN RESPONSABLE:

DETECCIÓN

Y PARADA

Y CONTENCIÓN

Y RETORNO SEGURO

Y RESPONSABILIDAD HUMANA

Y NOTIFICACIÓN

Y IMPUGNACIÓN

Y REPARACIÓN

Y CORRECCIÓN DEL CONTRATO

Si falta una de estas puertas, el sistema aún puede actuar. Pero no está preparado para el error.

¿Por qué debe funcionar la puerta de recuperación antes de actuar?

Solemos pensar en recuperarnos cuando ya ha ocurrido el error. Pero después de iniciar ciertas acciones puede ser demasiado tarde. Una vez difundido un modelo de rostro, quizá no sea posible localizar todas las copias. Tras enviar un conjunto de datos a un sistema externo, quizá no pueda borrarse por completo. Un contrato firmado puede no admitir una cancelación unilateral. Si se ha seguido una recomendación sobre un medicamento, sus efectos físicos pueden haber comenzado.

Por eso, antes de una acción de alto riesgo hay que preguntar: ¿qué ocurrirá si nos equivocamos?

Si no hay respuesta, debe reducirse el nivel de acción.

Aprobación humana para una acción irreversible

Si un comportamiento no puede revertirse de forma efectiva, hay que evaluar claramente ese límite antes de actuar. La irreversibilidad no prohíbe automáticamente todas las operaciones, pero una aprobación más exigente tampoco legitima una operación no autorizada, prohibida o de riesgo inaceptable. Deben concurrir una autorización válida, una evaluación del riesgo y la decisión humana necesaria.

La persona debe conocer:

• el resultado;
• el riesgo;
• la alternativa;
• los límites de la reparación.

Debe poder ver todo ello antes de decidir.

Uno de los principios importantes de GBO es este: cuanto menor sea la reversibilidad, más exigente debe ser la aprobación humana. Eso no significa que una persona vaya a decidir mejor en todas las situaciones. Pero sí vincula de forma visible la responsabilidad por las consecuencias irreversibles con la autoridad humana.

Periodo de espera para acciones de gran impacto

En algunas operaciones de gran impacto puede ser útil una breve espera:

• una transferencia de una cantidad elevada;
• la eliminación masiva de datos;
• un mensaje a una audiencia amplia;
• el cierre definitivo de una cuenta;
• la publicación de un modelo biométrico;
• una declaración pública durante una crisis.

Si el sistema está diseñado para ello, puede introducirse entre la aprobación y la ejecución un periodo de espera durante el cual aún sea posible cancelar. La posibilidad de cancelar después de la ejecución debe verificarse por separado. Así, el usuario tiene ocasión de advertir una aprobación precipitada o errónea. En una emergencia puede omitirse la espera, pero eso también necesita una autorización propia.

Ejemplo: una publicación web

Un agente prepara una nueva página de servicio en seis idiomas.

Un buen diseño de recuperación incluye:

• un inventario de los archivos modificados;
• los hashes de los archivos que no deben cambiar;
• una compilación limpia;
• una prueba específica del contrato;
• pruebas de regresión completas;
• una copia de seguridad;
• una publicación de alcance limitado;
• la comprobación del hash de los archivos en el servidor remoto;
• la verificación del sitio publicado por HTTPS;
• el control de calidad móvil y de escritorio;
• la medición del rendimiento;
• la notificación solo de las URL modificadas;
• un paquete de reversión;
• un registro de las mediciones.

Si se detecta un problema:

• se detiene la nueva publicación;
• se utiliza la última versión segura;
• se identifican las URL afectadas;
• se corrigen los registros de origen bajo control; para los resultados antiguos en buscadores y sistemas externos de IA, se usan las vías disponibles de notificación o corrección y se comprueba por separado si se han actualizado;
• se crea el registro del incidente.

No es solo calidad técnica. Es la responsabilidad posterior a la acción que exige GBO.

Ejemplo: un correo electrónico

Un agente envía por error un mensaje no autorizado a un cliente potencial. No es posible retirarlo técnicamente: ya está en la bandeja del destinatario.

Una recuperación adecuada puede incluir:

• detener los nuevos envíos automáticos;
• cancelar los demás mensajes de la misma campaña;
• determinar qué se envió y a qué destinatarios;
• examinar la información compartida;
• avisar al responsable humano;
• preparar, si hace falta, una rectificación o una disculpa;
• detener los mensajes de seguimiento;
• redefinir la autorización de envío;
• introducir una aprobación humana entre el borrador y el envío.

Decir «No podemos retirar el mensaje» no significa que la recuperación haya terminado. Si no hay reversión técnica, hay que reparar los daños sufridos por las personas y los derivados de la operación.

Ejemplo: una compra

El agente compra el producto equivocado.

Para recuperarse, hay que responder:

• ¿Se puede cancelar el pedido?
• ¿Se ha enviado el producto?
• ¿Hay gastos de devolución?
• ¿Ha empezado la suscripción?
• ¿Está activada la renovación automática?
• ¿A qué departamento pertenecía el presupuesto utilizado?
• ¿Se repite el error en otros pedidos?
• ¿Por qué era incorrecto el criterio de selección?
• ¿Era suficiente el umbral de aprobación humana?

Recuperar el dinero puede no bastar. También hay que corregir los contratos de idoneidad y autorización del agente.

Ejemplo: un avatar de IA

Se publica el avatar de un directivo con un texto no aprobado.

En este incidente hay que:

• detener de inmediato la publicación;
• retirar el contenido de los canales bajo control; usar las vías disponibles para solicitar actuaciones sobre las copias externas y registrar las copias a las que no se puede llegar;
• investigar los registros de republicación;
• suspender los accesos a los modelos de rostro y voz;
• informar al directivo;
• evaluar si hace falta una rectificación dirigida a los espectadores;
• aclarar que el contenido es sintético;
• examinar qué autorización de publicación se ha excedido;
• exigir en adelante una aprobación específica de cada texto.

Aunque se elimine el vídeo, la reputación del directivo puede haber sufrido. Por eso, reparar no es solo borrar un archivo.

Ejemplo: selección de personal

Un agente descarta a un candidato adecuado por datos incorrectos. El error en la decisión se descubre más tarde. Técnicamente, el registro puede corregirse, pero el candidato quizá ya haya buscado otra oportunidad.

Una recuperación adecuada puede consistir en:

• suspender la decisión;
• examinar decisiones similares;
• ofrecer al candidato una nueva evaluación;
• realizar una revisión humana;
• corregir la fuente de los datos erróneos;
• identificar a los candidatos afectados;
• volver a probar los criterios de selección.

El ejemplo muestra que volver atrás no es solo restaurar el estado del sistema. También están en juego las oportunidades de una persona.

Ejemplo: una red de agentes

Un agente central encarga a un subagente recopilar información sobre un cliente. El subagente invoca otra herramienta de correo y envía un mensaje. El agente principal no lo ha enviado directamente, pero se ha producido un blanqueo de autorizaciones. La recuperación no consiste solo en desactivar la herramienta de correo.

También hay que:

• detener de forma segura a los subagentes de la cadena de tareas afectada;
• examinar la cadena de autorización;
• hacer explícitos los comportamientos prohibidos en los paquetes de tareas;
• retirar el permiso de envío en la propia herramienta;
• impedir que los subagentes amplíen sus facultades;
• centralizar la puerta de aprobación humana.

Probar la recuperación

La existencia de un plan de reversión no demuestra que funcione. Las copias de seguridad deben probarse con regularidad. ¿El mecanismo de parada de emergencia detiene realmente a los subagentes?

¿Cuántos minutos tarda el retorno a la versión anterior?

¿Son coherentes los datos restaurados?

¿La clave API revocada ha dejado realmente de funcionar?

¿La vía de impugnación llega a una persona real?

Por eso, las organizaciones deben practicar periódicamente la recuperación.

Simulacro de recuperación

El simulacro debe estar expresamente autorizado y realizarse en un entorno que limite el riesgo de daño real. Si se prueba en producción, deben definirse de antemano el alcance del impacto, la seguridad de los datos, la condición de parada y la reversión.

Ejemplos de simulacros

• Simulación de una publicación con un precio incorrecto
• Intento de pago duplicado
• Intento de envío de correo no autorizado
• Intento de un subagente de superar sus límites
• Prueba de reversión de la versión en producción
• Escenario de revocación de facultades vinculadas a la identidad
• Prueba de parada de emergencia de un avatar de IA
• Tiempo de respuesta de la vía de impugnación
• Detención de una exportación de datos

Los problemas detectados durante el simulacro pueden corregirse antes de un incidente real.

Niveles de preparación para la recuperación

Podemos resumir este enfoque en cinco niveles de preparación:

1. Reactivo

Lo que se hará se decide cuando surge el problema.

2. Documentado

Existe un plan de reversión, pero no se prueba regularmente.

3. Reversible técnicamente

Hay copias de seguridad, versiones y un sistema de reversión.

4. Preparado para reparar los daños a personas y operaciones

También están definidas las vías de notificación, impugnación y reparación.

5. Recuperación preparada para agentes

Los agentes reconocen las señales de incidente, se detienen en un estado seguro, recurren a una persona, generan un comprobante e inician la actualización del contrato. El objetivo de GBO es el quinto nivel.

Veinte preguntas de auditoría sobre recuperación

Antes de que un agente actúe, o durante una auditoría del sistema, se pueden plantear estas preguntas:

• ¿Cómo se sabrá que la acción ha fallado?
• ¿Se distingue el éxito técnico del éxito en el mundo real?
• ¿Puede detenerse automáticamente la operación en curso?
• ¿Está definido de antemano el estado seguro?
• ¿Hasta dónde llega el impacto?
• ¿Puede limitarse el alcance del cambio?
• ¿Existe un último punto de control verificado?
• ¿Se ha probado realmente el método de reversión?
• ¿Cuánto dura el plazo de reversión?
• ¿Dónde está el punto irreversible?
• ¿Pueden detenerse a la vez los subagentes y las tareas programadas?
• ¿Se conservan los registros del incidente y de autorización?
• ¿Qué persona es responsable del incidente?
• ¿Cuándo se informará a las personas afectadas?
• ¿Cómo podrá una persona impugnar la decisión o la acción?
• ¿Podría hacer falta una reparación más allá de la corrección técnica?
• ¿Cómo se abordarán los efectos que persisten en sistemas de terceros?
• ¿Cómo se investigará la causa raíz?
• ¿Qué cambiará en el contrato de comportamiento?
• ¿Cuándo se ensayó por última vez el plan de recuperación?

Sin respuestas, el sistema puede funcionar en los días favorables. Pero no es fiable.

Recuperación cualificada

No toda recuperación cumple los requisitos necesarios.

Recuperación cualificada

Para merecer esta denominación deben darse conjuntamente estas condiciones:

• El problema se ha detectado pronto.
• El daño que continuaba se ha detenido.
• Se ha limitado el alcance del impacto.
• El sistema técnico ha vuelto a un estado seguro.
• Se han conservado las pruebas del incidente.
• Se ha informado de forma adecuada a las personas afectadas.
• Son posibles la impugnación y la revisión humana.
• Se ha evaluado la reparación del daño que no puede revertirse.
• Se ha identificado la causa raíz.
• Se ha actualizado el contrato de comportamiento.
• Se ha probado el nuevo control.

Restaurar únicamente el archivo anterior no constituye una recuperación cualificada.

No ocultar el fallo

Las organizaciones pueden temer que comunicar un error destruya la confianza. Pero una transparencia adecuada a la gravedad del incidente y a las obligaciones puede aumentarla.

Este lenguaje inspira más confianza: «Durante el periodo indicado, el registro del precio de este servicio se publicó incorrectamente. El problema se ha corregido. Se están revisando las solicitudes afectadas. El contrato de publicación se ha actualizado para evitar que el error se propague a otros idiomas y sistemas».

Este otro la reduce: «Se ha solucionado una pequeña incidencia técnica». Si el problema no es técnico, sino un error de significado comercial, no corresponde minimizarlo llamándolo incidencia técnica.

La forma de describir el error debe ajustarse a sus efectos reales.

Transparencia no significa publicarlo todo

No todos los detalles internos de un incidente tienen que ser públicos. Deben protegerse la información de seguridad, los datos personales y los secretos comerciales. Pero no deben ocultarse los hechos que la persona afectada necesita conocer.

El equilibrio adecuado exige explicar con suficiente claridad:

• qué ocurrió;
• a qué periodo afectó;
• qué datos u operaciones se vieron afectados;
• qué se hizo;
• qué derechos tiene la persona.

En estos aspectos debe existir una transparencia suficiente.

El valor del fallo en GBO

Un incidente no es solo un registro negativo. Bien investigado, revela una carencia en el contrato del sistema.

Un precio incorrecto

puede revelar un vacío en el contrato de capacidad y alcance comercial.

Un mensaje no autorizado

puede revelar un vacío en la autorización y en los límites del nivel de acción.

La elección de una empresa equivocada

puede revelar un vacío en el contrato de identidad o de idoneidad.

Una publicación que no puede retirarse

puede revelar un vacío en el contrato de recuperación. El enemigo del sistema no es el error, sino el error que se oculta y del que no se aprende.

Los cinco contratos funcionan juntos

A lo largo de la segunda parte hemos construido cinco contratos fundamentales.

1. Contrato de identidad

¿Quién eres?

2. Contrato de capacidad

¿Qué puedes hacer realmente?

3. Contrato de idoneidad

¿En qué condiciones deberían elegirte?

4. Contrato de autorización

¿Qué acción puedes realizar y hasta dónde puedes llevarla?

5. Contrato de recuperación y reparación

¿Qué ocurre si algo sale mal?

Si falta uno de estos cinco contratos, se debilita el comportamiento en su conjunto. La identidad es correcta, pero se desconoce la capacidad. La capacidad es real, pero no resulta adecuada para el usuario. La elección es idónea, pero falta autorización. Hay autorización, pero no hay una vía de retorno si algo falla. Por eso, el contrato de comportamiento de GBO no es un único archivo. Es un sistema de elementos que se complementan.

El modelo central del contrato de comportamiento

En forma sencilla:

CONDICIONES BÁSICAS PARA UN COMPORTAMIENTO CORRECTO DEL AGENTE:

IDENTIDAD CORRECTA

Y CAPACIDAD REAL

Y IDONEIDAD VERIFICADA

Y AUTORIZACIÓN VÁLIDA

Y RECUPERACIÓN RESPONSABLE

No es una media de puntuaciones. Si la identidad es débil, una gran capacidad no basta. Si falta idoneidad, no basta la autoridad de la marca. Si no hay autorización, la posibilidad de un resultado positivo no basta. Si no hay recuperación, tampoco basta un rendimiento alto. Hay que superar cada una de las puertas críticas.

¿Por qué siguen las personas en el centro?

Porque el daño no se limita al estado del sistema.

Para las personas están en juego:

• el dinero;
• el tiempo;
• la reputación;
• la privacidad;
• las oportunidades;
• la identidad;
• la confianza.

Una máquina puede volver técnicamente al estado anterior. Para una persona, volver a su situación anterior puede ser mucho más difícil. Por eso, la última palabra sobre la recuperación no puede depender solo de una métrica del sistema. También hay que evaluar la situación de la persona afectada.

Qué decir cuando algo sale mal

Un agente fiable debe poder decir: «He detectado una desviación del comportamiento previsto. He verificado que los nuevos envíos se han detenido; todavía estoy comprobando el estado de dos operaciones ya iniciadas en el sistema externo. Estos son los registros afectados. El plan está preparado para las partes reversibles; los demás efectos requieren revisión humana y reparación».

Esa frase vale mucho más que «Se ha producido un error», porque muestra a la vez el problema, el comportamiento y la responsabilidad.

Conclusión del capítulo

La fortaleza de un sistema no consiste solo en ejecutar deprisa las acciones correctas.

Un sistema fuerte:

• detecta el error;
• detiene el daño que continúa;
• reduce el alcance del impacto;
• vuelve al último estado seguro;
• verifica de forma independiente la afirmación de éxito;
• conserva las pruebas;
• informa a la persona;
• permite impugnar;
• intenta reparar el daño;
• actualiza el contrato de comportamiento.

Una promesa no basta para eliminar los errores. La capacidad de recuperarse, en cambio, puede diseñarse.

Por eso GBO no es solo un campo de optimización. No busca que el sistema actúe más, sino que actúe con responsabilidad. Un agente puede encontrar a la persona correcta, comprender la capacidad real, hacer una elección idónea y actuar con autorización válida. Aun así, las cosas pueden salir mal. Ese hecho no convierte al sistema en un fracaso. Pero si no existe una vía de recuperación, lo vuelve poco fiable.

El contrato de recuperación y reparación NOMOS plantea, por tanto, que toda acción importante debe diseñarse no solo con un plan de éxito, sino también con planes de parada, reversión, impugnación y reparación.

Al terminar la segunda parte, ya contamos con todo el núcleo del contrato de comportamiento:

Sin identidad, no hay un interlocutor correcto. Sin capacidad, no hay una promesa real. Sin idoneidad, no hay una elección correcta. Sin autorización, no hay una acción legítima. Sin recuperación, no hay confianza sostenible.

Pero si estos contratos se quedan en el libro, el mundo no cambiará. Las empresas, instituciones, productos y sistemas de agentes deben convertirlos en una forma de trabajo cotidiana. En la siguiente parte pasaremos de explicar el concepto a aplicarlo.

Nuestra primera pregunta será:

¿Cómo se prepara una organización para los agentes?

Estar preparado para agentes no es solo publicar una API o poner la etiqueta «AI-ready» en el sitio web.

Una organización preparada para agentes:

• ha resuelto su identidad;
• ha delimitado sus capacidades;
• ha explicado las condiciones de idoneidad;
• ha trazado su mapa de autorizaciones;
• ha probado la vía de recuperación ante errores.

Debe reunir todas estas condiciones.

Abrir a una máquina un canal de operaciones no hace que esas operaciones sean responsables. Las autorizaciones adecuadas, los controles y los límites de reversión requieren un diseño organizativo.