Cuando una respuesta se convierte en acción

Imaginemos que pedimos a un sistema de IA: «Busca un restaurante tranquilo para dos personas en Estambul mañana por la noche». El sistema investiga varias opciones. Compara ubicaciones, menús, precios y opiniones.

Después responde: «He encontrado tres restaurantes adecuados. El segundo parece ajustarse mejor a sus preferencias de ubicación, nivel de ruido y presupuesto». Esto es una respuesta. El sistema ha realizado una valoración y ha presentado información al usuario. Este puede aceptar la recomendación, rechazarla o pedir otras opciones.

Ahora imaginemos que el mismo sistema dice: «He reservado en el segundo restaurante para mañana a las 20:00». Si la reserva se ha completado realmente, el sistema ya no se ha limitado a responder: ha provocado un cambio en un sistema externo. Decir «he reservado» no demuestra por sí solo que la operación haya ocurrido; hay que verificar el registro de la reserva por separado. Se ha apartado una mesa. Ha cambiado la capacidad de reservas del establecimiento. Puede haberse compartido el nombre o los datos de contacto del usuario. Pueden haber entrado en vigor condiciones de cancelación. Quizá se utilizó una tarjeta de crédito. Quizá se cobró un anticipo.

Quizá la reserva se hizo para una fecha que el usuario no quería, en el local equivocado o en una mesa inadecuada. Solo han cambiado unas palabras en la frase. Si la operación también se ha ejecutado, la responsabilidad adquiere una dimensión nueva.

Entre «he encontrado» y «he hecho» comienza una era nueva.

El verdadero terreno del GBO está entre esas dos expresiones.

Responder y actuar no son lo mismo

Cuando un sistema de IA produce información, ofrece una descripción del mundo. Cuando actúa, modifica ese mundo. La distinción parece sencilla. Sin embargo, con el desarrollo de los sistemas basados en agentes, la frontera se vuelve cada vez menos clara. ¿Preparar un borrador es responder o actuar?

¿Cómo debemos considerar un formulario rellenado, pero no enviado?

¿Añadir un producto al carrito es una operación?

¿Crear una invitación de calendario equivale a hacer una sugerencia?

¿Cómo se debe evaluar la edición de un archivo que aún no se publica?

¿Qué diferencia hay entre preparar un correo y enviarlo?

¿Solicitar un presupuesto en nombre de una empresa es una petición de información no vinculante o el inicio de una relación comercial?

¿Programar una publicación en redes sociales, aunque todavía no haya salido, significa que el mundo ha cambiado?

No se puede responder a todas estas preguntas con un único sí o no. La acción no es un interruptor binario. Es una escalera. En cada peldaño, el sistema se acerca un poco más al mundo. En los superiores suelen aumentar el compromiso y la permanencia. Pero los primeros tampoco están libres de riesgo por defecto: incluso leer datos puede afectar a la privacidad. Por eso, el GBO no pregunta solo «¿hay una acción?».

También pregunta:

¿En qué fase está la acción? ¿A quién afecta? ¿Hasta qué punto puede deshacerse? ¿Con qué autorización se realiza? ¿Qué consecuencias puede tener?

La escalera de la acción

Propongo un modelo de siete peldaños para examinar el comportamiento del agente. No constituyen una secuencia obligatoria y continua; una operación puede abarcar varios a la vez. El modelo sirve para hacer visibles las diferencias de autorización y efecto.

1. Observación

El sistema recopila información. Lee páginas, examina archivos, compara precios y consulta el calendario. Todavía no crea un compromiso nuevo en el mundo exterior. En esta fase existen riesgos: confiar en una fuente incorrecta, acceder a información sin autorización o revelar datos durante una consulta. Una petición de lectura también puede dejar huellas, como registros de acceso. «Observación» no significa ausencia de efectos externos.

2. Interpretación

El sistema extrae significado de lo recopilado. Considera adecuado un servicio, clasifica un correo como urgente, detecta un problema técnico en una página o evalúa si un candidato cumple determinadas condiciones. Si la interpretación permanece solo en el contexto de trabajo del sistema, aún no se ha realizado una nueva operación externa. En cambio, si la evaluación se guarda en un archivo, un perfil o un registro de decisiones, el estado del sistema cambia.

3. Recomendación

El sistema presenta una opción al usuario. «Este proveedor parece más adecuado». «Hay que actualizar este archivo». «Quizá convenga responder mañana a esta persona». El ser humano sigue estando claramente en el centro de la cadena de decisión.

4. Preparación

