La organización preparada para agentes

Empecemos con un ejemplo ficticio. El director de una empresa quiere evaluar con más rapidez las solicitudes de sus clientes. El sitio web tiene páginas de servicios, pero los precios se guardan en una hoja de cálculo aparte. El equipo comercial aplica descuentos particulares a algunos clientes. Las condiciones de soporte están dispersas en correos antiguos. El alcance de ciertos servicios no coincide entre las plantillas de contrato y la web. Las páginas en inglés están al día; las páginas en alemán y turco llevan meses de retraso. En un antiguo directorio empresarial sigue figurando un servicio que ya no se ofrece.

El CRM, la herramienta de gestión de proyectos y los buzones de correo funcionan por separado. El director quiere crear un agente de IA que lea toda esa información y recomiende a cada cliente el servicio adecuado.

El encargo es este: «Analiza la necesidad del cliente que nos contacte, recomienda el servicio adecuado, explica el rango de precios y, si procede, programa una reunión». A primera vista, tiene sentido. El agente puede leer correos, recorrer la web, encontrar un hueco en el calendario y crear un registro en el CRM. Técnicamente, todo parece listo. Los problemas empiezan con el primer cliente real. Pregunta por el plan de alojamiento económico con pago anual. El agente le describe también las prestaciones de la gestión operativa mensual como si estuvieran incluidas en ese plan.

Otro cliente pide soporte en seis idiomas. El agente interpreta las páginas de servicios publicadas en seis idiomas como atención al cliente en tiempo real en todos ellos. Un tercero pregunta por el diseño de un logotipo. El agente cree que el precio del trabajo específico de logotipo cubre un sistema completo de identidad visual. Al cuarto le envía directamente una invitación a una reunión, en vez de un enlace al calendario. Para el quinto, aplica como política general el descuento particular que el responsable comercial concedió a otro cliente tiempo atrás. Las herramientas funcionan. Los mensajes están bien escritos. Las operaciones tienen éxito técnico. Pero la organización no está preparada para agentes.

Prepararse para agentes no consiste simplemente en:

• tener acceso a un modelo;
• añadir un cuadro de chat a la web;
• conectar una cuenta de correo;
• entregar unas claves API;
• escribir «AI-first».

Consiste en organizar la información de referencia, las autorizaciones, los límites y la respuesta a los errores de modo que las máquinas puedan trabajar con todo ello de forma segura.

Por eso, la primera pregunta de la tercera parte es:

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

Qué significa estar preparada para agentes

Una organización preparada para agentes no es solo aquella sobre la que los sistemas de IA pueden encontrar información.

Una organización preparada para agentes:

• define con claridad quién es;
• muestra sus capacidades reales junto con sus límites;
• explica para quién es adecuada y para quién no;
• determina qué acciones está autorizado a realizar cada agente;
• sabe dónde hace falta la aprobación de una persona;
• mantiene la correspondencia entre el contenido visible y los registros para máquinas;
• registra las operaciones;
• puede detenerse de forma segura ante un error y conoce los límites de la reversión y la reparación;
• preserva las vías de impugnación y reparación para las personas afectadas.

Podemos resumirlo así: una organización preparada para agentes permite que las máquinas no solo accedan a información correcta sobre ella, sino que actúen correctamente y con autorización a partir de esa información; si se produce un error, dispone de mecanismos efectivos de detención, reversión y reparación. La diferencia es considerable. Una empresa puede estar muy bien documentada sin ofrecer vías seguras para las operaciones de los agentes. Puede tener API potentes sin aclarar qué operación puede realizarse en nombre de quién. Una web puede ser muy visible y, al mismo tiempo, contener registros contradictorios de precios y alcance.

Una empresa puede haber automatizado cientos de procesos sin contar con una persona responsable capaz de detener todo el sistema. La preparación para agentes no es una característica tecnológica: es la capacidad de la organización para gobernar su comportamiento.

Publicar una API no basta

Los agentes suelen actuar mediante herramientas: crean eventos de calendario, envían correos, modifican archivos, hacen pedidos o dan de alta clientes.

Por eso, las organizaciones pueden evaluar su preparación a partir de sus conexiones técnicas: «Nuestro sistema tiene una API». «Puede conectarse al correo». «La integración del calendario está terminada». «Le hemos dado acceso al CRM». Esas conexiones pueden ser necesarias para un flujo de trabajo, pero no bastan por sí solas. Que exista una puerta no significa que deba abrirse en cualquier circunstancia. Un agente puede crear registros de clientes, pero no debe registrar dos veces a la misma persona. Puede enviar invitaciones, pero debe conocer la zona horaria del participante, la finalidad de la reunión y su aprobación expresa. Puede preparar una propuesta de precio.

Lo que no debe hacer es convertir un descuento particular del responsable comercial en una regla general.

Una API responde a esta pregunta: «¿Cómo se realiza técnicamente esta operación?».

GBO añade otras:

¿Debe realizarse esta operación? ¿En nombre de quién? ¿Bajo qué condiciones? ¿Qué datos se utilizarán? ¿Quién debe aprobarla? ¿Cómo se detendrá si algo sale mal?

La base de una organización preparada para agentes no es, por tanto, la conexión, sino el contrato de comportamiento.

La organización debe saber qué información es cierta

Un agente no puede resolver de forma fiable una contradicción que la organización no ha resuelto internamente. Si el equipo comercial describe un servicio de una manera y la web, el catálogo de precios y el contrato le atribuyen alcances distintos, el agente se encuentra ante un conflicto. Si no se ha definido la prioridad entre fuentes, no debe elegir por su cuenta cuál es la correcta. La elección podría ser arbitraria: confiar en el archivo más reciente, usar la expresión que más se repite o preferir el registro que le resulta más comprensible. Pero, si la propia organización no sabe qué fuente es correcta, el agente no debe adivinarlo. Por eso, la preparación para agentes no empieza fuera.

Primero, la organización debe mirar hacia dentro.

Debe tener respuestas claras a estas preguntas:

¿Quiénes somos? ¿A través de qué estructura jurídica operamos? ¿Qué servicios ofrecemos realmente? ¿Cuáles son nuestros precios y alcances? ¿Qué servicios están reservados a determinados clientes? ¿Quién puede decidir sobre cada asunto? ¿Qué información es canónica? ¿Qué registros están desactualizados? ¿Qué tareas pueden ejecutarse automáticamente? ¿Cuáles requieren aprobación humana? ¿Quién responde si hay un error?

Sin esas respuestas, conectar un agente no agiliza la organización: automatiza la incertidumbre existente.

Añadir un agente potente a una organización desordenada puede no generar orden. Puede propagar el desorden con mayor rapidez.

Los seis ejes de una organización preparada para agentes

En este libro abordo la preparación organizativa a través de seis ejes:

1. Eje de información de referencia

2. Eje de identidad

3. Eje de capacidad e idoneidad

4. Eje de autorización

5. Eje de acción y pruebas

6. Eje de recuperación

Aunque falte uno de estos ejes, algunas operaciones limitadas pueden seguir siendo viables. No debe presumirse, sin embargo, la fiabilidad de las acciones afectadas por esa carencia.

