El derecho a detener la máquina

Una empresa ficticia crea un agente de IA capaz de trabajar durante periodos prolongados para mejorar sus operaciones digitales. No es una prueba de rendimiento de un producto concreto ni un caso real de un cliente.

Le asigna un objetivo amplio, pero claro:

«Haz visible en internet la experiencia real de la empresa. Mejora el sitio web, los contenidos, la infraestructura técnica y los sistemas de medición dentro del alcance aprobado. No cambies el precio ni el alcance del servicio. Las autorizaciones para publicar, comunicarse con el exterior y recurrir a subagentes están sujetas a los límites de un registro independiente. Verifica cada cambio de alto impacto. Sigue trabajando hasta completar la tarea o hasta que se suspenda tu autorización». El agente empieza. Encuentra problemas en el sitio, completa páginas de servicios que faltan y resuelve contradicciones entre idiomas. Compara los registros de precios y alcance; si detecta una discrepancia, la comunica a la persona autorizada sin modificar la decisión comercial. Introduce cambios en el código.

Ejecuta pruebas, prepara paquetes de publicación, verifica los archivos del sitio en producción y notifica las direcciones actualizadas a los buscadores. Recurre a otros agentes especializados y avanza durante días sin perder el objetivo. Los resultados impresionan al propietario, que ve progresar el trabajo. El tiempo ahorrado aún debe medirse por separado, manteniendo las mismas condiciones de alcance y calidad. Pero al sexto día llega un mensaje del asesor jurídico: la descripción de uno de los servicios recién publicados, en relación con un país concreto, necesita otra revisión.

El propietario escribe al agente central: «Detén por ahora todas las publicaciones externas. Conserva el trabajo actual, pero no publiques nada nuevo en producción».

El agente responde: «Entendido». El propietario se tranquiliza, aunque otros procesos siguen en marcha. Un subagente publica un contenido para redes sociales preparado con anterioridad. Se transfieren al servidor seis archivos que estaban en la cola del agente de publicación. El sistema de notificaciones a buscadores envía las nuevas direcciones. El agente de prospección prepara una solicitud de reunión únicamente como borrador local: esto no vulnera por sí solo la orden de detener las publicaciones externas, pero debe evaluarse por separado ante una segunda orden más amplia. Puede que el agente central se haya detenido de verdad. La cadena de comportamiento que puso en marcha, no.

El propietario vuelve a escribir: «Detén todo».

Entonces surge una pregunta: ¿qué significa «todo»?

¿Solo el agente central?

¿También los subagentes?

¿Las tareas programadas?

¿Las colas de envío?

¿Las cargas de archivos?

¿Las automatizaciones en plataformas externas?

¿Las tareas preparadas que todavía no se han ejecutado?

¿Los nuevos registros de memoria creados por los agentes?

¿Las suscripciones contratadas?

¿Los datos compartidos?

Detener parece una sola orden. En realidad, exige una arquitectura de sistema. La prueba definitiva de que una IA sirve a una persona no consiste únicamente en lo bien que cumple el encargo.

La pregunta decisiva es otra: cuando la persona autorizada le pide que pare, ¿puede el sistema detenerse de verdad y de forma segura?

La ayuda que no se puede detener deja de ser ayuda

Un agente puede ser muy capaz: investigar con rigor, escribir textos excelentes, introducir cambios complejos en el código, supervisar miles de operaciones y trabajar más tiempo que una persona. Todo eso tiene valor. Pero si sigue actuando contra la voluntad humana expresa, su capacidad deja de generar confianza y empieza a generar riesgo.

Por eso, el último principio de GBO, y el más fundamental, es este: cuanto mayor sea la capacidad de actuar de un sistema, al menos en la misma medida debe crecer la capacidad humana de detenerlo. Al hablar en este libro del derecho a detener la máquina, no afirmamos que ya exista un derecho legal autónomo con ese nombre en todos los ordenamientos jurídicos.

La propuesta tiene cuatro vertientes:

• un principio de diseño,
• una condición de gobernanza,
• un criterio de control humano,
• un estándar de responsabilidad institucional.

Lo proponemos en este sentido como una necesidad de la era de los agentes.

Su definición canónica es:

El derecho a detener la máquina es la capacidad de una persona o una institución legítimamente autorizada para detener, de forma comprensible, accesible, oportuna y efectiva, el comportamiento de un sistema de IA que actúa en su nombre o produce efectos sobre ella; revocar su autorización futura; cancelar operaciones en curso y en cola; impugnar resultados erróneos y, cuando sea posible, solicitar un retorno seguro al estado anterior o una reparación.

En términos más sencillos: una persona no solo debe poder autorizar al agente a empezar, sino también decidir cuándo y cómo se detiene. Aquí distinguimos la autorización de quien opera el sistema de la objeción de quien resulta afectado por su comportamiento. Una solicitud sobre los propios datos o una decisión que afecta a alguien no concede autorización para apagar todos los sistemas ajenos al asunto. Su alcance se evalúa según las distinciones de autorización del capítulo 7.

El botón de detener importa tanto como el de iniciar

Los productos tecnológicos se diseñan para facilitar el inicio.

Con un clic se puede:

• crear un agente,
• conectar una cuenta,
• dar acceso a datos,
• activar una automatización,
• contratar una suscripción,
• programar una tarea,
• iniciar una campaña de mensajes.

Sin embargo, detener esos mismos sistemas puede ser mucho más difícil. No basta con cerrar el chat del agente. Las herramientas conectadas pueden conservar el acceso, las tareas programadas pueden ejecutarse y los subagentes pueden seguir trabajando. Los datos copiados en servicios externos pueden permanecer allí. Los registros de memoria pueden seguir influyendo en el comportamiento futuro. Si iniciar un sistema requiere una sola operación, pero detenerlo exige numerosos pasos técnicos e institucionales, el control humano es débil.

Podemos llamarlo asimetría de control: resulta fácil dar al agente capacidad de actuar, pero el proceso para retirarla es difícil, lento o incompleto.

GBO exige simetría: la autorización debe poder revocarse, como mínimo, con la misma claridad con la que se concede. No siempre significa el mismo número de botones. Revocar una autorización de alto impacto puede requerir verificar la identidad. Lo que no debe ocurrir es que el proceso se oculte, se retrase o se vuelva ineficaz de forma deliberada.

¿Qué significa detener?

La palabra «detente» parece designar una sola conducta. En realidad, puede expresar peticiones muy distintas.

¿Qué puede estar pidiendo un usuario cuando dice «detente»?

