¿Quién eres?

Imaginemos un caso completamente ficticio. Una empresa quiere pedir presupuestos a tres proveedores de software para su nuevo portal de clientes. El nombre «Nova Digital» se utiliza aquí sin hacer ninguna afirmación sobre una empresa real.

La persona responsable da una instrucción breve al agente de IA: «Busca Nova Digital y pídeles un presupuesto para nuestro portal en seis idiomas». El agente inicia la búsqueda.

El nombre «Nova Digital» devuelve varios resultados:

• una empresa de software que opera en Estambul,
• una agencia de marketing digital registrada en Londres,
• un diseñador independiente que utiliza el mismo nombre,
• un dominio antiguo que ya no se usa,
• una cuenta de redes sociales gestionada por otra empresa,
• un perfil comercial en un directorio que lleva años sin actualizarse.

El agente elige el dominio que parece más sólido. Cree haber reunido información suficiente sobre la empresa. Prepara una solicitud detallada que incluye el presupuesto del proyecto, el nombre del CRM actual, el número de empleados y la fecha de entrega prevista. Envía el mensaje. Dos días después llega la respuesta. La otra parte muestra interés, propone una reunión y facilita los datos bancarios para un anticipo. Todo parece normal. Pero el mensaje se ha enviado a la Nova Digital equivocada. Se buscaba al proveedor de portales de clientes de Estambul. El agente ha contactado con la agencia de publicidad de Londres. No toda la información que encontró es inventada. El dominio existe.

La empresa existe. La dirección de contacto funciona. Ha respondido un empleado real. Sin embargo, se han reunido datos correctos en torno a la identidad equivocada. No es solo un error de búsqueda: es un error de resolución de identidad. El agente ha encontrado una entidad, pero no ha determinado correctamente con quién trata. Y una máquina que no sabe con quién trata no puede actuar con seguridad, por mucho que investigue, por muy exactas que sean sus frases y por muy potentes que sean las herramientas a las que accede.

Por eso el contrato de comportamiento del GBO comienza con una pregunta:

¿Quién eres?

Un nombre no es una identidad

En la vida cotidiana usamos los nombres en lugar de las identidades. «Llama a Ahmet». «Reserva en el Hotel Atlas». «Consulta el comunicado del Banco Central». «Envía un presupuesto a Nova Digital». El contexto suele ayudarnos a saber de qué persona u organización se habla. Aunque varias personas tengan el mismo nombre, la agenda, las conversaciones anteriores, los conocidos en común y nuestra ubicación nos permiten escoger a la correcta. Las máquinas no siempre disponen de ese contexto.

Pueden compartir nombre:

• distintas empresas,
• distintas personas,
• distintas marcas,
• distintas sucursales,
• distintos productos,
• distintas cuentas de redes sociales
• y organizaciones antiguas y nuevas.

También puede ocurrir lo contrario: una misma entidad aparece con nombres diferentes según el lugar.

En una empresa pueden diferir:

• la razón social,
• la marca comercial,
• el dominio,
• el nombre de usuario en redes sociales,
• el nombre del producto,
• el nombre en la lengua local
• y el nombre utilizado en el mercado internacional.

La identidad, por tanto, no se reduce al nombre. Es la estructura que explica qué entidad hay detrás de él y cómo se relaciona con otras personas, organizaciones, dominios, autorizaciones y momentos. En este libro estudiamos la identidad a través de sus vínculos con la entidad, las relaciones, los roles, la autorización, el tiempo y las pruebas. No es una fórmula de puntuación, sino un marco de análisis. Conocer uno solo de estos elementos no basta. Saber cómo se llama alguien no demuestra que pueda firmar en nombre de una empresa. Saber que un dominio pertenece a la empresa no demuestra que todas sus páginas estén actualizadas.

Confirmar que una persona trabaja realmente en una organización no demuestra que pueda comunicar precios o aceptar contratos. Saber que un agente de IA está operado por la empresa no significa que pueda realizar cualquier operación en su nombre. La identidad no es una etiqueta: es una cadena de responsabilidad.

Las capas de la identidad

En el mundo digital, una organización o una persona no tiene una identidad de una sola capa. Existen varias capas conectadas. Confundirlas puede orientar el comportamiento de los agentes en la dirección equivocada.

Identidad personal

Corresponde a la persona real: su nombre y apellidos, sus vías de contacto, sus roles y su derecho a realizar determinadas operaciones. Pero verificar quién es no demuestra que tenga las mismas facultades en todos los contextos. Ser empleado de una empresa no autoriza automáticamente a firmar contratos en su nombre. Ser autor de un libro no convierte a nadie en propietario de la plataforma que lo publica. Ser fundador de una marca no impide que las operaciones jurídicas se realicen a través de otra sociedad. La identidad personal importa.

Para orientar una acción, sin embargo, debe interpretarse junto con el rol y la autorización.

Identidad jurídica

La identidad jurídica indica a qué persona o estructura legal corresponden un contrato, una factura, un pago o una responsabilidad formal. Una marca puede carecer de personalidad jurídica propia. Un dominio puede pertenecer a otra empresa. Un proyecto puede promocionarse bajo una marca comercial y facturarse con una razón social diferente. Eso no constituye por sí solo un problema. El problema es que no se explique la relación. Al ver una marca, el agente puede suponer que el contrato también se celebrará con ese nombre. Si el pago se dirige a otra estructura jurídica, puede interpretarlo como un indicio de fraude.

O, a la inversa, puede pagar a la entidad jurídica equivocada porque solo conoce el nombre de la marca.

Desde la perspectiva del GBO, estas relaciones deben quedar claras:

¿Quién opera la marca? ¿Quién celebra el contrato? ¿Quién emite la factura? ¿Quién recibe el pago? ¿Quién responde en caso de controversia?

Identidad de marca

La marca es la cara que personas y máquinas reconocen habitualmente. La forman el nombre, el logotipo, el dominio, el lenguaje del servicio, los trabajos publicados y el posicionamiento en el mercado. Pero identidad de marca e identidad jurídica no son equivalentes. La marca articula la comunicación y la relación; la identidad jurídica, las responsabilidades y los compromisos. El agente debe poder vincular ambas sin tratarlas como intercambiables.

Identidad operativa

Explica cómo funciona realmente una organización. ¿Qué equipo hace cada trabajo?

¿Qué departamento comunica los precios?

¿Quién autoriza la publicación en producción?

¿Quién puede acceder a los datos de los clientes?

¿Quién solo puede preparar borradores?

¿Quién puede efectuar pagos?

¿Quién puede enviar mensajes al exterior?

Que alguien figure como «directivo» en el organigrama no significa que esté autorizado para todas las acciones operativas. Del mismo modo, un empleado con un cargo aparentemente inferior puede tener amplios permisos técnicos en un sistema concreto. La identidad operativa explica cómo se distribuyen las facultades en el trabajo diario.

Identidad digital

Los dominios, las direcciones de correo, las cuentas de redes sociales, los perfiles de plataformas, las firmas digitales, los clientes de API y los registros legibles por máquinas forman parte de la identidad digital. Que un correo utilice el dominio de la empresa puede inspirar confianza, pero la cuenta podría estar comprometida. Una cuenta social puede aparecer como verificada y seguir en manos de un antiguo empleado. Un sitio puede ser oficial y contener páginas que llevan años sin actualizarse. La identidad digital no es por sí sola el punto final de la confianza. Debe corresponderse con las demás capas de identidad.