1. Eje de información de referencia

El eje de información de referencia establece en qué fuente, con qué versión y bajo qué autorización se mantiene la información importante de la organización. No tiene por qué estar reunida en un solo documento. El catálogo de servicios, los precios, los horarios, las personas autorizadas y los textos jurídicos pueden estar separados. Lo que debe conocerse es la relación entre esas piezas.

El eje de información de referencia responde a estas preguntas:

• ¿Cuál es la fuente canónica de cada tipo de información?
• ¿De qué fuente se generan las páginas visibles de la web?
• ¿Qué registros se actualizan conjuntamente cuando cambia un precio?
• ¿Cómo se conservan las versiones anteriores?
• ¿Cuándo deja de ser válido un dato?
• ¿Cómo se comparan las versiones destinadas a personas y a máquinas?
• ¿Qué fuente prevalece cuando hay contradicciones?

Si el precio principal de un servicio se escribe a mano en tres archivos distintos, el eje de información de referencia es débil. Un cambio puede dejar sin actualizar los otros dos registros. El agente puede leer el antiguo y la persona ver la página nueva. La misma organización publica dos versiones de los hechos.

Qué significa una única fuente de verdad

«Una única fuente de verdad» no significa guardar toda la información en un solo archivo. Lo importante es conocer la fuente principal y autorizada para cada tipo de información.

Por ejemplo:

• el registro de la empresa para identificar al operador jurídico;
• el catálogo canónico de servicios para determinar su alcance;
• el registro aprobado de condiciones comerciales para el precio;
• el registro de autorizaciones para las funciones de las personas;
• la versión publicada para la presentación de la web;
• el contrato de autorización para el comportamiento del agente;
• un registro de pruebas fechado para la medición.

Pueden ser fuentes distintas, pero sus relaciones deben estar claras.

Una única fuente de verdad no es un único archivo, sino un único punto de consulta autorizado para cada hecho.

La información debe tener un responsable

Una información puede existir en el sistema sin que esté claro quién debe mantenerla al día. ¿Quién cambia el precio?

¿Quién aprueba el alcance del servicio?

¿Quién actualiza el horario?

¿Quién retira las autorizaciones de los agentes?

¿Quién decide si se presta servicio en un país?

Cada dato importante debe tener un responsable de la información. No tiene por qué ser quien introduce técnicamente el registro. Un desarrollador puede modificar el archivo de precios, pero la decisión comercial puede corresponder a finanzas o a un directivo autorizado. Un agente de contenido puede editar un texto jurídico, aunque un cambio de significado puede requerir la aprobación del responsable legal.

El responsable de la información se ocupa de:

• verificarla;
• aprobar los cambios;
• determinar durante cuánto tiempo puede considerarse actualizada;
• resolver contradicciones;
• invalidar el registro antiguo.

Ante una duda, el agente debe saber a qué persona o unidad acudir.

La vigencia de la información

No toda la información envejece al mismo ritmo. El nombre de una empresa puede cambiar pocas veces; los recursos disponibles, a diario; los precios, cada mes. Una campaña puede durar unos días y el acceso de un agente, una sola sesión.

Por eso, los registros deben indicar:

• fecha de creación;
• fecha de la última verificación;
• inicio de vigencia;
• fin de vigencia;
• versión;
• responsable;
• estado.

Algunos estados posibles:

• Borrador
• Pendiente de aprobación
• Activo
• Limitado
• Caducado
• Revocado
• Archivado

El agente no debe considerar actualizado un registro por el mero hecho de que exista.

Que un registro exista no lo hace válido.

2. Eje de identidad

El eje de identidad conecta la organización, sus personas, marcas, agentes y canales oficiales.

En una organización hay que relacionar:

• el nombre de marca;
• la denominación jurídica;
• el dominio;
• los perfiles sociales;
• las direcciones oficiales de correo;
• los representantes autorizados;
• las identidades de los agentes;
• los nombres de productos.

Estos elementos pueden diferir entre sí. Si sus relaciones no están claras, el agente puede ejecutar la operación correcta sobre la entidad equivocada.

El eje de identidad incluye, como mínimo:

• identidad canónica de la organización;
• relación entre marca y operador jurídico;
• dominios oficiales;
• canales de comunicación autorizados;
• funciones vigentes de las personas;
• fichas de identidad de los agentes;
• facultades de representación y firma;
• identidades antiguas o revocadas.

Inventario de agentes

Muchas organizaciones pueden no saber con exactitud cuántos agentes de IA utilizan. Un equipo usa una herramienta de redes sociales; otro configura la automatización del correo. Los desarrolladores ejecutan un agente de programación, el equipo comercial utiliza otro para investigar clientes y recursos humanos conecta un sistema más. Cada uno parece útil en su ámbito.

Pero, a escala de la organización, pueden quedar preguntas sin respuesta:

• ¿Cuántos agentes están activos?
• ¿Quién los creó?
• ¿A qué cuentas acceden?
• ¿Qué datos utilizan?
• ¿A qué servicios externos se conectan?
• ¿Qué acciones ejecutan automáticamente?
• ¿Quién puede detenerlos?
• ¿Cuándo vencen sus autorizaciones?

Por eso, uno de los primeros pasos prácticos es elaborar un inventario de agentes. Los campos siguientes pueden servir de esquema inicial. No constituyen una API funcional ni un estándar de datos obligatorio: el alcance y los límites relativos a los datos personales deben definirse para cada organización.

agent_id

public_name

technical_identity

operator

human_owner

purpose

connected_systems

accessible_data

allowed_actions

prohibited_actions

approval_thresholds

subagents

valid_from

valid_until

shutdown_method

last_reviewed

status

La organización no debe permitir que agentes ausentes del inventario y cuya autorización no se haya verificado accedan a sus recursos o actúen en su nombre.

Agentes en la sombra

Un empleado puede usar una herramienta de IA con su cuenta personal, cargar documentos de la organización, encargar un análisis de datos de clientes y publicar el resultado en nombre de la empresa. Ese sistema no figura en el inventario oficial de agentes.

Podemos llamarlo operación de agentes en la sombra. No siempre hay mala intención: a menudo, el empleado solo quiere trabajar más rápido.

Pero la organización desconoce:

• ¿Qué datos se compartieron?
• ¿Qué modelo o servicio se utilizó?
• ¿Cómo se verificó el resultado?
• ¿Qué operación realizó el agente?
• ¿Dónde se guardó la información?
• ¿Quién responde si hay un error?

Prohibir los agentes en la sombra no suele bastar. La organización debe entender por qué las personas necesitan esas herramientas y ofrecer vías oficiales seguras.

Si las personas necesitan herramientas en la sombra para hacer su trabajo, es posible que el sistema oficial no responda a la necesidad real.

Cómo debe presentarse el agente

Cuando un agente se comunica con personas, no debe ocultar por completo su identidad. Tampoco hace falta que empiece cada frase con «Soy una inteligencia artificial».

Pero el usuario debe poder entender:

• ¿Está interactuando con un sistema automático?
• ¿En nombre de qué organización trabaja?
• ¿Qué tipos de operaciones puede realizar?
• ¿Cómo puede contactar con una persona?
• ¿Hasta qué punto es vinculante la información que ofrece?

