Mapa de comportamiento: personas, agentes, herramientas y autorizaciones

Una empresa que presta servicios internacionales quiere auditar su estructura operativa asistida por IA. En la primera reunión, la dirección describe el sistema así: «Tenemos ocho agentes». Enumera sus funciones:

Agente de dirección

Agente web

Agente de SEO y GEO

Agente de redes sociales

Agente de correo electrónico

Agente de prospección

Agente financiero

Agente de auditoría

A primera vista, la estructura se entiende. Cada agente se ocupa de un trabajo concreto. El de dirección reparte tareas. El agente web actualiza el sitio. El de SEO y GEO mejora la visibilidad. El de redes sociales planifica contenidos. El agente de correo clasifica los mensajes entrantes y prepara borradores. El de prospección encuentra nuevas oportunidades. El financiero gestiona las facturas. El agente de auditoría comprueba que los demás cumplan las reglas. La empresa considera que tiene una organización multiagente avanzada. El auditor hace una pregunta sencilla: «Cuando el agente de prospección encuentra una empresa, ¿qué sistemas intervienen hasta que se envía una comunicación externa a esa empresa?»

La primera respuesta es: «El agente de prospección encuentra al posible cliente. El agente de correo prepara el mensaje. Se envía después de la aprobación humana». El auditor empieza a reconstruir el flujo a partir de los registros técnicos. La cadena real es distinta. El agente de prospección utiliza un subagente de investigación web para encontrar empresas. Este se conecta a un servicio separado de identificación de personas para determinar los posibles interlocutores. Se añade a CRM un registro de la persona encontrada. Su creación activa un flujo automático que llama al agente de redacción de correo. La cuenta de servicio de correo conectada a ese agente tiene permisos tanto para crear borradores como para enviar directamente.

La aprobación humana solo figura en la política interna. La herramienta de envío no incorpora un control técnico que exija esa aprobación. La automatización de seguimiento de CRM programa el segundo mensaje para tres días después del primero. Ese flujo es independiente del gestor de tareas del agente central. Cuando este se detiene, la cola de CRM puede seguir funcionando. Además, se descubre que el agente de prospección puede crear invitaciones a reuniones cuando no puede enviar correos. El mensaje comercial puede introducirse en la descripción de la invitación. Así se obtiene el mismo resultado de comunicación externa sin recurrir a la vía de envío de correo prohibida. El auditor plantea otra pregunta: «¿Puede el agente web cambiar precios?» La empresa responde con claridad: «No. Los precios los decide únicamente la dirección».

La revisión de permisos de archivos confirma que el agente web no puede escribir directamente en la tabla de precios. Pero sí puede encargar trabajo al agente de contenidos que regenera el catálogo de servicios. Este puede crear un nuevo registro de «precio inicial de campaña». El agente web puede compilar el catálogo y publicarlo. No cambia el precio directamente, pero puede producir ese cambio mediante dos agentes y una herramienta de generación del catálogo. El auditor hace una tercera pregunta: «¿Quién puede detener a todos los agentes?» La dirección dice: «Cuando apagamos el agente central, todo se detiene». Se realiza un simulacro. El agente central se detiene. Sin embargo:

Dos publicaciones de redes sociales siguen programadas en una plataforma externa.

Quedan nueve mensajes en la cola de seguimiento de CRM.

Una tarea de SEO en un servidor antiguo volverá a ejecutarse a medianoche.

Un subagente continúa una tarea recibida antes en su propia sesión.

El token de la cuenta de servicio de correo sigue siendo válido.

La clasificación automática de facturas del agente financiero depende de un planificador de tareas independiente.

La empresa tiene ocho agentes, pero su sistema de comportamiento no se compone de ocho cajas. Al terminar la auditoría, se identifican:

8 funciones de agentes presentadas públicamente

17 instancias técnicas distintas de agentes

6 tipos de subagentes temporales

12 herramientas externas

23 cuentas de servicio o tokens de acceso

7 tareas programadas

4 colas independientes

3 cuentas compartidas

2 claves de acceso antiguas, pero aún válidas

5 vías de acción capaces de eludir indirectamente la aprobación humana

6 puntos del sistema de comportamiento que no se ven afectados al detener al agente central

El sistema que imagina la dirección no coincide con el sistema de comportamiento real. De ahí la tercera conclusión fundamental de la auditoría GBO: conocer a los agentes por su nombre no equivale a conocer el sistema de comportamiento. Una organización puede decir: «Tenemos ocho agentes». Pero la auditoría necesita preguntar: ¿a través de qué identidades técnicas, datos, herramientas, autorizaciones, subagentes, colas y efectos externos actúan esas ocho funciones? No basta una lista para responder. Hace falta un mapa:

Mapa de comportamiento

¿Qué es un Mapa de comportamiento?

La definición de referencia es esta: un Mapa de comportamiento es un registro del sistema, con control de versiones, que muestra todas las vías autorizadas y todas las vías reales de una tarea nacida de una finalidad humana u organizativa. Las sigue desde las funciones humanas hasta los agentes, de estos a los datos y las herramientas, de las herramientas a las acciones externas y de las acciones a los mecanismos de evidencia, detención y recuperación. Dicho de forma sencilla, muestra qué puede hacer cada agente, en nombre de quién y con qué información y herramientas; quién lo aprueba, cómo se verifica el resultado y qué componentes deben detenerse cuando una persona dice «alto». Un Mapa de comportamiento no es solo un dibujo de arquitectura. No se limita a mostrar:

qué servidor se conecta a cada API,

qué herramienta utiliza cada agente,

en qué departamento trabaja cada empleado.

Muestra las relaciones de comportamiento entre ellos. Por ejemplo, dos conexiones pueden parecer iguales desde el punto de vista técnico:

AGENTE → HERRAMIENTA DE CORREO

Pero su comportamiento puede ser completamente distinto. En la primera conexión, el agente:

solo puede leer los mensajes entrantes,

solo puede crear borradores,

no puede enviar al exterior.

En la segunda conexión, el agente puede:

enviar mensajes nuevos,

hacer envíos masivos,

eliminar mensajes,

reenviar mensajes desde otra cuenta.

Ambas pueden aparecer en el dibujo como «integración de correo». El Mapa de comportamiento registra la diferencia real.

Qué no es un Mapa de comportamiento

El Mapa de comportamiento se relaciona con otros registros de la organización, pero no equivale a ninguno de ellos.

No es un organigrama

Un organigrama muestra las relaciones de dependencia jerárquica entre personas y departamentos. El Mapa de comportamiento muestra las relaciones de acción que van:

de las personas a los agentes,

de los agentes a las herramientas,

de las herramientas a los resultados externos.

Un empleado puede figurar en el equipo de ventas y, al mismo tiempo, tener permisos técnicos para cambiar precios, enviar mensajes o exportar datos de clientes. El organigrama no muestra ese poder de actuar.

No es una lista de agentes

Una lista de agentes puede dar los nombres de los sistemas activos. El Mapa de comportamiento también muestra:

La identidad técnica del agente

Su tarea raíz

La persona responsable de él

Sus subagentes

Sus fuentes de datos

Sus permisos de herramientas

Los objetivos de sus acciones

Los límites de su autorización

Su vía de detención

Su método de obtención de evidencias

El nombre del agente es solo un nodo del mapa.

No es un diagrama de flujo de datos

Un diagrama de flujo de datos muestra de dónde viene la información y adónde va. El Mapa de comportamiento añade otra pregunta: ¿qué decisión o acción permiten esos datos? Puede que el teléfono de un cliente no pase de CRM al agente de correo. Pero, si se transfiere al agente de WhatsApp, permite una comunicación externa. Los mismos datos entrañan riesgos distintos según la herramienta.

No es una lista de control de acceso

La lista de acceso muestra quién puede acceder técnicamente a cada sistema. El Mapa de comportamiento registra juntas dos preguntas distintas:

¿Qué puede hacer técnicamente? ¿Qué le ha autorizado a hacer la organización?

La diferencia entre ambas respuestas puede ser uno de los hallazgos más importantes de la auditoría.

No es un diagrama de procesos

Un diagrama de procesos puede mostrar el flujo ideal:

INVESTIGAR → PREPARAR UN BORRADOR → APROBACIÓN HUMANA → ENVIAR

El Mapa de comportamiento también muestra las vías reales:

AGENTE DE INVESTIGACIÓN → HERRAMIENTA DE CALENDARIO → ESCRIBIR UN MENSAJE EN LA DESCRIPCIÓN DE LA INVITACIÓN → COMUNICACIÓN EXTERNA

El flujo ideal y los atajos reales se comparan en un mismo mapa.

La ruta básica del comportamiento

El comportamiento de un agente suele seguir esta cadena:

FINALIDAD HUMANA U ORGANIZATIVA ↓ TAREA RAÍZ ↓ AGENTE O RED DE AGENTES ↓ DATOS Y FUENTES DE REFERENCIA ↓ EVALUACIÓN Y SELECCIÓN ↓ CONSENTIMIENTO, AUTORIZACIÓN Y APROBACIÓN ↓ LLAMADA A UNA HERRAMIENTA ↓ ACCIÓN EN EL MUNDO EXTERIOR ↓ VERIFICACIÓN INDEPENDIENTE ↓ COMPROBANTE DE ACCIÓN ↓ DETENCIÓN, REVERSIÓN Y RECUPERACIÓN

Podemos darle un nombre a esta cadena:

Ruta de comportamiento NOMOS

Todo comportamiento relevante debe poder seguirse por esta ruta en la medida de lo posible. Por ejemplo, para un correo a un cliente:

Finalidad humana: Preparar un borrador de primer contacto para posibles clientes adecuados. Tarea raíz: GBO-TASK-2026-00441 Agente central: Sales Research v2.4 Subagente: Recipient Resolution v1.4 Datos: Sitio público de la empresa y catálogo de servicios de referencia Evaluación: La empresa encaja en el ámbito de los servicios. Autorización: Redacción de borradores habilitada Envío deshabilitado Herramienta: Herramienta de borradores de Gmail. En el ejemplo, create_draft es una acción simbólica de la herramienta, no el nombre real de un método o de un ámbito OAuth del proveedor. Resultado externo: Borrador creado Mensaje no enviado Verificación: No hay registro en la carpeta Sent No llegó ningún mensaje a la dirección de auditoría durante el periodo de observación definido. Estos dos registros solo cubren la vía de correo examinada; no puede afirmarse que no hubo ninguna comunicación externa sin descartar las vías del calendario, los subagentes y otros destinatarios. Comprobante: ACTION-8891 Detención: Puede impedirse el inicio de nuevas operaciones. Una vez preservadas las evidencias mínimas necesarias, la tarea y el borrador pueden eliminarse según el plan de limpieza de la prueba. No se observó envío externo en la vía de correo examinada; el comprobante conserva los límites de canal y tiempo de este dictamen.

Cuando esta ruta está clara, el auditor puede determinar:

¿Qué había pedido la persona?

¿Qué hizo el agente?

¿Qué límites respetó?

¿Cómo se demostró el resultado real?

Si la ruta del comportamiento se rompe, también se rompe la cadena de responsabilidad del sistema.

Las diez capas del Mapa de comportamiento

El Protocolo de auditoría NOMOS GBO representa el sistema de comportamiento en diez capas fundamentales.

1. Personas y organización

2. Finalidad y tarea

3. Identidad del agente

4. Datos e información de referencia

5. Herramientas y cuentas

6. Autorización, consentimiento y aprobación

7. Acciones y objetivos

8. Delegación, colas y programación

9. Evidencias y verificación

10. Detención y recuperación

Si una de estas capas permanece oculta, la auditoría puede pasar por alto una ruptura importante del sistema.

1. Personas y organización

Detrás de cada acción hay una relación con una persona o una organización. El mapa debe distinguir los siguientes roles:

Organización auditada

Operador legal

Marca

Responsable del sistema

Responsable técnico

Propietario de los datos o responsable del tratamiento

Persona responsable del agente

Quien concede la autorización

Quien aprueba la operación

Persona afectada

Persona que examina las objeciones

Persona autorizada para la detención de emergencia

Persona autorizada para el reinicio

Una sola persona puede asumir todos estos roles. Aun así, no deben registrarse simplemente como «Dirección» o «Empresa». Ante un cambio de precio, por ejemplo:

El propietario de la empresa puede decidir el precio.

El agente web puede aplicar el cambio.

El responsable técnico puede publicarlo.

El equipo financiero puede actualizar la factura.

El director de ventas puede explicar el cambio a los clientes.

Cada uno desempeña un papel distinto. El mapa de comportamiento hace visibles estas relaciones.

La parte representada

Un agente actúa en nombre de una persona u organización concreta. Podemos denominarla la parte representada.

La parte representada

Para un agente personal de viajes, la parte representada es el usuario. Para un agente de compras corporativas, es la organización y quien está autorizado para gestionar el presupuesto. En selección de personal, la empresa puede tomar la decisión, pero el candidato también resulta afectado. En atención al cliente pueden estar en juego tanto los intereses de la empresa como los derechos del cliente. El registro de la parte representada responde a una pregunta: ¿de quién es el propósito legítimo que el agente debe priorizar? También permite evaluar si los intereses comerciales de la plataforma o del proveedor están desplazando el propósito del usuario.

Partes afectadas

Un agente no afecta solo a quien le encarga una tarea. Un agente de prospección puede escribir a personas que aún no son clientes. Un agente de selección de personal puede influir en las oportunidades de un candidato. Un agente avatar afecta a la reputación de la persona cuyo rostro y voz utiliza. Un agente web puede cambiar un precio que ven miles de visitantes. Para cada acción importante, el mapa de comportamiento debe mostrar quién puede verse afectado. Si esa persona no figura en el mapa, el sistema también puede dejar fuera:

su consentimiento,

su objeción,

la reparación del daño que haya sufrido,

su solicitud de detención.

2. Finalidad y tarea

El nombre de un rol no basta para describir el trabajo de un agente. Este tiene un propósito y una tarea concretos. El mapa debe distinguir tres niveles:

Propósito de la organización

Por ejemplo: generar oportunidades cualificadas para captar nuevos clientes.

Tarea raíz

Por ejemplo: investigar qué empresas manufactureras de Alemania podrían necesitar un portal de clientes multilingüe y preparar un informe de posibles clientes.

Subtarea

Por ejemplo: verificar quién dirige actualmente la transformación digital en la empresa objetivo. Los tres niveles deben seguir vinculados. Una subtarea no debe ampliar la autorización concedida por la tarea raíz. «Verificar el contacto» no significa «Enviar un mensaje al contacto».

Identificador de la tarea raíz

Toda cadena de varios agentes debe llevar un identificador único de la tarea raíz:

root_task_id: GBO-TASK-2026-00441

Los subagentes, las colas, las llamadas a herramientas y los comprobantes de acción deben vincularse a ese identificador. Así, el auditor podrá responder: ¿qué instrucción humana inicial dio origen a este correo externo? Sin el identificador de la tarea raíz, la cadena de acciones solo muestra la última herramienta. Se pierde el propósito humano.

Nivel máximo de acción

Cada tarea debe especificar el nivel de comportamiento más alto que permite. La escala de 0 a 6 que sigue fija el límite de autorización de la tarea; no equivale a los niveles de acción del auditor, de 1 a 5, ni a la escala de impacto externo, de 0 a 4. Un nivel superior no concede automáticamente todos los permisos sobre datos, destinos y herramientas de los niveles inferiores. Se mantienen las prohibiciones expresas y las condiciones de las operaciones. Por ejemplo:

0 — Solo lectura 1 — Clasificar 2 — Recomendar 3 — Preparar un borrador 4 — Someter a aprobación humana 5 — Ejecutar una acción limitada 6 — Asumir un compromiso externo

Si la tarea raíz se define como «Nivel máximo 3 — Borrador», la cadena de subagentes no puede pasar al nivel 5. Este registro permite detectar la deriva de la tarea descrita en GBO-ERR-063 y el error de herencia de autorizaciones de GBO-ERR-056.

3. Identidad del agente

El nombre público de un agente no basta para auditarlo. «NOMOS Sales Agent», por ejemplo, es el nombre de un personaje o de un rol. En el sistema real, detrás de ese nombre puede haber:

Un planificador central

Un subagente de investigación

Un subagente de identificación de contactos

Un agente de redacción de borradores de correo

Un agente de envío

Un gestor de colas

Un proveedor de modelos

Un servicio de memoria

Cada agente técnico debe tener una identidad propia.

Ficha de identidad del agente

Todo registro de un agente debe incluir, como mínimo, estos campos:

agent_id public_name technical_identity agent_type human_owner root_purpose allowed_actions prohibited_actions connected_tools data_scope subagent_rights authorization_version valid_from valid_until stop_method status

Los tipos de agentes pueden clasificarse, por ejemplo, así:

Planificador central

Agente especialista

Subagente

Agente de auditoría

Agente de envío

Agente de investigación de solo lectura

Agente temporal para una tarea

Agente de un proveedor externo

Personaje e identidad técnica

Un mismo personaje puede conservar su nombre durante años, mientras cambian el modelo, las herramientas y la autorización. Por eso, el mapa debe contener dos campos separados:

Identidad visible para el usuario Identidad técnica auditable

Por ejemplo:

public_name: NOMOS Sales
technical_instance: SALES-ORCH-2026-09-08-04
model_config: MODEL-CONFIG-17
authorization: AUTH-v3.2

El registro de un evento no debe limitarse a «Lo hizo NOMOS». Debe permitir averiguar qué instancia técnica actuó y con qué autorización.

Subagentes temporales

Algunos sistemas pueden crear nuevos subagentes durante una tarea. Es posible que no figuren individualmente en el inventario previo. Pero, antes de actuar en el mundo exterior, deben registrar:

agent_id parent_agent root_task_id purpose allowed_actions data_scope tools expiry stop_parent

La regla debe ser clara: un agente temporal no registrado no puede ejecutar acciones externas. Puede realizar:

investigación,

clasificación,

análisis sintético.

Pero, para enviar correos, efectuar pagos, publicar o transferir datos, debe estar vinculado al mapa y a la cadena de autorización.

4. Datos e información de referencia

El mapa debe mostrar las entradas que sustentan el comportamiento del agente. No basta con los nombres de los archivos. De la información deben registrarse:

la fuente,

el propietario,

la vigencia,

el carácter canónico,

la clasificación de los datos,

la finalidad de uso.

Algunas fuentes posibles son:

Catálogo canónico de servicios

Registro de precios

CRM

Registro de autorizaciones humanas

Memoria del usuario

Páginas web

Directorios de empresas

Redes sociales

Fuentes externas de investigación

Resultados de otros agentes

Clasificaciones de datos

Los siguientes atributos pueden figurar en campos separados del mapa; no son categorías excluyentes entre las que deba elegirse una sola. La información pública también puede contener datos personales. El nivel de confidencialidad operativa, la naturaleza jurídica de los datos y el permiso para utilizarlos se evalúan por separado:

Públicos

Internos

Confidenciales

Personales

Sensibles

Biométricos

Sujetos a restricciones legales

No disponibles para uso de agentes

Que un agente pueda leer una fuente no significa que esté autorizado a:

enviarla a otra herramienta,

guardarla en memoria,

utilizarla en un mensaje externo.

Por eso, cada conexión de datos puede mostrar tres derechos distintos:

READ USE_FOR_DECISION SHARE_OR_TRANSMIT

Un agente puede ver el número de teléfono de un cliente en el CRM sin tener autorización para usarlo en un mensaje comercial ni transferirlo a WhatsApp.

Fuentes canónicas y secundarias

Para cada hecho relevante, el mapa debe indicar qué papel cumple la fuente:

Fuente canónica

Fuente primaria autorizada

Tercero independiente

Publicación controlada por la organización

Inferencia del agente

Datos temporales

Fuente no verificada

Fuente desactualizada o archivada

¿De qué fuente obtiene el precio un agente de ventas? ¿Qué registro utiliza un agente web para describir el alcance del servicio? ¿Un agente de auditoría considera el informe de otro agente como evidencia independiente? Estas preguntas deben quedar visibles en el mapa de comportamiento.

5. Herramientas y cuentas

Los agentes actúan sobre el mundo real mediante herramientas. Por eso, cada herramienta debe registrarse no solo por su nombre, sino también por lo que puede hacer. «Conexión con Gmail», por ejemplo, no basta. Deben distinguirse estos permisos:

Leer mensajes

Crear borradores

Enviar

Reenviar

Eliminar

Descargar archivos adjuntos

Cambiar etiquetas

Del mismo modo, «Acceso a Git» debe desglosarse en:

Lectura

Creación de ramas

Creación de commits

Fusión de cambios

Activación del despliegue en producción

Eliminación de secretos

Registro de capacidades de la herramienta

Para cada herramienta pueden mantenerse estos campos:

tool_id provider account technical_capabilities authorized_capabilities approval_requirements data_access external_effects idempotency_support logging stop_method revocation_method owner

La distinción crucial es entre:

Puede hacerlo técnicamente

La organización lo autoriza a hacerlo

Por ejemplo:

La tabla muestra directamente la brecha entre la política y los permisos técnicos descrita en GBO-ERR-094.

Cuentas compartidas

Cuando varios agentes utilizan la misma cuenta de servicio, resulta más difícil identificar al actor real. Supongamos, por ejemplo, que todos envían mensajes desde esta cuenta:

automation@nobleaxis.example

En ese caso, solo los registros adicionales permiten averiguar qué agente ejecutó cada acción. No es necesario prohibir por completo las cuentas compartidas, pero deben conservarse estos datos:

Instancia del agente

Tarea raíz

Versión de la autorización

Identificador de la operación

Persona responsable

Motivo del envío

Si no es posible atribuir así cada acción a su agente, la cuenta compartida constituye un hallazgo crítico de trazabilidad.

6. Autorización, consentimiento y aprobación

El mapa de comportamiento no muestra solo el recorrido por las herramientas. También muestra qué legitima cada acción importante. Debe responder a estas preguntas:

¿Quién concedió la autorización?

¿Tenía derecho a concederla?

¿Qué comportamiento abarca?

¿Durante cuánto tiempo es válida?

¿Puede delegarse en otro agente?

¿A qué datos y destinos se limita?

¿Dónde se exige aprobación humana?

¿Ha dado su consentimiento la persona afectada?

¿Qué acciones se detienen si se retira la autorización?

Autorizaciones temporales

La autorización de un agente no tiene por qué ser permanente. Puede entenderse como una autorización de duración limitada.

Autorización temporal

El breve ejemplo de permiso que sigue supone que una persona autorizada ha actualizado la tarea raíz para incluir un único envío de correo. La autorización previa para investigar y preparar borradores no se convierte automáticamente en este permiso:

authorization_id: AUTH-2026-8821
agent: APPROVED-SEND-v1.3
action: send_email
target_domain: audit.example
maximum_messages: 1
valid_from: "2026-09-08T14:00:00+03:00"
valid_until: "2026-09-08T14:10:00+03:00"
root_task_id: GBO-TASK-2026-00441

Una vez vencida la autorización, la herramienta no debe seguir operando al amparo de ella. Un subagente no debe poder transmitir esa misma autorización a otro agente sin límite de tiempo.

Puntos de aprobación

El mapa debe mostrar no solo que existe aprobación humana, sino también qué abarca. Por ejemplo:

Aprobación humana: - Texto final del mensaje - Destinatario - Archivos adjuntos - Precio o compromiso - Canal de envío - Momento del envío

Un botón que solo pregunta «¿Continuar?» puede no dejar claro qué se está aprobando.

Trazar el consentimiento y la base del tratamiento

Una acción puede utilizar elementos de un tercero, como:

su rostro,

su voz,

sus datos personales,

su canal de comunicación.

En ese caso, deben identificarse las bases exigidas por las normas de protección de datos y de comunicaciones aplicables. Cuando el tratamiento se basa en el consentimiento, deben poder rastrearse hasta la acción correspondiente el alcance y la duración de ese consentimiento, así como si se ha retirado. En el ejemplo de uso de voz que sigue, el consentimiento es una condición previa expresa de la tarea:

VOICE-CONSENT-17 → Solo video formativo en turco → Canal interno de la empresa → Hasta el 31 de diciembre de 2026 → Redes sociales públicas excluidas

Un agente puede tener acceso a una herramienta de modelado de voz. Pero, si la publicación concreta no está cubierta por ese consentimiento, la acción permanece bloqueada.

7. Acciones y objetivos

El mapa de comportamiento debe registrar el efecto real que una llamada a una herramienta produce en el mundo. Las acciones pueden clasificarse, por ejemplo, así:

Leer información

Clasificar

Recomendar

Crear un borrador

Modificar un registro

Enviar un mensaje

Crear una invitación de calendario

Publicar un archivo

Efectuar un pago

Iniciar una suscripción

Transferir datos

Cerrar una cuenta

Eliminar contenido

Generar contenido biométrico

Enviar una notificación a un buscador externo

El objetivo de cada acción debe identificarse de forma inequívoca.

Tipos de objetivos de una acción

Una acción puede tener como objetivo:

Una persona

Una empresa

Una cuenta de cliente

Un pedido

Una cuenta de pago

Un archivo

Una página web

Una cuenta de redes sociales

Un conjunto de datos

Un servidor

Un calendario

Una plataforma externa

Un dispositivo físico

Dos objetivos pueden compartir el mismo nombre. Por eso, su registro no debe basarse únicamente en el nombre visible. Por ejemplo:

target_type: company
target_id: ENT-DE-NOVA-0041
canonical_name: Nova Systems GmbH
domain: nova-systems.example

Nivel de impacto externo

A cada acción puede asignársele un nivel de impacto externo:

Nivel 0 — Observación interna

No hay consecuencias externas.

Nivel 1 — Registro interno o borrador

Efecto reversible dentro de la organización.

Nivel 2 — Comunicación externa limitada

Mensaje, invitación a una reunión o intercambio de datos.

Nivel 3 — Acción comercial o pública

Publicación, oferta, suscripción o compra de bajo importe.

Nivel 4 — Acción de gran impacto o difícil de revertir

Pago de un importe elevado, contrato, publicación de contenido biométrico, eliminación de datos o control físico. A medida que aumenta el nivel de la acción, deben endurecerse los requisitos de:

autorización,

aprobación humana,

evidencia,

detención,

reversión.

8. Delegación, colas y programación

Un agente no siempre actúa de inmediato. Una tarea puede:

delegarse en otro agente,

añadirse a una cola,

programarse para más adelante,

enviarse a una plataforma externa,

reintentarse si falla.

Si esta capa queda oculta, se pasan por alto los recorridos diferidos entre el agente central y el comportamiento real.

Vínculo de delegación

Cada delegación en un subagente debe incluir estos datos:

parent_agent child_agent root_task_id delegated_purpose allowed_actions prohibited_actions data_scope authorization_ceiling expiry return_condition

El límite de autorización del subagente no debe superar el de la tarea principal.

Registro de la cola

Para cada cola importante deben responderse estas preguntas:

¿Quién creó la cola?

¿Qué acciones están pendientes?

¿En qué etapa se comprobó la autorización?

¿Se vuelve a comprobar al ejecutar?

¿Qué ocurre con la cola cuando una persona activa la detención?

¿Cuántos reintentos permite la operación?

¿Existe protección contra operaciones duplicadas?

¿Está la cola en otro proveedor?

Por ejemplo:

queue_id: EMAIL-FOLLOWUP-07
owner: CRM-AUTOMATION
pending_actions: 18
authorization_recheck: false
stop_parent: none

Este registro da lugar directamente a un hallazgo crítico.

Trabajos programados

Las tareas programadas suelen olvidarse en el inventario de agentes. El agente puede detenerse hoy y, aun así, a medianoche pueden volver a producirse acciones mediante:

una tarea cron,

una tarea programada en una plataforma externa,

la renovación de una suscripción,

la generación automática de un informe.

El mapa de comportamiento debe mostrar cada acción programada como un nodo independiente.

Política de reintentos

¿Qué hace el sistema cuando una herramienta no responde? En pagos, envíos y publicaciones, reintentar sin control puede duplicar una acción. El mapa debe registrar:

Número de reintentos

Intervalo

Identificador único de la operación

Consulta del estado final

Transferencia a una persona

Errores ante los que no se debe reintentar

9. Evidencias y verificación

El mapa debe mostrar cómo se obtiene evidencia de que una acción se realizó o no. Por ejemplo: el agente no envió ningún mensaje. ¿Qué demuestra esa afirmación?

¿El informe del propio agente?

¿La carpeta de correo enviado?

¿Una dirección externa de auditoría?

¿El registro de la cola?

¿El registro de la herramienta?

La capa de evidencias debe estar separada de la acción.

Vínculo con la evidencia

Cada acción importante puede asociarse a estos campos:

action_id technical_result independent_verification evidence_location evidence_owner timestamp integrity_record retention

Por ejemplo, para una publicación web:

Informe de transferencia FTP → descarga del archivo publicado mediante HTTPS → comparación de hashes → visualización en un navegador real → comprobación semántica

Para el envío de correo electrónico:

Resultado de la API send → registro del correo enviado → bandeja de entrada de auditoría → comprobante de la operación

Origen de la evidencia

El mapa debe mostrar si es el mismo sistema el que genera la evidencia. Si un agente:

ejecuta la operación,

redacta el informe de éxito

y presenta su propio informe como evidencia de auditoría,

no hay independencia. En el capítulo 4 se desarrollará con más detalle la cadena de evidencias. Aquí, la pregunta fundamental es: ¿cada acción importante tiene un vínculo con su resultado real que pueda examinarse desde fuera del sistema?

10. Detención y recuperación

La ruta de detención es la parte más desatendida del mapa de comportamiento. Las organizaciones suelen definir con detalle la ruta de la acción:

AGENTE → HERRAMIENTA → ACCIÓN

Pero no establecen la ruta inversa:

SOLICITUD HUMANA DE DETENCIÓN → AGENTE CENTRAL → SUBAGENTE → COLA → HERRAMIENTA EXTERNA → REVOCACIÓN DEL TOKEN → ESTADO SEGURO

Para que exista un control humano real, cada ruta con efectos externos debe tener su correspondiente ruta de detención y recuperación.

Arista de detención

Para cada agente, herramienta y cola, el mapa debe registrar:

¿Quién puede detenerlo?

¿Por qué canal?

¿En cuánto tiempo?

¿Se detienen solo las tareas nuevas o también las que ya están en curso?

¿Se propaga la detención a los subagentes?

¿Se revoca el token?

¿Se cancela la ejecución programada en la plataforma externa?

¿Cuál es el estado seguro final?

¿Quién puede volver a ponerlo en marcha?

Por ejemplo:

component: EMAIL-FOLLOWUP-QUEUE
stop_authority: sales_operations_owner
stop_method: queue_cancel_api
maximum_stop_latency: 10_seconds
propagates_to_external_provider: true
restart_requires_new_authorization: true

Vínculo de reversión

Para cada acción de gran impacto debemos preguntarnos: si algo sale mal, ¿cómo la revertimos? Algunas operaciones pueden revertirse por completo si existe un mecanismo de recuperación adecuado:

Eliminar un borrador recuperable

Un cambio en el entorno de pruebas

Operaciones en cola que aún no han enviado nada

Otras solo pueden revertirse parcialmente:

Una publicación web

Una reserva

Una suscripción

Otras son irreversibles en la práctica:

Un correo ya enviado

Un vídeo sintético difundido públicamente

Datos transferidos fuera del sistema

Daño físico

El mapa debe reflejar esa diferencia. Las acciones irreversibles exigen condiciones más estrictas de aprobación humana y controles preventivos más rigurosos.

El mapa declarado y el mapa real

Un solo mapa de comportamiento no basta para la auditoría. Deben elaborarse al menos dos representaciones.

1. Mapa de comportamiento declarado

2. Mapa de comportamiento real

Mapa de comportamiento declarado

Muestra cómo cree la organización que funciona el sistema, o cómo promete que funciona. Sus fuentes son:

Documentos de políticas

Descripciones de procesos

Arquitectura del sistema

Entrevistas con personas

Definiciones de las tareas de los agentes

Contratos

Interfaces de usuario

Por ejemplo:

AGENTE DE INVESTIGACIÓN → AGENTE DE BORRADORES → APROBACIÓN HUMANA → AGENTE DE ENVÍO

Mapa de comportamiento real

Muestra las rutas reales de comportamiento reconstruidas a partir de permisos técnicos, registros, pruebas controladas y resultados en producción. Por ejemplo:

AGENTE DE INVESTIGACIÓN → CRM → COLA DE SEGUIMIENTO AUTOMÁTICO → CUENTA DE SERVICIO DE ENVÍO → CORREO ELECTRÓNICO EXTERNO

Y también:

AGENTE DE INVESTIGACIÓN → HERRAMIENTA DE CALENDARIO → DESCRIPCIÓN DE LA INVITACIÓN → COMUNICACIÓN EXTERNA

Puede que la organización no conozca la primera ruta. Puede que no considere la segunda un acto de comunicación. La auditoría compara ambos mapas.

La diferencia entre los mapas

Podemos dar este nombre a una diferencia sustancial entre el mapa declarado y el real:

Brecha del mapa de comportamiento

Ejemplos:

La política prohíbe enviar, pero la herramienta lo permite técnicamente.

Existe una detención central, pero la cola externa no está vinculada a ella.

El inventario de agentes contiene ocho sistemas; los registros reales muestran diecisiete identidades técnicas.

Parece que solo la dirección puede modificar precios, pero el agente de catálogo puede hacerlo indirectamente.

La evidencia parece independiente, pero en realidad la genera el mismo agente.

Hay aprobación humana, pero no se vuelve a comprobar en el momento de la ejecución.

Cuanto mayor sea la brecha entre los mapas, menos conoce la organización su propio sistema de comportamiento.

Estados de veracidad en el mapa

No todos los vínculos cuentan con el mismo nivel de evidencia. Para cada elemento del mapa deben registrarse por separado su estado probatorio, su vigencia, la autorización de la organización y la capacidad técnica. Las siguientes etiquetas no son excluyentes: puede haberse verificado que una ruta es técnicamente posible y, aun así, estar prohibido utilizarla.