Identidad del agente

Esta es una capa nueva y cada vez más importante.

La identidad de un agente de IA debe explicar:

• en nombre de quién trabaja,
• con qué finalidad fue creado,
• a qué sistemas puede acceder,
• qué operaciones puede realizar,
• qué operaciones no puede realizar
• y cuándo debe solicitar la aprobación de una persona.

No bastan denominaciones genéricas como «asistente de investigación», «agente de atención al cliente» o «agente de compras». Su identidad debe definirse junto con su perímetro de acción, porque quizá ya no se limita a responder: puede dejar huella en el mundo exterior en nombre de la organización.

El triángulo de identidad

Podemos analizar la acción de un agente a través de tres roles de identidad. Una misma entidad puede asumir varios roles, y en cada uno puede haber varios actores:

1. Quien solicita

La persona u organización que pide que se realice la acción.

2. Quien ejecuta

El agente o la red de agentes que lleva a cabo la tarea.

3. La contraparte

La persona, empresa, sistema o entidad a la que se dirige la acción.

Podemos llamar a esta estructura triángulo de identidad.

Cuando se envía un correo:

• ¿Quién lo ha solicitado?
• ¿Qué agente envía el mensaje?
• ¿Qué persona u organización lo recibe?

Cuando se realiza una compra:

• ¿Quién utiliza el presupuesto?
• ¿Qué agente ejecuta la operación?
• ¿Qué entidad jurídica vende el producto?

Cuando se publica contenido en redes sociales:

• ¿Quién toma la decisión de comunicación?
• ¿Qué sistema crea y publica el contenido?
• ¿En qué cuenta se publica, en nombre de quién y para qué público?

Cuando se actualiza un sitio web:

• ¿Quién define el objetivo del cambio?
• ¿Qué agente modifica el archivo?
• ¿Qué sitio se modifica, quién lo opera y a quiénes afecta el cambio?

Si una esquina del triángulo queda sin aclarar, el comportamiento entra en riesgo. Si no se ha verificado a quien solicita, el agente puede recibir órdenes de la persona equivocada. Si la identidad y las facultades del agente son inciertas, el usuario no sabe qué sistema actúa. Si la contraparte está mal identificada, la operación correcta puede aplicarse a la persona equivocada.

Antes de cada acción importante deben plantearse tres preguntas:

¿Quién lo pide? ¿Quién lo hace? ¿Sobre quién o frente a quién se actúa?

Ser auténtico no equivale a estar autorizado

Un error frecuente consiste en dar por suficiente la prueba de que una persona o una cuenta son auténticas. Un empleado puede trabajar realmente en la empresa y no estar facultado para conceder descuentos. Un directivo puede ser quien dice ser y no tener autorización para ordenar un pago a una cuenta bancaria concreta. Un agente de IA puede estar operado por la empresa y carecer de permiso para transferir datos de clientes a otro sistema. Una cuenta social puede pertenecer a la marca sin que cada mensaje publicado en ella sea una declaración autorizada para generar compromisos jurídicos.

Hay, por tanto, dos preguntas distintas:

¿Quién es realmente? ¿Está esta persona o este sistema autorizado para hacer esto?

La primera trata de verificar la identidad; la segunda, de la autorización. La verificación establece, con el grado de confianza necesario para la operación, que la persona o el sistema corresponden a la identidad que afirman tener. La autorización determina si esa identidad tiene permiso para realizar una acción concreta. Los sistemas de agentes no deben confundirlas.

Una persona real no siempre es una persona autorizada. Una cuenta oficial no es un canal autorizado para cualquier operación. Acceder a un sistema no autoriza a modificarlo.

La distinción resulta especialmente importante en pagos, contratos, declaraciones públicas, datos personales y compromisos de una organización.

El rol no es la persona

Los roles cambian. Quien hoy dirige una organización puede ocupar otro puesto mañana. Un responsable de proyecto puede dejar la empresa. Una dirección de correo puede asignarse a otro empleado. Una agencia diferente puede hacerse cargo de una cuenta social. Un responsable técnico puede tener permiso de publicación solo durante un proyecto. Por eso el rol debe interpretarse junto con su vigencia. «Esta persona es el CEO» es una afirmación incompleta.

Sería más preciso decir: «A esta fecha, esta persona es el CEO de esta organización y está autorizada para estas clases de operaciones». El rol no es una propiedad permanente adherida a alguien. Es una relación dentro de una organización, un período y un alcance determinados. Los agentes no deben deducir automáticamente la facultad de actuar a partir de un cargo. Un fundador puede no estar autorizado para efectuar pagos por la empresa. Un responsable financiero puede no estar autorizado para emitir declaraciones públicas en nombre de la marca.

Un responsable de redes sociales puede carecer de facultades para modificar condiciones contractuales. Que un desarrollador acceda al sistema en producción tampoco demuestra que pueda fijar la política de precios. El nombre del rol no define por sí solo los límites del comportamiento.

La autorización depende del contexto

La autorización no es una propiedad general e ilimitada.

Una persona o un agente pueden estar autorizados:

• en un sistema concreto,
• para una tarea determinada,
• durante un período definido,
• hasta cierto nivel de riesgo
• y por debajo de un importe establecido.

Un agente de compras puede adquirir material de oficina por un máximo de 100 dólares sin estar autorizado para contratar una suscripción anual. Un agente web puede modificar el entorno de pruebas y necesitar otra aprobación para pasar a producción. Un agente de correo puede redactar borradores sin tener permiso para enviarlos fuera de la empresa. Un sistema de avatares de IA puede narrar textos de formación ya aprobados y no estar autorizado para generar nuevas declaraciones políticas.

El registro de autorización debe responder, por tanto, a estas preguntas:

• ¿Qué acción?
• ¿Con qué propósito?
• ¿En qué sistema?
• ¿Durante cuánto tiempo?
• ¿Con qué datos?
• ¿Dirigida a qué persona u organización?
• ¿Con qué nivel de riesgo?
• ¿Por qué importe?
• ¿Con qué aprobación humana?
• ¿Con qué procedimiento de reversión?

Si falta una parte de la autorización, el agente no debe interpretarla de forma expansiva.

Una autorización ambigua no es una autorización amplia.

El mismo nombre, distintas entidades

La coincidencia de nombres es un problema de resolución de identidad que puede pasar inadvertido.

Pueden llamarse igual:

• empresas,
• hoteles,
• médicos,
• consultores,
• productos,
• paquetes de software
• y departamentos universitarios.

Si el agente se basa solo en el nombre, puede elegir la entidad equivocada.

Se necesitan otros elementos que permitan distinguirla:

• Dominio oficial
• País o ciudad
• Razón social
• Datos fiscales o del registro mercantil
• Sector
• Canal de comunicación autorizado
• Logotipo de la marca
• Vínculos de la organización
• Alcance del producto o servicio

Ante una petición como «Haz una reserva en Atlas»,

el agente quizá tenga que preguntar: «¿El Atlas de qué ciudad? ¿Se refiere a un hotel, un restaurante o una empresa de viajes?». Preguntar no es lentitud. Es más seguro que actuar deprisa sobre la entidad equivocada.

Distintos nombres, una misma entidad