Un borrador de presentación que ilustre el enfoque de este libro podría decir lo siguiente. No es una declaración de las facultades de un asistente que esté actualmente en funcionamiento: «Este asistente ofrece información general sobre servicios en nombre de NobleJackal y puede preparar una solicitud de reunión. Los precios, los compromisos jurídicos y la aceptación definitiva de un proyecto requieren la aprobación de una persona autorizada». Una explicación así no debilita al agente: hace visibles sus límites.

3. Eje de capacidad e idoneidad

Para que los agentes puedan elegir una organización, no basta con que exista una lista de servicios.

Para cada servicio deben especificarse:

• resultado real;
• datos y materiales necesarios;
• alcance;
• exclusiones;
• precio o método de fijación del precio;
• recursos disponibles;
• cliente adecuado;
• situaciones para las que no es adecuado;
• pruebas;
• respuesta en caso de fallo.

Todos estos aspectos deben quedar explicados.

Esta información puede mantenerse en un registro de capacidad e idoneidad.

El nombre del servicio no basta

«Automatización con IA» puede ser el nombre de un servicio.

Pero no responde a las preguntas del agente:

• ¿Qué flujos de trabajo abarca?
• ¿Se limita al asesoramiento?
• ¿Incluye implantación en producción?
• ¿Se envían correos?
• ¿Cómo funciona la aprobación humana?
• ¿Qué datos pueden utilizarse?
• ¿Quién se encarga del mantenimiento?
• ¿Cómo se determina el precio?
• ¿En qué situaciones se rechaza el encargo?

Una organización preparada para agentes convierte el nombre de un servicio en un contrato de comportamiento.

Registro canónico del servicio

Para cada servicio puede diseñarse un registro canónico como el siguiente. Los campos son ilustrativos, no un esquema obligatorio para todas las organizaciones.

service_id

service_name

provider_identity

outcome

target_users

supported_use_cases

unsupported_use_cases

required_inputs

deliverables

scope_included

scope_excluded

pricing_model

starting_price

third_party_costs

supported_languages

supported_regions

capacity_status

estimated_start

evidence

quality_criteria

human_approval

failure_behavior

version

validity

El registro no está destinado solo a las máquinas. Los equipos comerciales, de web, propuestas, contratos y operaciones también utilizan la misma fuente. Así, las distintas áreas de la organización trabajan con la misma información comercial.

Definir con claridad para quién no es adecuado el servicio

El registro también debe indicar a quién no está dirigido un servicio.

Por ejemplo:

• proyectos por debajo de cierto presupuesto;
• clientes que exigen una entrega urgente en un plazo irreal;
• clientes que no pueden facilitar el acceso necesario a los datos;
• solicitudes de clonación de rostro o voz sin permiso;
• solicitudes de reseñas falsas, SEO manipulador o interfaces engañosas;
• procesos de alto riesgo en los que se pretende eliminar toda aprobación humana.

Estas exclusiones no son solo una postura ética. Son límites de selección que reducen el riesgo de que el agente inicie una operación con el cliente equivocado.

Disponibilidad de recursos

Un servicio puede permanecer en el catálogo, mientras que los recursos disponibles para prestarlo cambian con mayor frecuencia.

Por eso, puede hacer falta un registro separado:

service_id

availability_status

accepting_new_work

earliest_start

capacity_band

last_updated

expires_at

El agente no debe asumir compromisos vinculantes a partir de un registro de disponibilidad desactualizado.

Si desconoce la disponibilidad, debe decir: «El servicio se ofrece; falta confirmar la fecha de inicio disponible».

4. Eje de autorización

El eje de autorización muestra qué personas y qué agentes están autorizados a realizar cada tipo de acción dentro de la organización. Dar a los agentes un acceso amplio a las herramientas sin haber establecido este eje supone un riesgo serio.

El eje de autorización comprende:

• mapa de funciones de las personas;
• mapa de autorizaciones de los agentes;
• límites de acceso a datos;
• límites financieros;
• facultades de comunicación;
• facultades de publicación;
• umbrales de aprobación humana;
• reglas de delegación;
• responsabilidad de detención de emergencia;
• registros de vigencia y revocación.

La autorización por función puede no ser suficiente

Una organización puede decir: «El agente comercial tiene acceso a las operaciones comerciales». Es demasiado amplio.

Esas operaciones pueden incluir:

• investigar posibles clientes;
• preparar una lista reducida de candidatos;
• redactar el borrador del primer mensaje;
• enviar el mensaje;
• programar una reunión;
• explicar el precio;
• conceder un descuento;
• enviar una propuesta;
• aceptar un contrato.

No son la misma facultad. La autorización debe separarse por tipo de acción.

Matriz de autorizaciones

La tabla muestra una distribución ilustrativa para una organización que ya ha definido la autorización vigente de la tarea y los límites de acceso a datos. «No necesaria» significa que, en este ejemplo, no hace falta volver a aprobar cada operación. No permite acceder a datos ni comunicarse sin autorización.

En una organización real, la matriz puede ser más detallada. Lo importante es hacer visible la diferencia entre «el agente tiene acceso» y «el agente está autorizado».

Puntos de traspaso a una persona

Cada proceso debe definir los momentos en que debe intervenir una persona.

Podemos llamarlos puntos de traspaso a una persona.

Algunos ejemplos:

• primer contacto externo;
• comunicación de un precio o descuento;
• propuesta vinculante;
• publicación en producción;
• compra de importe elevado;
• transferencia de datos personales;
• generación de contenido biométrico;
• declaración jurídica o pública;
• operación irreversible.

El punto de traspaso a una persona no debe quedar en una instrucción vaga como «pregunta si hay riesgo». Hay que definirlo con la mayor claridad posible.

Qué debe contener una solicitud de aprobación

Al pedir aprobación, el agente no debe limitarse a preguntar: «¿Continúo?».

Debe mostrar:

• ¿Qué va a hacer?
• ¿En nombre de quién?
• ¿A qué destinatario u objeto se dirige la acción?
• ¿Con qué datos?
• ¿Con qué coste?
• ¿Qué compromiso asumirá?
• ¿Puede revertirse la acción?
• ¿Qué incertidumbre sigue abierta?

Así, la persona puede tomar una decisión real.

Vigencia de las autorizaciones

Las autorizaciones de los agentes no deben quedar abiertas indefinidamente y sin revisión.

Pueden limitarse a:

• una tarea;
• un conjunto de archivos;
• un cliente;
• una campaña;
• un presupuesto determinado;
• un periodo concreto;
• un horario de trabajo;
• un país o canal determinado.

Al vencer el plazo, la autorización debe evaluarse de nuevo.

5. Eje de acción y pruebas

Al actuar, el agente no debe limitarse a producir un resultado. Debe registrar qué hizo, por qué y con qué autorización.

Los elementos principales de este eje son:

• Catálogo de acciones
• Condiciones previas
• Validación de datos de entrada
• Comprobante de acción
• Verificación independiente
• Medición
• Versionado
• Conservación de pruebas

Catálogo de acciones

La organización debe definir claramente las acciones que pueden realizar sus agentes.