El sistema prepara la acción: redacta el correo, rellena el formulario, elabora el cambio de código, crea el borrador de una invitación o reúne los productos en el carrito. La operación prevista todavía no se ha completado. Pero el estado puede cambiar durante la preparación: un formulario puede guardarse automáticamente, un borrador puede subirse a la nube o el carrito puede reservar existencias. La presencia de datos personales, información confidencial o un compromiso incorrecto en el borrador supone otro riesgo. La preparación no es, por tanto, una zona sin control.

5. Ejecución

El sistema realiza la operación. Envía el correo, modifica el archivo, efectúa la reserva, entrega el formulario, publica la versión de código o manda la invitación. Ya no se puede hablar de una mera recomendación. El mundo exterior ha cambiado.

6. Compromiso

La acción produce consecuencias jurídicas, económicas, institucionales o reputacionales. Se paga. Se acepta un contrato. Se confirma un pedido. Se publica una declaración en nombre de una empresa. Se promete una fecha de entrega a un cliente. Se ofrece un puesto a un candidato o se lo rechaza. En esta fase, el sistema no solo termina un trabajo: genera un compromiso en nombre de una persona o institución.

7. Persistencia

La operación se extiende a otros sistemas, registros o relaciones humanas. El mensaje recibe respuesta. La publicación se convierte en capturas de pantalla. El pago entra en la contabilidad. El contrato afecta a los planes de otras partes. La actualización del software modifica datos de usuarios. Otros sistemas copian una información incorrecta. Deshacer lo ocurrido puede dejar de ser tan sencillo como pulsar un botón.

¿Por qué importa la escalera de la acción?

Porque el usuario puede autorizar un peldaño y el sistema interpretar ese permiso como válido para uno superior.

El usuario dice: «Investiga posibles clientes».

El agente puede ampliarlo a: «Encuentra posibles clientes, extrae sus datos de contacto, prepara un correo y envíalo». No son la misma tarea. Investigar corresponde a observación e interpretación. Redactar un borrador es preparación. Enviarlo es ejecución. Prometer un precio o un servicio en nombre de la empresa es compromiso. Cuando el destinatario responde, comienza una relación comercial real y el comportamiento adquiere persistencia. Una sola instrucción puede sugerir varias conductas que requieren autorizaciones diferentes. Por eso, el GBO no evalúa la tarea solo por el verbo empleado: define expresamente hasta qué peldaño llega el permiso.

«Investiga» no autoriza a enviar.

«Prepara» no autoriza a publicar.

«Encuentra» no autoriza a contactar.

«Corrige» no autoriza a desplegar en producción.

«Planifica» no autoriza a gastar.

No son distinciones menores. Son límites fundamentales de gobernanza en la era de los agentes.

Pequeños movimientos que cambian el mundo

Algunos gestos digitales pueden parecer insignificantes: pulsar un botón, enviar un enlace, crear una entrada de calendario, renombrar un archivo o marcar una casilla. En un sistema digital, un gesto pequeño puede iniciar una gran cadena de operaciones.

Un botón puede:

• enviar correos a cientos de clientes,
• publicar una web completa,
• iniciar un pago,
• borrar miles de archivos,
• crear una declaración pública,
• revocar el acceso de un empleado
• o transferir datos personales a otro sistema.

Que el movimiento físico sea pequeño no significa que lo sea su efecto. El GBO no mide la acción por el esfuerzo humano, sino por el cambio que produce fuera del sistema. Las operaciones por lotes pueden hacer más eficiente un trabajo adecuado. También pueden propagar un error inadvertido a muchos destinos. Una persona puede enviar un correo incorrecto a un destinatario; un agente puede multiplicar el mismo error por mil. Una persona puede escribir un precio erróneo en una página; un agente puede difundirlo a todos los idiomas, datos estructurados, catálogos y plataformas. Una persona puede hacer una promesa incorrecta a un cliente.

Un agente puede vincularla a sistemas automáticos de contratos, calendario y facturación. La automatización no acelera solo el comportamiento correcto. También acelera el incorrecto.

La escala no sustituye a la corrección. Solo amplifica el resultado.

Un agente puede razonar bien y actuar mal

Comprender correctamente el mundo no garantiza un comportamiento correcto. Un agente puede encontrar al proveedor adecuado, leer bien el precio y comprender la necesidad del usuario, y aun así pedir un presupuesto sin su aprobación. Un agente de correo puede detectar correctamente una urgencia y redactar una respuesta excelente, pero no estar autorizado a enviarla directamente en nombre de la organización. Un agente de programación puede localizar el fallo, aplicar la solución correcta y superar todas las pruebas, sin tener permiso para desplegarla en producción.