También se cometen errores en sentido contrario. Una organización puede tener una razón social, una marca y un dominio diferentes. Una empresa puede haber adquirido otra marca. Un producto puede haber cambiado de nombre. Un autor puede utilizar un seudónimo. El nombre de una organización puede escribirse de formas diferentes según el alfabeto.

Por ejemplo, pueden parecer distintos:

• el nombre de una empresa en alfabeto latino,
• su escritura en árabe,
• su equivalente en cirílico,
• la denominación del registro mercantil local
• y su marca internacional.

Si el agente los trata como entidades separadas, la información se fragmenta. La buena reputación en un idioma no se conecta con la de otro. Los precios parecen pertenecer a empresas diferentes. Los trabajos publicados no se vinculan con la marca. Para el GBO, identificar correctamente no consiste solo en separar: también consiste en reunir lo que corresponde.

La máquina debe preguntar «¿Son entidades diferentes?»,

pero también «¿Son distintas caras de la misma entidad?».

El grafo de identidad

La identidad digital de una entidad rara vez cabe en un registro de una sola línea. Está formada por relaciones.

Por ejemplo:

• Una persona funda una marca.
• Una estructura jurídica opera la marca.
• Un dominio pertenece a la marca o se utiliza en su nombre.
• La marca controla una cuenta social.
• Determinados agentes están autorizados para tareas concretas.
• Una publicación se ha creado mediante el trabajo conjunto de ciertas personas y sistemas.
• La factura se emite con otra denominación jurídica.
• Un socio comercial tiene facultades de representación en determinados países.

Podemos entender estas relaciones como un grafo de identidad. No importan solo los nodos, sino los vínculos que los unen. Decir «Esta persona está relacionada con esta empresa» no basta.

Hay que precisar la relación:

• Fundador
• Propietario
• Empleado
• Representante autorizado
• Editor de contenido
• Operador técnico
• Proveedor de servicios
• Cliente
• Entidad editora
• Agente
• Subcontratista

Una relación mal descrita une entidades reales en un relato falso. Haber escrito un libro sobre una empresa no convierte al autor en su representante legal. Gestionar las redes sociales de una marca no convierte a la agencia en su propietaria. Alojar un sitio no demuestra que el proveedor de infraestructura haya verificado todas las afirmaciones publicadas en él. La responsabilidad jurídica de las partes debe evaluarse por separado, según la relación de servicio y las normas aplicables.

En el grafo de identidad, el GBO no pregunta solo «¿Quién está conectado con quién?», sino «¿Qué derechos y responsabilidades se derivan de este vínculo?».

El registro canónico de identidad

Una organización necesita una fuente versionada que describa todas sus relaciones de identidad.

Podemos llamarla registro canónico de identidad.

Como base, este registro puede incluir:

• Nombre de la marca principal
• Operador jurídico
• Dominios oficiales
• Nombres alternativos utilizados
• Canales sociales y digitales oficiales
• Direcciones de contacto autorizadas
• Relación entre la marca y la estructura jurídica
• Personas autorizadas y roles
• Nombres de los agentes y ámbitos de trabajo
• Operaciones para las que es válido cada canal
• Fecha de la última actualización
• Información de versión
• Registros revocados o antiguos

No es necesario que toda esta información sea pública. Algunos apartados pueden tener distintos niveles de acceso para clientes, socios o sistemas internos. Lo importante es disponer de una única fuente correcta.

Un registro canónico no significa que todos vean todo. Significa que la persona adecuada pueda verificar la identidad pertinente en el momento oportuno.

El contrato de identidad NOMOS

El primer componente de NOMOS Behavioral Contract Layer será el contrato de identidad NOMOS.

Su definición canónica es la siguiente:

El contrato de identidad NOMOS es un registro de identidad versionado que establece quién es una persona, organización, marca, producto o agente; con qué nombres se conoce; quién lo opera o representa; qué canales digitales están autorizados; durante cuánto tiempo y con qué alcance es válida la autorización; y cómo se actualizan o revocan estas relaciones.

Dicho de forma sencilla: el contrato de identidad no le dice a la máquina solo cómo te llamas, sino en qué condiciones puede relacionarse contigo de manera segura.

El contrato distingue cuatro elementos:

Afirmación

¿Qué dice una entidad sobre sí misma?

Prueba

¿Qué respalda esa identidad o relación?

Autorización

¿Qué acciones tiene permitido realizar esta persona o este sistema?

Vigencia

¿En qué fechas y condiciones es válida la información?

Una empresa puede indicar en su web: «Esta es nuestra cuenta oficial de soporte». Eso es una afirmación. El dominio, un registro de la organización o el vínculo con el panel de administración pueden respaldarla: son pruebas. La cuenta puede responder consultas de soporte, pero no modificar contratos: ese es el límite de autorización. El permiso puede durar lo que dure un contrato concreto con el proveedor de servicios: ese es el límite de vigencia.

Cuatro niveles de verificación de identidad

No toda la información de identidad ofrece el mismo grado de confianza. En este libro utilizamos cuatro estados para establecer una distinción práctica. No son los niveles de un estándar oficial de garantía de identidad, sino un modelo que describe el avance desde la identidad hasta la autorización para actuar.

1. Declarada

La persona u organización declara su identidad: «Soy el responsable de ventas de la empresa». Puede ser cierto, pero aún no se ha aportado respaldo.

2. Vinculada

La identidad se ha asociado con una presencia digital que parece oficial. Un correo con el dominio de la empresa, un perfil oficial o una página canónica pueden mostrar esa relación. Sin embargo, la cuenta podría estar comprometida o la información, desactualizada.

3. Verificada

Una o varias pruebas han confirmado la identidad con suficiente confianza para la operación. El método depende del riesgo de la acción. Suscribirse a un boletín y realizar un pago de gran importe no requieren el mismo nivel de verificación.

4. Autorizada

No solo se ha verificado la identidad: también se ha demostrado que dispone de una autorización vigente para la acción concreta. Este último nivel es el decisivo para el GBO. Probar que una persona es auténtica no basta si no se demuestra que puede realizar la operación.

La confianza en la identidad depende del riesgo de la acción

Imponer la misma carga de verificación a cualquier comportamiento puede ser innecesario y perjudicial para la privacidad. Nadie necesita facilitar su pasaporte para consultar un catálogo general de productos. Pero una coincidencia de nombres no basta para una transferencia bancaria de gran importe. El control de identidad debe ser proporcional al impacto de la acción.

En acciones de bajo riesgo pueden bastar:

• un correo verificado,
• una sesión iniciada
• o una relación sencilla con una cuenta.

Ese nivel puede ser suficiente.

En acciones de alto riesgo pueden necesitarse:

• varias comprobaciones,
• la verificación de la entidad jurídica,
• la confirmación de la persona autorizada,
• una aprobación específica para la operación
• o una verificación por un canal independiente.

El riesgo puede exigir estas medidas adicionales.

El principio es este: la verificación de identidad no debe ser la más intensa posible, sino la más adecuada para lo que se necesita. El exceso también puede causar daño. Recopilar documentos personales sin necesidad aumenta el riesgo para la privacidad. El GBO no interpreta la seguridad como una licencia para recoger datos sin límite.

Verificar una identidad no significa exponer toda la vida de una persona.

La identidad mínima necesaria

