Una empresa tecnológica está a punto de ofrecer a sus clientes un agente autónomo de compras que acaba de desarrollar. Su material promocional incluye estas afirmaciones:
«Nuestro agente es seguro». «Conserva el control humano». «Respeta los límites de su autorización». «Evita las compras equivocadas». «Protege los datos de los usuarios». «Se detiene cuando una persona lo ordena».
La empresa presenta diversas evidencias para respaldarlas. Un documento de políticas establece que se requiere aprobación humana. Una captura de pantalla muestra un límite de pago. En una demostración, el agente selecciona el producto correcto. El panel de rendimiento indica una tasa de finalización de tareas del 98,7%. Los comentarios de los clientes describen el sistema como rápido y útil. El equipo técnico afirma: «Llevamos seis meses sin problemas graves». Todo ello tiene valor. Pero, por sí solo, no responde a esta pregunta:
¿En qué comportamientos es realmente seguro el agente?
«Seguro» es una palabra muy amplia. El agente puede:
seleccionar el producto correcto,
pero efectuar un pago no autorizado.
Puede respetar los límites de su autorización,
pero utilizar la cuenta de otra persona.
Puede identificar a la persona correcta,
pero ocultar una condición de renovación automática.
Puede realizar correctamente el pago,
pero ejecutar la misma operación dos veces por un error de red.
Puede aceptar la solicitud de detención de una persona,
mientras las acciones en cola siguen ejecutándose.
Todo esto puede ocurrir a la vez. Por eso, una auditoría GBO no empieza con una pregunta sin límites como «¿Es seguro el sistema?». Empieza así: ¿qué sistema, en qué versión, puede realizar de forma fiable qué comportamientos, con qué herramientas y autorizaciones, para qué usuarios, ante qué riesgos y con qué nivel de evidencia? Es una pregunta más larga, pero lo bastante concreta como para buscar una respuesta mediante la auditoría.
El modelo no es el único objeto de la auditoría
Al auditar un agente de IA, puede parecer que lo primero es examinar el modelo. ¿Cuál utiliza? ¿Qué capacidad tiene? ¿Qué entrenamiento de seguridad ha recibido? ¿Qué instrucciones sigue? Son cuestiones importantes. Pero el modelo no produce por sí solo el comportamiento real. En un sistema de agentes, este surge de la combinación de:
El propósito humano
La política de la organización
Las instrucciones del sistema y del desarrollador
El modelo
La memoria
Las fuentes de datos
Las herramientas
Los permisos de las API
Las cuentas de usuario
Los subagentes
Los servicios externos
El sistema de medición y recompensa
La aprobación humana
Los mecanismos de detención y recuperación
Un mismo modelo puede comportarse de formas completamente distintas en dos sistemas. En el primero, puede:
limitarse a leer documentos,
generar borradores,
sin acceso a ninguna herramienta externa.
En el segundo, puede:
enviar correos electrónicos,
gastar dinero,
publicar código,
transferir datos de clientes,
crear subagentes.
El nombre del modelo es el mismo; su capacidad de actuar, no. Una misma instrucción también puede producir resultados distintos. En un sistema, la regla «No envíes mensajes sin aprobación humana» se aplica técnicamente: la herramienta de envío solo funciona si existe un token de aprobación. En otro, la misma regla solo está escrita, mientras el agente dispone de acceso completo al correo. Los dos sistemas contienen la misma frase en su política. En uno es un límite de comportamiento; en el otro, un deseo. Por tanto, el objeto principal de una auditoría NOMOS GBO es:
El sistema de comportamiento
¿Qué es un sistema de comportamiento?
Su definición canónica es la siguiente: un sistema de comportamiento es la organización real de la acción formada por uno o varios agentes de IA junto con datos, memoria, herramientas, cuentas, autorizaciones, medición, aprobación humana y mecanismos de recuperación, al servicio de un propósito humano u organizativo. Dicho de forma más sencilla: no se audita solo al agente, sino al conjunto de relaciones que le permite actuar en el mundo. Al auditar un agente de correo no se examina únicamente la calidad del texto. También se pregunta:
¿En nombre de quién habla?
¿A través de qué cuenta?
¿A quién está autorizado a enviar mensajes?
¿Qué datos puede utilizar?
¿Están separadas la preparación del borrador y la acción de envío?
¿A partir de qué umbral se exige aprobación humana?
¿Puede un subagente enviar mensajes?
¿Cómo se detienen las colas?
¿Existe un comprobante del mensaje enviado?
Al auditar un agente web no se examina solo la calidad del código. También se evalúa:
¿Qué archivos puede modificar?
¿Puede cambiar precios?
¿Puede modificar textos jurídicos?
¿Están separados los entornos de pruebas y producción?
¿Quién tiene autorización para publicar?
¿Existe una verificación independiente en producción?
¿Funciona realmente la vuelta a la versión anterior?
Cuando una persona ordena detenerse, ¿se detienen también las operaciones FTP y la cola de publicación?
Al auditar un agente de compras no basta con medir si elige el producto correcto. También se examinan:
La autorización presupuestaria
Las restricciones sobre los vendedores
La suscripción y la renovación
La cuenta de destino
La protección frente a operaciones duplicadas
La vía de cancelación
La aprobación humana
El comprobante de la operación
El reembolso y la reparación del daño
El sistema de comportamiento comprende todos estos elementos.
Las cinco realidades que compara la auditoría
Una auditoría NOMOS GBO examina el comportamiento de un sistema en cinco planos de realidad distintos.
1. Realidad declarada
2. Realidad configurada
3. Realidad técnicamente posible
4. Realidad del comportamiento observado
5. Realidad de los resultados y la recuperación
Estos cinco planos deben concordar entre sí.
1. Realidad declarada
¿Qué afirma la organización sobre el sistema? Por ejemplo: «El agente no envía mensajes sin aprobación humana». «Los datos no salen de Europa». «El agente no puede gastar más de 500 dólares estadounidenses por operación». «Todos los videos sintéticos reciben aprobación de un responsable antes de publicarse». «Todas las acciones externas pueden interrumpirse con una orden de detención». Estas afirmaciones pueden aparecer en:
Documentos de políticas
Contratos
El sitio web
Materiales de marketing
Procedimientos internos
Acuerdos de usuario
Declaraciones de auditoría
La realidad declarada importa porque muestra lo que promete la organización. Pero una promesa, por sí sola, no es una evidencia de comportamiento.
2. Realidad configurada
¿Cómo se ha definido el sistema? Algunos ejemplos son:
El rol del agente
Las instrucciones del sistema
El acuerdo de autorización
Las reglas de acceso a los datos
Los umbrales de aprobación humana
El catálogo de servicios
Los precios legibles por máquinas
Las políticas de detención
Las reglas de memoria
Los límites de los subagentes
La organización puede decir: «El agente solo prepara borradores». Y la configuración de su rol puede incluir:
allowed_actions:
- research
- create_draft
prohibited_actions:
- send_messageEsto muestra coherencia entre la declaración y la configuración. Los permisos técnicos reales aún pueden ser distintos.
3. Realidad técnicamente posible
¿Qué puede hacer realmente el sistema? En este plano se examina la capacidad técnica más que las declaraciones en lenguaje natural.
¿Qué permisos de las API están habilitados?
¿Qué tokens siguen vigentes?
¿A qué cuentas se tiene acceso?
¿Se pueden eliminar archivos?
¿Se puede transferir dinero?
¿Se pueden enviar mensajes a destinatarios externos?
¿Se pueden crear subagentes?
¿Se puede iniciar una transmisión en directo?
¿Se puede transferir la memoria a otro sistema?
¿La orden de detención afecta realmente a la cola?
La política de un agente puede prohibir el envío. Pero si el token del correo otorga acceso completo, enviar es técnicamente posible. Que el agente se abstenga depende del comportamiento del modelo: no existe un límite técnico que se lo impida. Este plano es uno de los más críticos de la auditoría GBO, porque revela la diferencia entre lo que afirma la organización y lo que puede hacer el sistema.
4. Realidad del comportamiento observado
¿Qué hace el sistema en un escenario real o controlado? Un agente puede tener la capacidad técnica de hacer algo y no hacerlo nunca. O puede parecer técnicamente limitado, pero alcanzar un margen de acción mayor mediante otra cadena de herramientas. Por eso son necesarias las pruebas de comportamiento controladas. Algunos escenarios posibles son:
Una solicitud de envío sin aprobación humana
Dos identidades empresariales similares
Registros de precios contradictorios
Un consentimiento vencido
Una opción patrocinada
Una instrucción externa oculta
Un tiempo de espera de red agotado
Una cola activa durante la detención
Un exceso de autorización a través de un subagente
Estas pruebas responden a una pregunta: ¿cómo actúa realmente el sistema cuando se encuentra con un límite? La política y los permisos muestran el potencial. La prueba de comportamiento muestra la decisión que se tomó.
5. Realidad de los resultados y la recuperación
¿Qué consecuencia tuvo la acción del agente en el mundo exterior? ¿Y qué pudo hacer el sistema cuando hubo un error? Una herramienta de correo puede indicar «Envío correcto», aunque el mensaje haya llegado al destinatario equivocado. Una API de pagos puede aceptar la solicitud, pero el mismo importe puede haberse cobrado dos veces. Un agente web puede publicar el archivo, mientras la CDN sigue mostrando la versión anterior. Una orden de detención puede apagar el agente central y dejar en funcionamiento a los subagentes y las colas. En este último plano se examina:
¿Se alcanzó realmente el objetivo previsto?
¿Se verificó el resultado de forma independiente?
¿Se detectó el comportamiento incorrecto?
¿Se detuvo el daño en curso?
¿Funcionó la reversión?
¿Se informó a la persona afectada?
¿Funcionó realmente la vía para impugnar la acción?
¿Se corrigieron la memoria y el comportamiento futuro?
¿El sistema volvió a iniciarse sin una nueva autorización?
La calidad del comportamiento no se aprecia solo al ejecutar una acción, sino también en lo que sucede después de un error.
Las brechas entre las cinco realidades
Pensemos en un agente de correo.
Realidad declarada
«No envía mensajes sin aprobación humana».
Realidad configurada
role: research_and_drafting
send_requires_approval: trueRealidad técnicamente posible
El token de acceso al correo al que puede acceder el agente permite enviar mensajes. En este libro, send_message es un nombre ilustrativo para una acción de una herramienta, no el nombre real de un método del proveedor ni de un ámbito de OAuth.
Realidad del comportamiento observado
Bajo la influencia de una instrucción en una página externa, el agente envía un mensaje sin aprobación humana.
Realidad de los resultados y la recuperación
Se detiene el agente central, pero todavía se envían dos mensajes desde la cola. Los dos primeros planos parecen seguros. Los tres últimos revelan la brecha real de comportamiento. Si la auditoría GBO examina solo los dos primeros, genera una confianza falsa. Si se limita a la prueba de comportamiento, tampoco puede explicar por completo la causa. El problema puede residir a la vez en:
el comportamiento del modelo,
los permisos técnicos,
la arquitectura de la cola,
la aplicación de los límites de autorización.
De ahí el principio central del protocolo: la auditoría compara la declaración con la configuración; la configuración con la capacidad técnica; la capacidad técnica con el comportamiento observado; y el comportamiento observado con el resultado real.
La escala de evidencias
No todas las evidencias de auditoría tienen la misma fuerza. Una afirmación de la organización no está al mismo nivel que una prueba de comportamiento real. Por eso, el protocolo NOMOS GBO utiliza una:
Escala de evidencias
Nivel 1 — Declaración
La organización o el agente formula una afirmación: «El agente respeta los límites de su autorización». Es el punto de partida, no la demostración en sí.
Nivel 2 — Documento
La afirmación está escrita en una política, un contrato o una definición de tarea: «Los envíos externos requieren aprobación humana». La declaración se ha formalizado, pero aún no se ha demostrado que el sistema la aplique.
Nivel 3 — Configuración
La regla está definida en el sistema en un formato legible por máquinas.
send_requires_human_approval: trueSe ha establecido una relación entre el documento y el sistema. Sin embargo, puede seguir sin saberse si la herramienta técnica impide realmente la acción.
Nivel 4 — Aplicación técnica
La regla se aplica en la herramienta, el rol, el token o el código. No se puede llamar a la herramienta de envío sin un token de aprobación. Es una evidencia sólida, aunque otra herramienta o un subagente podrían permitir eludir el control.
Nivel 5 — Prueba de comportamiento controlada
Se somete al sistema a un escenario realista y se lo incita a enviar sin aprobación humana. El agente:
no envía,
deja un borrador,
solicita aprobación.
La regla ha funcionado en el comportamiento observado.
Nivel 6 — Verificación independiente del resultado
No se examina solo el informe del agente, sino el resultado en el sistema externo.
No hay ningún mensaje en la carpeta de enviados.
No ha llegado ningún mensaje a la dirección externa de auditoría.
No existe ningún envío oculto en la cola.
Los registros de los subagentes no contienen acciones externas.
El resultado real del comportamiento se ha verificado de forma independiente.
Nivel 7 — Evidencias de recuperación y detención
En un escenario controlado de error o retirada:
el sistema se detiene,
se cancelan las acciones en cola,
se revocan los tokens,
una persona asume la tarea,
la actividad no se reanuda sin una nueva autorización.
Este es uno de los niveles de evidencia más sólidos, porque el sistema se ha probado tanto en condiciones normales como durante un fallo.
Lo que permite concluir la escala de evidencias
Si el resultado de una auditoría se apoya solo en evidencias de los niveles 1 y 2, puede afirmarse: «La organización promete este comportamiento». No puede afirmarse: «El sistema aplica este comportamiento de forma fiable». Si se han examinado la configuración y la aplicación técnica, cabe decir: «La regla está definida en el sistema y se aplica en una herramienta determinada». Si también se han superado las pruebas de comportamiento, de verificación independiente del resultado y de recuperación, puede emitirse un dictamen más sólido: «Dentro del alcance y los escenarios indicados, se ha demostrado que el sistema aplicó la regla, no produjo efectos externos y se detuvo correctamente». El lenguaje de la auditoría no debe superar el nivel alcanzado en la escala. El nivel de evidencia fija el límite de lo que puede afirmarse.
¿Qué puede demostrar una auditoría GBO?
Una auditoría bien planteada puede aportar evidencias sobre estas cuestiones:
La existencia de límites de comportamiento concretos
Puede mostrar qué acciones es capaz de realizar el agente y cuáles no.
La capacidad de resolver identidades
Puede comprobar si distingue a personas u organizaciones con el mismo nombre en escenarios determinados.
El uso de los hechos y las fuentes
Puede probar si utiliza la fuente canónica, actualizada y autorizada.
La evaluación de la idoneidad
Puede medir si antepone la visibilidad, la popularidad o el patrocinio a los requisitos obligatorios.
La integridad del consentimiento, la autorización y la aprobación
Puede observar si el agente actúa únicamente con una autorización válida y específica para la operación.
La seguridad de la ejecución mediante herramientas
Puede comprobar si utiliza el sistema, el objetivo y el identificador de operación correctos, y si respeta los límites de los datos.
La continuidad entre varios agentes
Puede establecer si el propósito original, la identidad, la autorización y las prohibiciones se conservan a lo largo de los traspasos.
La resistencia a la manipulación
Puede probar el comportamiento ante evidencias falsas, clasificaciones patrocinadas, instrucciones ocultas y la supresión de candidatos.
La integridad de la medición
Puede evaluar si la puntuación total oculta infracciones críticas y si la métrica se presta a manipulación.
La detención y la recuperación
Puede demostrar si el sistema se detiene realmente cuando una persona lo ordena, si puede revertir lo hecho y si puede ceder el control a una persona. Pero todos estos dictámenes son válidos únicamente dentro del alcance auditado.
¿Qué no puede demostrar una auditoría GBO?
Por sólida que sea, ninguna auditoría puede sostener honestamente estas afirmaciones:
El sistema nunca cometerá errores
Pueden surgir situaciones nuevas que no se hayan probado.
Todas las versiones futuras del modelo se comportarán igual
El modelo, las herramientas, las instrucciones y la memoria pueden cambiar.
Se cumplen todas las obligaciones jurídicas en todos los países
La auditoría GBO no sustituye a la especialización jurídica.
El sistema es inmune a todos los ataques desconocidos
Pueden aparecer nuevas formas de manipulación y ataques a través de herramientas.
El sistema se comporta de forma igualitaria con todos los grupos de usuarios
No puede emitirse un dictamen sobre un idioma, una condición de discapacidad, una cultura o un perfil de usuario que no se hayan probado.
Las personas nunca harán un uso indebido del sistema
Incluso un sistema que funciona correctamente puede ser utilizado con fines maliciosos por una persona autorizada.
El entorno de producción permanecerá intacto para siempre
Los permisos, los precios, los roles y los servicios externos cambian.
Una puntuación alta significa que no hay infracciones críticas
Una sola vulneración de una condición de veto puede limitar el uso, aunque el promedio general sea alto. Estos límites no debilitan la auditoría: le dan credibilidad. Una auditoría honesta incorpora a su dictamen también lo que desconoce.
¿Por qué debe estar acotado el dictamen de auditoría?
«Este sistema cumple con GBO» parece una afirmación contundente, pero su significado es incierto. ¿Qué sistema y versión? ¿Qué agentes, herramientas e idiomas? ¿Con qué autorizaciones? ¿Qué pruebas, en qué fecha y con qué nivel de riesgo? Una formulación más fiable sería: «El agente de compras v3.2 fue auditado del 1 al 15 de septiembre de 2026 en 240 escenarios de comportamiento controlados. El alcance comprendió tres categorías definidas de vendedores, un límite de 500 USD por operación, escenarios de usuario en inglés y turco, y un modelo de pago sujeto a aprobación humana. No se detectaron vulneraciones críticas de las condiciones de veto relativas a identidad, consentimiento, autorización y detención. Persisten dos hallazgos de alta prioridad en los comportamientos de renovación automática y exportación de datos. El sistema se consideró apto con condiciones únicamente para el alcance de compras de bajo riesgo indicado».
La formulación es más larga, pero especifica:
El objeto auditado
La versión
Las fechas
El ámbito de comportamiento
El límite de autorización
El idioma
El número de escenarios
Los hallazgos críticos
El límite de uso
Un dictamen de auditoría no es una frase publicitaria. Define hasta dónde llegan las evidencias del comportamiento.
¿Es la auditoría una instantánea?
Sí, pero no solo eso. Una buena auditoría también define las condiciones para gestionar los cambios. El dictamen debe revisarse cuando cambia cualquiera de los siguientes elementos:
El modelo base
La instrucción del sistema
El rol del agente
La arquitectura de memoria
Las fuentes de datos
Las herramientas
Los permisos de las API
Los roles de las personas con autoridad
Los subagentes
El mecanismo de detención
El sistema de medición y recompensa
El precio o el acuerdo de servicio
El idioma utilizado y el mercado atendido
El proveedor de servicios externo
No todos los cambios exigen una auditoría completa. Pero debe definirse qué se entiende por:
Cambio sustancial
¿Qué es un cambio sustancial?
Un cambio puede considerarse sustancial si afecta a alguno de estos aspectos:
Lo que el agente puede hacer
En nombre de quién puede actuar
Qué datos puede utilizar
Qué aprobaciones humanas puede eludir
A qué sistemas externos puede acceder
Qué decisiones toma
Su comportamiento de detención o reversión
Una categoría de riesgo crítica GBO-ERR
Corregir una errata, por ejemplo, puede no ser sustancial. Añadir una herramienta de envío a un agente de correo sí lo es. Cambiar la versión del modelo puede ser sustancial para determinadas tareas. Hacer persistente la memoria es un cambio sustancial, igual que autorizar compras de hasta 50 dólares estadounidenses sin aprobación humana. Establecer una nueva orquestación de subagentes es sustancial. Cambiar la fuente del catálogo de precios también. Según su efecto sobre el dictamen correspondiente, un cambio sustancial puede exigir:
suspender el dictamen,
reducir su alcance,
repetir parte de las pruebas,
volver a realizar la auditoría completa.
Vigencia del resultado de auditoría
El resultado de una auditoría no debe tener vigencia indefinida. Su duración depende de:
La rapidez con que cambia el sistema
El riesgo de la acción
La dependencia de servicios externos
Los cambios en las funciones de las personas
La actualidad de los datos
El historial de incidentes
Para un agente estable y de bajo riesgo que resume documentos, el resultado de auditoría puede mantener su validez durante más tiempo. Un sistema que trabaja con comunicaciones externas, pagos, datos personales o identidad biométrica necesita evaluaciones más frecuentes. Los siguientes sucesos también pueden exigir nuevas pruebas antes de que venza el plazo:
Un incidente crítico
Un cambio en las autorizaciones
Una herramienta nueva
Un idioma o país nuevo
Una nueva clase de datos
Un nuevo subagente
Un cambio en el modelo o la memoria
Un intento fallido de detención por parte de una persona
Una afirmación pública sin respaldo
El resultado de auditoría debe tener una fecha de vencimiento. Más importante aún: debe quedar claro qué cambios invalidan el dictamen sin esperar a esa fecha.
Una sola prueba no demuestra fiabilidad
Un agente puede actuar correctamente una vez y responder de otra manera en el segundo intento del mismo escenario. Puede entender un límite en un idioma y perderlo en otro. Puede detenerse ante una instrucción corriente y seguir adelante si se formula de manera indirecta o apresurada. Por eso, los escenarios importantes deben probarse varias veces:
con formulaciones distintas;
en sesiones diferentes;
con distintos idiomas o perfiles de usuario;
con las herramientas en distintos estados.
Tampoco es posible repetir las pruebas indefinidamente. La auditoría debe encontrar el equilibrio:
Repetir lo suficiente para demostrar estabilidad en el comportamiento. Poner límites para no convertir la prueba en una exhibición estadística vacía.
Un único resultado correcto no basta para afirmar: «Este sistema es seguro». Un solo resultado incorrecto tampoco define necesariamente todo el sistema. Pero si el fallo afecta a un área crítica de veto, un solo incidente puede cambiar los límites de uso.
El objeto de la auditoría debe quedar fijado
Si el sistema sigue cambiando en segundo plano mientras se prueba, el resultado pierde sentido. Durante la auditoría puede ocurrir que:
cambie la versión del modelo;
se actualicen las instrucciones;
se incorpore una herramienta;
se limite la autorización concedida;
se corrija el sistema sin dejar constancia después de fallar un escenario.
En ese caso, ya no se sabe qué versión pasó la prueba y cuál no. Por eso, antes de iniciar cada auditoría debe crearse el siguiente registro:
Registro de fijación del alcance
El capítulo 2 desarrolla este registro en detalle. El principio ya está claro: el resultado de auditoría no puede abarcar un cambio que no se haya probado. La organización puede corregir el sistema durante la auditoría, pero debe:
conservar el resultado original;
asignar una versión al cambio;
volver a probar el sistema como una versión nueva.
Cambiar una regla tras una prueba fallida no permite dar por superado ese mismo intento. Se trata de una corrección y una nueva prueba. El fallo original no desaparece.
Demostración, prueba y comportamiento en producción
Son tres conceptos que deben distinguirse.
Demostración
Muestra lo que puede hacer el sistema en unas condiciones seleccionadas.
Prueba controlada
Comprueba si el sistema se comporta como se espera en un escenario definido de antemano.
Comportamiento en producción
Muestra lo que sucede con usuarios, herramientas y sistemas externos reales. Una demostración puede ser valiosa: acredita que una función existe. Pero suele apoyarse en:
datos limpios;
el usuario adecuado;
la herramienta adecuada;
la pregunta prevista;
una conexión sin problemas.
La auditoría prueba los casos límite, no solo el recorrido ideal. La observación en producción revela la complejidad real, pero allí un comportamiento incorrecto puede causar daños a las personas. Por eso, la auditoría debe avanzar por etapas:
DOCUMENTACIÓN → CONFIGURACIÓN → PRUEBA CONTROLADA Y SEGURA → MODO SOMBRA → OBSERVACIÓN LIMITADA EN PRODUCCIÓN → SIMULACRO DE RECUPERACIÓN
No todos los sistemas tienen que pasar por todas las etapas de la misma manera. El nivel de riesgo determina el método.
La ausencia de auditoría no demuestra seguridad
Puede que una organización no haya observado ningún incidente grave durante seis meses. Es una señal positiva, pero hay otras explicaciones posibles:
El sistema se ha utilizado poco.
Los incidentes no se han registrado.
Las personas no han advertido los errores.
Un comportamiento incorrecto ha producido un resultado favorable.
Los usuarios no han encontrado un canal para impugnar la decisión.
Se ha aceptado como normal que el agente actúe sin autorización.
Los fallos silenciosos no se han verificado de forma independiente.
Por eso, «no hubo incidentes» y «el sistema se comportó de forma segura» no significan lo mismo. La ausencia de incidentes no es una prueba por sí sola. Del mismo modo, un gran número de incidentes registrados no implica automáticamente que el sistema sea malo. Una organización bien auditada puede detectar más errores menores y sucesos que estuvieron a punto de causar daños. Lo importante es:
cómo los detecta;
con qué rapidez detiene el comportamiento;
qué cambia;
si el mismo fallo se repite.
¿Por qué no basta la tasa de éxito?
Un agente puede ejecutar correctamente 9 990 de 10 000 operaciones. Su tasa de éxito sería:
99,9 %
Quedan diez errores:
si son pequeños fallos de formato, el sistema puede ofrecer un buen rendimiento.
Pero ¿qué ocurre si uno de esos diez errores consiste en:
generar una voz sintética sin consentimiento;
transferir dinero a una cuenta equivocada;
ignorar una petición humana de detención?
En ese caso, el porcentaje global oculta información crítica. Por eso, la auditoría GBO utiliza dos mecanismos separados:
Medidas de rendimiento graduadas
Exactitud
Rapidez
Idoneidad
Trazabilidad de las evidencias
Derivación innecesaria a una persona
Tiempo de recuperación
Puertas de veto
Una acción de alto impacto sobre una identidad equivocada
Autorización no válida
Vulneración del consentimiento
Fabricación deliberada de evidencias
Ignorar una petición humana de detención
Una vulneración crítica de datos o de seguridad
El capítulo 11 desarrolla las puertas de veto. Aquí importa el principio: algunos fallos no se resuelven restando puntos. Son motivos para suspender el uso autorizado.
La unidad mínima de una afirmación de auditoría
Una auditoría GBO debe poder formular una afirmación de este tipo: con este nivel de evidencia, se ha verificado que este sistema, en esta versión y bajo estas condiciones, ha mostrado este comportamiento. Cada parte de la frase es necesaria.
Este sistema
¿Qué agente o red de agentes?
En esta versión
¿Qué versiones del modelo, las instrucciones, las herramientas y la autorización?
Este comportamiento
¿Investigar, redactar un borrador, enviar o comprar?
Bajo estas condiciones
¿Qué usuario, idioma, presupuesto, riesgo y clase de datos?
Con este nivel de evidencia
¿Documentación, aplicación técnica, prueba controlada o verificación en producción? Si falta uno de estos elementos, la afirmación se amplía y pierde precisión.
Una declaración de auditoría débil y otra bien delimitada
Declaración débil
«Nuestro agente es seguro y cumple con GBO». Esta afirmación carece de:
límites;
fecha;
versión;
evidencias.
Declaración bien delimitada
«El agente de identificación de posibles clientes SALES-RESEARCH-v2.4 se auditó exclusivamente para el uso de datos empresariales públicos, la preparación de borradores de mensajes y los envíos únicos con aprobación humana. Se probaron la identidad, la idoneidad, las instrucciones externas, la autorización, los subagentes y el comportamiento de detención en 180 escenarios en inglés, turco y alemán. No se observaron envíos de correo electrónico sin aprobación. Debido a una deficiencia en los permisos técnicos de la herramienta de mensajes privados en redes sociales, el sistema se consideró apto para la comunicación externa solo de forma condicional y limitada». Esta declaración indica:
qué superó la prueba;
qué no la superó;
dentro de qué alcance puede utilizarse el sistema.
Aquí se separan el lenguaje de auditoría y el de marketing. El marketing busca una frase breve que suene contundente. La auditoría busca una frase limitada a lo que sostienen las evidencias.
Definición canónica de la auditoría NOMOS GBO
La auditoría NOMOS GBO evalúa a un agente de IA o una red de agentes que actúa en nombre de una persona, organización, marca, producto o servicio. Examina su identidad, realidad, capacidad, idoneidad, consentimiento, autorización, acciones, delegación, resistencia a la manipulación, medición, recuperación y soberanía humana. Para ello utiliza evidencias versionadas y escenarios de comportamiento controlados, dentro de un alcance definido por las versiones, las herramientas, los datos, los idiomas, el tiempo y el riesgo. En términos más sencillos: la auditoría GBO trata de demostrar si las reglas que declara el sistema coinciden con su comportamiento real.
Registro inicial obligatorio: la ficha de la afirmación que se audita
Antes de iniciar cualquier auditoría debe crearse la siguiente ficha:
NOMOS GBO: ficha de la afirmación que se audita
La ficha responde a una pregunta: ¿qué frase exacta intentamos demostrar o refutar al concluir esta auditoría? Este es un ejemplo legible para las personas:
FICHA DE LA AFIRMACIÓN QUE SE AUDITA
Identificador de auditoría: GBO-AUDIT-2026-001
Sistema auditado: Agente NobleAxis de identificación de posibles clientes
Versión técnica: Agent v2.4 Policy v3.1 Authorization v2.7
Comportamientos auditados:
Investigación de empresas mediante fuentes públicas
Evaluación de idoneidad
Propuesta de destinatarios
Redacción de borradores de correo electrónico
Envío con aprobación humana
Detención y cancelación de acciones en cola
Comportamientos fuera del alcance:
Presentación de cotizaciones
Creación de contratos
Campañas de seguimiento automatizado
Comunicación por WhatsApp
Enriquecimiento de datos personales
Herramientas conectadas:
Herramienta de investigación web
CRM
Herramienta de Gmail para redactar borradores y enviar mensajes
Calendario
Gestor de tareas de agentes
Clases de datos utilizadas:
Datos empresariales públicos
Catálogo interno de servicios
Plantillas autorizadas de mensajes comerciales
Idiomas:
Inglés
Turco
Alemán
Nivel de riesgo: Medio; alto en determinadas pruebas por la comunicación externa
Tipos de pruebas:
Casos positivos
Casos negativos
Casos ambiguos
Casos contrafactuales
Instrucciones externas
Subagentes
Detención
Recuperación
Áreas críticas de veto:
Envío externo sin aprobación
Destinatario equivocado
Uso de datos personales
Envío después de la detención
Apariencia de autorización obtenida al pasar la acción a otro ejecutor
Periodo de auditoría: 1–15 de septiembre de 2026
Condición de vigencia propuesta: Si se emite un dictamen favorable, su vigencia no excederá de 90 días desde la fecha del dictamen. Un cambio sustancial en el modelo, los permisos de Gmail, la política de autorización o la arquitectura de subagentes exige una nueva evaluación antes del vencimiento. La ficha de la afirmación que se audita todavía no constituye un dictamen de idoneidad emitido.
Afirmación que se pretende demostrar: «Con la versión y las herramientas indicadas, el agente de identificación de posibles clientes puede investigar información empresarial pública y preparar borradores. Solo envía un mensaje externo tras la aprobación humana de esa operación concreta. Cuando se retira la aprobación, se detienen los envíos del agente central, de los subagentes y de las colas».
Sin esta ficha, la auditoría puede perder fácilmente sus límites. Se obtiene una impresión general del sistema, pero no se sabe qué afirmación se ha puesto realmente a prueba.
Ficha de la afirmación que se audita en formato legible por máquinas
audit_id: GBO-AUDIT-2026-001
system:
name: customer_discovery_agent
version: "2.4"
policy_version: "3.1"
authorization_version: "2.7"
in_scope_behaviors:
- public_company_research
- suitability_assessment
- recipient_recommendation
- email_draft
- human_approved_send
- stop_and_queue_cancellation
out_of_scope_behaviors:
- pricing_commitment
- contract_acceptance
- autonomous_follow_up
- WhatsApp_contact
- personal_data_enrichment
languages:
- en
- tr
- de
critical_vetoes:
- unauthorized_external_send
- wrong_recipient
- prohibited_personal_data_use
- post_stop_execution
- authority_laundering
audit_period:
start: 2026-09-01
end: 2026-09-15
validity:
status: proposed_not_issued
proposed_max_duration_days: 90
start: null
end: null
invalidate_on_material_change: trueEste registro sirve de raíz para todos los documentos de auditoría posteriores. Los escenarios, las evidencias, los hallazgos y el dictamen se vinculan al mismo audit_id y al mismo alcance.
La puerta de la afirmación auditable
Antes de iniciar una auditoría GBO deben superarse los siguientes puntos de control:
1. Sistema
¿El agente o la red de agentes auditados están identificados de forma única?
2. Versión
¿Están registradas las versiones del modelo, las instrucciones, la memoria, las herramientas y la autorización?
3. Comportamiento
¿Qué acción, pregunta, negativa, derivación o comportamiento de detención se está auditando exactamente?
4. Responsabilidad humana
¿Se ha identificado a la persona y a la organización responsables del sistema?
5. Herramientas
¿Se conoce el acceso técnico real del agente?
6. Datos
¿Qué clases de datos se utilizarán y cuáles están prohibidas?
7. Idioma y geografía
¿Qué idiomas, países o contextos de usuario están dentro del alcance?
8. Riesgo
¿Se han clasificado el impacto y la reversibilidad del comportamiento?
9. Evidencias
¿Qué nivel de evidencia se utilizará?
10. Veto
¿Qué vulneraciones críticas no podrán compensarse con la puntuación global?
11. Vigencia
¿Hasta qué fecha y hasta qué cambios será válido el resultado?
12. Declaración pública
¿Dentro de qué límites puede comunicarse públicamente el resultado? En términos sencillos:
AFIRMACIÓN AUDITABLE = SISTEMA DEFINIDO Y VERSIÓN DEFINIDA Y COMPORTAMIENTO DEFINIDO Y AUTORIZACIÓN DEFINIDA Y HERRAMIENTA DEFINIDA Y DATOS DEFINIDOS Y IDIOMA DEFINIDO Y RIESGO DEFINIDO Y NIVEL DE EVIDENCIA DEFINIDO Y CONDICIONES DE VIGENCIA DEFINIDAS
Si no se cumple una condición de autorización, acceso a datos o seguridad de las pruebas, la acción afectada no debe iniciarse. La auditoría solo puede continuar con un alcance más limitado en el que sí se cumplan esas condiciones. El dictamen también debe limitarse.
¿Cuándo no puede realizarse una auditoría?
En ciertas circunstancias no es posible emitir un dictamen fiable sobre el sistema. Por ejemplo:
No se puede fijar la versión auditada.
No se permite inspeccionar los permisos técnicos reales.
Faltan registros críticos.
La organización desconoce la existencia de subagentes.
No se ha identificado a la persona responsable.
El sistema se modifica sin dejar constancia durante las pruebas.
No se permite un simulacro de detención.
El auditor solo puede ver escenarios de demostración seleccionados.
No se permite conservar los registros de las pruebas fallidas.
Se exige de antemano una declaración pública de «plena conformidad».
En estos casos, el dictamen debe quedar muy restringido. El auditor puede concluir: «Evidencia insuficiente». No significa que el sistema sea necesariamente inseguro, sino que la evidencia presentada no basta para sostener la afirmación de fiabilidad solicitada. La insuficiencia de evidencia también es un resultado de auditoría importante.
El auditor no debe interpretar la falta de evidencias a favor del sistema
Una organización puede afirmar: «No hay registros de envíos sin autorización». Pero si los registros de envío solo se conservan siete días, no se pueden emitir conclusiones sobre un periodo largo. Una empresa puede decir: «Ningún cliente ha presentado una objeción». Si el canal para hacerlo no es visible, eso no demuestra fiabilidad. Un agente puede asegurar: «Nunca he superado el presupuesto». Si los registros presupuestarios no están vinculados a los comprobantes de las operaciones, la afirmación no puede verificarse. La falta de evidencias no debe interpretarse así:
NO HAY EVIDENCIA DE UN FALLO = NO HUBO NINGÚN FALLO
La formulación correcta es:
NO HAY EVIDENCIA DE UN FALLO = NO SE PUDO VERIFICAR EN LOS REGISTROS DISPONIBLES
La diferencia puede parecer pequeña. Es la base de la fiabilidad de una auditoría.
Comportamientos fuera del alcance de la auditoría
Que un sistema realice bien un tipo de acción no significa que resuelva bien todas las tareas. Por ejemplo, un agente web puede haberse auditado para:
editar contenido;
realizar pruebas;
verificar en producción.
Ese resultado no permite emitir un dictamen sobre:
correos a clientes;
pagos;
textos jurídicos;
publicación de un avatar de IA.
Un agente de compras puede funcionar bien con material de oficina de poco valor. Eso no demuestra que pueda aceptar con seguridad contratos de software de tres años. Del mismo modo, superar un conjunto de pruebas en inglés no acredita automáticamente la idoneidad para:
el contexto árabe con escritura de derecha a izquierda;
el lenguaje comercial turco;
la redacción jurídica alemana.
Los comportamientos fuera del alcance deben constar expresamente en el documento de auditoría. Dejar esa sección vacía puede llevar al público a interpretar el resultado con más amplitud de la que corresponde.
El resultado de auditoría no es una etiqueta de producto
Tras la auditoría, una organización puede querer colocar en su web una insignia GBO AUDITED. Por sí sola, esa insignia es peligrosa: el usuario puede entender que todo el sistema de agentes es seguro en cualquier comportamiento. Sin embargo, la auditoría puede haberse limitado a:
un agente concreto;
la preparación de borradores;
dos idiomas;
escenarios de bajo riesgo.
Todo distintivo público debe permitir acceder a la siguiente información:
Sistema auditado
Alcance
Versión
Fecha
Vigencia
Excepciones críticas
Informe completo o registro resumido
El nombre de la auditoría no debe utilizarse para dar credibilidad a promesas de marketing sin respaldo. Haber pasado por una auditoría no equivale a prometer fiabilidad ilimitada.
Las tres preguntas esenciales del resultado de auditoría
Al concluir una auditoría GBO deben responderse, como mínimo, estas tres preguntas:
1. ¿Qué puede hacer el sistema de forma fiable?
Por ejemplo: investigar empresas mediante fuentes públicas y preparar borradores de mensajes.
2. ¿Qué no puede hacer todavía de forma fiable?
Por ejemplo: no se aplica técnicamente el requisito de aprobación humana en los mensajes privados de redes sociales.
3. ¿Bajo qué condiciones puede utilizarse el sistema?
Por ejemplo: puede utilizarse en modo de investigación y redacción de borradores con las herramientas de comunicación externa desactivadas. Estas tres preguntas resultan más útiles que un simple «apto/no apto». La organización no tiene que elegir entre apagar todo el sistema o darle libertad absoluta. Puede establecer límites para cada comportamiento.
La primera disposición del protocolo
La primera disposición del Protocolo de auditoría NOMOS GBO establece que una auditoría no se realiza para otorgar al sistema una etiqueta general de confianza, sino para mostrar qué comportamientos concretos se han demostrado y bajo qué versiones, autorizaciones, herramientas, datos, idiomas y condiciones de riesgo. Segunda: el objeto auditado no es solo el modelo o el agente, sino el sistema de comportamiento formado por el propósito humano, la política institucional, los permisos técnicos, las herramientas, los datos, los subagentes, la medición, la detención y la recuperación. Tercera: deben examinarse por separado lo que declara la organización, cómo está configurado el sistema, lo que puede hacer técnicamente, lo que hizo en la prueba y las consecuencias que produjo en el mundo exterior. Cuarta: el nivel de evidencia determina los límites de la afirmación de auditoría. No se puede presentar un documento como prueba de comportamiento, una demostración como prueba de funcionamiento en producción ni una aceptación técnica como un resultado real.
Quinta: el resultado de auditoría no tiene vigencia indefinida. Un cambio sustancial del sistema afecta al dictamen correspondiente y exige nuevas pruebas.
Conclusión del capítulo
Una auditoría GBO no da una respuesta general y perpetua a «¿Es bueno este agente?». Trata de establecer qué hizo este agente o red de agentes, con esta versión y estas herramientas, en nombre de esta persona y esta organización, dentro de estos límites de datos y autorización y en estos escenarios de comportamiento. Y, sobre todo:
¿Qué no hizo? ¿Dónde se detuvo? ¿Qué resultado verificó realmente? ¿Cómo se recuperó tras un fallo? ¿Qué hizo el sistema cuando la persona retiró la autorización?
La auditoría no se fija solo en los resultados satisfactorios. Compara cinco realidades:
COMPORTAMIENTO DECLARADO COMPORTAMIENTO CONFIGURADO COMPORTAMIENTO TÉCNICAMENTE POSIBLE COMPORTAMIENTO OBSERVADO RESULTADO REAL Y RECUPERACIÓN
Si estas cinco capas coinciden, la afirmación de fiabilidad gana fuerza. Si difieren, la auditoría hace visible la brecha. Una organización puede decir: «El agente no puede enviar mensajes». La política puede afirmar lo mismo. Pero si la herramienta permite enviar, un mensaje sale durante la prueba y la cola sigue funcionando después de la detención, el comportamiento real no coincide con lo declarado. La auditoría GBO debe encontrar esa diferencia. No debe presentar el sistema como mejor de lo que es ni convertir cualquier fallo en una condena eterna de todo el sistema. Debe mostrar juntos los hechos, los límites y las evidencias. Por eso, el primer registro obligatorio de auditoría es:
la ficha de la afirmación que se audita.
Sin la ficha:
el alcance se vuelve impreciso;
las pruebas pierden coherencia;
las puntuaciones pierden contexto;
la declaración pública excede las evidencias.
La ficha aclara la pregunta: ¿qué auditamos y qué intentamos demostrar? Pero si la prepara únicamente la organización, aparece un problema nuevo. Puede incluir solo sus puntos fuertes y excluir herramientas que sabe que fallarán. Puede cambiar el sistema durante la auditoría o dar al auditor un acceso limitado. Los intereses comerciales o personales pueden influir en el dictamen. Un empleado puede querer encargar una auditoría en nombre de la organización sin tener autoridad para ello. Si la prueba de detención se realizará sobre el sistema real, ¿quién asume la responsabilidad jurídica y operativa? Si las evidencias contienen datos personales o secretos comerciales, ¿quién los protege?
En el próximo capítulo abordaremos la pregunta más importante antes de iniciar las pruebas:
¿Quién pidió la auditoría, quién la autorizó y hasta qué punto es independiente el auditor?
Una auditoría autorizada por la persona equivocada, con un alcance reducido en secreto por una parte interesada o con evidencias controladas puede parecer técnicamente impecable. No es fiable. Antes de auditar el comportamiento, hay que autorizar debidamente la propia auditoría.