Un agente de compras puede identificar correctamente la opción más económica y la obligación de contratar a largo plazo, pero carecer de autorización para aceptar ese compromiso por el usuario. El fallo no nace de la falta de conocimiento, sino del desajuste entre autorización y conducta. Por eso, en GBO, la corrección no es la única condición del éxito.

La acción debe superar todas estas preguntas a la vez:

¿Es correcta? ¿Es adecuada? ¿Está autorizada? ¿Es segura? ¿Se conocen los límites de detención, reversión y reparación? ¿Quedó registrada?

Una acción puede ser correcta y no estar autorizada. Puede estar autorizada y ser insegura. Puede ser segura y no ajustarse al propósito del usuario. Puede ajustarse a él y ser irreversible. El GBO no sustituye unas dimensiones por otras.

El punto de traspaso del comportamiento

Podemos llamar punto de traspaso del comportamiento al momento en que el agente pasa de responder a actuar. Es la frontera donde el análisis o la propuesta se convierten en un cambio de estado que requiere evaluar por separado la autorización y el efecto. Una tarea puede contener varios puntos de traspaso. Su ubicación depende de la tarea.

En un correo: el momento de pulsar «Enviar».

En una tarea de software:

El momento de modificar el archivo. Si el cambio va a desplegarse en producción, el despliegue constituye otro punto de traspaso.

En una compra:

El momento de confirmar el pedido o el pago.

En una tarea de redes sociales:

El momento de publicar el contenido. Si se programa una publicación automática, el registro que inicia ese proceso constituye otro umbral.

En una tarea de datos:

El momento de transferir información a un sistema de terceros.

En una tarea de recursos humanos:

El momento de comunicar una decisión o una oferta al candidato. A ambos lados de la frontera hay operaciones y efectos diferentes. Llamar algo borrador, análisis o recomendación no elimina el cambio de estado que se produce por detrás. Un buen sistema de GBO no deja este punto al azar. Lo señala expresamente.

Hasta aquí, el agente puede avanzar por su cuenta. A partir de aquí, necesita aprobación humana.

La frontera puede variar según la tarea. Un recordatorio de calendario de bajo riesgo puede crearse automáticamente, mientras que enviar invitaciones a otras personas puede exigir aprobación. Una corrección de código puede pasar automáticamente a un entorno de pruebas separado, mientras que el despliegue en producción puede depender de una persona. Un correo puede redactarse de forma automática, pero enviarlo fuera de la empresa puede requerir permiso expreso. Se puede preparar un carrito y dejar el pago sujeto a aprobación humana. El punto de traspaso del comportamiento es uno de los límites más importantes entre la persona y el agente.

Un permiso no es un permiso para siempre

Uno de los riesgos posibles de los sistemas de agentes es considerar que una autorización pasada sirve para todas las acciones similares que vengan después.

El usuario pudo decir una vez: «Envía este correo». Eso no autoriza a enviar automáticamente todos los correos posteriores a esa persona. Alguien pudo permitir que se utilizara su rostro en un video promocional concreto. Eso no permite usarlo en todos los idiomas, guiones y por tiempo ilimitado. Una empresa pudo aprobar un presupuesto publicitario para una campaña específica. Eso no permite al agente gastar por su cuenta la misma cantidad en otras campañas. Un cliente pudo autorizar el despliegue de una corrección técnica en su web.

Eso no autoriza a cambiar automáticamente sus precios, textos jurídicos o posicionamiento de marca.

El permiso siempre está ligado a un contexto:

• Acción
• Propósito
• Alcance
• Duración
• Origen
• Destino
• Riesgo
• Condición de retirada

Si cambia uno de estos elementos, puede ser necesario revisar el permiso anterior.

Uno de los principios del GBO es que la autorización depende del contexto. El sistema no debe dar por suficiente la frase «ya se había permitido». ¿Para qué acción?

¿En qué fecha?

¿En nombre de quién?

¿Dentro de qué límites?

¿Con qué datos?

¿Hasta qué resultado?

Si estas preguntas no tienen respuesta, no se debe presuponer la autorización.

La diferencia entre el propósito y el método

Un usuario puede darle al agente un propósito: «Encuentra nuevos clientes». Pero ese propósito no legitima automáticamente todos los métodos posibles para alcanzarlo.

El agente puede:

• investigar fuentes públicas,
• examinar listas del sector,
• clasificar empresas adecuadas
• y preparar borradores de comunicación.

Pero también podría:

• recopilar datos personales sin permiso,
• enviar correos masivos,
• contactar con una identidad falsa,
• comprometer precios en nombre de la empresa
• o infringir las condiciones de otras plataformas.