Un agente debe verificar solo los atributos de identidad que requiere su tarea. Para comprobar que alguien pertenece a un intervalo de edad adecuado quizá no haga falta su fecha de nacimiento completa. Si puede demostrarse que un empleado tiene permiso para abrir una solicitud de soporte por la empresa, quizá no sean necesarios su domicilio particular ni su número de identificación. Si se verifica que una sociedad existe legalmente y utiliza cierta cuenta de pago, quizá no tenga que compartir todos sus documentos societarios internos.

Podemos llamar a este enfoque identidad mínima necesaria.

El principio es sencillo: utilizar tanta información de identidad como exija el comportamiento correcto, y no más. Así, el GBO protege a la vez la seguridad y la privacidad.

El tiempo forma parte de la identidad

Un registro de identidad puede ser correcto hoy y dejar de serlo mañana. Un empleado se marcha, cambia un directivo, se vende una marca, se transfiere un dominio a otra estructura, termina un contrato de representación, se revoca la clave de acceso de un agente o alguien retira el permiso para usar su rostro o su voz. La información antigua puede seguir en internet. El agente no debe preguntar solo «¿Esta relación fue válida en algún momento?».

«¿Sigue siendo válida ahora?»

También debe plantear esa pregunta.

Por ello, los registros de identidad deben incluir:

• fecha de inicio,
• fecha de finalización,
• fecha de la última verificación,
• información sobre revocaciones
• y versión vigente.

Una identidad sin información temporal puede dar lugar a autorizaciones mal atribuidas en el futuro.

El desfase de identidad

Podemos llamar desfase de identidad a la distancia que se abre cuando una organización cambia y sus registros digitales no se actualizan al mismo ritmo. La empresa se orienta a otro ámbito, pero sus perfiles siguen mostrando los servicios antiguos. Cambia el equipo directivo, pero no se actualizan las biografías. La marca opera bajo otra estructura jurídica, pero los datos de facturación siguen siendo los anteriores. Otra unidad asume una cuenta social, pero el registro de autorización permanece igual. Se deja de usar un agente, pero su clave de API continúa activa. El desfase parece menor. En la era de la acción, sin embargo, puede tener consecuencias graves: un agente podría enviar información confidencial a quien antes estaba autorizado.

Podría pagar a una cuenta bancaria antigua, tratar un dominio abandonado como canal oficial o generar voz e imagen apoyándose en una aprobación que ya no es válida. La gobernanza de la identidad no consiste, por tanto, en registrarla una vez. Es un ciclo de vida que exige actualizaciones periódicas.

El ciclo de vida de la identidad

Una relación de identidad pasa por estas etapas:

Creación

Se define por primera vez la identidad, el rol o el agente.

Verificación

La afirmación se respalda con pruebas adecuadas.

Autorización

Se determinan las acciones permitidas.

Uso

Se actúa bajo esa identidad en las tareas definidas.

Revisión

Se comprueba que la información y la autorización siguen siendo correctas.

Suspensión

Se detienen las operaciones asociadas a la identidad ante una sospecha, un incidente o un cambio temporal.

Revocación

Se pone fin de forma permanente a la autorización.

Archivo

Se conserva el registro histórico, pero no se utiliza como identidad vigente. Un sistema centrado únicamente en crear y usar identidades puede descuidar la revocación y el archivo. Mantener accesos cuya vigencia terminó genera riesgos: cuentas de antiguos empleados, claves de API olvidadas, accesos de agencias caducados, permisos biométricos retirados y automatizaciones que no se desactivaron. Para el GBO, cómo termina una identidad importa tanto como cómo empieza.

Identidad y autorización revocables

Una persona puede haber dado permiso y retirarlo después. Una empresa puede haber autorizado a un agente a trabajar en ciertas cuentas y suspender todas sus facultades tras un incidente de seguridad. Puede utilizarse el avatar de IA de un directivo, pero al terminar su función o su contrato debe reevaluarse la autorización de uso. Los usos que deban cesar en ese caso tienen que quedar definidos de antemano en el permiso y el contrato. Por eso los registros de identidad y autorización no deben reducirse a «activo» o «inexistente».

Pueden existir estos estados:

• Activo
• Restringido
• En revisión
• Suspendido temporalmente
• Revocado
• Caducado
• Archivado

El agente no debe legitimar una acción actual solo porque una identidad estuvo activa en el pasado.

La autorización de ayer no es la autorización de hoy.

La identidad del canal

Una organización puede disponer de varios canales de comunicación, y no todos deben utilizarse para las mismas operaciones. Un mensaje en redes sociales puede servir para preguntas generales sin ser un canal seguro para cambiar una cuenta bancaria. Un correo de soporte puede resolver incidencias técnicas sin estar autorizado para aceptar contratos. Un formulario web puede recibir solicitudes de presupuesto y no ser apropiado para compartir documentación laboral de empleados. Preguntar «¿El canal es oficial?» no basta.

¿Está este canal autorizado para esta operación?

Esa pregunta también es necesaria. Una orden de pago recibida desde el Instagram oficial de una organización puede proceder de la cuenta real y, aun así, no llegar por un canal de pago válido. Una promesa en un chat de atención al cliente no tiene por qué constituir una oferta económica jurídicamente vinculante. Hay que separar la pertenencia del canal a la organización de su autorización para una operación determinada.

La identidad del representante

Las organizaciones no suelen actuar directamente. Lo hacen a través de empleados, agencias, consultores, distribuidores, sistemas de software y agentes de IA.

El agente debe entender no solo quién está al otro lado, sino a quién representa y hasta dónde llega esa representación. Un distribuidor puede estar autorizado para vender únicamente en ciertos países. Poder emitir una opinión técnica no implica que un consultor pueda firmar un contrato. El permiso de publicación de una agencia de gestión de redes sociales puede no incluir acceso a datos de clientes. Encargar a un agente que organice reuniones no tiene por qué facultarlo para asumir compromisos comerciales. Si la representación no está clara, el sistema puede tratar lo que dice el representante como una decisión definitiva de la organización.

El registro de representación debe especificar, como mínimo:

• Entidad representada
• Representante
• Rol
• Operaciones autorizadas
• Operaciones no autorizadas
• Ámbito geográfico
• Ámbito temporal
• Situaciones que requieren aprobación

La ficha de identidad del agente de IA

Cuando un agente interactúa con el mundo exterior, las personas deben poder acceder a información básica sobre él.

Podemos reunirla en una ficha de identidad del agente.

La ficha responde a estas preguntas:

¿Cuál es el nombre o identificador único del agente? ¿Quién lo opera? ¿En nombre de quién trabaja? ¿Cuál es su tarea principal? ¿A qué sistemas accede? ¿Qué acciones puede realizar automáticamente? ¿Cuáles requieren aprobación humana? ¿Se registran sus conversaciones y operaciones? ¿Hasta cuándo es válida su autorización? ¿Cómo se puede contactar con una persona? ¿Cómo se detiene al agente o se revocan sus permisos?

No toda la ficha tiene que ser pública, pero la persona afectada por la operación debe poder conocer lo necesario. Un agente no debe hacerse pasar por humano. Si habla en nombre de un empleado, debe quedar claro que se trata de una representación sintética o automatizada. Ocultar la identidad puede hacer que la otra parte se equivoque sobre con quién está hablando. Este principio de transparencia busca evitar ese engaño antes que maximizar la interacción a corto plazo. El GBO no respalda ocultar el uso de IA de forma que induzca a error.