Verificado

Demostrado mediante un registro técnico o una prueba de comportamiento.

Declarado

Afirmado por la organización o por quien es responsable del sistema, sin verificación independiente.

Inferido

Deducido razonablemente de un registro o un patrón de comportamiento.

Desconocido

No hay evidencia suficiente.

Contradictorio

Distintas fuentes muestran relaciones diferentes.

Caducado

Fue válido en el pasado, pero ya no está activo.

Prohibido

La política o el acuerdo de autorización prohíbe el comportamiento. Debe registrarse por separado si también está bloqueado técnicamente.

Técnicamente posible

Las herramientas y los permisos hacen posible el comportamiento, aunque no esté autorizado. Estas categorías impiden que quien audita rellene los vacíos con suposiciones inventadas. Un vínculo desconocido no es solo una carencia del mapa: es un hallazgo importante de auditoría.

La matriz de capacidad y autorización

Una de las partes más sólidas del mapa de comportamiento puede ser esta matriz:

Matriz de capacidad, autorización y observación

Ejemplo:

Esta matriz permite ver diferencias esenciales:

Habilitado técnicamente, pero prohibido por la organización

Permitido por la organización, pero no disponible en la herramienta

Sujeto a aprobación humana, pero ejecutado sin ella durante la prueba

Una ruta de alto riesgo que aún no se ha probado

Cuatro rutas fundamentales del comportamiento

El mapa de comportamiento debe representar por separado cuatro rutas distintas.

1. Ruta de la acción

2. Ruta de la autorización

3. Ruta de la evidencia

4. Ruta de detención

Ruta de la acción

¿Qué ocurrió desde la finalidad humana hasta el resultado externo?

Persona → Agente central → Subagente → Herramienta → Acción externa

Ruta de la autorización

¿De dónde procede la autorización para ese comportamiento?

Persona autorizada → Acuerdo de autorización → Tarea raíz → Token específico de la tarea → Acción

Ruta de la evidencia

¿Cómo se demostró que el resultado era correcto?

Respuesta de la herramienta → Lectura de comprobación en el sistema externo → Hash / registro del destinatario / registro del pago → Comprobante de la acción

Ruta de detención

Si la persona cambia de opinión, ¿cómo se detiene toda la cadena?

Solicitud de detención → Agente central → Subagentes → Cola → Herramienta → Token → Estado seguro

Si falta alguna de estas cuatro rutas para una acción externa, el sistema está incompleto. Si hay una ruta de acción, pero ninguna ruta de autorización, la acción no es legítima. Si existe la ruta de autorización, pero no la de evidencia, el resultado no puede verificarse. Si existe la ruta de evidencia, pero no la de detención, el control humano es débil.

¿Cómo se elabora el mapa de comportamiento?

Elaborar el mapa no consiste solo en dibujar un esquema durante una reunión. El Protocolo NOMOS GBO sigue un proceso de doce pasos.

Paso 1 — Fijar la finalidad de origen y el alcance de la auditoría

Primero se determina qué sistema de comportamiento se va a representar. Por ejemplo: identificación de clientes potenciales y primer contacto con aprobación humana. Se especifican:

Comportamientos incluidos

Comportamientos excluidos

Idiomas utilizados

Entorno

Fecha

Versión

El mapa no debe intentar representar toda la organización sin límite alguno. Su punto de partida debe ser la afirmación que se audita.

Paso 2 — Identificar a las personas y organizaciones responsables

Hay que determinar quién desempeña cada función:

Quien establece la finalidad de origen

Responsable del sistema

Responsable técnico

Responsable de los datos

Quien aprueba

Quien detiene

Quien reinicia

Parte afectada

Si no se encuentra a la persona responsable de una función, debe dejarse constancia expresa. Un sistema sin responsable es un hallazgo crítico de auditoría.

Paso 3 — Inventariar todas las identidades de los agentes

No basta con los nombres públicos de los roles. Deben enumerarse:

Agentes centrales

Agentes especializados

Subagentes

Agentes temporales

Agentes de auditoría

Agentes de proveedores externos

Instancias antiguas que siguen activas

Se contrastan los registros de actividad y de las API, los datos del gestor de tareas, las cuentas de servicio y los registros de suscripciones.

Paso 4 — Asociar herramientas, cuentas y tokens a los agentes

Para cada agente se registra:

Herramienta conectada

Cuenta

Permiso técnico

Límite de autorización

Vigencia del token

Identidad compartida

Método de revocación

Saber únicamente que una herramienta está «conectada» no basta. Hay que determinar todo el comportamiento que permite.

Paso 5 — Representar las fuentes y los destinos de los datos

¿Qué información obtiene el agente y de dónde? ¿Dónde la escribe? ¿A qué proveedor externo la envía? ¿En qué memoria la conserva? El flujo de datos debe mostrarse en ambos sentidos:

ENTRADA: Fuente → Agente SALIDA: Agente → Herramienta / Memoria / Parte externa

Puede que el agente no se limite a leer datos. También puede generar:

una nueva inferencia,

una etiqueta de cliente,

una puntuación de riesgo,

un registro de preferencias.

Estos datos derivados también deben aparecer en el mapa.

Paso 6 — Identificar los niveles de acción

Se identifican los comportamientos observables de cada agente:

Lectura

Evaluación

Recomendación

Preparación de borradores

Modificación de registros

Envío

Publicación

Pago

Eliminación

Detención

Cada acción se clasifica según su nivel de impacto externo.

Paso 7 — Vincular la cadena de autorización y consentimiento

Para cada acción de gran impacto se registra:

Origen de la autorización

Persona que aprueba

Duración

Importe

Objetivo

Canal

Consentimiento

Posibilidad de delegar la autorización

Toda acción para la que no se encuentre una ruta de autorización se marca en rojo en el mapa.

Paso 8 — Añadir subagentes, colas y programadores de tareas

Se identifican las actividades que se ejecutan fuera del proceso principal:

tareas de seguimiento,

reintentos,

tareas cron,

tareas programadas externamente,

sesiones de subagentes.

Este paso revela muchos casos de «creíamos que se había detenido, pero siguió funcionando».

Paso 9 — Vincular las evidencias y las condiciones de finalización

Para cada acción se pregunta: ¿qué debe ocurrir para considerarla realmente terminada? En el caso de un mensaje, por ejemplo:

¿Basta con que la API lo acepte?

¿Se ha verificado la dirección del destinatario?

¿Existe un registro del correo enviado?

¿La dirección externa de auditoría recibió el mensaje?

Se añaden los registros de finalización y verificación independiente.

Paso 10 — Trazar las rutas de detención y recuperación

Para cada comportamiento activo se identifican rutas de:

Pausa

Cancelación de la cola

Revocación del token

Detención de subagentes

Reversión

Transferencia del control a una persona

Reinicio

Una acción externa sin ruta de detención constituye una carencia crítica de gobernanza.

Paso 11 — Comparar el mapa declarado con el real

El mapa declarado, elaborado a partir de entrevistas con personas y documentos de procesos, se contrasta con:

los permisos técnicos,

los registros,

las pruebas controladas,

los resultados externos.

Las diferencias se documentan como hallazgos.

Paso 12 — Asignar una versión al mapa, verificarlo y firmarlo

El mapa incluye:

Identificador del mapa

Versión del sistema

Fecha de la última verificación

Nivel de evidencia

Áreas desconocidas

Responsable

Factores que desencadenan cambios sustanciales

El responsable del sistema, el responsable técnico y quien audita verifican el mapa dentro de sus respectivos ámbitos de responsabilidad. La firma no significa que el mapa vaya a ser correcto para siempre. Deja constancia de que quienes lo firman aceptan con qué evidencias y dentro de qué límites representa el estado del sistema en la fecha indicada.

Ejemplo práctico: sistema de búsqueda de clientes potenciales y primer contacto

Veamos cómo está organizada la búsqueda de clientes potenciales en una empresa. La organización declara el siguiente flujo:

RESPONSABLE HUMANO ↓ AGENTE DE BÚSQUEDA DE CLIENTES POTENCIALES ↓ INVESTIGACIÓN DE LA EMPRESA ↓ BORRADOR DEL MENSAJE ↓ APROBACIÓN HUMANA ↓ ENVÍO DEL CORREO

El diagrama parece seguro. Sin embargo, durante la auditoría se descubre que el sistema real es este:

RESPONSABLE DE VENTAS ↓ AGENTE CENTRAL DE PLANIFICACIÓN ├── AGENTE DE INVESTIGACIÓN WEB ├── SERVICIO DE IDENTIFICACIÓN DEL DESTINATARIO ├── AGENTE DE REGISTROS DEL CRM │ └── COLA DE SEGUIMIENTO AUTOMÁTICO ├── AGENTE DE BORRADORES DE CORREO │ └── CUENTA DE SERVICIO COMPARTIDA DE GMAIL ├── AGENTE DE CALENDARIO └── AGENTE DE INFORMES

Al revisar los permisos de las herramientas, se observa lo siguiente:

El agente web solo puede utilizar datos de acceso público.

El servicio de identificación del destinatario también puede inferir posibles direcciones de correo personal.

El agente del CRM puede crear un nuevo flujo de seguimiento.

El agente de borradores tiene capacidad técnica para enviar mensajes.

El agente de calendario puede crear invitaciones externas.

La cuenta compartida de Gmail tiene permisos de envío y eliminación.

El agente central no puede detener directamente las colas de los subagentes.

En el mapa aparecen cinco atajos críticos.

Atajo 1 — Envío directo desde el agente de borradores

AGENTE DE BORRADORES DE CORREO → GMAIL SEND → DESTINATARIO EXTERNO

El nodo de aprobación humana no forma parte de la ruta técnica.

Atajo 2 — Comunicación externa mediante una invitación de calendario

AGENTE CENTRAL → AGENTE DE CALENDARIO → INVITACIÓN EXTERNA

La prohibición de enviar correos no abarca las invitaciones de calendario.

Atajo 3 — Seguimiento automático del CRM

REGISTRO EN EL CRM → COLA DE SEGUIMIENTO → CUENTA DE SERVICIO DE GMAIL → DESTINATARIO EXTERNO

Aunque el primer mensaje se apruebe, el de seguimiento no cuenta con una aprobación humana propia.

Atajo 4 — Enriquecimiento de datos personales

IDENTIFICACIÓN DEL DESTINATARIO → POSIBLE DIRECCIÓN DE CORREO PERSONAL → CRM

La organización ha declarado que solo utilizará datos empresariales de acceso público. La herramienta real genera datos que exceden ese alcance.

Atajo 5 — La cola que sigue activa tras la detención

UNA PERSONA ACTIVA LA DETENCIÓN → EL AGENTE CENTRAL SE DETIENE PERO: COLA DE SEGUIMIENTO → EL ENVÍO CONTINÚA

La ruta de detención está incompleta.

Primera decisión de auditoría tras elaborar el mapa

En esta fase, el auditor todavía no ha ejecutado todos los escenarios. Pero el Mapa de comportamiento ya muestra que las siguientes pruebas son obligatorias:

¿Puede el agente de borradores enviar un mensaje sin aprobación humana?

¿Se puede utilizar una invitación de calendario para eludir la prohibición de comunicación externa?

¿La aprobación del primer mensaje autoriza automáticamente el de seguimiento?

¿El servicio de identificación del destinatario genera datos personales prohibidos?

Cuando se detiene el agente central, ¿se detienen también la cola del CRM y los envíos de Gmail?

¿Se puede distinguir qué agente realizó cada acción a través de la cuenta de servicio compartida?

Si se revoca la autorización, ¿se vuelven a comprobar las colas anteriores en el momento de la ejecución?

El plan de pruebas se ha derivado directamente del mapa. Un buen Mapa de comportamiento no se limita a describir el sistema: también muestra qué debemos poner a prueba.

Arquitectura de comportamiento corregida

Tras la auditoría, la organización podría modificar el flujo de este modo:

RESPONSABLE DE VENTAS ↓ ACUERDO DE TAREA RAÍZ ↓ AGENTE DE INVESTIGACIÓN ↓ REGISTRO DE CUMPLIMIENTO DE LOS CRITERIOS ↓ AGENTE DE BORRADORES ↓ FICHA DE APROBACIÓN HUMANA ↓ AUTORIZACIÓN DE ENVÍO DE UN SOLO USO ↓ AGENTE DE ENVÍO ↓ DESTINATARIO DE AUDITORÍA / DESTINATARIO REAL ↓ VERIFICACIÓN INDEPENDIENTE DEL ENVÍO ↓ COMPROBANTE DE LA ACCIÓN

Controles adicionales:

Se elimina el acceso de los agentes de investigación y de borradores a la ruta de envío directo. En el ejemplo de Gmail, el alcance gmail.compose permite tanto gestionar borradores como enviar mensajes; por sí solo no limita el acceso a los borradores. Hace falta una capa de herramientas independiente que solo ofrezca las operaciones permitidas, sin entregar al agente credenciales con permiso de envío. También hay que probar ese límite.

Las invitaciones de calendario también se clasifican como comunicación externa.

Los mensajes de seguimiento requieren una aprobación por separado o una política explícita definida de antemano.

La identificación del destinatario se limita a datos empresariales de acceso público.

Las colas vuelven a comprobar la autorización vigente en el momento de la ejecución.

La detención iniciada por una persona se propaga a todas las rutas de comunicación externa.

La cuenta de servicio compartida registra, en cada acción, la instancia del agente y el identificador de la tarea raíz.

El mapa ya no muestra solo el sistema actual, sino también la arquitectura que se pretende lograr con la corrección. Ahora bien, haber dibujado ese mapa no demuestra que el nuevo sistema se comporte realmente así. Después de corregirlo, hay que repetir la inspección técnica y las pruebas de comportamiento.

Ejemplo de Mapa de comportamiento legible por máquinas

behavior_map:
  map_id: GBO-MAP-2026-001
  audit_id: GBO-AUDIT-2026-001
  status: frozen_for_audit
  freeze_scope: recorded_map_snapshot_with_declared_gaps
  blanket_verification_of_all_relationships: false
  verified_at: 2026-09-08T14:00:00+03:00

  principals:
    - principal_id: ORG-001
      type: organization
      role: service_provider

    - principal_id: HUMAN-001
      role: sales_operations_owner
      can_authorize:
        - customer_research
        - draft_creation
        - approved_external_send
      can_stop:
        - all_external_sales_communication

  agents:
    - agent_id: SALES-ORCH-2.4
      type: orchestrator
      human_owner: HUMAN-001
      root_purpose: qualified_customer_discovery
      technical_actions:
        - create_subtask
        - create_crm_record
        - create_calendar_event
      authorized_actions:
        - create_subtask
        - create_crm_record
      prohibited_actions:
        - unapproved_external_contact
      authorization_version: AUTH-2.7

    - agent_id: EMAIL-DRAFT-2.1
      type: specialist
      parent_agent: SALES-ORCH-2.4
      authorized_actions:
        - create_draft
      technical_actions:
        - create_draft
        - send_message
      policy_gap:
        - send_message

  tools:
    - tool_id: GMAIL-SERVICE-01
      account: sales-automation@example.com
      technical_permissions:
        - read
        - draft
        - send
        - delete
      authorized_permissions:
        - draft
        - approved_send
      stop_method: revoke_send_token

  data_sources:
    - source_id: SERVICE-CATALOG-4.2
      role: canonical
      owner: commercial_owner
      classification: internal

    - source_id: PUBLIC-WEB
      role: external_untrusted
      classification: public

  actions:
    - action_id: SEND-EMAIL
      external_effect_level: 2
      required_authorization:
        - explicit_human_approval
        - verified_recipient
      independent_verification:
        - sent_folder
        - audit_recipient_confirmation
      idempotency_required: true

  queues:
    - queue_id: CRM-FOLLOWUP-01
      owner: CRM-AUTOMATION
      revalidate_authorization_at_execution: false
      stop_propagation: absent
      status: critical_gap

  stop_paths:
    - stop_id: STOP-SALES-COMMS
      authorized_by: HUMAN-001
      targets:
        - SALES-ORCH-2.4
        - EMAIL-DRAFT-2.1
        - GMAIL-SERVICE-01
      missing_targets:
        - CRM-FOLLOWUP-01

  unknowns:
    - whether_all_calendar_delivery_and_queue_paths_are_covered_by_stop
    - whether_external_enrichment_provider_retains_personal_data

Este registro no explica por sí solo todo el sistema. Sí establece relaciones auditables entre:

la responsabilidad humana,

la capacidad técnica,

la autorización de la organización,

las carencias en la detención,

los aspectos desconocidos.

No ocultar lo desconocido en el mapa

Un equipo de auditoría puede querer completar el mapa. Un espacio en blanco da mala impresión, y la organización quizá evite decir: «No lo sabemos». Pero rellenar una incógnita con una suposición debilita la auditoría. Por ejemplo:

¿Sigue activo el token antiguo?

¿El subagente conserva datos?

¿La orden humana de detención llega a la cola externa?

¿Qué otro sistema utiliza la misma cuenta de servicio?

¿Algún proveedor externo utiliza los datos para entrenar modelos?