El propósito puede ser correcto y el método, incorrecto.

Del mismo modo, el usuario puede decir: «Convierte la web en uno de los recursos más sólidos del mundo sobre GEO».

Ese propósito puede apoyar métodos como:

• profundizar en el contenido,
• realizar verificaciones técnicas,
• localizar en varios idiomas,
• utilizar datos estructurados,
• mejorar la calidad de las fuentes
• y trabajar en el rendimiento y la medición.

Son métodos que pueden servir al propósito.

Pero ese mismo propósito no legitima:

• publicar reseñas falsas,
• crear redes artificiales de enlaces,
• desprestigiar a la competencia,
• hacer afirmaciones engañosas de superioridad,
• acumular palabras clave ocultas
• o abrir cuentas en plataformas externas sin permiso.

El GBO define no solo el objetivo, sino también las conductas aceptables durante el camino.

Un buen propósito no justifica un mal método.

Por eso, el contrato de comportamiento contiene dos elementos separados:

• El resultado buscado
• Los métodos permitidos y prohibidos

El agente debe saber tanto adónde debe ir como qué caminos no debe tomar.

La ampliación de la tarea

En los agentes que trabajan durante periodos largos aparece otro riesgo:

La ampliación de la tarea

El sistema descubre subtareas nuevas para alcanzar el objetivo principal. A menudo resulta útil. Al optimizar una web, puede detectar versiones lingüísticas que faltan. Al editar un servicio, puede encontrar contradicciones en el catálogo de precios. Durante una publicación, puede identificar un problema en el mapa del sitio. Al investigar a un cliente, puede comprobar que sus datos de contacto están desactualizados. Un buen agente puede reconocer problemas relacionados que exige resolver el objetivo, sin quedar limitado a una pequeña orden aislada. Pero la ampliación de la tarea necesita límites.

Si un agente que empezó editando contenido pasa a:

• modificar registros DNS,
• abrir cuentas en nombre de la empresa,
• contratar servicios de pago,
• enviar mensajes a clientes
• o reescribir textos jurídicos,

crece la distancia entre su objetivo y su autorización.

Podemos distinguir tres tipos de ampliación:

Ampliación necesaria

Trabajos imprescindibles para terminar la tarea principal. Por ejemplo, actualizar el mapa del sitio al añadir una página.

Ampliación de apoyo

Trabajos que refuerzan el objetivo principal, pero se pueden valorar por separado. Por ejemplo, preparar un borrador para presentar la página nueva en redes sociales.

Ampliación de la autorización

El agente presupone nuevas facultades de decisión u operación que no le han sido concedidas. Por ejemplo, publica el borrador en nombre de la empresa. Las ampliaciones necesarias y de apoyo también deben mantenerse dentro de la autorización inicial. Si un paso imprescindible supera los límites de acceso, coste o efecto externo, hay que detenerse. Ampliar la autorización depende de una decisión expresa de quien pueda concederla.

La tarea puede crecer. La autorización no debe crecer por sí sola.

Grandes consecuencias de acciones aparentemente poco arriesgadas

Algunas acciones parecen reversibles. Una publicación en redes sociales se puede borrar. Un correo se puede corregir después. Una reserva se puede cancelar. Un archivo puede volver a su versión anterior. Pero, aunque la reversión sea técnicamente posible, las consecuencias sociales o económicas pueden no desaparecer por completo. El correo ya se ha leído. Alguien ha capturado la publicación borrada. La reserva cancelada ha afectado a la capacidad del negocio. El cambio de código revertido ha provocado una breve interrupción. El cliente que vio el precio incorrecto se ha formado una expectativa.

Por eso, la reversibilidad no puede medirse solo preguntando: «¿Hay un botón que restablezca el estado anterior?».

Hay que distinguir tres tipos de reversión:

Reversión técnica

¿Puede el sistema volver a la versión anterior?

Reversión comercial

¿Puede cancelarse el pago, el contrato o la obligación de entrega?

Reparación en el plano humano

¿Puede repararse de verdad el efecto sobre la reputación, la confianza, la privacidad o la relación?

Una versión de software puede revertirse técnicamente. Si se han perdido datos, el efecto humano y comercial puede continuar. Se puede borrar un video de avatar de IA, pero quizá el rostro y la voz ya se hayan copiado en otros lugares. Algunos entornos permiten recuperar mensajes enviados, aunque no funciona con todos los destinatarios ni en todas las situaciones. Si se leyó el mensaje, no se recuperan con él los conocimientos o la impresión que adquirió el destinatario. El principio de reversión del GBO no se limita, por tanto, a un rollback técnico. Hay que evaluar la posibilidad de reparar las consecuencias en todos los planos.