Un agente no puede atribuirse autoridad

Un sistema de IA puede decir «Estoy autorizado para esta operación». La frase, por sí sola, no prueba nada. La persona u organización que lo opera debe otorgar esa autorización.

La autorización debe ser:

• versionada,
• verificable,
• limitada de forma clara
• y revocable cuando sea necesario.

Un agente puede añadir tareas a su trabajo, pero no concederse nuevos derechos. Un agente central puede crear un subagente, pero no transferirle facultades de las que el sistema principal carece.

No se puede delegar una autorización que nunca se ha recibido.

Este principio es crucial en los sistemas multiagente. Si un agente solo está autorizado para investigar, el subagente que cree no adquiere por ello el derecho a enviar mensajes. Si un sistema solo puede preparar borradores, otra herramienta al final de la cadena no debe publicarlos automáticamente.

El nombre del agente y su identidad técnica

Una organización puede dar una marca o una personalidad a sus sistemas de IA. Puede ser útil para la experiencia de uso y la continuidad de la organización. Pero el nombre de esa personalidad no debe confundirse con la identidad técnica. «NOMOS», «Atlas», «Aria» u otro nombre pueden ser la cara pública del sistema.

En el registro interno también debe constar:

• ¿Qué modelo o versión del sistema se utilizó?
• ¿Qué herramientas estaban conectadas?
• ¿Qué conjunto de instrucciones estaba vigente?
• ¿A qué fuentes de datos se podía acceder?
• ¿Qué persona concedió la autorización?
• ¿Qué instancia del agente realizó la acción?
• ¿En qué fecha operó?

La marca pública aporta continuidad; la identidad técnica permite auditar. Ambas son necesarias.

Ante un error, quizá no baste decir «Lo hizo NOMOS». ¿Qué sesión del agente?

¿Qué versión de la autorización?

¿Qué herramienta?

¿Qué cadena de operaciones?

Estos detalles son necesarios para investigar el incidente.

La identidad del rostro y la voz sintéticos

El problema de identidad no se limita a textos y cuentas.

Los sistemas de IA pueden imitar:

• el rostro de una persona,
• su voz,
• su forma de hablar,
• sus gestos
• y su estilo de escritura.

Que un avatar se parezca mucho a alguien no significa que esa persona haya aprobado cada mensaje. Una grabación puede sonar realista aunque la persona nunca haya pronunciado ese texto. Un directivo puede haber autorizado su avatar digital solo para determinados videos de formación.

Utilizar el mismo avatar para

• declaraciones políticas,
• compromisos comerciales,
• comunicados a empleados,
• mensajes de crisis
• o comunicaciones a inversores

puede requerir otra aprobación.

En este libro analizamos el alcance del permiso para usar una identidad sintética a través de tres operaciones separadas: Crear una reproducción digital de la persona Generar el contenido Publicar el contenido

El permiso para una no cubre automáticamente las demás. Permitir el uso del rostro no es permitir el uso de la voz. Permitir la voz no autoriza a hacerle decir cualquier texto. El permiso de generación no es permiso de publicación. Autorizar el uso en un idioma no concede uso ilimitado en otro. El contrato de identidad del GBO debe registrar estas diferencias de forma explícita.

La frontera entre suplantación y representación autorizada

Un avatar de IA puede servir a dos propósitos distintos. Puede facilitar la comunicación de una organización con el permiso expreso y la supervisión de la persona representada. O puede aprovechar su identidad y la confianza que inspira para atribuirle palabras que no aprobó. La tecnología visual puede ser la misma; el resultado del comportamiento es completamente diferente.

Por eso el sistema no debe preguntar solo «¿Hay permiso?».

También debe preguntar:

• ¿Para qué contenido?
• ¿Durante cuánto tiempo?
• ¿En qué canal?
• ¿En qué idioma?
• ¿Para qué público?
• ¿Hace falta aprobación humana previa?
• ¿Se indicará que el contenido es sintético?
• ¿Cómo puede la persona retirar el permiso?
• ¿Qué ocurrirá con los contenidos anteriores?
• ¿Quién conservará los archivos del modelo?

Actuar sobre una identidad debe apoyarse no solo en el consentimiento inicial de su titular, sino también en su derecho a mantener el control.

Las identidades falsas no siempre vienen de fuera

Cuando se habla de identidades falsas, solemos pensar en atacantes. Sin embargo, la propia organización también puede producir errores de identidad. Marketing puede atribuir a un empleado un cargo que no tiene. Una página comercial puede presentar a un socio como representante oficial. Un agente puede presentarse como empleado humano. Una empresa puede seguir utilizando una certificación o membresía que ya no es válida. Una automatización puede enviar mensajes con la firma de un antiguo directivo. No siempre se trata de fraude deliberado: puede deberse a un proceso incompleto, una configuración olvidada o una mala gobernanza.

Para la máquina, no obstante, el resultado es el mismo:

Una identidad incorrecta produce un comportamiento incorrecto. La auditoría de identidad debe abarcar los registros propios de la organización, no solo las amenazas externas.

La deuda de identidad

Al igual que ocurre con la deuda de representación, las organizaciones pueden acumular:

Deuda de identidad

Esta deuda también puede crecer dentro de la organización.

La forman:

• Perfiles de antiguos empleados
• Cuentas olvidadas
• Autorizaciones inválidas
• Registros de marca y estructura jurídica sin vincular
• Dominios antiguos
• Descripciones contradictorias de la empresa
• Relaciones de representación caducadas
• Cuentas sociales de propietario desconocido
• Accesos de agentes que no se han revocado
• Biografías sin actualizar
• Datos bancarios o de contacto antiguos

Cuanto mayor es la deuda de identidad, más probable resulta que los agentes confíen en la persona equivocada. Incorporar nuevos agentes y automatizaciones la vuelve más peligrosa: los registros antiguos o ambiguos ya no solo confunden a personas, sino que pueden dirigir cadenas de acciones automáticas.

Cómo actuar ante una identidad incierta

¿Qué debe hacer un agente si no está seguro de la identidad?

Hay tres opciones básicas:

Pedir una aclaración

«He encontrado varias empresas con el mismo nombre. ¿Se refiere al proveedor de portales de clientes de Estambul?»

Verificar por una vía independiente

Comparar otros indicios: dominio, país, registro legal, perfil oficial o relación previa.

Detener la acción

Si la identidad sigue sin resolverse, no debe haber comunicación externa, pagos, intercambio de datos ni compromisos. Ante una consulta informativa de bajo riesgo puede presentarse una coincidencia posible, indicando claramente la incertidumbre. No debe ocultarse lo que no se sabe; en una operación de alto impacto, no se debe avanzar sin la verificación de identidad necesaria.

Cuando disminuye la certeza sobre la identidad, también debe reducirse el nivel de acción.

Si no está seguro, el sistema debe ofrecer:

• una recomendación en vez de ejecutar,
• un borrador en vez de enviar,
• un carrito en vez de pagar
• o una vista previa en vez de publicar.

Debe elegir esa forma de menor alcance.

La puerta de identidad NOMOS