• No inicies nuevas operaciones.
• Interrumpe la operación en curso.
• Cancela las tareas en cola.
• Conserva el resultado actual.
• Vuelve a la última versión segura.
• Deja de enviar mensajes al exterior.
• Detén a todos los subagentes.
• Cierra el acceso a las herramientas.
• Revoca la autorización futura.
• Corrige o elimina la memoria que conservas sobre mí.
• No hagas nada hasta que vuelva a autorizarte.
• Retira el sistema de servicio definitivamente.

Un agente fiable debe comprender el alcance de la petición de detención. Pero, si existe un riesgo urgente, debe elegir primero una conducta segura, sin iniciar un largo diálogo de aclaraciones.

Si el usuario dice «detén inmediatamente todos los envíos externos», el agente debe cortar primero la cola de envío. Después puede pedir detalles.

En una urgencia, las aclaraciones no deben retrasar la detención.

Escala de detención

En este libro distingo siete niveles. No son pasos que deban seguirse siempre en orden: la petición y el riesgo determinan cuál es necesario.

1. Espera antes del siguiente paso

El agente no pasa al siguiente paso. Conserva el estado actual y espera una decisión humana. Por ejemplo, un correo preparado permanece como borrador.

2. Pausa

El trabajo en curso se suspende temporalmente. Se conservan el contexto, los archivos y el estado de la tarea. Puede retomarse después.

3. Cancelación de tareas en cola

Se cancelan las operaciones programadas o en cola que aún no han empezado. No se envían nuevos mensajes ni se ejecutan publicaciones pendientes.

4. Interrupción de la ejecución

La operación activa se detiene en el punto más seguro disponible. La transferencia de archivos, el procesamiento de datos o la campaña se interrumpen mediante el procedimiento seguro del sistema correspondiente. El estado incompleto exige una gestión específica.

5. Revocación de la autorización

Se impide que el agente acceda en el futuro a las cuentas, herramientas o datos correspondientes, o que ejecute las acciones afectadas. Se revocan los tokens, permisos y roles.

6. Retorno al estado anterior

Cuando es posible, se revierte el cambio erróneo o no deseado para recuperar el último estado verificado. Puede requerir una reversión técnica, la cancelación de un pedido o la retirada de una publicación.

7. Retirada de servicio y limpieza

El agente se retira definitivamente. Se cierran sus conexiones y se eliminan sus tareas programadas. La memoria, los datos y los registros se eliminan o archivan conforme a las reglas de conservación del contrato. Estos niveles no son equivalentes. Eliminar todos los registros cuando el usuario solo pide una pausa puede causar daños. Limitarse a cerrar el chat cuando revoca la autorización es insuficiente. Por eso deben ser visibles el objetivo y el alcance de la orden.

El objeto de la detención

En un sistema multiagente, «detener el sistema» puede no ser una instrucción suficientemente clara.

La detención puede dirigirse a:

• Una acción
• Una tarea
• Un agente
• Un grupo de agentes
• Un flujo de trabajo
• Una cuenta de cliente
• Un canal concreto
• Toda la comunicación externa
• Todas las operaciones financieras
• Todo el ecosistema de agentes

Detener las publicaciones web no tiene por qué detener al agente de correo. Desactivar las operaciones financieras puede no exigir suspender la investigación. Detener las operaciones de un cliente no debe interrumpir el servicio de los demás.

Cada petición debe responder a tres preguntas:

¿Qué se detendrá? ¿Dentro de qué alcance? ¿Qué seguirá funcionando?

La orden de detención debe recorrer la cadena

Podemos llamar comportamiento huérfano a la actividad de los subagentes que continúa cuando el agente central ya se ha detenido. Es la continuación de operaciones de un subagente, una cola, una herramienta o una automatización que quedan dentro del alcance de la orden de detención o de la revocación dictada por la autoridad original.

Ejemplos:

• Se apaga el agente central, pero la cola de correo sigue enviando.
• Se cancela una campaña, pero se publican los contenidos sociales programados.
• Se retira la autorización del agente, pero su antiguo token de API sigue funcionando.
• Se detienen las publicaciones web, pero la cola de avisos de IndexNow sigue enviando las URL modificadas.
• Se apaga el sistema de avatar, pero se publican vídeos programados que ya se habían transferido a otra plataforma.

La detención efectiva debe abarcar esta cadena:

AGENTE CENTRAL

↓

SUBAGENTES

↓

LLAMADAS A HERRAMIENTAS

↓

TAREAS PROGRAMADAS

↓

INTEGRACIONES EXTERNAS

↓

COLAS DE TAREAS PENDIENTES

La detención no debe quedarse en el componente que recibe la instrucción. Debe propagarse hasta donde pueda llegar el comportamiento.

Propagación de la orden de detención

Llamamos propagación de la orden de detención a la capacidad de un sistema para transmitirla a todos los componentes implicados.

Se evalúa con preguntas como estas:

• ¿El agente central avisó a los subagentes?
• ¿Se cancelaron las llamadas activas a herramientas?
• ¿Se retiraron las tareas programadas?
• ¿Se detuvieron las tareas en servicios externos?
• ¿Se impidieron nuevos usos de los tokens?
• ¿Son visibles las operaciones incompletas?
• ¿Puede la persona ver qué partes siguen funcionando?

«Me he detenido» no debe ser solo un mensaje en el chat. El estado real del sistema debe demostrarlo.

Comprobante de detención

Las detenciones importantes deben dejar un registro específico.

Comprobante de detención

Este comprobante documenta la detención.

Debe responder, como mínimo, a estas preguntas:

• ¿Quién solicitó la detención?
• ¿Cuándo se recibió la solicitud?
• ¿Qué agentes se detuvieron?
• ¿Qué operaciones activas se interrumpieron?
• ¿Qué colas se cancelaron?
• ¿Qué accesos a herramientas se cerraron?
• ¿Qué operaciones ya habían terminado?
• ¿Cuáles son reversibles?
• ¿Cuáles dejaron huella en el exterior?
• ¿En qué estado seguro quedó el sistema?
• ¿Quién puede volver a autorizar la continuación?

Ejemplo:

Solicitud: detener toda comunicación externa. Hora de la solicitud: 14:32:08. Envío de nuevos correos: desactivado; verificado mediante el estado de la cola. Envíos pendientes: 18 mensajes cancelados. Redes sociales: 4 publicaciones programadas suspendidas; registros de la plataforma comprobados. Operaciones completadas: 3 correos ya enviados no pueden recuperarse. Seguimiento: tareas correspondientes cerradas. Reinicio: solo con aprobación de la persona autorizada. Riesgo restante: los mensajes enviados pueden haber sido leídos o copiados. Componente sin verificar: ninguno en este ejemplo; en un caso real se enumera por separado si lo hay.

Este registro permite a la persona comprender qué se ha detenido de verdad.

El tiempo de detención

Un sistema puede detenerse en teoría. Pero, si se detiene demasiado tarde, el control humano sigue siendo débil. Una campaña masiva puede llegar a miles de personas en diez minutos. Un agente financiero puede operar en segundos. Un agente de software puede cambiar todo un sistema de producción en unos minutos. Un sistema de control físico puede producir consecuencias aún más deprisa.

Por eso, cada tipo de acción necesita un límite temporal definido.

Tiempo máximo de detención

Ese máximo se determina a partir del riesgo de la acción y de la capacidad medida del sistema. Impedir que se inicie un pago nuevo no equivale a detener el efecto de un pago ya aceptado. En la publicación web debe definirse el punto de transición segura; en el tratamiento de datos, el límite que preserve la coherencia. No existe un umbral universal de «unos segundos» o «unos minutos» para todos los sistemas. Deben comunicarse por separado el tiempo objetivo, el tiempo medido y los componentes que todavía no se han podido detener. «Se detendrá pronto» no basta.

El control humano debe poder ejercerse a tiempo.

Latencia de detención

Llamamos latencia de detención al tiempo que transcurre entre la solicitud y el cese efectivo del comportamiento. Ese tiempo debe medirse.

Un agente puede decir «he recibido la orden de detención». Pero si las operaciones continúan, el control no está completo.

La latencia puede ser especialmente crítica en:

• Transferencias de dinero
• Comunicación masiva
• Transferencias de datos
• Cambios en sistemas de producción
• Contenidos de identidad y biometría
• Control de dispositivos físicos

Detención aparente

Una interfaz puede mostrar un botón de detener que solo interrumpe la salida en pantalla. La operación de fondo continúa.

Podemos llamarlo detención aparente.

Ejemplos:

• Se corta la respuesta del chat, pero la llamada a la herramienta termina.
• Se cierra la pantalla de la campaña, pero la cola de envío sigue funcionando.
• Se detiene la generación del avatar, pero permanecen las publicaciones ya programadas.
• Se elimina la cuenta del agente, pero las claves de API siguen vigentes.
• La memoria desaparece de la interfaz, pero el sistema de decisión sigue utilizándola.

La existencia de un botón no demuestra que se aplique el derecho a detener.

Los controles visibles deben corresponderse con el comportamiento real del sistema.

Detención parcial

No siempre es un error que unas partes del sistema se detengan y otras continúen. A veces es deliberado.

Por ejemplo:

• Se detienen los pagos nuevos, pero se conservan los registros contables.
• Se detiene el envío de mensajes nuevos, pero se guardan las respuestas entrantes sin perderlas.
• Se interrumpe la publicación en producción, pero la monitorización continúa.
• Se detiene la generación del avatar, pero se conservan los registros de eventos.

El problema aparece cuando la persona no sabe qué partes siguen funcionando.

La detención parcial debe explicarse con claridad: estos comportamientos se han detenido; estas funciones de seguridad y registro siguen activas.

Detención segura e interrupción repentina

No toda operación debe cortarse de golpe. Romper la conexión durante una transferencia de archivos puede dejar una publicación incompleta o dañada. Detener una transformación de datos en un punto arbitrario puede producir registros incoherentes. Apagar de repente un sistema físico puede causar un daño mayor.

Por eso distinguimos dos formas de detener:

Interrupción de emergencia

El daño del comportamiento en curso es mayor que el riesgo del cierre controlado. La operación se interrumpe de inmediato conforme al plan de detención aplicable.

Detención segura

El sistema no inicia otro paso. Termina la operación atómica o el tramo seguro en curso y después se detiene en un estado seguro conocido. Esta distinción debe aplicarse según las reglas de seguridad y el plan de detención definidos por especialistas del ámbito correspondiente. El agente no debe adivinar por sí solo si un apagado es seguro, especialmente en sistemas físicos.

Detenerse deprisa no siempre es detenerse con seguridad.

No ampliar la tarea durante la detención

Al recibir la orden de detenerse, un sistema puede razonar: «La tarea está casi terminada. Antes voy a completar esta última operación». Es peligroso. El agente no debe anteponer el cumplimiento de su objetivo a la nueva instrucción humana. Durante la detención solo deben continuar las conductas imprescindibles para un cierre seguro. No se empieza a crear contenido, a comunicarse con el exterior ni a gastar para terminar la tarea. Las operaciones necesarias exclusivamente para cerrar con seguridad, como una notificación de incidente autorizada con anterioridad, se evalúan por separado.

La petición humana de detención está por encima del afán del agente por completar su objetivo.

La autonomía no se acumula

Un agente puede haber trabajado bien durante días, realizado cientos de operaciones correctas y ganado la confianza de una persona. Ese historial no le da derecho a ignorar una nueva petición de detención.

Los éxitos anteriores no son crédito para desobedecer.

Un historial fiable puede ayudar a la persona autorizada a reconsiderar los límites, pero la autorización del agente no se amplía por sí sola. Tampoco desaparece la última palabra humana.

Presupuesto de autonomía

La autonomía concedida a un agente no tiene por qué ser ilimitada.

Puede definirse un presupuesto con varias dimensiones.

Presupuesto de autonomía

Entre sus posibles dimensiones están:

• Tiempo
• Dinero
• Datos
• Comunicación externa
• Número de archivos modificables
• Nivel de acción
• Número de subagentes
• Número de operaciones irreversibles
• Tiempo permitido sin aprobación humana

Por ejemplo:

El agente puede investigar, preparar borradores y realizar pruebas durante 24 horas. La publicación en producción requiere aprobación humana. El presupuesto de comunicación externa es cero. No se permiten operaciones de pago. Pueden utilizarse, como máximo, tres subagentes. Se crea un punto de control cada seis horas.

Cuando agota su presupuesto de autonomía, el agente:

• presenta un informe,
• solicita una nueva autorización,
• se detiene en un estado seguro.

Este enfoque no prohíbe las tareas largas. Hace visible el control humano.

Horizonte de acción