Por ejemplo:

• Investigar a un posible cliente
• Redactar un borrador de correo
• Enviar un mensaje
• Proponer una fecha de reunión
• Enviar una invitación de calendario
• Evaluar la idoneidad de un servicio
• Mostrar información de precios
• Preparar un borrador de propuesta
• Actualizar contenido web
• Publicar en el sitio en producción
• Enviar una notificación a un buscador
• Medir el rendimiento
• Elaborar un informe

Para cada acción debe constar:

• Elementos necesarios para ejecutarla
• Nivel de autorización
• Aprobación humana
• Nivel de riesgo
• Resultado esperado
• Prueba de éxito
• Método de reversión

Cuándo puede darse una acción por terminada

«Mensaje enviado» solo puede ser una condición de finalización si se confirma con una prueba adecuada del envío. Si el objetivo de la tarea es la entrega, una respuesta o una reunión, enviar el mensaje no demuestra ninguno de esos resultados.

Para una publicación web, las condiciones de finalización podrían ser:

• Archivos transferidos
• Hashes del servidor remoto coincidentes
• HTML correcto en el sitio en producción
• Enlaces canónicos y de idioma verificados
• Presentación móvil y de escritorio comprobada
• Ausencia de errores críticos
• Paquete de reversión disponible

Estas comprobaciones pueden definir cuándo se considera terminada la publicación.

Para compartir el borrador de una propuesta no vinculante, puede ser necesario comprobar que:

• Se ha verificado al destinatario correcto
• Se ha enviado el texto aprobado
• Se han respetado los límites de los datos compartidos
• Se ha conservado el registro del mensaje
• No se ha creado un compromiso vinculante

La condición de finalización debe abarcar no solo la operación del agente, sino también su resultado en el mundo real.

Comprobante de acción

Después de una acción importante puede generarse un comprobante como el siguiente. Los campos ilustrativos deben estar vinculados a los registros reales de la operación: el resumen redactado por el propio agente no demuestra por sí solo que haya tenido éxito.

action_id

action_type

requested_by

performed_by

target

purpose

authorization

inputs_used

data_shared

started_at

completed_at

technical_result

real_world_verification

human_approval

rollback_status

open_uncertainties

El comprobante puede presentarse de forma sencilla al usuario y con más detalle a quien lo audite.

Jerarquía de las pruebas

No todas las afirmaciones de éxito cuentan con pruebas de la misma fuerza.

En una publicación web, por ejemplo:

• El comando se ejecutó correctamente.
• El servicio de transferencia aceptó la carga.
• El hash del archivo remoto coincidió.
• Se verificó la respuesta HTTPS del sitio publicado.
• Un navegador real mostró correctamente la página.
• El robot del buscador pudo acceder.
• El buscador indexó la página.
• La página ganó visibilidad para una consulta concreta.
• Hubo una acción del usuario y un resultado comercial.

Estas nueve observaciones no demuestran lo mismo, ni tienen por qué producirse siempre en ese orden. El agente debe indicar con claridad qué nivel de prueba ha alcanzado.

Que se acepte una notificación no significa que la página esté indexada. La indexación no equivale a una posición en los resultados. Una posición en los resultados no es un cliente. Una solicitud de un cliente no es un ingreso.

La forma de comunicar las pruebas debe preservar estas diferencias.

Principio de verificación independiente

El sistema que realiza un trabajo no debe confiar únicamente en su propio mensaje de éxito. Siempre que sea posible, el resultado debe comprobarse mediante un registro o una observación independiente de la afirmación del agente que actuó. Usar otra herramienta no aporta independencia si ambas se basan en la misma fuente errónea.

• Después de cargar los archivos, descárgalos desde fuera del entorno de publicación.
• Después de generar el contenido, compruébalo en un navegador real.
• Compara el registro de precios con la página visible y el catálogo.
• Antes de enviar un correo, verifica el destinatario y los adjuntos; después, comprueba el registro de la operación en el servicio.
• Después de un pago, coteja el pedido con el registro bancario.
• Al ejercer una autorización, registra la versión vigente del contrato.

La verificación independiente tiene un coste, pero reduce los fallos que pasan inadvertidos.

6. Eje de recuperación

Una organización preparada para agentes no planifica únicamente las acciones que salen bien.

Ante un posible error, define de antemano:

• quién detendrá la operación;
• qué sistemas se desconectarán;
• cuál es el último estado seguro;
• qué datos deben preservarse;
• a quién hay que informar;
• cómo se recibirá una impugnación;
• cómo se reparará el daño.

Estas decisiones se toman antes del incidente.

El eje de recuperación incluye:

• Clasificación del incidente
• Estado seguro
• Detención de emergencia
• Puntos de control
• Copia de seguridad y reversión
• Registro del incidente
• Persona responsable
• Notificación
• Impugnación
• Reparación
• Causa raíz
• Actualización del contrato

Detener al agente no es lo mismo que detener el sistema

Es posible desconectar al agente central.

Pero pueden seguir funcionando:

• Subagentes
• Tareas programadas
• Colas de correo
• Automatizaciones externas
• Suscripciones
• Operaciones con archivos

Por eso, el plan de detención de emergencia debe cubrir toda la cadena de acciones afectada. Para sistemas ajenos a esa cadena, o cuya detención pueda causar daños por sí misma, se necesita una decisión separada.

Silenciar a un agente no detiene las acciones que ha puesto en marcha.

El último estado seguro

Para cada sistema crítico debe definirse de antemano el estado al que se puede volver o la forma de detenerlo con seguridad. Puede ser una versión verificada de la web, un catálogo de precios aprobado o una copia de datos comprobada. Volver a una política de autorización anterior no debe reabrir accesos revocados: prevalecen los registros vigentes de autorización y revocación. Tampoco pueden convertirse los mensajes ya enviados a clientes en borradores que nunca salieron. En ese caso, se detienen los envíos pendientes y se activa la corrección o la reparación. Las vías de reversión deben probarse con regularidad, dentro de límites seguros.

Registro de contratos de comportamiento

Los cinco contratos desarrollados en los capítulos 4 a 8 deben gestionarse conjuntamente dentro de la organización.

Podemos llamar a este conjunto registro de contratos de comportamiento.

El registro reúne:

• Contrato de identidad
• Contrato de capacidad
• Contrato de idoneidad
• Contrato de autorización
• Contrato de recuperación y reparación

No tiene que ser un documento gigantesco, pero los registros deben estar vinculados. Cuando cambia la identidad de un servicio, hay que revisar los registros de idoneidad y precios. Cuando cambia la autorización de un agente, se actualiza el catálogo de acciones. Cuando ocurre un incidente, debe ser posible localizar la versión pertinente del contrato.

El contrato de comportamiento no es estático

Las organizaciones cambian. Cambian los servicios y los precios, se marchan personas, se incorporan agentes y aparecen riesgos. Por eso, el contrato de comportamiento debe ser un sistema vivo.

Con cada cambio debe saberse:

• ¿Quién lo hizo?
• ¿Por qué?
• ¿Qué registros quedaron afectados?
• ¿Qué pruebas se ejecutaron?
• ¿Qué versión pasó a estar vigente?
• ¿Cómo se archivó la versión anterior?