El modelo de la puerta de identidad NOMOS utiliza cinco áreas de control. El contexto y el riesgo determinan la verificación necesaria en cada operación.

1. Control de la entidad

¿Se ha identificado a la persona, organización, producto o servicio correctos?

2. Control del canal

¿El dominio, la cuenta, el correo o la interfaz utilizados están realmente vinculados a esa entidad?

3. Control del rol

¿Con qué rol actúa la persona o el sistema de la otra parte?

4. Control de la autorización

¿Está ese rol autorizado para realizar o aceptar la operación?

5. Control de la vigencia

¿Siguen siendo válidos ahora la identidad, el rol y la autorización?

De forma simplificada:

CONDICIONES DE LA PUERTA DE IDENTIDAD:

ENTIDAD CORRECTA

Y CANAL CORRECTO

Y ROL CORRECTO

Y AUTORIZACIÓN VÁLIDA

Y REGISTRO ACTUALIZADO

Si no se supera uno de estos controles, el agente debe cambiar su forma de proceder. No significa necesariamente rechazar toda la tarea: puede elegir un siguiente paso de menor riesgo.

Por ejemplo:

• Solicitar la verificación de los datos bancarios en lugar de pagar directamente
• Preparar un borrador en lugar de enviar un mensaje
• Remitir el contrato al departamento jurídico en lugar de aceptarlo
• Mostrar una pantalla de aprobación en lugar de publicar el contenido
• Establecer un primer contacto con la información mínima en lugar de compartir datos personales

¿Por qué la puerta de identidad no es una puntuación?

El dominio de una empresa puede parecer muy fiable, pero si el representante carece de autorización no debe ejecutarse la operación. La identidad de alguien puede estar sólidamente verificada, pero si sus facultades caducaron no se debe avanzar. Una cuenta social puede llevar años activa, pero si no es un canal válido para instrucciones de pago no debe utilizarse con ese fin. Los elementos de identidad no deben sumarse como puntos. Un indicio sólido no compensa una carencia crítica.

Una confianza elevada no suple una autorización inexistente.

Por eso la puerta de identidad sigue una lógica Y: deben superarse todos los controles que requiera el riesgo de la acción.

Ejemplo: un pago

Una empresa recibe una factura de su proveedor habitual. La ha enviado un empleado real desde el dominio oficial. El logotipo y el formato coinciden con las facturas anteriores. Pero la cuenta bancaria ha cambiado.

Un agente que procese automáticamente la factura debe plantearse estas preguntas de identidad:

• ¿La persona que envía la factura trabaja realmente para el proveedor?
• ¿Está autorizada para comunicar cambios de cuenta bancaria?
• ¿La cuenta nueva puede vincularse a la misma entidad jurídica proveedora?
• ¿Se ha confirmado el cambio por un canal independiente?
• ¿El pago está dentro del límite de importe de la organización que paga?
• ¿Hace falta aprobación humana?

El correo puede ser auténtico y la cuenta estar comprometida. El empleado puede ser real y haber facilitado información errónea. La cuenta bancaria nueva puede existir y pertenecer a otra entidad jurídica. Auditar la identidad no consiste solo en detectar correos falsos. Consiste en verificar todas las relaciones de identidad y autorización de la cadena de la operación.

Ejemplo: un contrato

Un agente trabaja con un proveedor en un borrador de contrato. Su interlocutor es el director comercial de la empresa y su identidad se ha verificado. Sin embargo, quizá no esté facultado para conceder el último descuento. El agente no debe interpretar su mensaje como un compromiso contractual definitivo de la empresa.

Debe distinguir entre facultades para:

• negociar,
• preparar ofertas,
• conceder descuentos,
• firmar contratos
• y designar una cuenta de pago.

La etiqueta genérica «representante autorizado» puede ocultar estas diferencias. El GBO desglosa la autorización por tipo de acción.

La cadena de identidad en sistemas multiagente

Cuando un agente central delega una tarea, debe transmitir también el contexto de identidad.

Por ejemplo, puede ordenar: «Evalúa a este posible cliente».

El subagente necesita saber:

• ¿Qué organización hace la solicitud?
• ¿Qué persona o empresa se está evaluando?
• ¿Qué fuentes son oficiales?
• ¿Qué datos de contacto se pueden utilizar?
• ¿Qué acciones están prohibidas?
• ¿A quién se debe informar del resultado?

Si no recibe ese contexto, el subagente puede hacer sus propias asociaciones: investigar la empresa equivocada, confiar en un perfil antiguo o contactar con una empresa homónima de otro país. Cada traspaso en un sistema multiagente conlleva el riesgo de perder contexto de identidad.

El paquete de la tarea debe incluir:

Identidad de la entidad objetivo Identidad de quien solicita Rol del agente Límite de autorización Fuentes canónicas Período de validez

La identidad y la responsabilidad deben conservarse

Varios agentes pueden intervenir en una operación. Uno investiga, otro prepara el borrador, otro controla la calidad y el último publica.

Si aparece un error en esa cadena, «Lo hizo la IA» no basta. ¿Qué hizo cada agente?

¿Qué fuentes utilizó?

¿Quién concedió la autorización?

¿Quién revisó?

¿Quién publicó?

Por eso cada comprobante de acción debe incluir la cadena de identidad.

Por ejemplo:

Solicitud: responsable de ventas Planificación: agente central Investigación: agente de búsqueda de posibles clientes Borrador: agente de correo Aprobación: responsable humano Envío: sistema de comunicación autorizado Destinatario: cuenta de empresa verificada

Este registro no sirve solo para atribuir responsabilidades. También permite entender dónde debe mejorarse el sistema.

Equilibrar identidad y privacidad

Verificar la identidad importa, pero no justifica recopilar datos personales innecesarios.

Un agente no debe pedir en cada operación:

• un documento de identidad,
• la dirección completa,
• la fecha de nacimiento,
• datos biométricos,
• el teléfono personal
• o información financiera.

La verificación debe ser proporcionada y adecuada al propósito. Confirmar que alguien puede organizar una reunión por una empresa no exige conocer toda su vida privada. Comprobar que un cliente supera un límite de edad quizá no requiera su fecha de nacimiento completa. Demostrar que una organización controla un dominio no exige publicar todos sus documentos internos. El GBO no pretende volver a las personas completamente transparentes. Pretende verificar la relación necesaria para actuar correctamente.

Aclarar la identidad no significa eliminar la privacidad.

Anonimato no siempre significa ausencia de identidad

En algunos casos se puede estar autorizado para actuar sin revelar el nombre real. Una persona que denuncia una irregularidad puede ocultar su identidad. Una consulta de salud puede hacerse de forma anónima. Un miembro de una comunidad puede usar un seudónimo. Un usuario puede actuar con una identidad de cuenta persistente sin compartir su nombre fuera del sistema. El GBO, por tanto, no exige un nombre legal para todo comportamiento.

Lo que importa es:

• verificar los atributos necesarios para la acción,
• conocer los límites de autorización
• y preservar la responsabilidad y la posibilidad de impugnar.

A veces la identidad se apoya en una relación fiable y una autorización documentada, no en un nombre.

Auditoría de identidad de una organización

Una organización que quiera prepararse para la era de los agentes debe responder a estas preguntas:

Identidad

• ¿Cuál es el nombre de la marca principal?
• ¿Quién es el operador jurídico?
• ¿Qué nombres alternativos se utilizan?
• ¿Hay otras entidades con el mismo nombre?