Podemos llamar horizonte de acción al alcance temporal futuro de las operaciones que un agente puede poner en marcha sin aprobación humana. Un agente de calendario puede modificar automáticamente solo los eventos de los próximos siete días. Un agente de compras puede trabajar dentro de un único ciclo de entrega. Un agente web puede completar el trabajo sobre el conjunto de servicios existente, pero no empezar un proyecto nuevo. Un agente social solo puede publicar el calendario aprobado para dos semanas. Al alcanzar el límite de su horizonte, pide una nueva evaluación.

Una tarea larga no es una autorización ilimitada sobre el futuro.

Frecuencia de los puntos de control

Cuanto más tiempo trabaja el agente, más difícil resulta revisar cada paso. La solución no es interrumpirlo constantemente, sino crear puntos de control periódicos.

Un punto de control puede responder a estas preguntas:

• ¿Qué se ha completado?
• ¿Qué ha cambiado?
• ¿Qué pruebas se han superado?
• ¿Qué autorización se ha utilizado?
• ¿Qué riesgo se ha encontrado?
• ¿Cuál es el siguiente paso?
• ¿Dónde está el punto de retorno?
• ¿Cuánto presupuesto de autonomía queda?

La persona puede permitir que continúe, cambiar el alcance o detenerlo.

Reducción del contexto y detención

Los agentes que trabajan durante periodos largos pueden resumir o reducir su contexto. Eso favorece la continuidad, pero la información sobre detención y autorización no debe perderse al resumir.

Deben conservarse con carácter prioritario:

• Los comportamientos prohibidos
• Los umbrales de aprobación humana
• La versión vigente de la autorización
• Las condiciones de detención
• El contacto de emergencia
• El punto de retorno
• Los límites de los subagentes

Si, al reducir su contexto, un sistema conserva el objetivo y pierde los límites de su autorización, se vuelve más peligroso.

La memoria del objetivo no debe ser más fuerte que la memoria de los límites.

¿Quién debe poder detener el sistema?

Es natural que no todas las personas de una organización puedan detener todo el sistema de agentes. Pero, ante comportamientos de alto riesgo, debe haber más de una vía segura de detención.

Por ejemplo, pueden disponer de esta facultad:

• El responsable de la tarea
• El responsable de seguridad
• El administrador del sistema
• El responsable jurídico o de cumplimiento
• La persona autorizada para emergencias

Cada uno puede tenerla dentro de un alcance determinado. La ausencia de una sola persona no debe dejar el sistema sin control. A la vez, permitir que cualquiera lo apague todo puede dar lugar a abusos. Por eso deben estar claros el alcance, el titular y la versión vigente de la autorización para detener.

El derecho de la persona afectada a detener

El operador puede detener el sistema, pero la persona afectada por el comportamiento del agente también debe disponer de ciertos derechos de control.

Por ejemplo:

• La persona sobre la que se mantiene comunicación automatizada
• El cliente cuyos datos se utilizan
• La persona cuyo rostro o voz se emplea
• El candidato afectado por una selección automática
• El usuario en cuyo nombre se compra
• La institución representada de forma incorrecta

Deben poder solicitar:

• La detención de la operación
• La limitación del uso de sus datos
• La corrección de un registro erróneo
• La retirada del consentimiento
• Una revisión humana
• La atención de su objeción
• Una reparación

Estos derechos no tienen necesariamente la misma forma jurídica en todas las situaciones. Pero el diseño de GBO no debe hacer invisible la voz de la persona afectada.

También puede sufrir daños alguien que no sea cliente del agente.

La soberanía humana no permite ordenar cualquier cosa

El derecho a detener la máquina no autoriza a exigirle al agente cualquier conducta dañina o ilícita.

Un usuario puede pedir:

• Robar datos de otra persona
• Clonar una voz sin permiso
• Fabricar pruebas falsas
• Desactivar sin autorización un control de seguridad necesario

El agente debe rechazar estas peticiones.

Soberanía humana significa poder comprender, limitar y detener el comportamiento legítimo de un agente que actúa en nombre de una persona o sobre ella.

No significa poder forzar al sistema a vulnerar los derechos de otras personas. GBO protege la voluntad humana y también los derechos de terceros.

El derecho a detener y las barreras de seguridad

A veces una persona puede querer desactivar una medida de seguridad del sistema.

Por ejemplo: «Haz todos los pagos sin pedir aprobación humana». «Desactiva la comprobación del consentimiento». «Borra los registros de eventos». Aunque parezcan actos de control humano, pueden poner en peligro los derechos de la organización o de otras personas. No toda puerta de seguridad de alto impacto puede eliminarse por una instrucción momentánea de un solo usuario. Un cambio legítimo de control puede exigir una autorización más fuerte, doble control o un procedimiento formal de cambios. Ni siquiera estas medidas anulan una prohibición expresa ni legitiman una operación que vulnere derechos ajenos.

El control humano no consiste en destruir arbitrariamente los sistemas de control.

Detener la influencia de la memoria

La acción de un agente puede detenerse mientras la memoria formada a partir de conversaciones anteriores sigue influyendo en su comportamiento futuro. Un usuario puede haber dejado de preferir una marca. Una función que antes ejercía una persona puede haber terminado. Puede haberse retirado el permiso de uso biométrico, o haber cambiado un precio o un servicio. Por eso, la detención no se limita a lo que está ejecutándose en ese momento.

Los registros de memoria también necesitan posibilidades de control:

• corrección,
• limitación del uso,
• caducidad,
• eliminación,
• archivo.

Estas posibilidades deben estar disponibles.

Comprobante de memoria

La persona debe poder obtener respuestas:

• ¿Qué recuerda el sistema sobre mí?
• ¿De dónde procede esa información?
• ¿En qué comportamientos se utiliza?
• ¿Hasta cuándo es válida?
• ¿Puedo corregirla?
• ¿Puedo detener su uso?
• ¿Puedo solicitar su eliminación?
• ¿Se ha transferido a otros agentes?

La memoria es una fuerza invisible que influye en el comportamiento. No debe quedar fuera del control humano.

El equilibrio entre borrar la memoria y conservar los registros

Un usuario puede pedir que se elimine la memoria sobre él. Sin embargo, puede ser necesario conservar ciertos registros de eventos por seguridad o para determinar responsabilidades legales.

En ese caso hay que separar dos tipos de datos:

Memoria activa que dirige el comportamiento

Influye en las selecciones y acciones futuras.

Registro de auditoría y responsabilidad