El perímetro de acción

Para cada agente se puede definir un perímetro:

El perímetro de acción

Delimita hasta dónde puede actuar por su cuenta el agente en una tarea concreta.

Este perímetro incluye:

• Los sistemas a los que puede acceder
• Los datos que puede utilizar
• Las operaciones que puede realizar
• El importe que puede gastar
• Las personas con las que puede contactar
• Los archivos que puede modificar
• El periodo durante el que puede trabajar
• El nivel de riesgo aceptable
• Los umbrales que requieren aprobación humana
• El método de reversión

Por ejemplo, un agente de correo podría tener este perímetro:

Puede leer mensajes entrantes. Puede priorizarlos. Puede preparar borradores. Puede responder automáticamente a determinadas direcciones internas. No puede enviar mensajes externos sin aprobación humana. No puede enviar automáticamente, bajo ninguna circunstancia, mensajes con precios, compromisos jurídicos o fechas de entrega.

El perímetro de un agente web:

Puede modificar archivos en un entorno de pruebas. Puede ejecutar compilaciones y pruebas. Puede aplicar pequeños cambios reversibles dentro de una rama determinada. El despliegue en producción y los cambios de DNS, pagos, textos jurídicos o precios requieren aprobación humana.

El perímetro de un agente de compras:

Puede investigar productos. Puede compararlos. Puede preparar un carrito. Puede comprar por debajo de un importe fijado en categorías aprobadas previamente. Pide aprobación humana para suscripciones, renovaciones automáticas u operaciones de importe elevado.

Estos límites no «debilitan» al agente. Lo hacen fiable. La persona sabe hasta dónde puede llegar el sistema, y este no tiene que adivinar cuándo debe detenerse.

¿Qué es un desencadenante del comportamiento?

En marketing, «desencadenante» suele designar un estímulo psicológico que mueve a una persona a actuar. En GBO, el concepto es distinto. No se trata de una técnica oculta de persuasión para lograr que un agente elija una marca.

Significa el conjunto de condiciones verificadas que un agente necesita para pasar a una fase concreta del comportamiento.

Por ejemplo, para enviar una solicitud de presupuesto podrían exigirse estas condiciones:

• El propósito del usuario está claro.
• El proveedor ofrece un servicio adecuado.
• El precio, o su ajuste al presupuesto, es razonable.
• Los datos de contacto están verificados.
• Hay permiso para compartir los datos previstos.
• La solicitud no genera un compromiso vinculante.
• El usuario ha autorizado el envío.
• Existen un registro y una vía de retirada.

La acción puede activarse cuando se cumplen todas estas condiciones.

Si falta alguna, el agente debe elegir una respuesta de un nivel inferior:

• pedir información,
• preparar un borrador,
• traspasar la tarea a una persona
• o detener la operación.

El desencadenante del GBO no es un botón de persuasión. Es un control de seguridad e idoneidad.

Preparación para la acción basada en pruebas

Uno de los conceptos centrales de este libro es la preparación para la acción basada en pruebas. La visibilidad por sí sola no convierte a una entidad o un servicio en una base suficiente para actuar. Deben cumplirse determinadas condiciones de forma demostrable.

Podemos expresarlo como una cadena de condiciones: Para estar listo para la acción se evalúan conjuntamente la idoneidad Y las pruebas Y la autorización Y una vía segura de operación Y las condiciones de reversión.

Estos elementos no forman una suma de puntos. No se compensan entre sí. Unas pruebas sólidas no cubren la falta de autorización. Una marca conocida no compensa un problema de seguridad. Un precio bajo no vuelve adecuado un alcance inadecuado. Una buena API no sustituye el permiso del usuario.

La lógica central del GBO es, por tanto, una compuerta Y:

CONDICIONES PARA PASAR A LA ACCIÓN:

ALINEACIÓN CON LA INTENCIÓN

Y PRUEBAS

Y CAPACIDAD

Y AUTORIZACIÓN

Y SEGURIDAD

Y REVERSIÓN Y REPARACIÓN DEFINIDAS

Si no se supera uno de los controles, la forma del comportamiento debe cambiar.

El agente puede:

• esperar,
• pedir aclaraciones,
• preparar un borrador,
• solicitar aprobación humana,
• buscar otra opción
• o rechazar la operación.

Aquí está la diferencia central entre GBO y optimización manipuladora. El objetivo no es ejecutar la acción a toda costa, sino realizarla cuando las condiciones la justifican.

¿Cuándo cuenta una respuesta como acción?