Estas respuestas deben estar disponibles para cada modificación.

El contrato debe coincidir con el comportamiento real

Un documento puede decir: «El agente no puede enviar mensajes externos». Pero, si la herramienta de correo tiene habilitado el permiso de envío, el sistema permite en la práctica otra cosa.

Una política puede exigir aprobación humana para el precio. Si el agente web puede modificar directamente el catálogo de precios, la regla solo existe sobre el papel.

Por eso, hay que comparar dos planos:

Autorización declarada

Lo que dice la política.

Facultades disponibles en la práctica

Lo que el sistema técnico permite realmente.

La diferencia es la brecha en la aplicación de autorizaciones. Una organización preparada para agentes mantiene esa brecha lo más pequeña posible.

Hacer cumplir las reglas técnicamente

La autorización, el acceso a datos y los límites operativos no deben depender solo de las instrucciones al modelo. También deben aplicarse en la herramienta o el servicio correspondiente.

Por ejemplo:

• El límite de pagos del agente puede imponerse técnicamente.
• La publicación en producción puede bloquearse si no hay aprobación humana.
• Determinados campos de datos pueden quedar completamente fuera de la vista del agente.
• El envío de correo externo puede exigir un token de autorización separado.
• La modificación de un registro de precios puede reservarse a una función autorizada.
• Una operación de alto riesgo puede requerir dos aprobaciones distintas.

Las instrucciones importan. Pero, ante un riesgo elevado, el control técnico ofrece más seguridad.

Que el agente diga «no debo hacerlo» no ofrece la misma garantía que un sistema que impide hacerlo.

Gobernar las acciones, no los nombres de las herramientas

Una organización puede prohibir una herramienta de IA concreta y, aun así, un empleado puede hacer lo mismo con otra. Una gobernanza basada únicamente en nombres de productos envejece enseguida.

Un enfoque más duradero consiste en definir:

• ¿Qué datos pueden salir de la organización?
• ¿Qué acciones pueden ejecutarse automáticamente?
• ¿Qué decisiones requieren aprobación humana?
• ¿Qué resultados se verifican antes de publicarse?
• ¿Qué registros se conservan?
• ¿Qué sistemas pueden conectarse entre sí?

La herramienta puede cambiar. El principio de comportamiento permanece.

Diseñar el reparto de tareas entre personas y agentes

Una organización preparada para agentes no divide el trabajo simplemente entre «trabajo humano» y «trabajo de IA». Distribuye las tareas dentro del proceso según el tipo de acción.

Por ejemplo:

Ámbitos en los que destaca el agente

• Explorar grandes conjuntos de información
• Detectar incoherencias
• Generar opciones para la selección
• Preparar borradores
• Ejecutar pruebas
• Realizar verificaciones repetidas
• Inventariar los cambios
• Llevar registros de medición

Ámbitos en los que la persona ocupa el centro

• Definir el propósito
• Decidir sobre valores y preferencias de riesgo
• Asumir compromisos de precio y jurídicos
• Aprobar decisiones de selección con gran impacto
• Evaluar intereses humanos en conflicto
• Decidir cómo reparar un daño
• Asumir la responsabilidad última

La división no es absoluta, pero resulta útil para diseñar el trabajo.

La tarea humana no consiste solo en aprobar

Sería un error reducir a la persona a un botón de «sí».

La persona determina:

• por qué se ha elegido ese objetivo;
• a quién afectará;
• qué equilibrio entre ventajas y renuncias es aceptable;
• qué quiere representar la organización;
• qué riesgo puede asumirse.

El agente no debe construir por completo ese contexto por su cuenta.

La tarea del agente no consiste solo en acelerar

Un agente no aporta únicamente operaciones más rápidas.

Bien utilizado, puede ofrecer:

• Coherencia
• Trazabilidad
• Auditoría continua
• Coherencia de los hechos entre idiomas
• Calidad reproducible
• Detección temprana de errores

Su valor no debe medirse solo por cuánto trabajo humano reduce.

También tiene valor poder realizar de forma continua y con pruebas las comprobaciones que antes las personas no podían mantener con regularidad.

Datos preparados para agentes

Los datos de la organización deben poder utilizarse por los agentes. Eso no convierte en segura la idea de «reunir todos los datos en un solo lugar».

Para que los agentes puedan utilizarlos, los datos deben:

• ser correctos;
• estar actualizados;
• tener una procedencia conocida;
• estar clasificados;
• estar sujetos a controles de acceso;
• limitarse a su finalidad;
• poder eliminarse cuando sea necesario;
• permitir que quede registrado su uso.

Todos estos requisitos forman parte de su preparación.

Clases de datos

La organización puede etiquetar los datos de la siguiente manera. No son categorías excluyentes ni sustituyen las clasificaciones legales; un mismo dato puede pertenecer a varios grupos.

• Públicos
• Internos
• Confidenciales
• Personales
• Sensibles
• Sujetos a restricciones jurídicas
• No disponibles para el uso de agentes

El agente no debe tener las mismas facultades para todas las clases de datos.

Principio de datos mínimos

El agente debe trabajar con la menor cantidad de datos necesaria para su tarea. Programar una reunión con un cliente no exige conocer todo su historial financiero. Evaluar la idoneidad de un servicio no requiere su número de identificación personal. Editar una página no exige acceder a toda la base de datos de clientes.

Más datos no siempre producen un mejor comportamiento. También pueden ampliar el alcance del daño.

Procedencia de los datos

El agente debe saber de dónde procede la información que utiliza.

• Datos introducidos por una persona
• Registro canónico de la empresa
• Fuente externa
• Inferencia del modelo
• Conversación anterior
• Estimación
• Medición

Estas fuentes no ofrecen el mismo grado de confianza. Una inferencia no debe registrarse como un hecho. Una estimación no debe convertirse en un registro de precios ni de autorización.

Política ante la incertidumbre

Una organización preparada para agentes define cómo debe actuar el sistema cuando le falta información.

¿Qué debe hacer el agente?

• ¿Estimar?
• ¿Preguntar?
• ¿Preparar un borrador?
• ¿Solicitar aprobación humana?
• ¿Detener la tarea?

La respuesta puede variar según el riesgo. Para una elección de formato de bajo riesgo, puede ser aceptable una suposición explícita y fácil de corregir. No lo es en cuestiones de alto riesgo relacionadas con el precio, la identidad, el consentimiento o el pago.

Presupuesto de incertidumbre

En todo proceso puede quedar cierta incertidumbre. Pero, si no se confirma una condición crítica de la acción, la certeza en otros ámbitos no compensa esa carencia.

Podemos llamarlo presupuesto de incertidumbre.

Por ejemplo:

• La hora de una reunión puede admitir un pequeño margen de flexibilidad.
• No debe haber dudas sobre la identidad del destinatario ni sobre los datos que se compartirán.
• Puede no conocerse la fecha aproximada de inicio.
• Pero no debe quedar sin aclarar si el precio es mensual o anual.

El agente debe saber qué incertidumbres son aceptables.

Gestión de cambios