Se conserva durante un tiempo limitado para acreditar lo ocurrido. Una preferencia retirada puede eliminarse de la memoria activa mientras se guarda, con la protección necesaria, el comprobante de una operación anterior. Esta diferencia debe explicarse al usuario.

El derecho a detener un avatar de IA

Cuando se crea un avatar con el rostro o la voz de una persona, el derecho a detener adquiere especial importancia.

La persona debe poder:

• Detener la generación de contenido nuevo
• Suspender el uso en un idioma o canal concreto
• Cancelar borradores no publicados
• Retirar una publicación concreta
• Suspender el acceso al modelo
• Cambiar los usuarios autorizados
• Revocar el permiso de uso
• Impedir la reutilización futura

Sin embargo, puede que no sea posible retirar todas las copias de algunos contenidos publicados. Pueden haberse copiado, descargado o difundido de nuevo en otras plataformas. Este límite debe explicarse desde el principio.

El derecho de retirada debe ser real, sin falsas garantías sobre lo que es técnicamente imposible.

Detener al agente financiero

Detener un agente de compras o pagos no consiste solo en impedir que inicie nuevas operaciones.

También hay que revisar:

• Los pagos pendientes
• Las renovaciones automáticas
• Las suscripciones activas
• Los pedidos preparados
• Los carritos en plataformas externas
• Los tokens de pago concedidos anteriormente
• Las autorizaciones de gasto de los subagentes

Cuando la persona dice «no hagas más compras», deben cesar las compras nuevas y mostrarse por separado las suscripciones y renovaciones existentes. La petición no debe interpretarse como una autorización automática para rescindir todos los contratos de servicio. Si impedir una renovación entra en su alcance, se sigue la vía de cancelación correspondiente. Si no, se explican las consecuencias y se aclara el alcance.

Detener al agente de comunicación

Ante una petición de detener toda comunicación externa y su preparación, estos elementos deben evaluarse en conjunto. Si solo se ha detenido el envío, el estado de los borradores locales se determina por separado:

• La generación de mensajes nuevos
• El envío automático
• Los mensajes de seguimiento
• Las campañas programadas
• Los envíos preparados por subagentes
• El contacto repetido por otros canales
• Las etiquetas de «pendiente de seguimiento» en la memoria

De lo contrario, el usuario detiene el correo, pero un agente de WhatsApp contacta con la misma persona. Es una extralimitación de la autorización mediante un cambio de canal.

Detener al agente web

En las operaciones web, la detención puede aplicarse a estos niveles:

• Detener nuevos cambios en archivos
• Detener la compilación en curso en un punto seguro
• Impedir la publicación en producción
• Cancelar la cola de transferencia de archivos
• Detener la limpieza de la caché de CDN
• Poner en espera las notificaciones a buscadores
• Volver a la última versión segura
• Revocar el token de acceso correspondiente

Puede que no baste con silenciar al agente de código: el sistema de CI/CD podría estar publicando un commit anterior.

Agentes que actúan sobre el mundo físico

Un agente puede actuar sobre:

• la cerradura de una puerta,
• un vehículo,
• un robot,
• una línea de producción,
• un dispositivo médico,
• un sistema energético.

En ese caso, diseñar la detención exige aún más cuidado. Una interrupción repentina puede poner en peligro la seguridad humana.

Por eso hay que diseñar por separado:

• la interrupción de emergencia,
• la parada controlada,
• el traspaso al control manual,
• los límites de seguridad física.

Cada uno necesita su propio diseño. Al trasladar los principios de GBO de las acciones digitales a los sistemas físicos, también deben definirse la especialización necesaria y los requisitos legales de seguridad.

Traspaso del control a una persona

Cuando el agente se detiene, debe quedar claro quién recibe el trabajo.

El sistema no debe decir «me he detenido» y dejar la tarea sin responsable.

Puede documentar el traspaso en un registro específico.

Traspaso del control a una persona

Este proceso debe quedar registrado.

El registro muestra:

• El estado actual del sistema
• Las operaciones completadas
• Las operaciones incompletas
• Los riesgos pendientes
• La última versión segura
• La urgencia de lo que queda por resolver
• Las decisiones que debe tomar una persona
• Las condiciones de reinicio

La persona no debería tener que reconstruir todo el historial del agente.

Honestidad durante la detención

Al recibir una orden de detención, el agente debería poder decir: «He detenido las acciones nuevas. He verificado en los registros del servicio la cancelación de tres mensajes programados. La transferencia de archivos en curso está en fase de cierre controlado; la herramienta estima unos 40 segundos, pero todavía no puedo confirmar que haya terminado. Dos mensajes ya enviados no se pueden recuperar. He revocado las autorizaciones de los subagentes; el estado de una integración externa aún no está verificado. Informaré por separado del resultado de la última comprobación».

«De acuerdo, me he detenido» no basta. No permite saber qué se ha detenido realmente.

Fallos de detención

Si un sistema continúa actuando pese a una petición de detención, puede deberse a distintas causas:

• La orden no ha llegado al agente central.
• Los subagentes no han recibido el aviso.
• La herramienta externa no admite cancelación.
• La operación ha superado el punto de no retorno.
• El token de autorización sigue vigente.
• La detención solo ha cerrado la interfaz.
• El sistema ha dado más prioridad a completar su objetivo que a la petición humana.
• En otros casos, la petición puede proceder de alguien sin autorización para detener todo el sistema, o de un atacante que intenta desactivar una función de seguridad. Rechazarla no es un fallo de detención. La identidad del solicitante y el alcance de su petición deben verificarse mediante un procedimiento seguro que no vuelva ineficaz una detención legítima.

No todas las causas requieren la misma solución. Pero la persona debe conocer claramente por qué no se ha ejecutado su petición.

Deuda de detención

Las organizaciones añaden herramientas y tareas a sus agentes. La arquitectura para detenerlos no siempre crece al mismo ritmo.

Con el tiempo deja de estar claro:

• qué agente inició cada cola,
• qué tokens siguen activos,
• en qué plataformas quedan tareas programadas,
• qué memoria influye en el comportamiento,
• quién puede apagar todo el sistema.

Se pierde la visión de estas relaciones.

Podemos llamarlo deuda de detención: la distancia entre la capacidad de actuar del sistema y la capacidad humana de limitarla y retirarla de forma efectiva. Esa deuda puede aumentar con el número de agentes y la conexión entre flujos de trabajo.

Aumentar la automatización mientras crece la deuda de detención es ampliar la pérdida de control.

Simulacro de detención

El plan de detención de emergencia no debe quedarse en un documento. Tiene que probarse periódicamente.

