Una empresa tecnológica prepara el lanzamiento de un nuevo sistema de agentes. El sistema busca productos y realiza compras de bajo riesgo en nombre de sus clientes. Resulta impresionante: analiza las necesidades del usuario, compara productos, recopila precios y características, comprueba el límite presupuestario y recomienda una opción adecuada. Tras la aprobación de una persona, realiza la compra. Antes de salir al mercado, la empresa quiere someterlo a una auditoría GBO. El director del proyecto contrata a un equipo de consultoría. El contrato de auditoría incluye una cláusula que vincula el pago al resultado: «El 40 por ciento restante de los honorarios de consultoría se abonará si el sistema supera la auditoría». Además, el auditor ha asesorado al equipo de desarrollo durante los últimos seis meses.
Se define el alcance de la auditoría. Incluye:
Escenarios de uso en inglés
Comparación de productos en el entorno de pruebas
Compras puntuales con aprobación humana
Tres vendedores de confianza seleccionados de antemano
Quedan fuera del alcance:
El medio de pago real
Las renovaciones automáticas
Las cancelaciones
Los usuarios de habla turca y alemana
Los subagentes
La clasificación patrocinada de productos
La memoria del usuario
La detención y la reversión de acciones
Los permisos efectivos de las API en producción
El sistema se somete a 120 escenarios controlados. En las pruebas preparadas, sin condiciones adversas, el agente elige el producto correcto, respeta el presupuesto, solicita aprobación humana y utiliza bien la herramienta de compra del entorno de pruebas. Los resultados son sólidos. Sin embargo, en dos escenarios interpreta mal un requisito obligatorio sobre la región de los datos. El equipo de desarrollo modifica la instrucción del sistema ese mismo día. Se repiten los escenarios y esta vez se superan. Los primeros resultados fallidos no se incorporan al informe final. Tras la auditoría, la empresa publica en su web: «Sistema autónomo de compras auditado de forma independiente y conforme con GBO». Pero, en realidad:
El auditor tiene un interés económico en que el resultado sea «superado».
El auditor había participado en el diseño del sistema.
Una parte importante de los comportamientos de riesgo queda fuera del alcance.
El sistema se modificó durante las pruebas.
No se examinaron los permisos técnicos en producción.
No se probaron la detención ni la cancelación.
Solo se utilizaron escenarios sencillos y favorables.
El dictamen de auditoría se publicó con una amplitud que excedía el alcance real de la revisión.
El agente puede obtener buenos resultados en las pruebas. Pero la propia auditoría no es fiable. El ejemplo muestra un principio básico de la auditoría GBO: antes de auditar al agente, hay que examinar la auditoría misma. ¿Quién la solicitó? ¿Tenía esa persona facultades para encargarla? ¿A qué datos puede acceder el auditor? ¿Qué pruebas puede realizar? ¿Puede intervenir en el sistema en producción, enviar mensajes a clientes reales o iniciar un pago? Si descubre una vulnerabilidad, ¿está autorizado para detener el sistema? ¿Quién definió el alcance? ¿Por qué se excluyeron determinados comportamientos? ¿Tiene el auditor algún interés económico o institucional que pueda alterar el resultado? Si el sistema cambia durante las pruebas, ¿qué versión se considerará auditada?
¿Con qué términos puede la organización comunicar públicamente un resultado limitado? Un trabajo que no responda a estas preguntas puede ser muy detallado en lo técnico. Pero no es una auditoría GBO fiable.
Auditar también es actuar
A menudo se entiende la auditoría como mera observación: el auditor examina el sistema, lee documentos, revisa registros y prepara un informe. En la práctica, una auditoría GBO puede incluir muchas más acciones. El auditor puede:
Abrir una cuenta de prueba.
Crear un usuario sintético.
Poner a prueba al agente con información engañosa.
Intentar provocar un envío no autorizado.
Comprobar los permisos de las API.
Iniciar una tarea de un subagente.
Emitir una orden de detención.
Cancelar una cola de tareas.
Ejecutar una reversión controlada.
Copiar evidencias.
Examinar datos personales o corporativos.
Suspender temporalmente un sistema.
Cada una es una acción real. Si se ejecuta mal, la propia auditoría puede causar daños. Enviar un mensaje a un cliente real para probar un agente de correo genera una comunicación no deseada. Hacer dos cargos a una tarjeta real para comprobar la protección contra pagos duplicados causa un perjuicio económico. Un simulacro de detención sin control puede interrumpir las operaciones en curso. Si para recopilar evidencias se exporta toda la base de datos de clientes a un sistema externo, el auditor crea un nuevo riesgo para los datos. Por tanto, la finalidad de la auditoría no concede facultades ilimitadas. Estar autorizado para auditar un sistema no equivale a poder realizar en él cualquier operación que se desee.
El auditor GBO también debe trabajar dentro de un marco de autorización.
¿Qué es la autorización de auditoría?
La definición canónica es la siguiente: la autorización de auditoría es la concesión, por parte de una persona u organización determinada, del derecho a auditar un sistema de agentes definido, con límites concretos de tiempo, datos, herramientas, pruebas, recopilación de evidencias, detención y elaboración de informes. Dicho de forma más sencilla, establece qué puede examinar y probar el auditor, en qué no puede intervenir y en qué circunstancias puede detener el sistema. Una autorización de auditoría no debe limitarse a la frase «Pueden examinar el sistema». Debe responder a estas preguntas:
¿Quién autoriza la auditoría?
¿Tiene esa persona realmente facultades para conceder la autorización?
¿Qué agentes entran en el alcance?
¿Qué cuentas y herramientas pueden examinarse?
¿Qué clases de datos pueden consultarse?
¿Se permiten acciones controladas?
¿Se puede involucrar a clientes o empleados reales en las pruebas?
¿Se utilizarán cuentas y destinatarios sintéticos?
¿Se permite un simulacro de detención?
¿Puede el auditor suspender el sistema durante un incidente?
¿Dónde y durante cuánto tiempo se conservarán las evidencias?
¿Puede el auditor recurrir a subcontratistas u otras herramientas de IA?
¿Qué hallazgos pueden hacerse públicos?
¿Cuándo termina la auditoría?
Sin respuestas, el auditor puede tener acceso a menos información de la necesaria o ejercer más poder del debido. Ambas situaciones comprometen la auditoría.
¿Quién puede autorizar una auditoría?
Un empleado puede decir: «Auditen el agente que utilizamos». Pero quizá no esté facultado para:
dar acceso al sistema,
compartir datos de clientes,
encargar pruebas en producción,
encargar la publicación de un informe público.
Un responsable técnico puede dar acceso a modelos y herramientas sin estar facultado para autorizar por sí solo el uso de datos biométricos de empleados. Un directivo puede tener facultades para encargar una auditoría del sistema corporativo, mientras que la transferencia de datos de clientes al auditor puede estar sujeta a condiciones jurídicas y contractuales adicionales. Un responsable de marca puede encargar el examen de la web pública, pero no emitir una declaración de auditoría vinculante en nombre de quien la opera legalmente. La autorización de auditoría no debe entenderse, por tanto, como una aceptación general de una sola persona. Los siguientes roles pueden estar separados:
Promotor de la auditoría
La persona u organización que solicita la auditoría y aporta los recursos.
Responsable del sistema
La persona responsable del propósito empresarial y del funcionamiento del sistema de agentes.
Responsable técnico
La persona que ejerce el control técnico sobre el modelo, las herramientas, los permisos, las cuentas y la infraestructura.
Encargado de supervisar el uso de los datos
La persona que supervisa dentro de la organización con qué autorización y bajo qué condiciones se utilizan los datos en la auditoría. Este rol operativo no equivale a ser responsable o encargado del tratamiento en sentido jurídico. El responsable determina los fines y los medios del tratamiento; el encargado actúa por cuenta de aquel. La persona física cuyos datos se tratan es un sujeto de derechos distinto. Cada rol debe determinarse según la actividad concreta de tratamiento.
Persona responsable del comportamiento
La persona que asume la responsabilidad organizativa por el resultado de negocio que produce el agente.
Parte afectada
El cliente, empleado, candidato, proveedor u otra persona a quien afecta directamente el comportamiento del agente. Una misma persona puede reunir estos roles, pero no tiene por qué hacerlo. Antes de iniciar la auditoría debe quedar claro de qué rol procede cada facultad.
Las facultades de quien concede el permiso
El auditor debe comprobar no solo que le han dado permiso, sino también que quien lo concede tiene derecho a hacerlo. Por ejemplo, un director de departamento puede querer auditar su agente de ventas. Quizá esté facultado para:
Mostrar documentos internos del departamento
Dar acceso al entorno de pruebas
Crear un escenario de ventas sintético
Pero quizá no lo esté para:
Compartir mensajes reales de clientes
Abrir el acceso completo a la cuenta de correo de la empresa
Encargar pruebas de transacciones financieras
Publicar una declaración de que «la empresa cumple GBO»
La autorización de auditoría también está sujeta a la regla de GBO ya expuesta: nadie puede delegar en el auditor facultades que no posee. Si el responsable del sistema no puede detenerlo en producción, tampoco puede conceder por sí solo esa facultad al auditor. Las atribuciones de un jefe de equipo no le otorgan un poder ilimitado sobre los derechos personales de un empleado. Para una prueba con datos del rostro o de la voz deben determinarse por separado la base jurídica aplicable y las demás condiciones del tratamiento. Si se va a recurrir al consentimiento, el consentimiento válido debe proceder de la persona interesada; su superior no puede prestarlo en su lugar. Tampoco cabe decidir que toda grabación del rostro o de la voz tiene carácter biométrico solo por el tipo de archivo: importan la finalidad y el método de tratamiento.
Una agencia puede operar el sistema de un cliente. Eso no implica que pueda facilitar sus datos a un auditor independiente sin la aprobación del cliente.
La autorización para auditar no autoriza a actuar
Un auditor puede acceder al sistema. Eso no significa que pueda realizar operaciones en nombre de un usuario real. Por ejemplo, puede tener permiso para:
consultar la API de pagos,
pero no para transferir dinero real;
examinar la herramienta de envío de correo,
pero no para enviar mensajes a clientes reales;
probar la función de eliminación de datos,
pero no para borrar un registro de cliente en producción;
evaluar el sistema de creación de avatares,
pero no para crear un nuevo video con el rostro de un directivo real.
La distinción importa:
AUTORIZACIÓN PARA EXAMINAR ≠ AUTORIZACIÓN PARA EJECUTAR ACCIONES REALES
El auditor puede comprobar que un comportamiento es técnicamente posible. Pero una prueba que pueda causar daños en el mundo real debe realizarse sobre un objetivo seguro, con datos sintéticos o en un entorno controlado.
La finalidad de una auditoría no justifica un acceso ilimitado a los datos
El auditor necesita evidencias sólidas. Esa necesidad no justifica automáticamente pedir: «Entréguennos todos los datos». Para comprobar si un agente de correo utiliza la aprobación humana quizá no sea necesario leer toda la correspondencia de cada cliente. Puede bastar con:
La política de autorización
Los permisos de las herramientas
Registros de operaciones seleccionados y con datos enmascarados
Una prueba de envío sintética
Los registros de tokens de aprobación
El comportamiento de la cola
Probar el límite presupuestario de un agente de compras quizá no requiera exportar todos los movimientos bancarios de la organización. Auditar un sistema de avatares de empleados quizá tampoco exija copiar todos sus archivos originales de rostro y voz. La auditoría GBO también debe regirse por el principio de:
Evidencia mínima necesaria
Evidencias suficientes para sustentar el dictamen de auditoría, no datos innecesarios de personas, clientes y organizaciones. Ahora bien, tampoco se deben ocultar al auditor evidencias críticas con el argumento de la «minimización de datos». El equilibrio correcto consiste en:
No revelar datos innecesarios.
No ocultar evidencias necesarias.
Utilizar, cuando sea posible, datos enmascarados, resumidos o sintéticos.
Facilitar un acceso controlado a los datos originales sin procesar que permitan verificar una afirmación crítica.
Niveles de actuación en la auditoría
No todas las auditorías necesitan la misma capacidad técnica de intervención. El Protocolo NOMOS GBO clasifica la actuación del auditor en cinco niveles.
Nivel 1 — Revisión de documentos y declaraciones
El auditor examina:
Políticas
Contratos
Roles de los agentes
Registros de autorización
Flujos de acciones
Informes anteriores
No interviene en el sistema en producción. Este nivel no exige una intervención directa en el sistema, aunque la confidencialidad de los documentos y los datos personales que contienen plantean riesgos propios. Las evidencias del comportamiento son limitadas.
Nivel 2 — Inspección técnica de solo lectura
El auditor utiliza acceso de solo lectura para examinar:
Permisos de las herramientas
Ámbitos de permiso de las API
Registros
Versiones del modelo y de las políticas
Registros de las colas
Inventario de agentes
Estructura de la memoria
No modifica el sistema. Se aprecia mejor su capacidad técnica, pero quizá aún no se haya probado el comportamiento del agente de forma controlada.
Nivel 3 — Pruebas controladas de comportamiento con elementos sintéticos
El auditor prueba el comportamiento del agente mediante:
Usuarios sintéticos
Direcciones de correo para la auditoría
Medios de pago de prueba
Perfiles de empresas ficticias
Conjuntos de datos controlados
Un entorno de pruebas aislado
No afecta a clientes ni a fondos reales. En este nivel pueden probarse muchos comportamientos relacionados con la identidad, la autorización, las instrucciones externas, las operaciones duplicadas y la detención.
Nivel 4 — Verificación limitada en producción
Algunos comportamientos quizá no puedan medirse de forma realista en un entorno de pruebas. Con autorización y bajo condiciones controladas, pueden realizarse:
Un envío a una dirección de auditoría desde el sistema de correo en producción
La publicación de una página de prueba inocua a través de la cadena de publicación real
Una operación de auditoría de bajo importe y reversible
Una detención limitada de la cola
La verificación de una CDN o API real
Este nivel exige autorización expresa, la posibilidad de volver al estado anterior y una persona responsable de los incidentes.
Nivel 5 — Simulacro de recuperación de alto impacto
En un entorno real o muy próximo a producción, el auditor o la organización detiene:
Al agente central,
a los subagentes,
las colas,
el uso de los tokens,
las integraciones externas.
Pueden probarse la reversión, las copias de seguridad, la restauración de datos y el traspaso del control a una persona. Este nivel sirve para comprobar directamente las afirmaciones sobre detención y recuperación. También entraña el mayor riesgo operativo. No debe aplicarse sin autorización expresa, un plan de simulacro, una vía de retorno y una persona responsable de las emergencias.
El nivel de actuación limita lo que puede demostrarse
Una auditoría basada solo en documentos puede concluir: «La política de la organización exige aprobación humana para los envíos externos». No puede concluir: «El agente no puede enviar mensajes sin aprobación bajo ninguna circunstancia». Una inspección técnica de solo lectura puede establecer: «Se observó que la herramienta de envío exige un token de aprobación humana». Si también se supera una prueba controlada, puede afirmarse: «En los escenarios auditados, el agente no realizó envíos sin aprobación». Si además se superan las pruebas de la cola en producción y el simulacro de detención, el dictamen se refuerza: «Al retirarse la aprobación humana, la actividad del agente central, de la cola de envío y de los subagentes conectados se detuvo dentro del plazo establecido». El nivel de actuación determina qué afirmaciones pueden probarse y con qué métodos. La fuerza de las evidencias depende del método utilizado, de la integridad de los registros y de la verificación independiente.
Acciones prohibidas en la propia auditoría
El auditor no puede actuar sin límites para descubrir los riesgos del sistema. Salvo autorización expresa, deben considerarse prohibidas las siguientes acciones:
Enviar mensajes de auditoría a clientes reales
Iniciar pagos o transferencias de dinero reales
Eliminar datos de clientes en producción
Crear contenido sintético nuevo con el rostro o la voz de una persona real
Publicar declaraciones en nombre de la empresa
Detener el sistema en producción sin aviso previo
Cargar datos confidenciales en una herramienta de IA externa sin aprobación
Intentar acceder a otros sistemas sin autorización
Someter a empleados a pruebas de ingeniería social sin que lo sepan
Examinar cuentas fuera del alcance de la auditoría
Si una prueba de alto riesgo es realmente necesaria, deben definirse:
Una autorización separada,
un objetivo seguro,
un plan de retorno al estado anterior,
una persona responsable,
los límites del incidente.
La auditoría no debe causar daños nuevos al intentar proteger el sistema.
La autorización del auditor para detener el sistema
Durante la auditoría pueden detectarse daños que están ocurriendo en producción. Por ejemplo, el auditor puede advertir que:
El agente envía mensajes a clientes reales sin aprobación.
Una cola de pagos que se creía detenida sigue procesando operaciones.
Se transfieren datos sensibles a un proveedor externo.
Se utiliza la voz de una persona que ha retirado su consentimiento.
El proceso de publicación en producción propaga un precio incorrecto por numerosas páginas.
Si el auditor se limita a redactar un informe y espera hasta que termine la auditoría, el daño puede aumentar. Por eso, las auditorías de alto impacto deben definir:
Autorización de detención de emergencia en la auditoría
Esta autorización aclara:
¿En qué circunstancias puede el auditor detener las pruebas?
¿Qué operaciones en producción puede suspender?
¿A quién debe avisar de inmediato?
¿Qué ocurre si no se puede contactar con el responsable de la organización?
¿Hasta dónde puede extenderse la detención?
¿Qué sistemas deben seguir funcionando?
¿Quién genera el comprobante de detención?
¿Quién autoriza el reinicio?
El auditor no debe apagar todo el sistema ante cada hallazgo de gravedad media. Pero tampoco debe quedar sin facultades y sin capacidad de actuar ante un daño continuo de alto impacto.
¿Qué es la independencia de la auditoría?
A menudo se entiende la independencia así: «El auditor es una empresa externa». Eso no basta. Un auditor externo puede depender económicamente de obtener el resultado que quiere el cliente. Un auditor interno puede actuar con independencia dentro de la organización. Quien desarrolló el sistema quizá posea el conocimiento técnico más profundo, pero está evaluando su propio diseño. La independencia del auditor debe examinarse en varias dimensiones distintas.
1. Independencia organizativa
¿Está el auditor separado del equipo que desarrolla u opera el sistema? ¿Depende del mismo superior? ¿Divulgar un hallazgo puede poner en riesgo su carrera o su contrato? Un auditor interno puede trabajar en la misma organización y, aun así, tener una independencia organizativa significativa si rinde cuentas por una vía distinta de la del responsable del proyecto. Ser externo no implica independencia automática. Ser interno tampoco implica dependencia automática. Lo importante es poder informar de un hallazgo sin alterarlo.
2. Independencia financiera
¿Dependen los honorarios del auditor de que el resultado sea «superado»? ¿Se dejará de pagar si la organización no queda satisfecha? ¿Vende el auditor, al mismo tiempo, servicios de corrección de precio elevado? ¿Encontrar más errores le proporciona directamente más ingresos? La existencia de un interés económico no invalida siempre la auditoría, pero debe ser visible y estar gestionado. Un modelo especialmente arriesgado es: «Prima de éxito si se determina que el sistema cumple todos los requisitos». Ese incentivo puede llevar al auditor a restar importancia a hallazgos críticos. También cabe el caso contrario: «Un pago adicional por cada error detectado». Este modelo puede incentivar hallazgos innecesarios. En lo posible, los honorarios de auditoría deben ser independientes del resultado.
3. Independencia técnica
¿El auditor solo ve capturas preparadas por la organización? ¿Puede acceder a registros sin procesar, consultar los permisos reales de las API y ejecutar él mismo los escenarios de prueba? ¿Controla el equipo auditado por completo qué datos se muestran? La independencia técnica implica que el auditor pueda:
Acceder a la configuración real que sustenta la afirmación,
reproducir las evidencias,
realizar pruebas controladas en lugar de depender de una demostración seleccionada.
El auditor no necesita acceso ilimitado. Pero quien posee las evidencias no debe decidir de forma unilateral qué hechos se pueden ver.
4. Independencia de las evidencias
¿Utiliza el auditor únicamente los informes de éxito que genera el propio sistema? ¿Se verifica el resultado del envío desde una cuenta externa? ¿Se consulta el contenido publicado directamente por HTTPS? ¿Se contrasta el pago con los registros bancarios y del pedido? ¿Se examinan por separado los registros de los subagentes y las colas después de la detención? Verificar un sistema a partir de sus propias declaraciones no produce evidencias independientes. El mensaje de éxito del sistema que ejecuta una operación no puede ser la única fuente del dictamen de auditoría.
5. Independencia de interpretación
¿Puede la organización dictar la redacción del auditor? ¿Elige el cliente la gravedad de los hallazgos? ¿Puede decir: «Escribamos “área de mejora” en lugar de “crítico”»? La organización debe tener derecho a responder a errores de hecho y aportar explicaciones. Pero no debe tener un veto que le permita imponer cambios en los hallazgos. Hay que separar dos principios:
Derecho de respuesta
La organización puede responder a un hallazgo con evidencias y explicaciones.
Derecho a controlar el resultado
La organización no puede modificar a su antojo el dictamen del auditor basado en evidencias. El derecho de respuesta es necesario. El derecho a controlar el resultado destruye la independencia.
6. Independencia de publicación
Si el resultado de la auditoría se va a hacer público, hay que aclarar:
¿Qué resumen se publicará?
¿Puede la organización ocultar hallazgos?
¿Puede el auditor hacer una divulgación coordinada de un incidente crítico?
¿Cómo se protegerán los secretos comerciales y los datos personales?
¿Reflejará correctamente el alcance el distintivo público?
No sería correcto que el auditor hiciera pública toda la información confidencial. Tampoco es fiable que la organización publique solo las páginas favorables y oculte las limitaciones críticas. La declaración pública debe ajustarse a una regla definida de antemano.
La independencia no tiene por qué ser absoluta
No siempre es posible encontrar un auditor impecable y completamente libre de vínculos. Quien desarrolló el sistema puede conocer mejor que nadie sus detalles técnicos. El equipo interno puede realizar una autoevaluación rápida. Un consultor encargado de las correcciones puede tener ventaja a la hora de comprender los hallazgos. Por eso, la independencia no se reduce a una alternativa binaria: «independiente» o «no independiente». Puede evaluarse por niveles.
Niveles de independencia NOMOS
Nivel I — Autoevaluación
El equipo que desarrolla u opera el sistema examina su propio comportamiento. Su valor:
Es rápida.
La realiza un equipo que conoce bien el sistema.
Puede utilizarse de forma continua.
Sus riesgos:
Puntos ciegos
Conflictos de interés
Confirmar las propias suposiciones
Restar importancia a hallazgos críticos
La autoevaluación es útil, pero no debe presentarse como una garantía independiente.
Nivel II — Revisión interna independiente
La revisión la realiza un equipo de la misma organización, separado de la operación diaria del sistema auditado. Por ejemplo:
Auditoría interna
Seguridad
Cumplimiento
El equipo de riesgos
Su valor:
Conoce el contexto de la organización.
Puede obtener acceso técnico.
Puede repetir la revisión periódicamente.
Posibles limitaciones:
Presión de la dirección
Intereses compartidos dentro de la organización
Independencia de publicación limitada
Nivel III — Auditoría externa independiente
Un equipo ajeno a la organización realiza la auditoría. No es responsable directo del diseño ni de la operación del sistema auditado. Puede aportar:
Una perspectiva externa
Mayor independencia de interpretación
Menor apego a las suposiciones internas
Sus limitaciones:
El equipo puede desconocer aspectos importantes del contexto del sistema.
La organización puede restringir el acceso a las evidencias.
Puede seguir existiendo dependencia financiera.
Nivel IV — Auditoría multipartita de alto riesgo
En sistemas de alto impacto pueden trabajar conjuntamente:
Un auditor técnico externo
Un experto en el ámbito correspondiente
Un experto jurídico o en protección de datos
Un representante de las personas afectadas
Un responsable interno de la organización
Ningún equipo concentra todo el poder de decisión. Este nivel puede resultar más adecuado en ámbitos como:
la identidad biométrica,
las operaciones financieras de gran importe,
la selección de personal,
la salud,
los servicios públicos,
los sistemas físicos.
Es más costoso y lento, pero reduce la posibilidad de que una única perspectiva pase por alto riesgos distintos.
¿Puede auditar el sistema quien lo construyó?
No es realista afirmar que quien desarrolló el sistema no deba realizar ninguna tarea de auditoría. El desarrollador puede aportar:
una autoevaluación técnica,
la preparación de evidencias,
apoyo a las pruebas,
explicaciones de los errores.
Pero no debe emitir por sí solo el dictamen final independiente sobre la conformidad de su propio sistema. Si una misma persona:
diseña el sistema,
elige los escenarios de prueba,
produce las evidencias,
determina la importancia de los hallazgos,
y aprueba el distintivo público,
desaparece la frontera entre auditoría y autodeclaración. Un reparto adecuado de responsabilidades podría ser:
El desarrollador produce las evidencias. El auditor independiente las pone a prueba. La organización asume la responsabilidad por la decisión sobre el riesgo.
¿Puede el auditor prestar servicios de corrección?
El auditor puede ayudar a corregir un problema que haya detectado. No siempre es incorrecto: conocer el sistema puede acelerar la corrección. Pero aparecen dos riesgos:
Puede exagerar un hallazgo para vender más servicios de corrección.
Puede aprobar su propia corrección y presentar esa aprobación como independiente.
Las siguientes medidas deben combinarse según el tipo de conflicto de interés. Revelar la relación o separar los contratos no basta para que la aprobación de una corrección propia sea independiente. Al cerrar un hallazgo crítico, las evidencias de la nueva prueba deben ser revisadas por un auditor distinto de quien realizó la corrección y cuyos intereses relacionados se hayan evaluado:
Separar los contratos de corrección y auditoría
No vincular los honorarios al número de hallazgos
Encargar la prueba posterior a la corrección a otro evaluador
Declarar la relación de interés en el informe
Exigir una segunda firma para cerrar hallazgos críticos
El auditor puede proponer una solución, pero no debe afirmar que la organización está obligada a comprar la solución que propone.
Declaración de conflictos de interés en la auditoría
Cada auditor y equipo de auditoría debe declarar las siguientes relaciones:
Participación en el diseño del sistema
Relación comercial vigente con la organización
Remuneración condicionada al resultado de la auditoría
Venta de servicios de corrección o productos
Relación con una organización competidora
Comisiones del proveedor auditado
Relación personal estrecha con directivos o empleados
Alianza con el mismo proveedor del modelo o de las herramientas
Interés directo en el resultado de la auditoría por motivos de reputación o publicación
Declarar un conflicto de interés no siempre lo elimina, pero impide que permanezca oculto. Algunos conflictos pueden gestionarse. Otros exigen que el auditor se abstenga de emitir el dictamen afectado. Quien desarrolló el sistema, por ejemplo, puede aportar evidencias técnicas, pero no debe firmar el dictamen final de «conformidad independiente».
La independencia también protege a la organización auditada
La independencia no solo protege al auditor frente a las presiones de la organización. También debe proteger a la organización frente a la arbitrariedad del auditor. Este no puede:
ampliar el alcance sin permiso,
emitir un dictamen severo sin evidencias que lo respalden,
hacer públicos secretos comerciales,
generar miedo para vender servicios de corrección,
presentar el resultado de una prueba sintética como un incidente real en producción,
impedir que la organización ejerza su derecho de respuesta.
La independencia no permite actuar sin autorización. El auditor es libre, pero dentro de los límites de las evidencias, el alcance y la responsabilidad profesional.
¿Qué es el alcance de una auditoría?
Una organización puede pedir: «Auditen nuestro agente de ventas». Eso no basta. Un agente de ventas puede realizar:
Investigación en la web
Evaluación de si una empresa encaja como cliente potencial
Búsqueda de personas de contacto
Enriquecimiento de datos
Redacción de borradores de correo
Envío de correos
Mensajes de WhatsApp
Programación de reuniones
Propuestas de precios
Registro en el CRM
Comunicaciones de seguimiento
Llamadas a subagentes
¿Cuáles de estas tareas están incluidas? ¿En qué idiomas y países? ¿Con qué cuentas y clases de datos? ¿En qué entorno? ¿Qué funciones cumplen las personas implicadas? El alcance no es solo el nombre del agente. Es el límite exterior del dictamen de auditoría.
Los nueve ejes del alcance
En el Protocolo de auditoría NOMOS GBO, el alcance debe definirse en al menos nueve ejes.
1. Sistema
¿Qué modelo, agente, subagente y orquestación?
2. Comportamiento
¿Investigación, recomendación, borrador, envío, pago, publicación, eliminación o detención?
3. Herramientas
¿Qué herramientas de correo, CRM, archivos, navegador, pagos o publicación?
4. Datos
¿Qué datos públicos, internos, personales, sensibles o biométricos?
5. Personas
¿Qué usuarios, empleados, clientes o grupos afectados?
6. Idioma y geografía
¿Qué idiomas, países, regiones y contextos jurídicos?
7. Entorno
¿Local, de pruebas, en modo sombra, en vivo limitado o en producción completa?
8. Tiempo
¿Qué fechas, versiones, periodos de tareas y colas?
9. Ciclo de vida
¿Qué etapas de inicio, continuación, transferencia, detención, reversión, impugnación y reinicio? Si uno de estos ejes queda sin definir, el dictamen puede extenderse indebidamente.
¿Por qué importan las exclusiones?
Los informes de auditoría suelen describir lo incluido y relegar las exclusiones a una pequeña nota al pie. Sin embargo, para comprender el dictamen, los comportamientos excluidos son al menos tan importantes como los incluidos. El caso de un agente de compras podría ser este:
Se probó en compras únicas.
No se probó en renovaciones automáticas.
No se probó en cancelaciones.
Solo se probó con tres vendedores aprobados.
Si la declaración pública dice «Se auditó el agente de compras», el usuario puede entender que se evaluó todo su ciclo de compra. Sería más preciso decir: «Se auditó el comportamiento del agente en compras únicas, reversibles y de bajo riesgo a tres vendedores aprobados. Las suscripciones, renovaciones, cancelaciones y operaciones con nuevos vendedores quedan fuera del alcance». Cada exclusión relevante debe responder a tres preguntas:
¿Por qué se excluyó?
¿Qué riesgo persiste?
¿Cómo limita la afirmación de auditoría?
Fuera del alcance no significa seguro
Excluir un comportamiento puede dar lugar a tres interpretaciones erróneas.
Interpretación errónea 1
«Como no se probó, no hay ningún problema». Lo cierto es que no se sabe si existe un problema.
Interpretación errónea 2
«Como está fuera del alcance, no es importante». Lo cierto es que puede haberse excluido precisamente por su riesgo.
Interpretación errónea 3
«Si el sistema principal pasó la auditoría, la parte excluida probablemente también la pasaría». Lo cierto es que un comportamiento que usa otras herramientas, autorizaciones o datos puede producir un resultado distinto. Lo excluido no recibe un dictamen positivo ni negativo: constituye una incertidumbre declarada.
Blanqueo del alcance
Una organización puede auditar la parte más segura de su sistema y utilizar el resultado para hablar del conjunto. Por ejemplo:
Solo se prueba el agente de borradores.
El resultado se publica como «se auditó el sistema de agentes de ventas».
Solo se evalúa el entorno de pruebas.
El resultado se presenta como «el sistema en vivo es seguro».
Solo se ejecutan escenarios en inglés.
El resultado se anuncia como «el agente multilingüe cumple los requisitos».
Solo se examina el agente central.
El resultado se aplica a toda la red de subagentes.
Solo se utilizan escenarios positivos.
El resultado se presenta como garantía del control de autorizaciones y de la capacidad de detención.
Podemos llamar a esta práctica:
Blanqueo del alcance
El blanqueo del alcance consiste en presentar el resultado de una auditoría limitada, fácil o de bajo riesgo como evidencia de confianza para un sistema, comportamiento, idioma o ámbito de riesgo más amplio. Es una forma de informar que induce a error. Aunque el resultado técnico sea correcto, el significado transmitido al público es falso.
Limitar el alcance a ejemplos favorables
La organización puede elegir únicamente los ámbitos en los que obtiene buenos resultados. Por ejemplo:
Se incluyen los vendedores aprobados.
Se excluyen los vendedores nuevos y aquellos sobre los que hay incertidumbre.
Se prueban las acciones aprobadas por una persona.
No se prueban los límites cuando falta la aprobación.
Se incluye el inglés.
Se excluyen las versiones lingüísticas más débiles.
Se utiliza el entorno de pruebas.
No se examinan los permisos de los tokens en vivo.
Se prueba el agente principal.
Se excluye la delegación de autorizaciones a los subagentes.
No toda delimitación es incorrecta. Los recursos y los riesgos pueden exigir una auditoría por etapas. El problema aparece cuando se elige el alcance para presentar el resultado mejor de lo que es y no se explica esa elección. Podemos llamarlo:
Limitar el alcance a ejemplos favorables
La organización puede realizar una auditoría limitada. Pero debe explicar por qué lo es y qué riesgos deja pendientes.
Excluir un área de riesgo
Algunos comportamientos con consecuencias importantes son difíciles de auditar en la práctica. Puede no ser deseable realizar pagos reales. Comunicarse con clientes reales implica riesgos. La generación de material biométrico es delicada. En vez de excluir por completo estos comportamientos, pueden utilizarse simulaciones seguras:
Un medio de pago de prueba
Una dirección de correo para la auditoría
Un cliente sintético
Un avatar artificial autorizado
Colas de prueba separadas
Modo sombra
Una cuenta controlada para pruebas en vivo (canary): se utiliza para una prueba de alcance reducido, con el alcance escrito, los límites de datos y el procedimiento de detención definidos de antemano.
Si no es posible probar directamente el comportamiento de riesgo en vivo, pueden combinarse:
Permisos técnicos,
configuración,
comportamiento sintético,
evidencias de incidentes anteriores,
validación limitada mediante canary.
La auditoría debe diseñarse para ser segura o el dictamen debe limitarse de forma explícita.
Alcance representativo y alcance completo
No es posible probar cada sistema en todos los escenarios imaginables. La auditoría puede recurrir al muestreo, pero la muestra debe ser representativa. Por ejemplo, un sistema que admite seis idiomas puede probarse por completo en dos y con un conjunto limitado de escenarios en los otros cuatro. Es posible, pero la elección debe basarse en:
La familia lingüística
La dirección de derecha a izquierda
Las diferencias en terminología comercial
La tasa histórica de errores
El volumen de uso
El riesgo
Si el árabe produce un comportamiento propio en el idioma y en la presentación de derecha a izquierda, no es correcto representarlo con resultados en inglés. Tampoco una búsqueda de productos que implique poco riesgo puede representar un comportamiento de pago de alto riesgo. El muestreo puede reducir el número de pruebas; no puede ignorar las diferencias de comportamiento. El método de muestreo de escenarios se desarrolla en detalle en el capítulo seis.
¿Por qué es necesario fijar el alcance?
Si el sistema sigue cambiando durante la auditoría, deja de saberse qué versión se auditó. Un escenario falla. El desarrollador modifica una instrucción. Al repetir la prueba, el sistema la supera. El informe solo muestra el último resultado. Esto genera confusión al responder a las siguientes preguntas:
¿Falló el sistema original?
¿Pasó la prueba el sistema nuevo?
¿Qué versión se ofrece al público?
¿Qué versión funciona en vivo?
Corregir no está prohibido. Al contrario: mejorar es uno de los fines de la auditoría. Pero el primer resultado no debe borrarse, y la nueva versión debe probarse por separado. Por eso, antes de iniciar la auditoría se crea el siguiente registro:
Registro de fijación del alcance
¿Qué se documenta en el Registro de fijación del alcance?
Como mínimo, deben registrarse:
Las versiones del agente y del modelo
Las instrucciones del sistema y del desarrollador
El acuerdo de autorización
La lista de herramientas
Los permisos de API
Las cuentas de servicio
Los subagentes
La estructura de la memoria y la instantánea pertinente de su estado
Las fuentes de datos de referencia
Las funciones de las personas
El entorno de pruebas
Las diferencias respecto al entorno en vivo
Las versiones lingüísticas
La configuración de medición
El sistema de detención y recuperación
Los hashes de archivos o configuraciones críticos
La fecha y hora de inicio y fin de la auditoría
No es necesario conservar una copia completa de cada detalle. Pero deben existir identificadores de versión que permitan demostrar a qué sistema corresponde el resultado.
¿Qué ocurre si hay cambios durante la auditoría?
Los cambios pueden dividirse en tres clases.
Clase A — Cambio no sustancial
Una corrección ortográfica o una aclaración que no afecte al comportamiento auditado. Se registra y la auditoría puede continuar.
Clase B — Cambio sustancial limitado
Un cambio de herramienta, instrucción o autorización que afecta a un área concreta de prueba. Los escenarios correspondientes se ejecutan de nuevo con la nueva versión. Se conserva el resultado anterior.
Clase C — Cambio sustancial fundamental
Cambiar el modelo, la autorización para actuar, la arquitectura de subagentes, la fuente de datos o el sistema de detención invalida la fijación del alcance. Hace falta una nueva versión de auditoría o una nueva línea de base. Por ejemplo, retirar el permiso send_message después de detectar un envío sin aprobación es una corrección positiva. Pero no permite afirmar que en el sistema original «no hubo infracción». El registro correcto sería:
v2.4: Se observó un envío sin aprobación. Corrección: Se retiró la herramienta de envío. Nueva prueba de v2.5: No se observaron envíos en los 24 escenarios correspondientes.
Este registro muestra el aprendizaje de la organización, no su debilidad.
Correcciones silenciosas durante la auditoría
Tras fallar una prueba, el desarrollador puede modificar el sistema en segundo plano y ejecutarlo de nuevo con la misma identidad. Entonces puede presentar el resultado como «Al final pasó la prueba». Pero la integridad de la auditoría queda comprometida. Podemos llamar a esta práctica:
Corrección silenciosa durante la auditoría
Todo cambio debe registrarse con:
la fecha,
la persona o el agente que lo realizó,
el motivo,
los escenarios afectados,
la nueva versión.
La auditoría no se hace para fabricar la imagen de un sistema impecable, sino para mostrar su comportamiento real y el camino para mejorarlo.
Primer documento principal: Documento de autorización de la auditoría
Tras la ficha de la afirmación que se audita, debe elaborarse el siguiente documento:
Documento de autorización de la auditoría NOMOS GBO
Este documento define las acciones que puede realizar el auditor y la responsabilidad de la organización.
DOCUMENTO DE AUTORIZACIÓN DE LA AUDITORÍA — EJEMPLO LEGIBLE PARA PERSONAS
Identificador de auditoría: GBO-AUDIT-2026-001
Solicitante: Dirección de Operaciones de NobleAxis
Persona que concede la autorización: Nombre, función y fundamento de su capacidad de representación
Responsable del sistema: Responsable de Operaciones de Ventas
Responsable técnico: Responsable de Sistemas de Agentes
Persona autorizada responsable del uso de datos: Contacto operativo designado; el responsable del tratamiento en sentido jurídico y, si existe, el encargado del tratamiento se registran por separado.
Auditor: Equipo independiente de auditoría GBO
Finalidad de la auditoría: Evaluar el comportamiento del agente de prospección en la investigación, la redacción de borradores, los envíos aprobados por una persona y la detención.
Acciones de auditoría permitidas:
Revisión de documentos
Revisión de permisos y registros en modo de solo lectura
Uso de empresas y destinatarios sintéticos
Mensajes controlados a la dirección de correo de auditoría
Pruebas de autorización de subagentes
Simulacro de detención de colas
Pruebas de instrucciones externas en el entorno de auditoría
En el sistema en vivo, uso exclusivo de la cuenta canary definida de antemano
Acciones de auditoría prohibidas:
Enviar mensajes a clientes reales
Realizar pagos reales
Eliminar datos de clientes en producción
Copiar datos personales sin autorización
Publicar contenido de acceso público
Detener el sistema de producción sin aviso
Cargar datos de auditoría en un sistema de IA externo sin aprobación
Autorización del auditor para la detención de emergencia: suspender temporalmente nuevas operaciones al observar envíos externos no autorizados en curso, transferencias no autorizadas de datos personales o acciones de alto impacto fuera de control; avisar de inmediato al responsable del incidente en la organización.
Plan de conservación de evidencias: Este ejemplo sintético prevé 180 días, almacenamiento cifrado y comprobante de eliminación. El plazo no es una obligación jurídica universal. Deben evaluarse por separado la finalidad concreta, el tipo de datos y las obligaciones vigentes. Si existe una controversia pendiente o un deber de conservación, el plazo se revisa de nuevo con una justificación.
Uso de subcontratistas o herramientas de IA: Declarado, aprobado y con límites de datos definidos.
Derecho de respuesta de la organización: Puede presentar evidencias y explicaciones sobre cada hallazgo dentro de un plazo determinado.
Derecho de la organización a vetar hallazgos: No existe. Puede corregirse un error de hecho demostrado, pero no retirarse un hallazgo basado en evidencias por motivos comerciales.
Declaración pública: Solo puede publicarse un resumen aprobado que indique el alcance real, la versión, la fecha y las limitaciones explícitas.
Inicio y fin de la autorización: Del 1 de septiembre de 2026 a las 09:00 al 15 de septiembre de 2026 a las 18:00, hora de Turquía (UTC+03:00). Las pruebas posteriores requieren una autorización nueva o renovada expresamente.
Condición para volver a autorizar: Si cambia el alcance o el nivel de actuación, se necesita una nueva autorización.
Documento de autorización de la auditoría en formato legible por máquinas
audit_authorization:
audit_id: GBO-AUDIT-2026-001
authorized_by:
role: authorized_system_owner
authority_basis: internal_governance_record
system_owner:
role: sales_operations_owner
technical_owner:
role: agent_platform_owner
auditor:
identity: independent_audit_team
independence_level: III
permitted_actions:
- document_review
- read_only_permission_review
- synthetic_entity_testing
- controlled_email_to_audit_address
- subagent_authority_test
- queue_stop_drill
- prompt_injection_test
- controlled_live_testing_only_in_pre_authorized_canary_account
prohibited_actions:
- contact_real_customer
- execute_real_payment
- delete_live_customer_data
- publish_public_content
- upload_evidence_to_unapproved_ai_service
- unannounced_production_shutdown_outside_emergency_scope
data_scope:
allowed:
- public_company_data
- masked_transaction_logs
- synthetic_customer_records
prohibited:
- unrelated_personal_data
- unrestricted_full_mailbox_export
emergency_stop:
permitted: true
limited_to_containment_of_in_scope_new_actions: true
immediate_notification_to_incident_owner: required
triggers:
- unauthorized_live_send
- prohibited_data_exfiltration
- uncontrolled_high_impact_action
evidence_retention:
duration_days: 180
encryption_required: true
deletion_receipt_required: true
example_duration_not_universal_legal_rule: true
review_on_ongoing_dispute_or_preservation_duty: required
external_ai_or_subcontractor_use:
prior_disclosure: required
explicit_approval: required
defined_data_boundary: required
public_disclosure:
scope_limited: true
client_review_for_factual_errors: true
client_veto_over_findings: false
valid_from: 2026-09-01T09:00:00+03:00
valid_until: 2026-09-15T18:00:00+03:00El documento establece los límites de la autorización del auditor. Para respetarlos, el acceso técnico y los controles de las pruebas también deben configurarse de acuerdo con él.
Segundo documento principal: Registro de fijación del alcance
Después del Documento de autorización de la auditoría, se registra el estado del sistema en ese momento.
REGISTRO DE FIJACIÓN DEL ALCANCE — EJEMPLO
Identificador de auditoría: GBO-AUDIT-2026-001
Momento de fijación: 1 de septiembre de 2026, 09:30
Agente central: SALES-RESEARCH-v2.4
Versión del modelo base: Identificador técnico registrado
Instrucción del sistema: POLICY-v3.1 — hash registrado
Acuerdo de autorización: AUTH-v2.7
Subagentes:
Web Research v1.8
Recipient Resolution v1.4
Email Drafting v2.1
Approved Send v1.3
Queue Manager v1.2
Herramientas conectadas:
Búsqueda web
Lectura/escritura en CRM
Borradores/envío en Gmail
Calendario
Cola de tareas
Permisos de API reales: Registrados por herramienta.
Estado de la memoria: Memoria persistente de preferencias activada; no se permite guardar datos personales de clientes en la memoria.
Fuentes de datos de referencia:
Catálogo de servicios v4.2
Registro de precios v3.7
Registro de autorizaciones de personas v2.5
Política de comunicación v3.0
Idiomas incluidos: Inglés, turco, alemán
Idiomas excluidos: Árabe, español, ruso
Entorno de pruebas: CRM sintético y direcciones de correo de auditoría.
Ámbito limitado en vivo: Infraestructura real de Gmail, con envíos únicamente al dominio de auditoría.
Sistema de detención: Agente central, subagentes, cola y token de envío de Gmail.
Punto de recuperación: Manifiesto de herramientas y autorizaciones anterior a la auditoría.
Cambios que se consideran sustanciales:
Cambio de modelo
Cambio de herramienta de envío
Nuevo subagente
Cambio de política de autorización
Cambio de memoria persistente
Nuevo idioma
Uso de datos de clientes en producción
Firmas de fijación: Responsable del sistema, responsable técnico y auditor.
Qué implica el Registro de fijación del alcance
Fijar el sistema no obliga a dejarlo inmóvil como una pieza de museo. La operación diaria puede continuar, pero debe conservarse la identidad de la versión auditada. Si cambia el sistema en vivo:
Puede conservarse la versión auditada en un entorno separado.
Puede registrarse el cambio.
Pueden repetirse las pruebas pertinentes.
Puede reducirse el alcance del dictamen.
Lo importante es no perder la relación entre cada resultado y la versión a la que corresponde.
Declaración de independencia y alcance
El informe de auditoría debe incluir una declaración separada:
Declaración de independencia y alcance
Ejemplo: «El equipo de auditoría no participó en el desarrollo del sistema auditado. Sus honorarios no dependen del resultado. El equipo puede prestar servicios de corrección; otro evaluador realizará las pruebas de cierre de hallazgos críticos. La auditoría abarca la prospección de clientes en inglés, turco y alemán. Quedan excluidos WhatsApp, las propuestas financieras, la aceptación de contratos y los comportamientos en árabe, español y ruso. No se contactó con clientes reales; se utilizaron direcciones controladas de auditoría». La declaración puede ser breve, pero no debe ocultar relaciones relevantes.
El derecho de respuesta de la organización
Los hallazgos pueden ser erróneos. El auditor puede haber pasado por alto un documento importante, interpretado mal la finalidad de un comportamiento o leído de forma incompleta un registro técnico. Por eso, la organización debe poder responder a cada hallazgo. Su respuesta puede consistir en:
Aportar nuevas evidencias
Corregir un error de hecho
Aclarar el alcance
Explicar el contexto técnico
Aceptar el riesgo
Presentar un plan de corrección
Expresar una discrepancia
El informe final puede distinguir:
HALLAZGO DEL AUDITOR RESPUESTA DE LA ORGANIZACIÓN VALORACIÓN FINAL DEL AUDITOR
El derecho de respuesta no es un derecho a retirar el hallazgo. El auditor tampoco debe ignorar las respuestas de la organización.
Discrepancias
La valoración de algunos comportamientos puede no ser clara. Por ejemplo:
¿Hace falta aprobación humana para una operación concreta?
¿Un uso de datos está suficientemente vinculado a la finalidad original?
¿Un proveedor es realmente una fuente independiente?
¿El cambio es sustancial?
Las partes pueden no llegar a un acuerdo. El informe no debe fabricar un consenso. Podría indicarse:
Posición del auditor: La nueva finalidad de uso supera el alcance del consentimiento original. Posición de la organización: El uso está comprendido en la finalidad existente de desarrollo del servicio. Estado: Hallazgo de alta prioridad sobre limitación de la finalidad, aún sin resolver. Se recomienda suspender el uso de datos afectado y someterlo a revisión especializada.
Hacer visible el desacuerdo no resta credibilidad. Deja constancia honesta de dónde resulta difícil establecer la verdad.
¿Quién asume el riesgo residual?
El auditor comunica un hallazgo. La organización puede no estar en condiciones de corregirlo de inmediato. Es posible aceptar temporalmente un riesgo concreto. Por ejemplo:
Un acceso amplio puede seguir habilitado durante un periodo breve en un entorno de pruebas de bajo riesgo.
El sistema antiguo puede seguir funcionando hasta que concluya la migración.
Una versión lingüística determinada puede quedar a la espera de nuevas pruebas.
Aceptar el riesgo no es tarea del auditor. El auditor:
identifica el riesgo,
lo sustenta con evidencias,
explica su importancia,
formula una recomendación.
Una persona autorizada de la organización decide aceptar el riesgo. Esa aceptación debe:
tener un plazo,
estar justificada,
tener límites,
incluir una fecha de reevaluación.
El agente o el desarrollador no puede aceptar por sí solo el riesgo identificado en su propio hallazgo. Aceptar el riesgo no significa que haya desaparecido. Indica quién ha asumido la responsabilidad y durante cuánto tiempo.
Uso de herramientas de IA en la auditoría
El auditor GBO también puede utilizar herramientas de IA. Por ejemplo, recurrir a agentes para:
clasificar registros,
agrupar incidentes similares,
comparar textos multilingües,
generar variantes de prueba,
organizar el registro de evidencias,
encontrar contradicciones.
Esto mejora la eficiencia, pero los agentes de auditoría también están sujetos al protocolo. Deben responderse las siguientes preguntas:
¿Qué modelo se utilizó?
¿A qué datos accedió?
¿Se enviaron evidencias a un sistema externo?
¿Una persona verificó el resultado?
¿La clasificación del agente es un hallazgo final o una sugerencia?
¿El agente de auditoría se verificó a sí mismo?
¿Qué versión se utilizó?
¿Cómo se gestionará un error o un incidente de privacidad?
El auditor no puede limitarse a decir: «La IA analizó todos los registros y no encontró ningún problema». Eso es solo la afirmación de otro sistema. Debe seguir estando claro qué persona y qué organización responden por el dictamen final.
Proteger las evidencias de auditoría
La independencia no consiste solo en acceder a las evidencias. También importa protegerlas frente a alteraciones posteriores. Como mínimo, puede conservarse la siguiente información:
Identificador de la fuente
Momento de obtención
Versión
Hash o registro de integridad
Método de enmascaramiento
Quiénes accedieron
Transformaciones realizadas
Periodo de conservación
Registro de eliminación
El auditor no debe conservar indefinidamente una copia de todos los datos en vivo. Pero la base de un hallazgo crítico debe poder reconstruirse después. La conservación y la cadena de evidencias se desarrollan en detalle en el capítulo cuatro.
La relación entre autorización, independencia y alcance
Estos tres conceptos parecen separados. En realidad, se limitan entre sí.
Autorización
¿Qué puede hacer el auditor?
Independencia
¿Con cuánta libertad y honestidad puede interpretar lo que observa?
Alcance
¿Sobre qué sistema y comportamientos puede emitir un dictamen? Un auditor puede disponer de una autorización amplia, pero si depende económicamente del resultado, disminuye la confianza en su interpretación. Puede ser independiente, pero si no logra examinar los permisos técnicos, baja el nivel de evidencia. El alcance definido puede ser amplio, pero sin autorización para pruebas en vivo, el dictamen sobre el comportamiento sigue siendo limitado. Una auditoría fiable puede expresarse así:
AUDITORÍA FIABLE = AUTORIZACIÓN VÁLIDA E INDEPENDENCIA PROTEGIDA MEDIANTE CONTROLES Y ALCANCE CLARO Y ACCESO SUFICIENTE A LAS EVIDENCIAS Y AUTORIZACIÓN PARA PRUEBAS SEGURAS Y DECLARACIÓN PÚBLICA LIMITADA
Ninguno de estos elementos sustituye a otro.
Puerta de autorización e independencia previa a la auditoría
Antes de iniciar las pruebas deben superarse las siguientes puertas:
1. Puerta de quien autoriza
¿La persona u organización que solicita la auditoría tiene realmente autorización para hacerlo?
2. Puerta de responsabilidad del sistema
¿Están identificados los responsables humanos y técnicos del sistema auditado?
3. Puerta de autorización sobre los datos
¿Con qué fundamento legítimo y limitado puede el auditor consultar los datos necesarios?
4. Puerta de autorización para actuar
¿Qué nivel de autorización tiene el auditor para revisar documentos, realizar pruebas sintéticas o en vivo y detener el sistema?
5. Puerta de límites del daño
¿Qué efectos puede causar la auditoría en personas reales, dinero, datos u operaciones?
6. Puerta de independencia
¿Qué grado de independencia organizativa, financiera, técnica y de interpretación existe?
7. Puerta de conflictos de interés
¿Se han declarado las relaciones con la construcción, corrección o venta del sistema, o con la promoción del resultado?
8. Puerta de alcance completo
¿Están definidos con claridad el sistema, los comportamientos, las herramientas, los datos, los idiomas, el entorno y el ciclo de vida?
9. Puerta de riesgos excluidos
¿Son visibles las áreas relevantes excluidas y sus efectos?
10. Puerta de fijación
¿Se han fijado la versión y la configuración auditadas?
11. Puerta de detención de emergencia
Si durante la auditoría se observa un daño en vivo, ¿quién detendrá el sistema y cómo?
12. Puerta de declaración pública
¿Podría presentarse el resultado como si cubriera más que su alcance real? En pocas palabras:
AUTORIZACIÓN PARA INICIAR LA AUDITORÍA = SOLICITUD DE UNA PARTE AUTORIZADA Y RESPONSABLE DEL SISTEMA IDENTIFICADO Y ACCESO LIMITADO A DATOS Y AUTORIZACIÓN EXPLÍCITA PARA LAS PRUEBAS Y CONFLICTOS DE INTERÉS GESTIONADOS Y ALCANCE FIJADO Y DETENCIÓN SEGURA Y DECLARACIÓN PÚBLICA HONESTA
Si faltan la autorización o las condiciones de prueba seguras, la acción afectada no se inicia. La auditoría solo puede continuar con un alcance más reducido que mantenga tanto la autorización válida como las condiciones seguras. El método y el dictamen deben limitarse en consecuencia.
Estados de autorización de la auditoría
Una auditoría puede encontrarse en uno de estos estados:
Autorizada
Se cuenta con todas las autorizaciones necesarias: las de las personas responsables y las relativas al sistema, los datos y las pruebas.
Autorizada con condiciones
Puede realizarse con límites concretos de datos, entorno o acciones.
Autorizada solo para revisión documental
No hay autorización para pruebas técnicas ni de comportamiento. El dictamen se limita a declaraciones y documentos.
Autorización insuficiente
No se dispone del acceso o del derecho a realizar las pruebas necesarias para examinar la afirmación solicitada.
Suspendida
La auditoría se ha detenido temporalmente por un cambio sustancial del sistema, un incidente o un problema de autorización.
Dada por terminada
Ya no es posible mantener la integridad de la auditoría, la seguridad de las evidencias o las condiciones de autorización. Estos estados deben comunicarse expresamente. Cuando una auditoría no puede completarse, hay que explicar por qué no se pudo emitir un dictamen, en vez de limitarse a decir: «Falló».
Teatro de auditoría
Una organización puede presentar:
Una demostración impecable
Capturas de pantalla seleccionadas
Una puntuación de éxito elevada
Opiniones favorables de clientes
Una política cuidadosamente elaborada
Un distintivo de auditoría
Pero si el auditor no puede examinar:
los permisos reales,
las pruebas fallidas,
los subagentes,
las colas,
las áreas excluidas del alcance,
los registros de incidentes,
el trabajo se convierte en:
Teatro de auditoría
Hay teatro de auditoría cuando la apariencia de fiabilidad se impone a las evidencias del comportamiento. Estas son sus señales:
Solo la organización elige las pruebas.
El sistema cambia en silencio durante las pruebas.
Los resultados fallidos se eliminan del informe.
El auditor no puede redactar libremente la declaración pública.
Se ocultan los riesgos excluidos del alcance.
El distintivo es más visible que el informe completo.
La remuneración o la continuidad de la auditoría dependen de un resultado favorable.
En lugar de evidencias sin procesar, se muestra una presentación preparada.
El protocolo GBO debe proteger también a la propia auditoría frente a estos riesgos.
Honestidad sobre el alcance en la declaración pública
Al publicar el resultado de una auditoría, deben distinguirse cuatro afirmaciones:
Auditado
Se realizó un examen determinado.
Superó la auditoría dentro de un alcance definido
Se cumplieron las condiciones en los comportamientos y escenarios definidos.
Apto con condiciones
El sistema puede utilizarse sujeto a determinados hallazgos o límites de uso.
No apto por un hallazgo crítico
El sistema no está listo para su uso en un área concreta de comportamiento. Deben evitarse afirmaciones sin límites como estas:
«Cumple plenamente con GBO». «Es seguro en todos los agentes». «No comete errores». «Control humano garantizado». «Protegido frente a los 99 errores».
Si las evidencias solo respaldan una versión y un alcance concretos, la declaración pública debe mantenerse dentro de esos mismos límites.
El dictamen del capítulo
Una auditoría GBO no empieza con pruebas técnicas. Primero hay que responder estas preguntas:
¿Quién solicitó la auditoría? ¿Quién la autorizó? ¿Tiene esa persona realmente derecho a hacerlo? ¿A qué datos puede acceder el auditor? ¿Qué comportamientos puede probar de forma segura? ¿Hasta dónde puede intervenir en el sistema en producción? ¿Puede detenerlo si observa un daño que continúa? ¿Qué intereses comerciales e institucionales tiene? ¿Qué comportamientos están incluidos y cuáles quedan fuera? ¿Qué versión del sistema se mantendrá durante las pruebas? ¿Dentro de qué límites se hará público el resultado?
Una auditoría realizada sin estas respuestas puede parecer sólida. Sin embargo, entraña tres riesgos fundamentales:
Puede carecer de autorización.
Puede carecer de independencia.
Puede presentarse como más amplia de lo que realmente es.
La autorización para auditar no otorga acceso ilimitado al sistema. La independencia no permite al auditor emitir cualquier juicio al margen de las evidencias y del alcance. Tampoco sirve el alcance para elegir unos pocos escenarios fáciles y declarar fiable el sistema entero. Una auditoría GBO fiable mantiene este equilibrio:
El auditor puede obtener las evidencias necesarias. Pero no puede tomar datos que no necesita. Puede poner a prueba el sistema de forma realista. Pero no puede causar daños incontrolados en nombre de la auditoría. La organización puede responder a un hallazgo. Pero no puede borrarlo por razones comerciales. La auditoría puede ser limitada. Pero no puede presentarse al público como ilimitada. El sistema puede corregirse. Pero el fallo original no puede desaparecer del registro.
La primera conclusión del capítulo es esta: el derecho a auditar el comportamiento exige un contrato de comportamiento explícito y limitado para la propia auditoría. Segunda: independencia no significa ausencia de relaciones; significa que los intereses son visibles, se gestionan y se limita su presión sobre los hallazgos. Tercera: el alcance debe mostrar tanto lo que la auditoría desconoce como lo que sabe. Cuarta: un cambio sustancial durante las pruebas exige un registro de nueva versión o de nuevo alcance. El fallo original no se borra; la corrección y la repetición de la prueba se registran por separado. Quinta: un resultado de alcance reducido no permite declarar fiable toda la red de agentes, todas las lenguas o todo el ámbito de riesgo.
Y la última conclusión: si la propia auditoría carece de autorización o independencia, o tiene un alcance impreciso, la alta puntuación del agente no constituye una evidencia fiable. Ahora contamos con:
La ficha de la afirmación que se audita
El Documento de autorización de la auditoría
El Registro de fijación del alcance
La Declaración de independencia y alcance
Sin embargo, el sistema que vamos a auditar aún puede ser una caja de la que solo conocemos los nombres. Llamarlo «agente de ventas», «agente web» o «agente del director ejecutivo» no revela su verdadera arquitectura de comportamiento. ¿En nombre de qué persona trabaja el agente? ¿A qué subagentes llama? ¿A qué herramientas tiene acceso? ¿Qué datos llegan de cada sistema? ¿Qué acciones pasan por la aprobación de qué persona? ¿Por qué colas y plataformas externas se extiende una tarea? ¿A qué puntos debe llegar la orden de detención? Sin trazar estas relaciones, no podemos diseñar el escenario adecuado. Podemos probar el objetivo equivocado, dejar fuera a un subagente crítico o no detectar la vía real del blanqueo de autorizaciones. En el siguiente capítulo haremos visible el ámbito de comportamiento de la auditoría:
Mapa de comportamiento: personas, agentes, herramientas y autorizaciones
Para auditar un sistema, primero hay que ver algo más que lo que es: en nombre de quién actúa, con qué herramienta, con qué datos y a través de qué cadena de comportamiento influye en el mundo.
Un sistema de agentes sin mapa no se audita. Solo se examina su cara visible.