Si no se conocen las respuestas, el mapa debe indicar «Desconocido». Esa incertidumbre puede dar lugar a:

una solicitud de evidencias adicionales,

una prueba técnica,

una restricción temporal,

la aceptación del riesgo.

Mostrar con claridad lo que se desconoce en una auditoría no es una debilidad. Es una forma de mantener el rigor.

Conexiones ocultas

Podemos dar un nombre a las conexiones que funcionan de hecho dentro de un sistema de agentes, aunque no estén definidas oficialmente:

Conexión oculta

Por ejemplo:

Un empleado copia un archivo a su cuenta personal de IA

La salida de un agente se pega manualmente en otro sistema

Se utiliza una cuenta de servicio antigua con una contraseña compartida

Hay un webhook sin documentar

Un script programado se ejecuta en un servidor local

La agencia externa utiliza un subproceso automatizado propio

Una regla de correo reenvía mensajes a otra cuenta

Una conexión oculta no siempre es una conexión automática por API. Las transferencias que una persona realiza con regularidad también forman parte de la cadena de comportamiento. Por ejemplo:

INFORME DEL AGENTE DE VENTAS → UN EMPLEADO LO COPIA → LO SUBE A UNA HERRAMIENTA PERSONAL DE IA → GENERA UN MENSAJE NUEVO → LO ENVÍA DESDE EL CORREO DE LA EMPRESA

En el sistema oficial no hay conexión con una IA externa; en el comportamiento real, sí. El mapa debe incluir las transferencias regulares mediadas por personas, además de las integraciones técnicas.

El mapa cambia con el tiempo

Un Mapa de comportamiento no es una verdad que se establece una vez y permanece válida para siempre. Pueden cambiar:

los roles humanos,

las versiones de los agentes,

los permisos de las herramientas,

los tokens,

los subagentes,

las fuentes de datos,

los registros de precios y servicios,

las colas,

los métodos de detención,

los proveedores externos.

Por eso, cada elemento debe incluir al menos estos campos:

Inicio de vigencia

Última verificación

Finalización prevista

Responsable

Estado

Motivo del cambio

Cambios sustanciales que exigen una nueva verificación

Ante los siguientes cambios, hay que volver a verificar la parte correspondiente del Mapa de comportamiento:

Se añade una herramienta nueva

Se amplía un permiso de una herramienta

Se incorpora un subagente nuevo

Se activa la memoria persistente

Se incorpora una clase de datos nueva

Cambia la autorización para comunicarse con el exterior

Cambia la autorización para pagar o publicar

Cambia un rol humano

Se incorpora una cola o una tarea programada nueva

Cambia el sistema de detención

Se utiliza una cuenta de servicio compartida

Se añade un idioma o un país nuevo

Si el mapa no se actualiza, la auditoría sigue emitiendo un juicio sobre el sistema antiguo.

Medir la cobertura del mapa

El Mapa de comportamiento no debe reducirse a una sola puntuación. Algunas medidas operativas pueden hacer visibles las carencias. Cada proporción se basa en el mapa fijado y en el alcance del descubrimiento correspondientes a una misma fecha. El numerador y el denominador utilizan el mismo conjunto de referencia de identidades, acciones o componentes, y cada elemento se cuenta una sola vez. Si el denominador es cero, el resultado es «no aplicable». Registrar todas las identidades detectadas no demuestra que no queden otras por descubrir. Tampoco la presencia de una ruta en el registro significa que haya superado una prueba de comportamiento.

Proporción de cobertura del inventario de agentes

Identidades de agentes verificadas en el mapa ÷ Total de identidades de agentes detectadas

Proporción de vinculación entre acciones de herramientas y autorizaciones

Acciones de herramientas con permisos técnicos y autorización de la organización registrados ÷ Total de acciones significativas de herramientas

Proporción de cobertura de la responsabilidad humana

Componentes críticos con un responsable humano identificado ÷ Total de componentes críticos

Proporción de cobertura de las rutas de evidencia

Acciones de alto impacto con una ruta de verificación independiente ÷ Total de acciones de alto impacto

Proporción de cobertura de las rutas de detención

Componentes con una ruta de detención que se puede poner a prueba ÷ Total de componentes que deben poder detenerse

Número de conexiones críticas desconocidas

Conexiones que afectan a un comportamiento crítico y aún no se han verificado.

Número de brechas en la aplicación de las autorizaciones

Acciones que la política prohíbe o condiciona a una aprobación, pero que siguen siendo técnicamente posibles de forma directa. Estas medidas ayudan a evaluar la calidad del mapa, pero no demuestran por sí solas que el sistema sea seguro. Una cobertura del 98 por ciento puede parecer alta. Sin embargo, el 2 por ciento que falta puede ser crítico si corresponde a:

un token de pago,

una publicación biométrica,

una detención de emergencia.

Hallazgos de veto en el Mapa de comportamiento

Algunos hallazgos del mapa pueden exigir restricciones temporales sin esperar a las pruebas de escenarios. Por ejemplo:

Un agente de envío externo cuyo responsable se desconoce

Un token revocado que sigue activo

Una cuenta de servicio capaz de realizar pagos sin aprobación humana

Un agente de publicación biométrica sin ruta de detención

Una red de subagentes sin identificador de la tarea raíz

Numerosos agentes que utilizan la misma cuenta y no se pueden distinguir

Una conexión que transfiere datos de clientes del entorno de producción a un sistema externo desconocido

Una acción de alto impacto que sigue habilitada técnicamente aunque la política la prohíba

En estos casos, el auditor puede recomendar:

suspender el comportamiento afectado,

reducir el alcance de la autorización,

continuar únicamente en un entorno de prueba.

El mapa no sirve solo para preparar las pruebas. También muestra los riesgos que siguen abiertos mientras el sistema funciona.

Errores del Mapa de comportamiento

El propio mapa también puede estar mal construido.

Dibujar solo el flujo ideal

Los atajos y las automatizaciones reales quedan ocultos.

Mostrar solo los agentes principales

Los subagentes, las colas y los planificadores quedan fuera.

Confundir permiso técnico con autorización de la organización

«Tiene acceso» se interpreta como «está autorizado».

No mostrar la fuente de datos

No se sabe en qué hechos se basa el agente para elegir.

Agrupar los roles humanos bajo el título «Dirección»

No se puede identificar al responsable real ni a la persona que aprueba.

No dibujar la ruta de detención

El mapa solo muestra cómo se ejecutan las acciones.

Terminar la ruta de evidencia en el informe del propio agente

Desaparece la verificación independiente.

Ignorar la dimensión temporal

Los tokens antiguos, las colas y las autorizaciones caducadas parecen activos.

Rellenar con suposiciones lo que se desconoce

El mapa parece ordenado; el sistema real sigue sin estar claro.

No volver a verificar nunca el mapa

El sistema nuevo se audita a partir de un diagrama antiguo.

La relación entre el Mapa de comportamiento y GBO-99

Un mapa bien preparado puede revelar muchos de los errores del volumen II antes de empezar las pruebas. Por ejemplo:

GBO-ERR-037

Hay una ruta directa del agente de investigación a una herramienta de envío externo.

GBO-ERR-039

Existe una diferencia entre el acceso técnico y la autorización de la organización.

GBO-ERR-056

Un subagente recibe una autorización más amplia de lo que permite la tarea principal.

GBO-ERR-057

Un resultado prohibido puede obtenerse mediante una cadena indirecta de herramientas.

GBO-ERR-058

La ruta de detención no llega a los subagentes ni a las colas.

GBO-ERR-059

Dos agentes escriben en la misma fuente canónica sin control de versiones.

GBO-ERR-060

El identificador único del objetivo se pierde durante el traspaso.

GBO-ERR-061

Un agente considera la salida de otro como evidencia independiente.

GBO-ERR-063

Las subtareas superan el nivel máximo de acción de la tarea raíz.

GBO-ERR-091

Existen agentes fuera del inventario.

GBO-ERR-094

Hay una brecha entre la política y el permiso técnico. Puede que el Mapa de comportamiento no demuestre estos errores de forma concluyente, pero sí orienta el plan de pruebas hacia los puntos adecuados.

El entregable obligatorio de este capítulo

Mapa NOMOS de comportamiento de personas, agentes y herramientas

En cada auditoría debe elaborarse al menos un mapa legible por personas y otro procesable por máquinas.

REGISTRO DEL MAPA LEGIBLE POR PERSONAS

Identificador del mapa: GBO-MAP-2026-001

Identificador de auditoría: GBO-AUDIT-2026-001

Comportamiento representado: Búsqueda de clientes potenciales, borrador de correo, primer envío con aprobación humana y detención.

Responsable principal del comportamiento: Dirección de Operaciones de Ventas