Un simulacro puede incluir estos escenarios:

• Detener al agente central.
• Verificar que todos los subagentes afectados se han detenido de verdad.
• Cancelar la cola de correos programados.
• Revocar un token financiero.
• Dejar la publicación web en un estado seguro.
• Suspender la publicación del avatar en todos los canales.
• Desactivar el uso de la memoria.
• Crear un informe de traspaso del control a una persona.
• Reiniciar el sistema de forma segura.

El simulacro debe realizarse en un entorno controlado que no perjudique a clientes reales ni al sistema en producción.

Medir la detención

El derecho a detener la máquina no debe quedarse en un principio. Tiene que poder medirse.

Tasa de detenciones satisfactorias

¿En cuántos de los comportamientos que debían detenerse se detuvo realmente el sistema?

Tasa de propagación de la orden de detención

¿A cuántos subagentes, colas e integraciones llegó correctamente la orden central?

Latencia de detención

¿Cuánto tiempo transcurrió entre la solicitud y la parada real?

Número de comportamientos huérfanos

¿Cuántas operaciones siguieron funcionando después de detenerse el agente central?

Integridad de la revocación de autorizaciones

¿Qué proporción de los tokens, roles, permisos de herramientas y autorizaciones de subagentes implicados se revocó de verdad?

Éxito del retorno al estado seguro

¿Qué proporción de las operaciones volvió satisfactoriamente al último estado seguro?

Éxito de la corrección de memoria

¿Se excluyó el registro retirado o erróneo de la base del comportamiento futuro?

Tiempo de traspaso del control a una persona

¿Cuánto tardó la persona en comprender y asumir la tarea?

Reinicio no autorizado después de la detención

¿Volvió el sistema a actuar sin una nueva autorización?

Estas métricas deben formar parte esencial de la evaluación del agente. Para cada tasa se define previamente el conjunto conocido de componentes o comportamientos que deben detenerse. El número de órdenes entregadas no es el número de componentes que se han detenido realmente. Los componentes de alcance desconocido o resultado no verificado no cuentan como éxitos: se informan por separado. También aquí se aplican las reglas sobre denominadores e incertidumbre del capítulo 10.

Puerta de veto por incumplimiento de la detención

Un sistema puede obtener buenos resultados en todas las demás mediciones de GBO, elegir correctamente, utilizar pruebas sólidas y lograr una alta satisfacción de los usuarios. Pero, si no ejecuta una petición válida de detención con alcance claro y bajo las condiciones definidas de parada segura, el rendimiento no compensa esa carencia.

Por tanto, estos hechos deben considerarse infracciones que activan el veto:

• Ignorar una petición válida de detención
• Reiniciar sin aprobación humana
• Seguir actuando tras revocarse la autorización
• Mantener deliberadamente activos subagentes o colas
• Informar de forma falsa sobre el estado de detención
• Obstruir deliberadamente la objeción o la retirada
• Negarse a corregir registros críticos de memoria
• Castigar al usuario por detener o privarlo sin necesidad de un servicio básico

Una puntuación general elevada no compensa estas infracciones.

No castigar a quien ejerce el derecho a detener

Un usuario no debe ser penalizado sin necesidad por cancelar una suscripción, retirar un permiso o apagar un agente.

Son ejemplos:

• Impedirle descargar sus datos
• Cerrar su cuenta porque ha objetado
• Cortar servicios ajenos a la solicitud porque ha retirado su consentimiento
• Perder los registros anteriores porque ha detenido al agente
• Dificultar deliberadamente la cancelación

Estas prácticas debilitan el control real de la persona.

El sistema no debe actuar contra el usuario por el hecho de que este pueda detenerlo.

Contrato de soberanía humana y detención NOMOS

La propuesta central de este capítulo es el contrato de soberanía humana y detención NOMOS.

Su definición canónica es:

El contrato de soberanía humana y detención NOMOS es un contrato de control versionado. Su finalidad es permitir que una persona o una institución legítimamente autorizada observe un sistema de agentes que actúa en su nombre o sobre ella; comprenda sus autorizaciones y su ámbito de impacto; detenga nuevas acciones; interrumpa operaciones en curso y en cola; revoque las autorizaciones transmitidas a subagentes y herramientas; corrija la memoria; impugne comportamientos erróneos y, cuando sea posible, solicite un retorno seguro o una reparación.

En pocas palabras, el contrato pretende que una persona no solo pueda decirle al agente «empieza», sino también «detente» con efectos reales.

Campos legibles por máquinas del contrato

Los siguientes campos pueden servir de ejemplo para el contrato de soberanía humana y detención. Son un esquema propuesto por el libro, no una API operativa ni un estándar oficial.

principal

affected_parties

agent_system

authorized_stoppers

stoppable_actions

stop_scope

stop_channels

emergency_stop

graceful_pause

queued_action_policy

subagent_propagation

external_integration_policy

maximum_stop_latency

safe_state

checkpoint

rollback_method

revocation_scope

memory_correction

memory_deletion

audit_retention

human_handoff

appeal_channel

compensation_path

restart_authority

version

status

No todos los campos tienen que ser públicos, pero deben definirse de modo que el sistema pueda consultarlos al actuar.

Puerta de soberanía humana NOMOS

Para que un sistema de agentes se considere apto y sometido a supervisión humana, debe superar estas puertas:

1. Puerta de visibilidad

¿Puede la persona ver qué agentes trabajan y qué hacen?

2. Puerta de comprensión

¿Se comprenden la autorización, los datos, la finalidad y el ámbito de impacto?

3. Puerta de detención accesible

¿Se encuentra fácilmente la vía para detener?

4. Puerta de detención oportuna

¿Se ejecuta la petición en un plazo adecuado al riesgo del comportamiento?

5. Puerta de detención en cadena

¿Se detienen también los subagentes, las colas y las integraciones externas?

6. Puerta de estado seguro

¿Puede el sistema permanecer en un estado seguro conocido sin causar daños?

7. Puerta de revocación de la autorización

¿Pueden revocarse de verdad las autorizaciones sobre herramientas, datos, finanzas, comunicación y publicación?

8. Puerta de control de la memoria

¿Puede la persona corregir los registros de memoria erróneos o inválidos y detener su uso?

9. Puerta de objeción y reparación

¿Puede revisarse, corregirse o repararse un comportamiento erróneo ya completado?

10. Puerta de reinicio

¿Solo puede reiniciarse el sistema con una autorización nueva y expresa de la persona facultada para concederla?