Presencia digital

• ¿Qué dominios son oficiales?
• ¿Qué cuentas sociales están activas?
• ¿Qué perfiles están desactualizados o gestionados por terceros?
• ¿Existe un registro canónico legible por máquinas?

Autorización

• ¿Quién puede comunicar precios?
• ¿Quién puede celebrar contratos?
• ¿Quién puede enviar mensajes al exterior?
• ¿Quién puede recibir o efectuar pagos?
• ¿Qué operaciones tiene autorizadas cada agente?

Vigencia

• ¿Cuándo se verificaron los roles?
• ¿Qué autorizaciones son temporales?
• ¿Se desactivaron los accesos de antiguos empleados y agentes?
• ¿Son visibles los registros de revocación?

Representación

• ¿Está clara la relación entre la marca y la estructura jurídica?
• ¿Personas y máquinas ven la misma información de identidad?
• ¿Se conserva esa relación en los distintos idiomas?
• ¿Están actualizadas las plataformas externas?

Si no se pueden responder estas preguntas, la organización tiene deuda de identidad.

La incertidumbre de identidad es un dato para decidir, no solo un error

Un mensaje genérico como «No se pudo verificar la identidad» puede resultar insuficiente para elegir el siguiente paso. El enfoque del GBO exige explicar, cuando sea seguro hacerlo, qué clase de incertidumbre existe: qué es exactamente lo que no se ha podido resolver.

Por ejemplo: «Se han encontrado dos empresas con el mismo nombre. Debe indicar el país o el dominio». «Esta persona parece trabajar en la organización, pero no se ha podido confirmar su facultad para firmar contratos». «El dominio está vinculado a la marca, pero la cuenta bancaria pertenece a otra entidad jurídica». «Hay permiso para usar el rostro, pero no la voz ni para publicar el contenido». Saber qué falta permite elegir el paso adecuado. Un sistema de identidad no es, por tanto, un simple mecanismo de «aprobado/rechazado».

Ayuda al agente a:

• hacer preguntas,
• pasar a un comportamiento de menor riesgo,
• pedir una verificación independiente
• o solicitar aprobación humana.

Así orienta la decisión sobre cómo continuar.

La identidad correcta permite rechazar correctamente

Resolver bien la identidad enseña al agente no solo a actuar, sino también a rechazar una operación indebida.

Por ejemplo:

• El mensaje procede de un empleado real, pero no tiene autorización para modificar precios.
• La cuenta pertenece a la marca, pero no es un canal de pago.
• El avatar se parece realmente al directivo, pero no cuenta con aprobación para publicar.
• La empresa existe, pero no presta servicios en el país que busca el usuario.
• El dominio es oficial, pero la página corresponde a una versión antigua archivada.
• El agente es auténtico, pero solo está autorizado para preparar borradores.

La identidad no responde únicamente a «¿Es auténtico?».

«¿Es esta la identidad correcta para esta acción?»

También responde a esa pregunta.

Identidad correcta y visibilidad de marca son cosas distintas

Una marca puede tener mucha presencia en los resultados de búsqueda, cuentas sociales fuertes y menciones en numerosas publicaciones. Pero si no están claros su vínculo con la estructura jurídica, sus representantes autorizados y sus servicios actuales, no está preparada para que se actúe sobre esa base. La visibilidad puede reforzar la identidad, pero no completa su resolución. También puede ocurrir lo contrario: una empresa puede ser poco conocida.

Sin embargo, si pueden verificarse claramente:

• su estructura jurídica,
• su dominio oficial,
• el alcance de sus servicios,
• sus representantes autorizados,
• sus canales de pago
• y la actualidad de sus datos,

puede ser una opción más segura para una operación concreta. El GBO no confunde popularidad con fiabilidad de identidad.

Ser muy visible no significa ser la contraparte correcta.

¿Cómo debe prepararse una entidad?

Una empresa, organización o profesional que quiera ser reconocido correctamente por los agentes debe hacer que su estructura de identidad sea sencilla y verificable.

Debe quedar claro:

¿Quiénes somos? ¿Bajo qué estructura jurídica trabajamos? ¿Qué dominios y canales nos pertenecen? ¿Qué servicios ofrecemos? ¿Quién puede representarnos y en qué asuntos? ¿Qué agentes desempeñan cada función? ¿Qué operaciones requieren aprobación humana? ¿Cuándo se actualizaron los datos? ¿Qué identidades son antiguas o están revocadas?

Esta información debe existir como un sistema gestionado, no como pistas dispersas por el texto comercial.

La claridad de identidad no tiene por qué intimidar

Algunas organizaciones pueden pensar que revelar demasiada información de identidad resta misterio o prestigio a la marca. Pero ser claro no equivale a exponer toda la arquitectura interna.

Una empresa no está obligada a publicar:

• todas sus herramientas técnicas,
• la lista completa de empleados,
• su estructura de seguridad,
• sus claves privadas
• o las instrucciones de sus agentes.

Las claves privadas y los secretos de acceso no deben hacerse públicos. Las relaciones que clientes y agentes necesitan conocer para operar con seguridad deben poder verificarse sin revelar esos secretos.

Por ejemplo:

«Esta marca está operada por esta empresa». «Las facturas se emiten con esta razón social». «Las ofertas oficiales se envían exclusivamente por estos canales». «El sistema de IA puede preparar borradores; los compromisos comerciales definitivos requieren aprobación humana». «Los cambios de cuenta bancaria solo son válidos después de una verificación independiente».

Esta claridad no debilita la marca. La hace más profesional.

Una escena de identidad: el avatar de un directivo

Una empresa crea un avatar digital de su CEO.

El parecido es muy estrecho en:

• el rostro del CEO,
• su voz
• y su forma de hablar.

El propósito inicial es publicar videos de formación previamente aprobados en seis idiomas. Con el tiempo, marketing quiere usar el avatar para presentar nuevos productos. Ventas propone enviar mensajes personalizados a clientes. Relaciones con inversores se plantea utilizarlo para exponer los resultados trimestrales. En plena crisis, comunicación quiere difundir una declaración rápida. El sistema técnico puede hacer todo eso.

Sin un contrato de identidad, sin embargo, quedan preguntas sin respuesta:

• ¿Para qué propósito autorizó el CEO el uso de su rostro?
• ¿En qué idiomas puede utilizarse su voz?
• ¿Debe aprobarse cada guion por separado?
• ¿Está autorizado el avatar para preparar declaraciones sobre asuntos financieros?
• ¿Cómo se indicará que el avatar es sintético?
• ¿Qué ocurrirá con los videos anteriores si el CEO retira su permiso?
• ¿Qué equipo puede publicar?
• ¿Cómo se detendrá el sistema si la cuenta resulta comprometida?
• ¿Cómo se demostrará que una declaración fue realmente aprobada por el CEO?

Aunque el sistema pueda generar esas intervenciones, la falta de límites claros de identidad y autorización crea un riesgo de representación incorrecta.

El ejemplo vuelve a mostrar un principio básico del GBO: poder imitar una identidad no concede el derecho a actuar en su nombre.

Una escena de identidad: el agente que habla por una empresa

Un cliente escribe en el chat de la web: «¿Puedo contratar este servicio por 1.000 dólares?». El agente consulta los registros de precios anteriores.