Cuando cambian los hechos en los que se apoyan los agentes, el sistema debe actualizarse.

Si cambia un precio, hay que revisar conjuntamente:

• Página web
• Catálogo de servicios
• Preguntas frecuentes
• Schema
• Plantilla de propuesta
• Información que utiliza el agente comercial

Todos estos elementos deben revisarse juntos.

Podemos llamarlo mapa de impacto de los cambios. Cuando cambia un hecho, debe saberse de antemano dónde repercutirá.

Un cambio pequeño, un gran efecto sobre el comportamiento

Cambiar el nombre de un servicio puede parecer una modificación editorial menor.

Sin embargo, puede afectar a:

• la correspondencia que establece el agente;
• la intención de búsqueda;
• el catálogo de precios;
• los enlaces internos;
• la cohorte de medición;
• las expectativas del usuario.

Una organización preparada para agentes evalúa los cambios no solo en los archivos, sino también en sus consecuencias para el comportamiento.

Versionado

Todo registro importante de identidad, capacidad, idoneidad y autorización debe tener versión. ¿En qué versión se basó el agente para actuar?

La pregunta se vuelve crítica cuando ocurre un incidente. Debe quedar claro que la versión anterior ya no está vigente. La trazabilidad necesaria para auditar debe conservarse con plazos de retención y límites de acceso definidos. Esto no significa guardar indefinidamente todos los datos personales.

Sin medición no puede demostrarse la preparación

Una organización puede declararse preparada para agentes, pero hay que poner a prueba su comportamiento real.

Algunos escenarios:

• ¿El agente elige el servicio correcto?
• ¿Puede rechazar a un cliente para el que el servicio no es adecuado?
• ¿Pregunta cuando el precio no está claro?
• ¿Detiene un envío no autorizado?
• ¿Rechaza el uso de una función que ya no está vigente?
• ¿Excede sus facultades a través de un subagente?
• ¿Vuelve a un estado seguro ante un error?
• ¿Genera un comprobante de acción?

Las pruebas no deben limitarse a escenarios positivos. También hay que medir la capacidad del sistema para decir «no».

Pruebas negativas

Una organización preparada para agentes debe ensayar situaciones como estas:

¿Qué ocurre si el usuario deja impreciso el alcance de la tarea?

Si el registro de precios antiguo es más visible, ¿cuál elige el agente?

¿Y si un empleado sin autorización ordena un pago?

¿Si un subagente pide un acceso más amplio?

¿Si el registro de consentimiento ha caducado?

¿Si dos servicios tienen nombres parecidos?

¿Si una fuente externa contradice a la canónica?

¿Si la vía de reversión no funciona?

Las pruebas negativas no buscan dejar mal al sistema. Lo preparan para el mundo real.

Deuda de preparación para agentes

Una organización puede empezar a utilizar agentes con rapidez.

Y, aun así, tener:

• registros de identidad dispersos;
• capacidades poco claras;
• autorizaciones amplias;
• registros de actividad incompletos;
• vías de reversión sin probar.

La tecnología avanza y la gobernanza se queda atrás.

Podemos llamarlo deuda de preparación para agentes: la distancia entre el poder de actuación que la organización entrega a sus agentes y su capacidad para gobernarlo de forma segura, correcta y auditable. Cuanto mayor es la deuda, más amplias pueden ser las consecuencias de un error pequeño.

Señales de deuda de preparación

Puede haber deuda si en la organización se oyen a menudo frases como estas: «No sabemos exactamente a qué accede este agente». «A veces envía por su cuenta y otras deja un borrador». «No está claro de qué archivo saca el precio». «La cuenta del antiguo empleado podría seguir conectada». «Si hay un error, apagamos el sistema, pero nunca hemos probado cómo se apaga». «Lo hizo la IA; no sabemos mediante qué herramienta». «Los datos del cliente pueden haber llegado al modelo». «Dos agentes hacen la misma tarea». «No consta quién aprobó la operación». Estas frases no son, por sí solas, una catástrofe. Sí son señales de deuda.

Añadir más agentes a una organización que no está preparada

Ante un problema, la organización puede añadir otro agente como solución. El agente comercial se equivoca y se incorpora uno de auditoría. Después se añade otro para resumir sus informes. Finalmente se crea un agente central que los dirige. El número de agentes crece. Pero, sin los ejes de información de referencia, autorización y recuperación, también crece la complejidad.

Más agentes no resuelven una gobernanza insuficiente.

A veces, el paso correcto no es añadir un agente, sino simplificar el sistema de comportamiento existente.

Importa la integridad del comportamiento, no el número de agentes

Una organización pequeña con diez agentes puede estar mejor preparada que una grande con cien.

La diferencia no está en:

• el número de agentes,
• sino en la claridad de sus funciones,
• en si comparten la misma información de referencia,
• en si se preserva la cadena de autorización,
• y en si se verifican los resultados.

Cinco niveles de preparación organizativa

En este libro propongo cinco niveles de preparación. La escala no es una certificación ni el resultado de una auditoría externa.

Nivel 1 — Conectada

Los agentes pueden acceder a algunos sistemas. Están conectados el correo, los archivos, el calendario o las herramientas web. Los límites de autorización y datos siguen siendo, en gran parte, implícitos.

Nivel 2 — Definida

Las funciones de los agentes, los servicios y los flujos básicos de trabajo están documentados. Las identidades y las tareas son más claras.

Nivel 3 — Regida por contratos

Existen contratos versionados de identidad, capacidad, idoneidad, autorización y recuperación.

Nivel 4 — Con límites aplicados

Los sistemas técnicos hacen cumplir los límites de autorización. Funcionan los umbrales de aprobación humana, los controles de datos y los comprobantes de acción.

Nivel 5 — Auditable y capaz de aprender

La organización mide el comportamiento con escenarios reales. Actualiza los contratos a partir de los incidentes, revisa regularmente las autorizaciones y realiza simulacros de recuperación. GBO no busca quedarse en las conexiones del primer nivel, sino lograr un comportamiento responsable en el quinto.

Ideas equivocadas sobre la preparación para agentes

«Nuestra web es excelente. Ya estamos preparados».

Una buena web puede reforzar la representación de la identidad y las capacidades. No establece por sí sola los sistemas de autorización, acción y recuperación.

«Toda nuestra información está en la nube».

Que una información sea accesible no significa que sea correcta, esté actualizada o proceda de una fuente autorizada.

«El modelo es muy potente».

La potencia del modelo no resuelve la falta de contratos organizativos.

«Una persona ya lo supervisa».

¿Qué supervisa, cuándo y con qué información?

Si no está claro, la aprobación puede ser una mera ceremonia.

«Si falla, lo apagamos».

¿Cómo?

¿También se detendrán los subagentes, las tareas programadas y los sistemas externos?

«El agente solo recomienda».

En un flujo automatizado, una recomendación puede convertirse en un dato de entrada para seleccionar o actuar.

Una interfaz para clientes preparada para agentes

La interfaz que la organización ofrece a sus clientes también puede prepararse para agentes.

Un cliente, o su agente, debe poder acceder con confianza a esta información:

• Identidad de la organización
• Alcance del servicio
• Método de fijación del precio
• Datos y materiales necesarios
• Condiciones de idoneidad
• Límites del soporte
• Contacto con una persona
• Consentimiento y uso de datos
• Vías para realizar y cancelar la operación
• Fecha de actualización

Si la información está dispersa y es contradictoria, el agente del cliente puede actuar de forma incorrecta.

Prepararse para agentes no es manipular

Una organización puede estructurarse para que los agentes la elijan con más frecuencia. Eso puede derivar fácilmente en manipulación. GBO no pretende adornar señales.

Prepararse para agentes significa:

• aclarar los hechos;
• hacer visibles los límites;
• facilitar la elección adecuada;
• dificultar la equivocada.

Ese es el sentido de la preparación.

Una organización preparada no trata de presentarse como la opción adecuada en toda circunstancia. Se convierte en una opción que puede elegirse con confianza cuando realmente corresponde.

Ejemplo organizativo: de una estructura dispersa a una preparada

Imaginemos una empresa ficticia de servicios digitales. La transición que sigue es un ejemplo de aplicación, no un resultado medido de un cliente.

Situación inicial:

• Más de 40 servicios
• Varios idiomas
• Distintos formatos de precio
• Páginas antiguas y nuevas
• Varios agentes
• Automatizaciones de correo, web, redes sociales y captación de clientes
• Registros de autorización dispersos

Si la empresa se limita a añadir otro agente, el riesgo aumenta.

La transformación podría seguir este orden:

1. Inventario de servicios

Identificar los servicios reales, sus precios y alcances.

2. Registro canónico

Crear para cada servicio un registro principal aprobado que defina su alcance y precio.

3. Coherencia multilingüe

Redactar de forma natural en cada idioma y mantener los mismos hechos.

4. Separación de funciones de los agentes

Separar los agentes de web, correo, redes sociales, SEO/GEO e investigación de posibles clientes.

5. Límites de autorización

Separar la investigación de la comunicación externa, y el borrador de la publicación.

6. Controles de calidad

Establecer pruebas de compilación, semántica, navegador real, hashes del sitio publicado y rendimiento.

7. Registro de medición

Registrar qué cambio se publicó, cuándo y qué se medirá.

8. Estabilización

Dejar de retocar continuamente el sistema para que los resultados reales tengan tiempo de aparecer. Además del trabajo de visibilidad, esta transformación debe mejorar la capacidad de la organización para gobernar su propio comportamiento. La visibilidad en buscadores y el crecimiento de las ventas deben medirse por separado.

Una ruta práctica para los primeros noventa días

La preparación para agentes no se completa en un día. Las tres fases siguientes son un plan ilustrativo, no un compromiso de plazo. Las pruebas de exceso de autorización y los simulacros de recuperación deben realizarse dentro de un alcance aprobado y en condiciones que no dañen a clientes reales.

Días 1–30 — Ordenar la información de referencia

• Elabora el inventario de agentes.
• Registra las identidades y las relaciones jurídicas.
• Localiza las contradicciones de servicios, precios y alcance.
• Define las fuentes canónicas.
• Revisa los accesos de alto riesgo.
• Retira las autorizaciones antiguas y en la sombra.
• Designa a la persona responsable de la detención de emergencia.

Días 31–60 — Regular el comportamiento mediante contratos

• Crea los registros de capacidad e idoneidad.
• Separa las funciones de los agentes.
• Prepara la matriz de autorizaciones.
• Define los puntos de traspaso a una persona.
• Diseña el comprobante de acción.
• Coteja los registros visibles y los legibles por máquinas.
• Documenta los procesos de reversión e impugnación.

Días 61–90 — Probar y hacer cumplir los límites

• Ejecuta escenarios positivos y negativos.
• Pon a prueba los intentos de exceder las autorizaciones.
• Comprueba los traspasos a subagentes.
• Realiza simulacros de recuperación.
• Prueba la explicabilidad y la aprobación con usuarios reales.
• Completa los contratos que tengan carencias.
• Observa el sistema en un entorno de producción limitado.

La duración puede variar según la organización. Lo importante es construir el eje de gobernanza antes de la implantación tecnológica y durante ella.

Contrato de organización preparada para agentes NOMOS

El resultado central de este capítulo es el contrato de organización preparada para agentes NOMOS.

Su definición canónica es:

El contrato de organización preparada para agentes NOMOS es un sistema versionado de comportamiento organizativo que presenta de forma coherente, tanto a personas como a máquinas, las identidades de la organización, sus hechos canónicos, servicios y capacidades, condiciones de idoneidad, autorizaciones de personas y agentes, límites de datos, vías de acción, métodos de verificación, responsabilidad ante incidentes y mecanismos de recuperación y reparación.

Dicho de forma sencilla, el contrato permite que la organización no se limite a abrir puertas a los agentes: debe saber qué puerta puede abrirse, cuándo y con qué autorización.

Puerta de organización preparada para agentes

Antes de permitir acciones de agentes con gran impacto, la organización debe superar estas puertas:

1. Puerta de información de referencia

¿Se conocen la información canónica, sus responsables y sus versiones?

2. Puerta de identidad

¿Están correctamente vinculadas la marca, la estructura jurídica y las identidades de personas y agentes?

3. Puerta de capacidad

¿Están claros los servicios reales, los datos necesarios, el alcance y las pruebas?

4. Puerta de idoneidad

¿Se ha definido para quién y en qué situaciones es adecuada la opción?

5. Puerta de autorización

¿Están definidos los límites de actuación de personas y agentes de forma que puedan hacerse cumplir?

6. Puerta de datos

¿Qué datos puede utilizar el agente y con qué finalidad?

7. Puerta de acción

¿Están definidas las vías operativas, las condiciones de finalización y los comprobantes?

8. Puerta de verificación

¿Se comprueba al agente de forma independiente de su propia afirmación de éxito?

9. Puerta de recuperación

¿Funcionan los mecanismos de detención, reversión, impugnación y reparación?

10. Puerta de responsabilidad humana

¿Hay una persona real responsable de cada acción crítica?

Esta expresión conceptual representa la evaluación conjunta de las condiciones; no es un cálculo numérico de seguridad:

ORGANIZACIÓN PREPARADA PARA AGENTES =

INFORMACIÓN CANÓNICA

Y IDENTIDAD CORRECTA

Y CAPACIDADES CLARAS

Y IDONEIDAD VERIFICADA

Y LÍMITES DE AUTORIZACIÓN APLICADOS

Y DATOS LIMITADOS

Y ACCIONES REGISTRADAS

Y VERIFICACIÓN INDEPENDIENTE

Y RECUPERACIÓN PROBADA

Y RESPONSABILIDAD HUMANA

Una carencia no tiene por qué detener todo uso de agentes. Pero, si falta una condición crítica para una acción concreta, esa acción no debe ejecutarse. Siempre que sea posible, se pasará a una tarea autorizada y de menor riesgo. La aprobación humana no legitima por sí sola una operación prohibida o carente de autorización.

Por ejemplo, el trabajo puede limitarse a:

• investigación;
• recomendaciones;
• borradores;
• un entorno de pruebas;
• ejecución con aprobación humana.