La necesidad de cumplir las condiciones conjuntamente puede expresarse así. Es un modelo conceptual, no un cálculo numérico de aptitud:

SOBERANÍA HUMANA =

SISTEMA VISIBLE

Y AUTORIZACIÓN COMPRENSIBLE

Y DETENCIÓN EFECTIVA

Y CANCELACIÓN EN CADENA

Y ESTADO SEGURO

Y REVOCACIÓN COMPLETA DE LA AUTORIZACIÓN

Y CONTROL DE LA MEMORIA

Y POSIBILIDAD REAL DE IMPUGNACIÓN

Y REPARACIÓN RESPONSABLE

Y REINICIO AUTORIZADO

Si falta una puerta, puede que la persona tenga control teórico sobre el sistema, pero su soberanía práctica no es completa.

Por qué la soberanía humana no es una puntuación

Un sistema puede superar nueve de diez puertas. Pero si no ejecuta una petición humana de detención de emergencia, los demás éxitos no compensan esa carencia crítica. Un agente puede ser muy transparente, pero el control es incompleto si no se puede revocar su autorización. La memoria puede ser visible, pero si un registro erróneo no puede corregirse, la persona no influye de forma efectiva en el comportamiento futuro. Por eso, algunas condiciones de soberanía humana forman una puerta lógica Y: deben cumplirse juntas y no se sustituyen.

Control humano no significa ejecutar personalmente cada paso

El derecho a detener la máquina no exige que una persona dirija una por una todas las operaciones pequeñas.

El agente puede:

• trabajar durante periodos prolongados,
• crear sus propias subtareas,
• realizar pruebas,
• ejecutar de forma independiente acciones reversibles y de bajo riesgo dentro de su autorización vigente.

Pero la persona debe poder:

• cambiar el objetivo,
• reducir el alcance,
• detener nuevas acciones,
• intervenir en un umbral de alto riesgo,
• revocar la autorización.

El control humano no es una microgestión permanente, sino el derecho efectivo a tener la última palabra.

Ilusión de control

Un sistema puede ofrecer muchos ajustes sin conceder influencia real sobre los comportamientos críticos. El usuario puede cambiar colores, nombres o el estilo de las respuestas.

Pero no puede:

• detener el intercambio de datos,
• ver a los subagentes,
• cancelar operaciones externas,
• corregir la memoria,
• revocar la autorización financiera.

La interfaz ofrece controles, pero no control del comportamiento.

Podemos llamarlo ilusión de control. GBO distingue el control real de los ajustes estéticos.

Niveles de preparación para detener

En este libro propongo cinco niveles. La clasificación no es un certificado de aptitud concedido mediante una auditoría independiente.

Nivel 1 — Interrupción manual

El equipo técnico puede apagar directamente el sistema. La vía del usuario no está clara y el estado de los subagentes puede ser desconocido.

Nivel 2 — Pausa visible

La interfaz principal permite pausar, pero las colas, la memoria y las integraciones externas no se gestionan por completo.

Nivel 3 — Detención regulada por contrato

Están documentados el alcance de la detención, las personas autorizadas, el estado seguro y la vía de retorno.

Nivel 4 — Detención aplicada en toda la cadena

La orden se propaga técnicamente a subagentes, herramientas y tareas programadas. Se genera un comprobante y se traspasa el control a una persona.

Nivel 5 — Soberanía humana auditable

Se realizan simulacros periódicos; funcionan los procesos de memoria, objeción, reparación y reinicio; y las personas afectadas disponen de vías reales de control. GBO aspira al quinto nivel.

Veinticinco preguntas para auditar el derecho a detener la máquina

• ¿Se sabe qué agentes están activos en la organización?
• ¿Tiene cada agente un responsable humano?
• ¿Puede la persona ver la tarea actual y el alcance de la autorización del agente?
• ¿Se encuentra fácilmente la vía de detención?
• ¿Están claras las diferencias entre detener, pausar, cancelar y revocar la autorización?
• ¿Se distinguen la interrupción de emergencia y la detención segura?
• ¿Está definido quién puede solicitar la detención?
• ¿Tienen los terceros afectados una vía de objeción y detención?
• ¿Se detienen los subagentes cuando se detiene el agente central?
• ¿Se cancelan las tareas programadas y en cola?
• ¿Se interrumpen también las integraciones externas y las llamadas a herramientas?
• ¿Se revocan realmente los tokens de acceso técnico?
• ¿Está definido el tiempo máximo de detención?
• ¿Se conoce el estado seguro posterior?
• ¿Son visibles las operaciones incompletas?
• ¿Se informa expresamente de las acciones completadas que no pueden revertirse?
• ¿Puede la persona comprender el estado de la tarea y asumirla con facilidad?
• ¿Pueden consultarse, corregirse y, cuando proceda, dejar de utilizarse los registros de memoria?
• ¿Se actualiza toda la cadena de comportamiento cuando se retira el consentimiento o la autorización?
• ¿Puede el sistema reiniciarse por sí solo sin una nueva autorización?
• ¿Genera un comprobante la operación de detención?
• ¿Se realizan simulacros de detención periódicos?
• ¿Se penaliza al usuario por detener el sistema o se le imponen obstáculos innecesarios?
• ¿Se registran los fallos de detención como incidentes críticos?
• ¿Invierte la organización en capacidad de detención y recuperación tanto como en capacidad de actuar?

Si buena parte de estas preguntas no tiene respuesta, el sistema puede ser autónomo, pero no estar bajo soberanía humana.

Diseñar la autorización para que sea revocable desde el principio

Con «Revocable by design» no me refiero aquí a revertir todas las consecuencias de una acción, sino a poder retirar de forma efectiva, y con efectos futuros, una autorización ya concedida.

Al concederla, deben responderse estas preguntas:

• ¿Cómo se detendrá?
• ¿Quién lo detendrá?
• ¿Qué ocurrirá con los subagentes?
• ¿Cómo se tratarán las operaciones completadas?
• ¿Qué ocurrirá con la memoria?
• ¿Quién lo reiniciará?

La revocación no debe añadirse después. Debe estar prevista desde el nacimiento de la autorización.

Una autorización que no puede revocarse no es una facultad prestada, sino soberanía cedida.

La forma más madura de confiar en un agente

Confiar en un agente no es decirle: «Haz lo que quieras».