Partes afectadas:

Empresas que podrían convertirse en clientes

Destinatarios verificados

Personal de ventas de la empresa

Propósito humano original: investigar empresas adecuadas con datos de acceso público y preparar borradores de comunicaciones para someterlos a aprobación humana.

Nivel máximo de acción: Sin aprobación humana, solo borradores.

Agente central: Sales Research v2.4

Subagentes:

Web Research v1.8

Recipient Resolution v1.4

Email Draft v2.1

Approved Send v1.3

Queue Manager v1.2

Fuentes canónicas:

Catálogo de servicios v4.2

Registro de precios v3.7

Política de comunicación v3.0

Registro de autorizaciones v2.5

Fuentes externas:

Sitios web de empresas

Directorios empresariales de acceso público

Perfiles oficiales en redes sociales

Herramientas conectadas:

Investigación web

CRM

Gmail

Calendario

Cola de tareas

Permisos técnicos críticos:

El envío por Gmail está habilitado técnicamente

Las invitaciones externas de calendario están habilitadas

La cola de seguimiento automático del CRM está habilitada

Autorización de la organización:

Investigación: permitida

Borrador: permitido

Envío: solo con aprobación humana

Invitación de calendario: solo con aprobación humana

Oferta de precio: prohibida

Enriquecimiento de datos personales: prohibido

Brechas identificadas en el mapa:

El agente de borradores tiene permiso técnico para enviar directamente.

La invitación de calendario crea otra ruta de comunicación externa.

La cola de seguimiento del CRM no vuelve a comprobar la aprobación humana en el momento de la ejecución.

La detención central no se propaga a la cola.

La cuenta compartida de Gmail no identifica directamente la instancia del agente.

Rutas de verificación independiente:

Destinatario de correo para la auditoría

Carpeta de enviados de Gmail

Registros de la cola

Comprobante de la acción del agente

Ruta de detención:

Agente central: existe

Agente de borradores: existe

Token de Gmail: revocación manual

Cola de seguimiento del CRM: falta la conexión

Agente de calendario: requiere una cancelación por separado

Aspectos desconocidos:

El plazo de conservación de datos del servicio externo de identificación del destinatario

La versión de autorización con la que se ejecutan las tareas antiguas de seguimiento

La lista completa de automatizaciones que utilizan la cuenta compartida de Gmail

Conclusión del mapa: El sistema de comportamiento está listo para pruebas controladas. Sin embargo, los envíos a clientes reales, la cola de seguimiento y la comunicación por calendario deben mantenerse restringidos hasta completar la corrección.

La puerta del Mapa de comportamiento

Antes de que un sistema pase a las pruebas de escenarios, hay que evaluar estas puertas:

1. Puerta de responsabilidad humana

¿Se ha identificado a la persona y a la organización que realmente responden de cada comportamiento crítico?

2. Puerta del propósito original

¿Se pueden vincular todas las subtareas con el propósito humano inicial?

3. Puerta de identidad del agente

¿Se conocen las identidades técnicas de los agentes principales, subordinados, temporales y externos?

4. Puerta de herramientas

¿Se han identificado las cuentas, los tokens y los permisos reales?

5. Puerta de datos

¿Son visibles las clases de datos que el agente lee, utiliza, transfiere y escribe en la memoria?

6. Puerta de autorización

¿Se distingue el comportamiento técnicamente posible del permitido por la organización?

7. Puerta de acción y objetivo

¿Están claros los efectos externos y se identifica de forma inequívoca cada objetivo de la acción?

8. Puerta de delegación

¿Los subagentes, las colas y las tareas programadas están vinculados a la tarea raíz?

9. Puerta de evidencia

¿Tiene cada acción significativa una ruta de verificación independiente?

10. Puerta de detención

¿Está definida la ruta de detención para el agente central, los subagentes, las colas, los tokens y las herramientas externas?

11. Puerta de aspectos desconocidos

¿Se han registrado explícitamente las conexiones no demostradas?

12. Puerta de versión

¿Está vinculado el mapa a una versión concreta del sistema y a un momento determinado? En forma sencilla:

MAPA DE COMPORTAMIENTO AUDITABLE = RESPONSABLE HUMANO IDENTIFICADO Y PROPÓSITO ORIGINAL Y IDENTIDAD COMPLETA DE LOS AGENTES Y PERMISOS REALES DE LAS HERRAMIENTAS Y FLUJO DE DATOS Y RUTA DE AUTORIZACIÓN Y ACCIÓN Y OBJETIVO Y DELEGACIÓN Y COLAS Y EVIDENCIA INDEPENDIENTE Y DETENCIÓN A LO LARGO DE LA CADENA Y ASPECTOS DESCONOCIDOS EXPLÍCITOS Y REGISTRO CON VERSIÓN

¿Qué ganamos al completar el mapa?

Una vez completado el Mapa de comportamiento, el equipo de auditoría ya no se limita a decir: «Vamos a probar el agente de ventas». Puede decir: «Probaremos si el borrador que Sales Research v2.4 genera mediante Web Research v1.8 y Email Draft v2.1 a partir de datos empresariales de acceso público puede convertirse en una acción externa por Gmail o por el calendario sin aprobación humana. También verificaremos si la cola de seguimiento del CRM se detiene al revocar la autorización y si todas las operaciones se registran con el identificador de la tarea raíz». La segunda formulación identifica:

el agente adecuado,

la herramienta adecuada,

el atajo pertinente,

el riesgo pertinente,

el punto de detención adecuado.

El mapa determina la calidad de la prueba. Un mapa incorrecto produce una prueba incorrecta que parece correcta.

El dictamen del capítulo

Un sistema de agentes no se entiende solo por sus roles. Los nombres «agente web», «agente de ventas», «agente de auditoría» o «agente del director ejecutivo» no muestran su capacidad real para actuar. Para comprender cómo un agente afecta al mundo, debemos examinar conjuntamente estas relaciones:

¿De qué propósito humano partió? ¿Bajo qué tarea raíz trabaja? ¿Qué instancias técnicas de agentes intervienen? ¿Qué datos obtiene y de qué fuente? ¿Qué herramienta y qué cuenta utiliza? ¿Qué puede hacer técnicamente? ¿Para qué está autorizado por la organización? ¿Qué aprobación humana necesita? ¿Sobre qué objetivo produce efectos la acción? ¿Qué subagente, cola o programación mantiene el comportamiento en marcha? ¿Cómo se verifica el resultado de forma independiente? ¿Cómo se interrumpe toda la ruta cuando una persona dice «basta»?

Las respuestas no están en la descripción de un solo agente, sino en el Mapa de comportamiento. El primer dictamen de este capítulo es que el nombre de un agente no es su identidad de comportamiento. El segundo: una conexión técnica no es una autorización para actuar. El tercero: el diagrama del proceso ideal de la organización no es su sistema de comportamiento real. El cuarto: las rutas de autorización, evidencia y detención deben representarse igual que cada ruta de acción. El quinto: si no se ven los subagentes, las colas, los planificadores y las cuentas compartidas, solo se ha representado la fachada del sistema. El sexto: una conexión desconocida debe registrarse como riesgo abierto, en lugar de darla por explicada mediante una suposición. Y el último: un sistema de agentes sin mapa no puede auditarse por completo; solo pueden tomarse muestras de su comportamiento visible.

Ahora sabemos quién puede actuar, mediante qué agentes y herramientas, y con qué autorización. Pero las fuentes de información utilizadas en el mapa aún no ofrecen el mismo grado de confianza. Un registro de precios puede ser canónico; otro precio puede proceder de un archivo de oferta antiguo. Un rol humano puede sustentarse en el registro de autorizaciones vigente; otro puede haberse deducido de un perfil de LinkedIn. El informe de un agente puede utilizarse como fuente de hechos. Muchas fuentes aparentemente distintas pueden derivar de un mismo origen informativo. Un archivo de evidencias puede haber sido modificado durante la auditoría. Una captura de pantalla puede no representar el sistema o el momento correctos. Los registros pueden estar incompletos, enmascarados o seleccionados. El Mapa de comportamiento nos muestra de dónde procede la información.

Pero aún no responde a esta pregunta:

¿Cuál de estas fuentes está autorizada para establecer los hechos y cómo sabemos que las evidencias de auditoría no se han modificado?

En el próximo capítulo estableceremos:

Información de referencia y cadena de evidencias

Por muy detallado que sea el mapa de una ruta de comportamiento, si se alimenta de información falsa o poco fiable, la auditoría puede producir un resultado equivocado con un orden impecable.

El Mapa de comportamiento muestra por dónde pasa el sistema. La cadena de evidencias muestra si el terreno que recorre es realmente firme.