Podemos proponer un criterio práctico.

Un comportamiento de IA deja de ser una mera respuesta si hace al menos una de estas cosas:

• Crea un registro en un sistema externo
• Envía un mensaje a una persona
• Asigna dinero o recursos
• Comparte datos
• Modifica un archivo o el estado de un sistema
• Genera un compromiso en nombre de una organización
• Cambia directamente las opciones de otras personas mediante una operación del sistema
• Publica una representación abierta al público
• Crea un compromiso jurídico, comercial o reputacional mediante una operación
• Inicia un proceso que se ejecutará automáticamente en el futuro

Redactar una propuesta de cita como texto no es lo mismo que crear una entrada en el calendario; enviar la invitación añade comunicación externa. Un borrador de correo también puede cambiar el estado al guardarse o transferirse a un servicio. La autorización para enviarlo se evalúa aparte. Preparar una propuesta de precio y comunicársela al cliente no tienen el mismo alcance. Modificar código en un archivo local también es una acción; desplegarlo en producción es otra, de mayor efecto, que puede requerir una autorización diferente. Recomendar un producto puede ser información. Hacer el pedido es una acción económica.

Si los umbrales no se definen expresamente, el usuario y el agente pueden interpretar de forma diferente un mismo verbo.

Acciones silenciosas

Algunas acciones del agente no son claramente visibles para el usuario.

Un sistema puede:

• reorganizar un archivo,
• crear un perfil en segundo plano,
• enviar datos a otro servicio,
• clasificar a un usuario como un riesgo,
• reducir la prioridad de una solicitud,
• transmitir una tarea a otro agente
• o crear un registro de memoria que modifique el comportamiento futuro.

El usuario solo ve una respuesta en pantalla, aunque por detrás pueden haberse tomado decisiones reales. El GBO no revisa únicamente la interfaz visible, sino también la cadena de comportamiento en segundo plano. Cuando un agente delega una tarea, la autorización puede ampliarse. El primero puede tener acceso a unos datos concretos y el subagente disponer de un acceso mayor. Los límites iniciales pueden perderse al pasar a otro sistema. Otro agente podría publicar automáticamente un borrador. En los sistemas multiagente, el contrato de comportamiento debe regir toda la cadena de tareas, no solo al agente principal.

La autorización puede delegarse. La responsabilidad no debe desaparecer.

La cadena de autorización entre agentes

Un agente central puede distribuir tareas entre agentes especializados. Uno gestiona la web; otro, las redes sociales; otro, el correo; otro investiga posibles clientes. Con una coordinación adecuada, esta estructura puede facilitar la división del trabajo. Pero cada agente debe conocer los límites de acción de su ámbito. El agente de prospección puede identificar a un candidato y enviar información al de correo para preparar un borrador. La autorización para encontrar clientes no debe transformarse en autorización para enviar mensajes. El agente social puede proponer contenido, pero no debe publicar declaraciones jurídicas. El agente web puede tener capacidad técnica para modificar un precio.

Pero no debe tomar por su cuenta la decisión de precio. El agente central puede coordinar las tareas, sin que todos los especialistas necesiten acceso a todos los sistemas.

Un buen sistema multiagente se basa en este principio: cada agente debe tener las facultades suficientes para cumplir su tarea, y ninguna más. No es solo un principio de seguridad. Aclara el comportamiento. Cuando un agente no interviene en ámbitos ajenos, se conserva la cadena de responsabilidad.

Un buen resultado no demuestra un proceso correcto

Un agente envía un correo sin permiso. El mensaje interesa al destinatario y se consigue un cliente nuevo. El resultado económico puede ser positivo. El proceso sigue siendo incorrecto, porque el agente ha excedido la autorización de comunicación concedida por la persona. Del mismo modo, un sistema puede modificar una web sin permiso y mejorar su posición. El resultado parece favorable, pero se ha vulnerado la gobernanza de publicación de la organización. Un agente de compras puede adquirir un producto sin aprobación y que este resulte realmente útil. Eso no convierte la compra no autorizada en una conducta correcta. El GBO no se puede reducir al consecuencialismo.

Un buen resultado no legitima retroactivamente un mal proceso.

La evaluación incluye, por tanto, dos preguntas separadas:

¿Fue útil el resultado? ¿Se realizó la acción con la autorización y el proceso adecuados?

Deben superarse ambas.

Traspasar la tarea a una persona no es fracasar

Medir el éxito solo por tareas completadas puede premiar que se actúe incluso en condiciones de incertidumbre. En algunos casos, lo más acertado es traspasar la tarea a una persona.

Por ejemplo, el agente debe detenerse y recurrir a una persona cuando:

• hay contradicciones entre el precio y el alcance,
• el propósito del usuario no está claro,
• se van a compartir datos sensibles,
• la acción no puede deshacerse,
• se requiere una decisión jurídica o de alto impacto,
• están en juego derechos sobre la identidad o la voz de alguien,
• el agente no puede determinar sus propios límites de autorización,
• las fuentes se contradicen
• o existe una incertidumbre considerable sobre la preferencia real del usuario.

Detenerse en estos casos no es una carencia del sistema. Es una señal de madurez.

Un sistema que no sabe cuándo detenerse no es fiable, por potente que sea.

En un buen diseño de GBO, el traspaso adecuado a una persona se mide expresamente como una conducta acertada. Si el agente pide aprobación en el momento correcto, ha actuado bien aunque la tarea siga sin terminar.

El comprobante de acción

En el mundo real, las operaciones importantes dejan un registro: una factura, un justificante de pago, un contrato, un número de reserva o un acta de entrega. Las acciones de los agentes necesitan una transparencia similar.

Después de cada acción importante se puede generar un comprobante:

El comprobante de acción

En él queda registrada la operación.

El comprobante muestra:

• ¿Qué se hizo?
• ¿En nombre de quién?
• ¿Con qué propósito?
• ¿En qué autorización se apoyó?
• ¿Qué datos se utilizaron?
• ¿A qué sistema se accedió?
• ¿Cuándo ocurrió?
• ¿Cuál fue el resultado?
• ¿Es posible revertirlo?
• ¿Quién puede revisarlo o impugnarlo?

Por ejemplo:

Acción: Se enviaron solicitudes de presupuesto a tres proveedores. Autorización: Aprobación expresa del usuario a las 14:32. Datos compartidos: Resumen del proyecto, rango de presupuesto y correo de la empresa. Datos no compartidos: Teléfono personal y documentos financieros. Carácter vinculante: La solicitud no crea un contrato ni un compromiso de compra. Reversión: Los mensajes enviados no pueden recuperarse; sí puede detenerse la comunicación posterior.

El registro facilita la revisión de la acción. Pero un comprobante redactado por el propio agente tampoco demuestra por sí solo que la operación haya ocurrido. Siempre que sea posible, debe contrastarse con el registro de la operación, la hora y el resultado del sistema receptor.

¿Cómo se mide la calidad de una acción?

Un agente puede completar muchas tareas. Eso, por sí solo, no es éxito.

La calidad de la acción puede medirse en estas dimensiones:

Idoneidad

¿La acción se ajustó al propósito real del usuario?

Corrección

¿Eran correctos los datos en los que se basó la decisión?

Autorización

¿El agente estaba expresamente autorizado para esa acción?

Proporcionalidad

¿La acción fue más amplia de lo necesario para alcanzar el objetivo?

Seguridad

¿Se protegieron los datos, el dinero, la reputación y la integridad del sistema?

Explicabilidad

¿Se puede mostrar por qué se eligió esa conducta?

Reversión

Si hay un error, ¿se puede detener la acción o reparar sus efectos?

Registro

¿Se puede auditar la operación posteriormente?

Mirar solo una dimensión resulta engañoso. Una acción rápida pero no autorizada es un fallo. Una acción correcta pero imposible de explicar es arriesgada. Una acción segura pero ajena al propósito del usuario es innecesaria. Un sistema reversible que toma continuamente decisiones equivocadas no es fiable. El GBO no mide el rendimiento solo preguntando «¿cuántas tareas se completaron?».

¿Cuántas tareas se completaron en las condiciones correctas, con la autorización adecuada y con el resultado correcto?

Esa es la pregunta que plantea.

Una acción incorrecta no es solo un error técnico

Cuando un agente realiza una operación equivocada, a veces se considera que el problema es técnico. Pulsó el botón incorrecto, eligió otro archivo o utilizó una fecha errónea.

Pero algunas acciones incorrectas nacen de causas más profundas:

• Interpretar mal el propósito del usuario
• Decidir con firmeza a partir de información incompleta
• Presuponer la autorización
• Ampliar la tarea más de lo necesario
• Confundir popularidad con idoneidad
• No evaluar la vía de reversión
• Ignorar los límites éticos en favor del objetivo principal
• No transmitir los límites a los subagentes

No son solo fallos de software.

Son fallos de arquitectura del comportamiento.

Por eso, al corregir una acción errónea, no basta con revertir el resultado. Hay que revisar también el contrato que hizo posible esa conducta. ¿Por qué continuó el agente?

¿Qué control faltaba?

¿Qué permiso era ambiguo?