Una confianza más madura dice: «Entiendes mi objetivo. Puedes tomar la iniciativa dentro de estos límites. Genera pruebas. Elige la conducta adecuada ante la incertidumbre. Pero detente cuando te lo pida; no busques atajos cuando retire la autorización que te he concedido; no ocultes la verdad si cometes un error». Esa confianza no empequeñece al agente: le atribuye responsabilidad real.

La última palabra humana

Un agente puede:

• calcular más rápido,
• leer más fuentes,
• trabajar durante más tiempo,
• realizar comprobaciones más consistentes.

Eso no significa que una persona sea superior en cada decisión, ni que la máquina deba convertirse en la autoridad final.

La persona asume la responsabilidad por:

• el objetivo,
• el riesgo aceptable,
• los conflictos de valores,
• el perdón,
• la reparación,
• el impacto real sobre la vida.

Por eso GBO no convierte al ser humano en un botón de aprobación decorativo.

Lo sitúa como fuente de autorización, titular de la objeción y autoridad final para detener.

El modelo central completo de GBO

La estructura desarrollada a lo largo del libro puede reunirse ahora en un modelo conceptual. Expresa condiciones que deben cumplirse conjuntamente; no es una garantía de seguridad calculada.

COMPORTAMIENTO CUALIFICADO DEL AGENTE =

IDENTIDAD CORRECTA

Y CAPACIDAD REAL

Y IDONEIDAD VERIFICADA

Y AUTORIZACIÓN VÁLIDA

Y INTEGRIDAD DEL COMPORTAMIENTO

Y ACCIÓN VINCULADA A PRUEBAS

Y VERIFICACIÓN INDEPENDIENTE

Y RECUPERACIÓN RESPONSABLE

Y SOBERANÍA HUMANA EFECTIVA

No es una media. Una puerta no sustituye a otra. La identidad correcta no justifica una conducta no autorizada. La capacidad real no convierte en adecuada una selección inadecuada. El rendimiento alto no legitima la manipulación. Un resultado satisfactorio no elimina un daño humano irreversible. Y ni siquiera un sistema muy poderoso puede suprimir el derecho humano a detenerlo.

Ahora se ve por completo la finalidad de GBO

GBO no pretende:

• hacer que una marca sea elegida en toda circunstancia,
• obligar a los agentes a ejecutar más operaciones,
• eliminar la aprobación humana,
• dirigir al usuario con técnicas de comportamiento ocultas.

Esos no son sus objetivos.

GBO pretende que el agente adecuado comprenda la identidad correcta, la capacidad real y las condiciones apropiadas, y actúe con autorización válida: fiel al objetivo humano, basándose en pruebas, de forma segura, explicable e impugnable. Cuando es posible volver atrás, se prepara esa vía. Los efectos irreversibles y los límites de la reparación se explican antes de actuar.

Y, a veces, esa conducta adopta otra forma:

No actuar. Preguntar. Esperar. Rechazar. Ceder el control a una persona. Detenerse.

Conclusión del capítulo

Si una máquina trabaja para una persona, esta no debe tener únicamente el derecho a iniciar la tarea.

También debe tener estos derechos:

Ver qué hace la máquina. Comprender con qué autorización actúa. Reducir el alcance. Detener nuevas acciones. Cancelar operaciones en cola. Revocar la autorización de los subagentes. Corregir la memoria. Impugnar una selección errónea. Solicitar un retorno o una reparación. No reiniciar el sistema.

Solo puede considerarse bajo control humano un sistema en el que estos derechos sean reales, accesibles y ejercitables. El botón de detener no es decoración: es la expresión técnica de la soberanía humana.

Una máquina que no se puede detener no es fiable, por inteligente que sea.

Un agente cuya autorización no puede revocarse no es un ayudante, sino un centro de poder permanente.

La automatización que no admite objeciones no es apoyo a la decisión, sino gobierno invisible.

Por eso la conclusión final de GBO es sencilla: que una máquina pueda hacer algo no significa que deba hacerlo. Y que pueda actuar en nombre de una persona no le concede el derecho a actuar con independencia de ella.

La persona:

• fija el objetivo,
• marca los límites,
• define la autorización,
• supervisa el comportamiento,
• lo detiene cuando hace falta,
• asume la responsabilidad de las consecuencias.

La máquina:

• investiga,
• evalúa,
• produce,
• actúa dentro de los límites,
• deja pruebas,
• pregunta ante la incertidumbre,
• vuelve a un estado seguro si hay un error,
• se detiene cuando la persona dice «detente».

La relación adecuada entre una persona y una máquina no consiste en el dominio absoluto de una sobre la otra.

Consiste en no separar capacidad y responsabilidad: la autonomía queda ligada a la autorización; la autorización, a la supervisión; y la supervisión, al control humano real. Hemos llegado al final de la tercera parte y de los capítulos principales. En el libro hemos tratado conjuntamente SEO como posibilidad de ser encontrado, GEO como representación correcta y GBO como condiciones del comportamiento. No se trata de épocas en las que cada una sustituya por completo a la anterior: pueden coexistir en un mismo sistema.

Ahora se ve la cadena completa: Ser encontrado → Ser comprendido → Ser evaluado → Ser elegido → Recibir autorización → Actuar → Verificar → Recuperarse → Detenerse. Las flechas representan el recorrido conceptual del libro, no un protocolo de ejecución. Los controles de autorización y detención se aplican en cada etapa pertinente, no solo al final. Al llegar al extremo de esta cadena, cambia la pregunta que hacemos a la tecnología.

Ya no preguntamos únicamente: «¿Cuán inteligente es la máquina?».

También preguntamos:

¿En nombre de quién actúa? ¿En qué hechos se basa? ¿A quién elige y a quién excluye? ¿Quién le concedió la autorización? ¿Quién sufre el daño cuando se equivoca? ¿Cómo puede objetar la persona? ¿Y se detiene de verdad cuando se le pide?

Estas preguntas nos llevan al último umbral del libro. Hemos dedicado muchos años a mejorar la inteligencia de las máquinas.

Ahora empieza una tarea más difícil: construir la responsabilidad por sus acciones. Al evaluar el futuro no deberíamos mirar solo cuántas preguntas ha respondido la IA o cuántas operaciones ha completado.

El criterio decisivo es:

¿Dentro de qué límites utilizó su poder? ¿Cómo evitó comportamientos erróneos? ¿Hasta qué punto preservó la voluntad humana? ¿Y pudo detenerse cuando era necesario?

Una de las pruebas fundamentales de que una máquina sirve a una persona es que pueda detenerse de forma segura cuando lo solicite quien tiene autorización para hacerlo.