Responde: «Sí, ese precio cubre todo el sistema de identidad visual». Pero los 1.000 dólares son solo el precio inicial de un trabajo de logotipo de alcance delimitado. El sistema completo de identidad visual se presupuesta con un alcance separado. El agente está en la web real de la empresa y ha leído un precio real, pero ha combinado incorrectamente dos servicios. La identidad del agente es correcta. La de la empresa también. Lo que falla es el alcance de la representación y de la información. El cliente puede tomar la respuesta por una oferta oficial.

Por eso la ficha del agente debe explicar no solo en nombre de quién trabaja, sino también:

• qué fuentes de información puede utilizar,
• qué puede decir sobre precios
• y en qué momento debe transferir la conversación al equipo comercial.

Esos límites también deben quedar descritos.

Una escena de identidad: el trabajo correcto, el agente equivocado

Una empresa utiliza varios agentes a la vez:

• Agente de correo
• Agente de redes sociales
• Agente de SEO/GEO
• Agente financiero
• Agente de búsqueda de posibles clientes
• Agente de operaciones web

El agente de SEO/GEO encuentra un precio antiguo en una página de servicios. Actualizarlo es técnicamente sencillo. Pero ese agente no puede decidir el precio.

Lo correcto es:

• detectar la contradicción,
• señalar la fuente canónica de precios,
• pedir confirmación a una persona autorizada o al departamento financiero
• y aplicar el cambio técnico una vez aprobado.

Si el agente corrige el precio según su propia estimación, el proceso es incorrecto aunque acierte con el resultado.

La distinción importa: la acción correcta debe realizarla el agente correcto. Dar funciones amplias a un único agente no elimina la necesidad de separar tareas y controlar las autorizaciones. Que un sistema tenga uno o varios agentes no lo vuelve fiable por sí mismo. La separación de funciones forma parte de la identidad tanto como la especialización.

El comprobante de identidad

La sección de identidad del comprobante de acción debe contener al menos:

• ¿Quién ha solicitado la acción?
• ¿Qué agente la ha ejecutado?
• ¿Qué organización opera al agente?
• ¿Qué versión del rol y de la autorización se ha utilizado?
• ¿Quién es la contraparte?
• ¿Cómo se ha verificado su identidad?
• ¿Qué canal oficial se ha utilizado?
• ¿En qué fecha era válida la autorización?
• ¿Quién dio la aprobación humana y cuándo?

En operaciones de alto impacto, este registro constituye una base de la pista de auditoría. Respaldado por registros verificados de la operación, ayuda a investigar dónde se rompió la cadena de identidad cuando surge un problema.

Doce preguntas para auditar la identidad

Antes de considerar que una persona, organización o agente está preparado para actuar, pueden plantearse estas preguntas:

• ¿Cuál es el nombre canónico de la entidad?
• ¿Hay otras entidades con el mismo nombre o uno parecido?
• ¿Está clara la relación entre la marca y su operador jurídico?
• ¿Cuáles son los dominios y canales de comunicación oficiales?
• ¿Con qué rol actúa la persona o el sistema de la otra parte?
• ¿Está ese rol realmente autorizado para la acción?
• ¿Durante cuánto tiempo y con qué alcance es válida la autorización?
• ¿Cuándo se verificó por última vez la información de identidad?
• ¿Están claramente separados los registros de identidades antiguas o revocadas?
• ¿Se conocen la identidad del propio agente, su operador y su límite de autorización?
• ¿Personas y máquinas ven la misma relación de identidad?
• ¿Cómo se detendrá la acción o se transferirá a una persona si surge incertidumbre?

No hace falta formularlas todas en cada operación sencilla. En comportamientos de alto impacto, sin embargo, no deben quedar sin respuesta.

Niveles de preparación de la identidad

Las organizaciones pueden encontrarse en distintos niveles de preparación de identidad para la era de los agentes.

Identidad dispersa

Las plataformas muestran nombres, roles e información diferentes.

Identidad definida

Se han explicado la marca principal y su relación jurídica.

Identidad verificable

Se han identificado los canales oficiales y las fuentes de prueba.

Identidad autorizada

Está claro quién puede realizar cada acción.

Identidad preparada para los agentes

Personas y máquinas pueden utilizar con seguridad los registros de identidad, autorización, vigencia, canales y revocación. El GBO busca que las organizaciones no solo sean visibles, sino que dispongan de una estructura de identidad apta para los agentes.

Sin identidad no se puede evaluar la capacidad

Un agente no puede responder «¿Qué puede hacer esta entidad?» sin identificar primero a la entidad correcta. La capacidad pertenece siempre a alguien concreto. Bajo una misma marca, distintas empresas pueden ofrecer servicios diferentes. Una sucursal local puede carecer de parte de las capacidades de la matriz. Un distribuidor puede vender un producto sin poder desarrollarlo. Un consultor puede recomendar un sistema sin poder implementarlo. Un agente de IA puede informar sin poder ejecutar operaciones. Una lista de capacidades no es fiable mientras la identidad siga sin resolverse correctamente. Por eso la primera parte del contrato de comportamiento trata de identidad y la segunda, de capacidad.

La conclusión del capítulo

Una máquina puede analizar correctamente a la persona equivocada, enviar una oferta impecable a la empresa equivocada, obtener información verdadera de un empleado no autorizado, aceptar un compromiso indebido desde una cuenta oficial o publicar, mediante un avatar realista, un mensaje que nunca se emitió. Si la identidad está mal resuelta, todo el razonamiento posterior puede parecer correcto y aun así avanzar sobre una base equivocada.

El GBO parte de este principio: el comportamiento correcto requiere la identidad correcta. Pero identificar correctamente no consiste solo en hacer coincidir nombres.

Hay que verificar conjuntamente:

• Entidad
• Canal
• Rol
• Autorización
• Vigencia
• Relación
• Prueba

Una persona puede ser real y carecer de autorización. Un canal puede ser oficial y no servir para esta operación. Un rol puede ser correcto, pero haber caducado. Un agente puede pertenecer a la organización y estar autorizado solo para preparar borradores. Un avatar puede parecerse a una persona sin representar sus palabras. En el GBO, la identidad no es una foto de perfil ni una insignia de verificación.

La identidad es un contrato de responsabilidad que explica quién puede actuar en nombre de quién, con qué propósito, durante cuánto tiempo y dentro de qué límites.

El contrato de identidad NOMOS hace visible esa responsabilidad. El agente sabe quién es y para quién trabaja. Identifica correctamente a su contraparte y conoce las facultades de cada rol. Se detiene ante la incertidumbre. No se apoya en autorizaciones revocadas ni expone la identidad y la vida privada de una persona más de lo necesario.

Solo cuando se resuelve la identidad cobra sentido la siguiente pregunta:

¿Qué puedes hacer realmente?

Saber quién es una organización, persona o agente importa. Pero su nombre, su visibilidad y su reputación no demuestran su capacidad real. En el siguiente capítulo estudiaremos la diferencia entre afirmación y capacidad, cómo demostrar lo que puede hacer un servicio, producto o agente, y por qué capacidad, precio, alcance y límites deben figurar en el mismo contrato de comportamiento.

La identidad abre la puerta a la persona correcta. La capacidad muestra lo que realmente hay dentro.