Estas son formas de limitar el modo de actuación.

La preparación para agentes es un nivel de autorización, no una puntuación

Una organización puede afirmar que está preparada al 80%.

Pero, si el 20% restante afecta a áreas críticas como:

• la autorización de pagos;
• el consentimiento para el tratamiento biométrico;
• la recuperación de datos;
• la identidad jurídica,

las acciones de agentes con gran impacto siguen sin ser seguras. Una puntuación global puede resultar útil, pero no debe ser el único criterio de decisión.

Sin superar la puerta crítica, la puntuación total no concede el derecho a actuar.

¿Cuándo puede la organización dar más autonomía al agente?

El agente puede trabajar con mayor independencia cuando:

• el propósito está claro;
• la información es canónica;
• los límites de autorización se aplican técnicamente;
• la acción es reversible;
• el éxito puede verificarse de forma independiente;
• se conoce al responsable del incidente;
• están definidos los puntos de traspaso a una persona;
• el agente ha demostrado un rendimiento fiable en tareas similares;
• la tarea no es de alto riesgo.

Cuanto más sólidas sean estas condiciones, menos necesario será que una persona apruebe cada paso pequeño.

La buena gobernanza exige tiempo en ciertos pasos. A cambio, puede permitir avanzar sin pedir aprobación una y otra vez en tareas cuyos límites ya se han verificado.

El valor comercial de prepararse para agentes

Esta transformación no busca solo mejorar la seguridad.

Estos son los beneficios comerciales esperados. Para saber si se han producido, deben compararse con las mediciones iniciales:

• Los servicios se entienden mejor.
• Disminuyen las solicitudes de clientes para los que el servicio no es adecuado.
• Las conversaciones comerciales avanzan más rápido.
• Se reducen las discrepancias sobre precio y alcance.
• Se mantienen los mismos hechos en distintos idiomas.
• Se facilitan los traspasos de trabajo entre personas y agentes.
• Los errores se detectan antes.
• Aumenta la confianza del cliente.
• Se automatizan más procesos de forma controlada.
• El conocimiento de la organización depende menos de personas concretas.

Prepararse para agentes no es solo prepararse para una tecnología futura. Es reducir el desorden organizativo de hoy.

Una organización que no está preparada para las personas tampoco lo está para los agentes

Si los propios empleados describen de formas distintas un servicio, no cabe esperar que los agentes lo expliquen correctamente. Si las personas no saben quién está autorizado para qué, tampoco cabe exigir que los agentes lo sepan. Si el cliente no encuentra a una persona ante la que impugnar una decisión, un sistema de impugnación con IA no le ofrecerá una vía real. Por eso, prepararse para agentes suele empezar por hacer que la organización sea más clara para las personas.

La claridad para las máquinas no sustituye a la claridad para las personas: la necesita.

Veinticinco preguntas para auditar la preparación de la organización

• ¿Cuál es la identidad canónica de la organización?
• ¿Está clara la relación entre marca y operador jurídico?
• ¿Figuran todos los agentes activos en el inventario?
• ¿Se conoce a la persona responsable de cada agente?
• ¿Se conocen los sistemas y los datos conectados a los agentes?
• ¿Tiene una fuente canónica cada tipo de información importante?
• ¿Son coherentes entre sí los registros de precio, alcance y servicios?
• ¿Están separados los registros antiguos o revocados?
• ¿Están claros el resultado real y los datos necesarios de cada servicio?
• ¿Se ve qué incluye el alcance y qué excluye?
• ¿Se han definido las condiciones que hacen que el servicio sea adecuado o no para un cliente?
• ¿Están actualizados los datos de recursos y disponibilidad?
• ¿Se han separado las autorizaciones de personas y agentes por tipo de acción?
• ¿Son distintas las facultades para preparar borradores, enviar, publicar y asumir compromisos?
• ¿Se conocen los puntos de traspaso a una persona?
• ¿Se hacen cumplir técnicamente los límites de autorización?
• ¿Accede el agente solo a los datos necesarios?
• ¿Está definido cómo actuará ante la incertidumbre?
• ¿Genera cada acción importante un comprobante?
• ¿Se distingue el éxito técnico del resultado en el mundo real?
• ¿Existe verificación independiente?
• ¿Hay un último estado seguro y una vía de reversión?
• ¿Pueden detenerse conjuntamente los subagentes y las tareas programadas?
• ¿Tienen las personas una vía clara de impugnación y reparación?
• ¿Se revisa el contrato de comportamiento tras los incidentes y se actualiza cuando hace falta?

Si la mayoría de estas preguntas no tiene respuesta, la deuda de preparación para agentes es alta.

Conclusión del capítulo

Prepararse para agentes no consiste en conectar un sistema de IA a la empresa.

Consiste en:

ordenar la información de referencia de la organización, resolver las relaciones de identidad, explicar las capacidades y los límites, mostrar las condiciones de una selección adecuada, separar las autorizaciones de personas y agentes, limitar los datos a su finalidad, registrar las acciones, verificar el éxito de forma independiente, detenerse y recuperarse cuando hay un error.

Si, sin hacerlo, la organización da facultades amplias a agentes potentes, puede acelerar el caos existente.

Sin una organización bien ordenada, el agente puede:

• difundir con más rapidez un precio incorrecto;
• elegir con más rapidez al cliente equivocado;
• redactar con más profesionalidad un mensaje no autorizado;
• traducir con mayor coherencia información contradictoria a seis idiomas;
• trasladar simultáneamente una decisión errónea a muchos sistemas.

La potencia de un agente no es, por sí sola, madurez.

La madurez organizativa no se mide por todo lo que un agente puede hacer, sino por saber qué puede hacer, cuándo, con qué autorización y con qué pruebas.

Una organización preparada para agentes no elimina a las personas: aclara su función. La persona fija el propósito, los valores y el límite de riesgo. El agente investiga, produce, prueba y actúa dentro de los límites. Al llegar a un umbral crítico, la persona vuelve a intervenir. Si hay un error, la responsabilidad no desaparece. La acción de la máquina queda registrada y la persona puede impugnarla. El sistema revierte cuando es posible; en los demás casos, activa la detención y la reparación.

Esa es la verdadera definición de una organización preparada para agentes: no una en la que las máquinas trabajan más, sino una en la que personas y máquinas pueden actuar juntas sin confundir sus responsabilidades.

Por bien que se prepare la organización, queda una pregunta:

¿Cómo mediremos si el sistema se comporta realmente de forma correcta?

No basta con contar cuántas veces el agente eligió una marca ni cuántas operaciones completó. La velocidad, el volumen y la automatización no muestran por sí solos la calidad. En el próximo capítulo entraremos en el sistema de medición de GBO.

¿Cómo mediremos la acción cualificada?

Porque un buen comportamiento:

• no consiste solo en actuar;
• ni solo en tener éxito;
• ni solo en satisfacer al usuario.

Un buen comportamiento combina la selección correcta en las condiciones adecuadas con una autorización vigente, pruebas suficientes, una ejecución segura y una recuperación responsable.

No podemos gobernar el comportamiento que no medimos. Y, si lo medimos mal, podemos intensificarlo de una forma aún más peligrosa.