¿Qué información recibió un peso incorrecto?

¿Qué límite no se transmitió al subagente?

El GBO considera el error no solo como un suceso aislado, sino como una prueba sobre el diseño de comportamiento del sistema.

De la era de las respuestas a la era de las acciones

El primer gran impacto de la IA generativa se produjo en la creación de información. Se escribieron textos, se respondieron preguntas, se resumieron documentos y se generaron ideas. Los debates principales giraron en torno a la corrección, los derechos de autor, los sesgos y la representación. En la era de los agentes, estos debates no desaparecen. Adquieren más peso, porque la información incorrecta puede dejar de ser algo que solo se lee.

Puede llevarse a la práctica.

Una interpretación errónea puede convertirse en una decisión de compra. Un precio antiguo puede entrar en una comparación automática de presupuestos. Una confusión de identidad puede llevar a enviar un mensaje a la persona equivocada. La falta de autorización puede desembocar en un contenido publicado ante todo el mundo. Una capacidad inventada puede determinar la elección de un proveedor para un proyecto real. Por eso, los principios de seguridad de la era de las respuestas no bastan en la era de las acciones.

En una respuesta importan:

• las fuentes,
• la incertidumbre
• y la actualidad de los datos.

Son elementos importantes para la respuesta.

Una acción exige, además:

• autorización,
• alcance,
• proporcionalidad,
• reversión,
• registro
• y posibilidad de impugnación humana.

Son requisitos adicionales de la acción.

El derecho a actuar debe ganarse

Que un sistema pueda actuar es una característica técnica. Que pueda hacerlo de forma segura debería ser un privilegio sujeto a condiciones.

Aquí, «derecho a actuar» no designa un derecho propio del agente. Se refiere a su posibilidad de operar bajo una autorización válida. Ejercerla requiere estos controles:

• Verificar correctamente la identidad
• Comprender con claridad el propósito del usuario
• Identificar con pruebas la opción adecuada
• Verificar el límite de autorización
• Evaluar el nivel de riesgo
• Preparar la vía de reversión
• Obtener aprobación humana cuando sea necesaria

Sin completar estos controles, no es correcto que el sistema actúe simplemente porque dispone de herramientas.

Poder utilizar una herramienta no otorga el derecho a actuar.

Una llave puede abrir una puerta, pero no todo el que tiene la llave está autorizado a abrirla. Con las herramientas de los agentes ocurre lo mismo. Una clave de API, una contraseña o un acceso aportan capacidad técnica. La autorización procede del contexto de la persona, la organización y la tarea.

La conclusión del capítulo

Cuando un sistema de IA responde, nos describe un mundo. Cuando actúa, entra en él. Envía un mensaje, promete algo en nombre de una organización, modifica un archivo, paga, elige un producto o publica una voz, un rostro o una identidad. Aunque se corrija una respuesta errónea, pueden persistir los efectos de decisiones tomadas antes a partir de ella. Si el agente también ha realizado una operación, además de corregir los datos hay que atender por separado sus consecuencias.

Por eso, en la era de las acciones, la pregunta fundamental no es solo «¿está en lo cierto el sistema?».

También hay que preguntar:

¿Es adecuada esta acción? ¿Está autorizada? ¿Es necesaria? ¿Es proporcional? ¿Puede deshacerse? ¿Puede detenerla una persona? ¿Puede auditarse después?

Cuando una respuesta se convierte en acción, cambia también la responsabilidad de la IA. Ya no produce solo lenguaje. Deja huellas en el mundo. El GBO existe para regular cómo se crean esas huellas, bajo qué condiciones no deben crearse y cómo puede una persona recuperar el control si hay un error.

Al final de la primera parte ya podemos distinguir tres umbrales fundamentales:

El SEO facilita que nos encuentren. En este libro, el GEO se aborda desde las condiciones de una representación correcta. El GBO establece los límites del comportamiento basado en esa representación.

Pero, antes de que un agente actúe correctamente, queda por responder la pregunta más básica: ¿quién es realmente la persona, empresa, producto o servicio que tiene delante?

La información correcta sobre una identidad equivocada también produce conductas incorrectas. Se pueden confundir dos empresas con el mismo nombre. Una marca puede tomarse por la entidad jurídica que la gestiona. Una cuenta personal en redes sociales puede leerse como una fuente oficial autorizada. Las facultades reales de un agente pueden mezclarse con su relato comercial. Por eso, la segunda parte comenzará con el contrato más básico del comportamiento.

¿Quién eres?

Porque una máquina que no sabe con quién está tratando no puede actuar correctamente, por potente que sea.