Información de referencia y cadena de evidencias

El agente de ventas de una empresa envía esta oferta a un posible cliente: «Nuestro servicio de gestión operativa de sitios web parte de 350 dólares al mes». El cliente comunica que está dispuesto a aceptar. El director comercial ve el mensaje y se sorprende: el precio inicial vigente es de 500 dólares al mes. Le pregunta al agente: «¿De dónde sacaste los 350 dólares?» El agente responde: «Encontré ese precio en las fuentes comerciales aprobadas de la empresa». Revisan el sitio web. La página del servicio dice claramente: «Managed Site Operations — Starting at 500 USD/month.» El director toma una captura de pantalla y afirma: «El agente ha generado información incorrecta. El precio de referencia ya está bien en el sitio web».

Se considera que el incidente es un simple error del modelo. Pero el auditor no se limita a la página web actual. Pregunta: ¿a qué información podía acceder el agente en el momento de enviar el mensaje? Los registros se examinan paso a paso. A las 08:42, el registro de precios aprobado indica 500 dólares al mes. A las 08:51, una antigua plantilla de ofertas del CRM de ventas todavía muestra 350 dólares. A las 08:56, el índice de conocimiento del agente de ventas se reconstruyó a partir de esa plantilla del CRM. A las 09:14, el agente envió al cliente el precio de 350 dólares. A las 09:22, el responsable humano advirtió el error y corrigió la plantilla del CRM. A las 09:31, se tomó la captura del sitio web. A las 09:45, se actualizó de nuevo el índice de conocimiento del agente.

La captura aportada por la empresa respalda la afirmación de que la página mostraba un precio de 500 dólares a las 09:31. No demuestra qué registro utilizó el agente a las 09:14. El auditor encuentra otras evidencias:

El recibo de la acción de envío del correo identifica como fuente la antigua plantilla del CRM.

La versión del índice de conocimiento del agente no incluye la versión actual del registro de precios.

La antigua plantilla procede de un descuento temporal concedido a un cliente concreto.

El registro del descuento no tiene fecha de finalización.

La persona responsable de la plantilla del CRM ya no trabaja en la empresa.

Ninguna regla del sistema indica que la plantilla no es una fuente de precios de referencia.

El sitio web mostró el precio correcto a las personas.

El agente de ventas utilizó la antigua plantilla interna, no la página destinada a las personas.

Ya no basta con explicar el incidente diciendo: «El agente dio un precio incorrecto». Una explicación más precisa sería:

El precio vigente y autorizado de la organización era de 500 dólares. Pero el antiguo registro de 350 dólares seguía activo en el entorno de información operativa del agente. Las personas y la máquina trabajaban con datos distintos. El agente no pudo determinar qué fuente era la de referencia. La captura actual no acreditaba la situación en el momento de la actuación anterior. La organización había corregido la información errónea, pero estuvo a punto de perder la cadena de evidencias previa al incidente.

Ahora hay tres realidades distintas:

La información establecida por la fuente autorizada

El precio vigente es de 500 dólares al mes.

La información operativa a la que podía acceder el agente

El índice de ventas muestra un precio de 350 dólares al mes.

El resultado en el mundo exterior

Se ofreció al cliente un precio de 350 dólares al mes. Si una auditoría confunde estas tres realidades, no podrá encontrar la causa raíz. Si solo mira el sitio web, dirá: «El agente inventó los hechos». Si solo examina los registros del agente, podrá decir: «El agente actuó de acuerdo con la fuente disponible». Si únicamente revisa el mensaje enviado al cliente, podrá concluir: «La empresa anunció un precio de 350 dólares». Las tres lecturas captan una parte del incidente. Ninguna muestra por sí sola toda la verdad. Por eso, la auditoría GBO necesita dos estructuras distintas:

Registro de información de referencia

y

Cadena de evidencias

El registro responde: ¿qué información procedía de la fuente autorizada y estaba vigente en un momento y un ámbito determinados? La cadena de evidencias responde: ¿a través de qué fuentes, transformaciones y pasos de verificación llegamos a ese juicio?

Encontrar información no equivale a establecer los hechos

Una información puede estar en internet o en los sistemas de una organización. Eso no significa que sea:

correcta,

actual,

procedente de una fuente autorizada,

pertinente para el ámbito considerado,

suficiente para actuar.

Un precio puede estar disponible, pero desactualizado. La descripción de un servicio puede corresponder solo a un cliente concreto. Una función humana puede seguir registrada aunque su vigencia haya terminado. Un registro de consentimiento puede cubrir otro propósito. Un comentario puede repetirse en muchas páginas y proceder de una única declaración de la propia entidad. Una captura puede mostrar el contenido correcto y, sin embargo, haberse tomado después del incidente. Comparar el hash de un archivo con un valor hash anterior conservado de forma fiable ayuda a comprobar si el archivo ha cambiado. No demuestra que su contenido sea verdadero. Una firma digital puede indicar que una persona o un sistema concreto firmó un documento.

Pero no demuestra automáticamente que la afirmación contenida en él se ajuste a la realidad. Una cita puede llevar a la página correcta sin que esa página respalde la frase formulada por el modelo. Por eso, la auditoría GBO no acepta este atajo:

INFORMACIÓN ENCONTRADA = HECHO VERIFICADO

La cadena correcta es más larga:

INFORMACIÓN ENCONTRADA ↓ ENTIDAD VERIFICADA ↓ FUNCIÓN DE LA FUENTE IDENTIFICADA ↓ RESPONSABLE AUTORIZADO IDENTIFICADO ↓ TIEMPO Y ÁMBITO CONTRASTADOS ↓ CONTRADICCIONES DIFERENCIADAS ↓ ORIGEN DE LAS EVIDENCIAS PRESERVADO ↓ JUICIO SOBRE LOS HECHOS FORMULADO

¿Qué es la información de referencia?

La información de referencia no es el relato que una organización prefiere o quiere repetir. Tampoco es la frase que aparece en el encabezado más grande de una página web. El concepto no significa que la organización pueda definirse como le convenga. En este protocolo, la información de referencia se define como un registro auditable sobre una entidad y un tipo de hecho concretos. Tiene establecidos su responsable autorizado, la función de la fuente, el ámbito, el periodo de validez, las excepciones y el historial de versiones. Indica qué valor debe regir el comportamiento humano y de las máquinas. Dicho de forma más sencilla, la información de referencia explica qué registro puede tener la última palabra sobre una pregunta concreta, dentro de qué periodo y ámbito.

Aquí, «la última palabra» no significa una verdad ilimitada e inmutable. El precio de una organización puede cambiar. Una función humana puede terminar. El alcance de un servicio puede ampliarse. El consentimiento puede retirarse. La capacidad puede agotarse. Un registro puede ser válido hoy y no serlo mañana. Por eso, la información de referencia no es solo un valor. Es una:

Relación entre valor, responsable, ámbito y tiempo.

Los ocho campos básicos de la información de referencia

Un registro de hechos debe responder al menos a ocho preguntas.

1. ¿Qué entidad?

¿Qué empresa?

¿Qué persona?

¿Qué marca?

¿Qué producto?

¿Qué agente?

¿Qué cuenta?

No deben confundirse entidades que tengan el mismo nombre.

2. ¿Qué tipo de hecho?

Precio

Alcance del servicio

Capacidad

Función humana

Autorización

Consentimiento

Plazo de conservación de datos

Elegibilidad

Operación efectivamente realizada

Estado de publicación

La fuente autorizada puede ser distinta para cada tipo de hecho.

3. ¿Cuál es el valor?

Por ejemplo: el precio inicial de Managed Site Operations es de 500 USD al mes. Pero el valor por sí solo no basta.

4. ¿Cuál es el ámbito?

Este precio:

¿es para clientes nuevos?

¿es para clientes actuales?

¿se aplica a un país concreto?

¿corresponde a un paquete concreto?

¿incluye impuestos?

¿cubre solo el servicio básico?

5. ¿Quién es responsable?

¿Qué persona u órgano autorizado determina la exactitud y actualidad de esta información?

6. ¿Qué fuente tiene autoridad?

¿La página web? ¿El registro de precios aprobado? ¿Un contrato firmado? ¿El CRM? ¿El registro de autorizaciones de recursos humanos? ¿El calendario de operaciones?

7. ¿Cuándo es válida?

Fecha de inicio

Fecha de finalización

Última verificación

Revisión

Hecho que la invalida

8. ¿Qué excepciones hay?

Un descuento para un cliente concreto

Una promoción temporal

Un precio conservado de un contrato anterior

Un país o un idioma determinados

Un compromiso específico de capacidad

Sin estos campos, limitarse a decir «El precio es de 500 dólares» deja la información incompleta.

La fuente de referencia no es una única base de datos enorme

Las organizaciones suelen decir: «Necesitamos una única fuente de verdad». La idea es útil. Pero, mal entendida, puede llevar a intentar encajar toda la organización en un archivo o una base de datos. En la práctica, cada tipo de hecho puede tener una fuente autorizada distinta.

Un sistema de referencia no exige necesariamente que todo esté en un mismo lugar. Exige que quede claro qué fuente está autorizada para determinar cada tipo de hecho importante. El precio de un servicio puede proceder del registro de precios. La página web visible puede ser su representación para las personas. El catálogo de agentes puede ser su representación para las máquinas. La plantilla de ofertas del CRM puede ser una copia derivada. Estos cuatro registros no cumplen la misma función.

Funciones de las fuentes

En una auditoría, la función de cada fuente debe clasificarse de forma explícita.

1. Fuente autorizada

La fuente facultada por la organización o por el derecho para determinar el hecho. Por ejemplo, el registro de precios aprobado.

2. Fuente operativa

La fuente que utiliza el agente durante su comportamiento real. Por ejemplo, el índice de conocimiento de ventas.

3. Fuente de representación

La superficie en la que se presenta la información a personas o máquinas. Por ejemplo, una página web o datos estructurados.

4. Fuente de ejecución

El sistema que controla la acción real. Por ejemplo, la dirección de entrega en el sistema de pedidos.

5. Fuente de archivo

La fuente que permite reconstruir un estado anterior. Por ejemplo, un repositorio de documentos con control de versiones.

6. Fuente de verificación independiente

Verifica el resultado por separado del sistema que realiza la operación. Por ejemplo, una lectura de comprobación del sitio en producción mediante HTTPS o un buzón de auditoría.

7. Fuente de interpretación secundaria

Una fuente de terceros que resume o evalúa los datos primarios.

8. Inferencia del agente

Una conclusión derivada de fuentes, pero no verificada directamente. Estas funciones no son intercambiables. Una página web puede ser una buena fuente de representación sin estar autorizada para determinar el precio contractual de un cliente concreto. Un informe del agente puede ser un resumen operativo útil, pero no una verificación independiente. Una captura puede ser evidencia de una representación anterior, pero no es la fuente que fija el precio.

Que un registro sea de referencia no significa que sea correcto

Una organización puede haber introducido un precio incorrecto en su registro autorizado. Ese registro puede tener carácter de referencia para la organización y, aun así, contradecir la situación comercial real o un contrato firmado. La auditoría debe mantener separadas dos preguntas: ¿qué registro era el autorizado por la organización? Y ¿era coherente con la operación vinculante y con el resultado real? Por ejemplo:

El registro de precios indica 500 dólares.

El contrato firmado con el cliente indica 450 dólares.

Para el precio general, la referencia son 500 dólares. Para la operación de ese cliente, rigen los 450 dólares del contrato. No es una contradicción: son dos datos válidos en ámbitos distintos. Conservar esa diferencia es una función importante de la información de referencia.

Regla general, excepción y operación específica

Muchos hechos de una organización existen en tres niveles.

Regla general

El servicio parte de 500 dólares al mes.

Excepción temporal o limitada

Del 1 al 15 de septiembre se aplica un descuento del 10 por ciento a los clientes actuales.

Operación específica

El contrato firmado con el Cliente A establece un precio de 430 dólares. Si el agente reduce todos estos registros a un único campo de precio, se producen errores. Los 430 dólares concedidos a un cliente concreto pueden confundirse con el precio general. Una promoción temporal puede convertirse en indefinida. El precio general puede desplazar la condición específica de un contrato firmado. Por eso, el registro de referencia debe contener relaciones de prioridad y ámbito, no un solo valor. La interpretación correcta puede seguir esta lógica:

UN REGISTRO VÁLIDO DE UNA OPERACIÓN ESPECÍFICA DEJA SIN EFECTO LA REGLA GENERAL SOLO DENTRO DE SU PROPIO ÁMBITO

No esta:

EL VALOR MÁS RECIENTE O MÁS BAJO ES EL NUEVO DATO VÁLIDO PARA TODOS

El registro más reciente no siempre es el de referencia

Un empleado puede introducir un precio nuevo en el CRM a las 10:00. El registro de precios aprobado puede haberse creado a las 09:00. El registro del CRM es más reciente. Pero, si el empleado no está autorizado para cambiar precios, ser más reciente no convierte ese registro en la referencia. Una publicación en redes sociales puede ser posterior a un contrato antiguo, pero no puede modificar el contrato firmado. Un resumen del agente puede haberse creado hoy y resumir una fuente de hace tres años. Por tanto, la prioridad de las fuentes no debe establecerse solo por orden cronológico. Una evaluación adecuada considera conjuntamente al menos estas cuatro dimensiones:

AUTORIZACIÓN + ÁMBITO + TIEMPO + FUNCIÓN DE LA FUENTE

El tiempo forma parte de la información de referencia

La auditoría no pregunta solo: «¿Qué es cierto hoy?» Al investigar un incidente, importa más esta pregunta: ¿qué información era válida y accesible cuando se produjo la acción? Un agente puede haber usado un precio antiguo el lunes. El martes se corrigió. La página del martes no explica el incidente del lunes. Por eso, todo registro sustancial debe contener estos campos temporales:

effective_from effective_until created_at approved_at last_verified_at superseded_at invalidated_by_event

Estos campos no son equivalentes. Un documento puede haberse creado el 1 de septiembre y aprobado el 5 de septiembre. Puede haber entrado en vigor el 10 de septiembre y haber sido sustituido por otro registro el 20 de septiembre. No basta con mirar la fecha de creación del archivo.

Hechos que invalidan un registro

Algunos datos pueden perder validez sin esperar a una fecha determinada. Por ejemplo, cuando ocurre lo siguiente:

La salida de un empleado de la organización

La retirada del consentimiento

El agotamiento de la capacidad

La falta de existencias del producto

La terminación del contrato

La revocación del token del agente

Un cambio en la entidad jurídica de la empresa

La detección de un incidente de seguridad

Por eso, el registro no debe limitarse a decir «Válido hasta el 31 de diciembre». También debe incluir:

invalidate_on:
  - employee_termination
  - consent_revocation
  - contract_cancellation
  - security_incident

El agente no debe mirar el calendario y actuar solo porque el registro siga dentro de su periodo de validez. Debe comprobar también los hechos que lo invalidan.

Clases de información según su ritmo de cambio

La información no queda desactualizada siempre al mismo ritmo.

Hechos que cambian lentamente

Fecha de fundación

Una publicación anterior

El nombre básico de la arquitectura del producto

Hechos que cambian a un ritmo intermedio

Funciones humanas

Alcance del servicio

Horario de soporte

Políticas de autorización

Hechos que cambian rápidamente

Precio

Existencias

Capacidad

Disponibilidad de vuelos

Promociones

Tokens activos

Estado de la cola

La auditoría debe fijar un umbral de actualización según el tipo de hecho. Por ejemplo:

price:
  refresh_required_before_action: true

capacity:
  maximum_age: 24_hours

legal_entity:
  verify_on_material_change

authorization:
  verify_at_execution

Un registro de capacidad pudo ser correcto hace tres meses. No sirve para prometer una entrega hoy.

Tres representaciones de la información de referencia

Un mismo hecho sustancial puede tener tres representaciones en una organización.

1. Información interna autorizada

El valor establecido por quien tiene la facultad de decidir dentro de la organización.

2. Información presentada a las personas

El valor que aparece en el sitio web, la oferta, el contrato o la comunicación con el cliente.

3. Información presentada a las máquinas

El valor que aparece en una API, un esquema, un catálogo de agentes, un índice de conocimiento o la descripción de una herramienta. Estas tres representaciones no tienen que coincidir palabra por palabra, pero sí ser equivalentes en lo sustancial. Por ejemplo, el texto para personas puede decir: El servicio de gestión operativa parte de 500 dólares al mes. El alojamiento y las licencias de terceros se valoran por separado. El registro para máquinas:

pricing_model: starting_price
starting_price: 500
currency: USD
billing_period: month
excludes:
  - hosting
  - third_party_licenses

Las frases son distintas. El dato comercial es el mismo.

Equivalencia entre representaciones

Podemos llamar a la correspondencia sustancial entre las representaciones para personas y para máquinas:

Equivalencia entre representaciones

Esta equivalencia debe probarse al menos en los siguientes aspectos:

Identidad de la entidad

Identidad jurídica del operador

Resultado del servicio

Alcance incluido

Alcance excluido

Distinción entre precio inicial y precio total

Requisito de consentimiento

Aprobación humana

Capacidad

Resultados que no se garantizan

Vía de cancelación y retirada

Patrocinio o relación comercial

Si un límite importante presente en una representación desaparece en la otra, el sistema publica realidades de comportamiento distintas.

Información de referencia multilingüe

Un servicio publicado en seis idiomas puede tener seis formas de presentarse. Las estructuras de cada lengua son distintas. El grado de detalle técnico puede variar según el lector y la función del texto, no según el idioma en sí. El texto árabe se dispone de derecha a izquierda; el orden de las explicaciones y la estructura de las frases pueden seguir el curso natural del árabe. El texto español puede transmitir el mismo significado mediante formas de tratamiento y expresiones naturales para su lector. Esa variedad no es el problema. El problema es que cambien los hechos sustanciales. Si el texto inglés dice «Every public avatar publication requires human approval.», pero otra lengua solo transmite «Los contenidos se preparan conforme al procedimiento de aprobación», puede haberse perdido el requisito de aprobación humana para cada publicación.

Por eso, la información de referencia multilingüe debe gestionarse en dos niveles:

Un acuerdo sobre los hechos independiente del idioma

Precio

Ámbito

Consentimiento

Autorización

Prohibiciones

Cancelación

Resultados que no se garantizan

Expresión natural en cada idioma

El mismo acuerdo sobre los hechos se expresa en una lengua local y natural. Las fuentes traducidas no cuentan como evidencias independientes. Que la misma información aparezca en seis idiomas no aporta seis evidencias: son seis representaciones de un único hecho de referencia.

La versión lingüística que prevalece

Algunos contratos o documentos jurídicos pueden indicar expresamente qué versión lingüística prevalece si hay diferencias entre los textos. El efecto jurídico de esa elección se evalúa por separado. En ese caso, los demás idiomas pueden ofrecerse con fines de:

información,

localización,

accesibilidad.

Dar prioridad a una versión lingüística no hace aceptables los errores sustanciales en las demás. Si el usuario toma una decisión importante en otro idioma, deben quedar claros:

los límites de la traducción,

el texto que prevalece,

las diferencias importantes.

El agente que utiliza una traducción también debe saber qué versión es vinculante.

La información de referencia no es una afirmación subjetiva de superioridad

Una empresa puede registrar como información de referencia: «Ofrecemos páginas de servicios en seis idiomas». Si realmente las ofrece, es un hecho verificable. No puede convertir en referencia, por decisión propia, esta afirmación: «Somos la mejor empresa GBO del mundo». Para sostenerla hacen falta:

un universo de comparación definido,

un método de comparación,

datos,

una fecha,

una evaluación independiente.

Una organización puede hacer oficial su propio relato. Pero no puede convertir una declaración oficial sobre sí misma en un hecho de superioridad en el mundo exterior. Por eso, el registro debe distinguir estas categorías:

Hecho verificado de la organización

Declaración sobre sí misma

Posicionamiento de marketing

Resultado de medición

Evaluación independiente

Inferencia

Opinión

Publicar una afirmación como información de referencia no la convierte automáticamente en un hecho externo objetivo.

Conflictos entre datos de referencia

Durante una auditoría, distintas fuentes pueden mostrar valores diferentes sobre una misma cuestión. Por ejemplo:

Página web: 500 dólares

CRM: 350 dólares

Contrato: 430 dólares

Catálogo del agente: previa solicitud

PDF antiguo: 400 dólares

El primer paso no es elegir uno. Antes hay que preguntar: ¿responden realmente a la misma pregunta? El precio de 430 dólares del contrato podría corresponder a un cliente concreto. El PDF antiguo podría haber perdido su vigencia. El precio de 350 dólares registrado en el CRM podría ser incorrecto y no estar aprobado. Es posible que el catálogo del agente no haya actualizado el precio. La página web podría mostrar el precio general para nuevos clientes. Aparentemente hay cinco precios distintos. Tras clasificarlos correctamente, quizá solo uno constituya un conflicto real.

Cómo resolver contradicciones entre datos

Cuando se detecte una contradicción sustancial, debe seguirse este proceso.

1. Detener la acción según el nivel de riesgo

Una operación de alto impacto no debe continuar si hay incertidumbre sobre el precio, la autorización, el consentimiento o la identidad del destino.

2. Conservar todas las versiones existentes

No corregir un registro de inmediato a costa de destruir la evidencia histórica.

3. Fijar el tipo de dato y su alcance

¿Es un precio general? ¿Un contrato específico de un cliente? ¿Una promoción temporal?

4. Clasificar las funciones de las fuentes

¿Es una fuente facultada para establecer el dato, una representación, una copia derivada o un archivo histórico?

5. Determinar el periodo de vigencia

¿Qué versión estaba vigente cuando ocurrió el hecho?

6. Identificar a la persona responsable

¿Quién está facultado para resolver esta cuestión?

7. Distinguir una excepción de un error

¿La diferencia responde a condiciones especiales legítimas o a un registro sin actualizar?

8. Dejar constancia de la resolución

¿Qué valor se aceptó como válido, para qué alcance y para qué fecha?

9. Trasladar el cambio a todas las representaciones

Web, API, CRM, directorio de agentes, cotizaciones y versiones lingüísticas.

10. Verificar la propagación de forma independiente

No basta con afirmar que la fuente ha cambiado; hay que comprobar que se han actualizado los sistemas que la utilizan.

11. Identificar las operaciones afectadas

¿En qué mensajes, cotizaciones, pagos o decisiones influyó el dato incorrecto?

12. Repetir la prueba

¿Utiliza ahora el agente la fuente correcta en el mismo escenario?

Borrar el registro antiguo antes de resolver la contradicción

Al encontrar un registro incorrecto, una organización puede querer corregirlo cuanto antes. La intención es buena. Pero, si se borra el registro antiguo antes de iniciar la auditoría, ya no será posible responder a estas preguntas:

¿Vio realmente el agente este registro?

¿Cuánto tiempo llevaba activo?

¿En qué operaciones influyó?

¿A qué directorio de agentes se propagó?

¿Dónde se originó el error?

¿Siguen activas otras copias?

El procedimiento correcto:

Conservar el estado anterior.

Fijar la evidencia del hecho.

Publicar la nueva versión.

Marcar la versión anterior como no válida o archivada.

Examinar el alcance del impacto.

Conservar un registro histórico incorrecto no significa mantenerlo activo. Hay que separar la evidencia histórica de los datos que rigen la operación.

Propagación de los datos de referencia

Una vez que la fuente facultada ha establecido el dato, este debe llegar a todos los puntos que influyen en el comportamiento. Podemos llamar a este proceso:

Propagación de los datos de referencia

Por ejemplo, un cambio de precio puede afectar a:

La página web dirigida a las personas

El catálogo de servicios legible por máquinas

Los datos estructurados

La plantilla de cotización del CRM

El índice de conocimiento del agente de correo electrónico

Las páginas multilingües

La presentación de ventas

La plantilla del contrato

Los directorios empresariales

Las plataformas externas

Si el cambio solo se realiza en el registro de referencia, el agente puede seguir utilizando la copia antigua. La fuente de referencia es correcta. La realidad operativa sigue siendo incorrecta.

Demora en la propagación

Podemos dar este nombre al tiempo que transcurre entre el cambio de un dato de referencia y la actualización de todos los puntos pertinentes:

Demora en la propagación

Por ejemplo:

Registro de precios actualizado: 09.00 Página web actualizada: 09.05 Catálogo del agente actualizado: 09.20 Plantilla del CRM actualizada: 11.30 Índice del agente de ventas actualizado: al día siguiente

Durante ese periodo, la organización opera con más de una versión de los datos. En cambios de alto impacto, puede restringirse el comportamiento del agente afectado hasta que se complete la propagación.

Medir la cobertura de referencia y la equivalencia

Una sola puntuación no basta. Sin embargo, algunas métricas permiten ver dónde hay carencias.

Proporción de datos de referencia con responsable

Datos sustanciales con una persona responsable identificada ÷ Total de datos sustanciales

Proporción de representaciones equivalentes

Registros cuyo significado sustancial coincide en las representaciones para personas y máquinas ÷ Total de registros comparados

Proporción de versiones lingüísticas equivalentes

Versiones lingüísticas que preservan el acuerdo sobre los hechos críticos ÷ Total de versiones lingüísticas

Proporción de cumplimiento de los requisitos de actualización

Datos dinámicos verificados dentro del plazo requerido ÷ Total de datos dinámicos

Grado de completitud de la propagación

Puntos que muestran el valor de referencia actual ÷ Total de puntos que deben actualizarse

Número de contradicciones sustanciales sin resolver

Contradicciones abiertas que afectan a la acción, por ejemplo, en el precio, la autorización, el consentimiento, el alcance o la identidad. Estas métricas solo ofrecen visibilidad operativa. Una única contradicción crítica no debe quedar oculta tras una proporción global elevada.

¿Qué es la evidencia?

Repetir una afirmación no es evidencia. Que un sistema diga «Lo he conseguido» no es evidencia. Que una organización diga «Aquí no ocurren problemas así» tampoco lo es. La definición de referencia es la siguiente: la evidencia es un registro observable sobre una afirmación, configuración, comportamiento o resultado concreto, cuyo origen, momento, integridad, alcance y método de obtención se conocen, y que ayuda a otro evaluador a reconstruir el juicio. La evidencia no siempre constituye una prueba concluyente. Su fuerza puede variar. Una captura puede mostrar lo que aparecía en pantalla en un momento determinado, pero no todo el sistema que hay detrás. Un registro de actividad puede mostrar una operación registrada, pero no el comportamiento que queda fuera del mecanismo de registro.

Un contrato puede acreditar una autorización. No demuestra, sin embargo, que el sistema técnico haya cumplido ese contrato. Por eso, la evidencia debe utilizarse teniendo en cuenta:

su función,

sus límites,

su fuerza.

Afirmación, observación, inferencia, decisión y resultado

La auditoría debe distinguir estos cinco conceptos.

Afirmación

El agente no envía mensajes sin aprobación humana.

Observación

En el escenario sin aprobación no se llamó a la herramienta de envío.

Inferencia

Es posible que el sistema esté impidiendo los envíos sin aprobación.

Decisión

Dentro del alcance definido para la prueba, el control de autorización superó la evaluación.

Resultado

No llegó ningún mensaje al destinatario de auditoría y la cola de envío permaneció vacía. Antes de pasar de una observación a una afirmación amplia, hay que evaluar si la evidencia es suficiente. Que no se envíe un mensaje en un escenario no permite concluir: «Nunca puede enviarlo». Del mismo modo, que un mensaje no llegue no demuestra necesariamente que el agente no intentara enviarlo. La llamada a la herramienta pudo haber fallado. La auditoría no debe confundir estos niveles.

¿Qué es una cadena de evidencias?

La definición de referencia es la siguiente: una cadena de evidencias es un rastro versionado que muestra de dónde se obtuvieron las fuentes sin procesar que respaldan o refutan una afirmación de auditoría, quién las obtuvo, cuándo y mediante qué método; qué transformaciones, enmascaramientos, clasificaciones y análisis experimentaron; a qué observaciones y hallazgos se vincularon; y cómo se conservaron su integridad y su estado de retención. Dicho de forma más sencilla, una cadena de evidencias responde de principio a fin a la pregunta: «¿Cómo llegaron a esta conclusión?». Puede mostrar este recorrido:

FUENTE SIN PROCESAR ↓ MÉTODO DE OBTENCIÓN ↓ MOMENTO Y PERSONA QUE LA RECOPILÓ ↓ REGISTRO DE INTEGRIDAD ↓ ENMASCARAMIENTO NECESARIO ↓ OBSERVACIÓN ↓ CORRESPONDENCIA CON LA AFIRMACIÓN ↓ EVIDENCIA EN CONTRA ↓ JUICIO DE AUDITORÍA

La cadena de evidencias no es la cadena de pensamiento interna y privada del agente. La auditoría no intenta registrar por completo el razonamiento oculto del sistema. Lo que hace falta es un rastro observable que permita rendir cuentas:

¿Qué fuente se leyó?

¿A qué herramienta se llamó?

¿Qué autorización se utilizó?

¿Qué resultado se produjo en el mundo exterior?

¿Qué registro lo verificó?

Diez cualidades de la evidencia

Cada evidencia debe evaluarse según estas dimensiones.

1. Pertinencia

¿La evidencia guarda realmente relación con la afirmación planteada? La política general de seguridad de una empresa puede no demostrar que el envío de un correo concreto estuviera autorizado.

2. Facultad de la fuente

¿Está la fuente facultada para pronunciarse sobre este tipo de hecho? Un comentario en redes sociales no puede determinar el precio actual.

3. Correspondencia temporal

¿La evidencia refleja el momento del hecho o el periodo de vigencia pertinente? Una captura de hoy no demuestra el comportamiento de la semana pasada.

4. Autenticidad

¿Puede verificarse que el origen de la fuente es realmente la persona, el sistema o la organización que se indica?

5. Integridad

¿Se ha modificado la evidencia desde que se obtuvo? El hash del archivo puede ayudar a comprobarlo.

6. Completitud y contexto

¿Contiene el registro la información de contexto necesaria? Una captura recortada puede ocultar una excepción importante.

7. Independencia

¿Es la evidencia independiente de la declaración del propio sistema auditado?

8. Reproducibilidad

¿Puede otro evaluador obtener una observación similar con el mismo método?

9. Especificidad

¿A qué usuario, tarea, versión y operación se refiere la evidencia? Un registro general puede no permitir distinguir el comportamiento concreto.

10. Proporcionalidad y privacidad

¿Se recopilaron datos innecesarios sobre personas u organizaciones para obtener la evidencia? Una evidencia sólida no equivale a una recopilación ilimitada de datos.

Tipos de evidencia

En una auditoría pueden combinarse distintas clases de evidencia.

1. Evidencia de políticas y contratos

Política corporativa

Contrato de la tarea del agente

Documento de consentimiento

Registro de autorización

Catálogo de servicios

Muestra lo que debería ocurrir. Por sí sola no muestra lo que ocurrió realmente.

2. Evidencia de configuración

Instrucciones del agente

Permisos de las herramientas

Registro del modelo y la versión

Alcance de permisos de la API

Configuración de la cola

Política de detención

Muestra cómo se configuró el sistema.

3. Evidencia de comportamiento

Llamada a una herramienta

Comprobante de la acción

Registro de ejecución de la prueba

Delegación a un subagente

Registro de aprobación humana

Muestra qué hizo el sistema en una situación concreta.

4. Evidencia del resultado

Mensaje en la bandeja de entrada del destinatario

Registro bancario o de pago

Contenido de la web en producción

Registro modificado del cliente

Estado real de la API

Muestra qué ocurrió en el mundo exterior.

5. Evidencia de recuperación

Comprobante de detención

Cancelación de la cola

Invalidez del token

Resultado de la reversión

Traspaso del control a una persona

Registro de reinicio

Muestra el comportamiento en el momento del error o de la retirada.

6. Evidencia aportada por personas

Declaración de una persona autorizada

Registro de la conversación

Explicación de la aprobación

Objeción de la persona afectada

Es importante, pero por sí sola puede no demostrar el resultado técnico.

7. Evidencia externa independiente

Confirmación del destinatario

Registro de un sistema de terceros

Lectura independiente del estado del sistema en producción

Medición externa

Aporta un resultado separado del informe del propio sistema.

¿Qué demuestra una captura de pantalla?

Las capturas de pantalla son útiles en una auditoría, pero su función es limitada. Una captura puede mostrar que en un momento concreto había cierto texto en pantalla. Por sí sola no demuestra que:

la página fuera realmente la fuente de referencia,

el contenido fuera el mismo cuando ocurrió el hecho,

los datos subyacentes fueran los mismos,

otros usuarios vieran lo mismo,

la imagen no estuviera recortada,

el agente utilizara esa página,

la acción se produjera realmente,

la página no mostrara contenido distinto a los bots.

La captura gana fuerza como evidencia cuando se acompaña de:

URL o identificador del sistema

Fecha y hora

Zona horaria

Rol del usuario

Contexto de la pantalla completa

Registro de red o de la fuente pertinente

Valor de integridad del archivo

Un segundo método independiente

Una captura registra una observación; por sí sola no tiene la facultad de establecer el hecho.

¿Qué demuestra un registro de actividad?

Los registros de actividad pueden constituir evidencia sólida, pero tampoco son una representación ilimitada de la realidad. Hay que preguntar:

¿Qué sistema lo generó?

¿Qué eventos no registra?

¿Están sincronizados los relojes?

¿Puede modificarse después?

¿Es suficiente el nivel de registro?

¿Cuántos agentes utilizan la misma cuenta de servicio?

¿Se conservan tanto las operaciones fallidas como las exitosas?

¿La ausencia de un registro significa que la acción no ocurrió?

Si un mensaje no aparece en el registro de envíos:

puede que no se haya enviado,

puede que haya vencido el plazo de retención del registro,

puede que se haya utilizado otra herramienta,

puede que la cuenta de servicio fuera distinta,

puede que haya fallado el registro de actividad.

Por tanto:

NO FIGURA EN EL REGISTRO ≠ CON CERTEZA NO OCURRIÓ

Un juicio adecuado podría ser: «No se encontró constancia en los registros examinados; debido a otras vías de envío y a los límites de retención, esta ausencia no permite una conclusión definitiva».

¿Qué demuestra un hash?

La comparación del resumen criptográfico de un archivo —su hash— con un resumen anterior conservado de forma fiable ayuda a comprobar si el archivo ha cambiado. Esto tiene valor. Pero un hash no demuestra que:

el archivo proceda de la fuente correcta,

su contenido sea verdadero,

incluya todo el contexto importante,

estuviera en uso cuando ocurrió el hecho.

Un archivo incorrecto también puede tener un hash calculado correctamente. Un informe inventado puede conservarse sin cambios. Comparar hashes ayuda a comprobar la integridad, no la veracidad. Por eso hay que distinguir cuatro conceptos:

INTEGRIDAD: ¿Ha cambiado el archivo? AUTENTICIDAD: ¿Procede realmente el archivo de la fuente indicada? FACULTAD DE LA FUENTE: ¿Está la fuente facultada para decidir sobre esta cuestión? VERACIDAD: ¿Se ajusta el contenido a los hechos y al contexto?

La evidencia sólida de uno no demuestra automáticamente los demás.

¿Qué demuestra una firma digital?

Una firma digital válida, si se cumplen las condiciones relativas a la clave utilizada y a la verificación, puede mostrar que:

el documento se firmó con la clave de firma verificada,

el documento no ha cambiado desde la firma.

Un registro ordinario de aprobación no aporta automáticamente la misma garantía criptográfica. En ambos casos deben evaluarse por separado la vinculación con la identidad, el alcance de la aprobación y la facultad de decisión. Sin embargo, la persona firmante puede:

tener información incorrecta,

carecer de facultades sobre esa cuestión,

interpretar mal el alcance,

no haber visto todos los anexos del documento.

Por tanto, la firma solo ayuda a responder «¿Quién lo aprobó?» si se acompaña de una vinculación fiable con la identidad y de un contexto de aprobación claro. Por sí sola no demuestra que el contenido sea indudablemente correcto.

¿Qué demuestra una cita?

Una respuesta de IA puede citar la página web correcta. Esto puede mostrar que el modelo ha vinculado esa página como una de sus fuentes. No demuestra que todas las afirmaciones de la respuesta figuren en la página. La auditoría debe comparar al menos estos tres elementos:

La afirmación de la respuesta

El texto real de la fuente citada

Los límites dentro de los cuales la fuente respalda la afirmación

Una cita es evidencia de una relación. Debe comprobarse por separado si la fuente respalda el contenido de la afirmación.

¿Puede una salida de IA servir como evidencia?

Sí, pero debe quedar claro de qué es evidencia. Una respuesta de IA puede acreditar lo que el agente dijo en un momento concreto. No demuestra la veracidad de lo afirmado sobre el mundo exterior. Un agente puede explicar: «Tomé este precio del sitio web». Esa es su propia explicación. El uso real de la fuente debe verificarse mediante:

el registro de recuperación de información,

el identificador de la fuente,

la llamada a la herramienta,

el comprobante de la acción.

Que varios agentes digan lo mismo tampoco constituye evidencia independiente. Todos podrían haber utilizado la misma fuente o las salidas de los demás.

Evidencia sin procesar y evidencia derivada

En la auditoría hay que distinguir dos tipos de evidencia.

Evidencia sin procesar

El registro más próximo a la fuente. Ejemplos:

Respuesta original de la API

Fragmento del registro de actividad sin procesar

Archivo del contrato firmado

HTML de la página en producción

Registro del mensaje enviado

Registro de consentimientos

Evidencia derivada

Puede adoptar estas formas a partir de la evidencia sin procesar:

resumen,

clasificación,

versión enmascarada,

tabla,

representación gráfica,

interpretación de un agente.

La evidencia derivada es útil, pero debe vincularse con su origen sin procesar. Un resumen puede afirmar: «Se superaron 36/36 pruebas de acceso». El auditor debe poder consultar, cuando sea necesario, qué 36 pruebas se ejecutaron, cuándo y con qué agente de usuario (User-Agent).

Transformaciones de la evidencia

La evidencia puede transformarse durante la auditoría. Por ejemplo:

Se enmascaran los datos personales.

Se filtran los registros de actividad por el intervalo pertinente.

Se ajustan las referencias de tiempo entre distintas zonas horarias.

Se convierten los archivos a un formato común.

Se utiliza IA para clasificar eventos.

Se extrae texto de una imagen.

Se combinan varios registros en una sola tabla.

Cada transformación debe documentarse. Hay que responder a estas preguntas:

¿Qué herramienta se utilizó?

¿Qué versión?

¿Qué campos se eliminaron?

¿Qué valores se enmascararon?

¿Cambió el significado?

¿Se conserva la fuente sin procesar?

¿Puede reproducirse la transformación?

La evidencia transformada no debe presentarse como una fuente sin procesar.

Enmascaramiento y ocultación de datos

Las evidencias de auditoría pueden contener información personal o secretos comerciales. Por eso es posible ocultar algunas partes. Sin embargo, esa ocultación no debe:

alterar el contexto sustancial,

confundir la identidad del destinatario u objetivo,

distorsionar las relaciones temporales,

dejar visibles solo los fragmentos favorables.

El nombre de un cliente puede sustituirse, por ejemplo, por el seudónimo Müşteri-017. Pero asignar el mismo seudónimo a dos clientes distintos puede perjudicar el análisis de una acción dirigida al destinatario equivocado. El registro de ocultación debe incluir la siguiente información:

redaction_applied: true
redacted_fields:
  - personal_name
  - email_local_part
reason:
  privacy_protection
performed_by:
  AUDITOR-02
raw_source_retained:
  secure_vault

El informe público puede ocultar datos y, a la vez, mantenerse un acceso controlado a las evidencias originales para una revisión autorizada.

Relojes y zonas horarias en la cadena de evidencias

Los relojes pueden diferir de un sistema a otro.

El servicio de correo electrónico utiliza UTC.

El CRM utiliza la hora local.

El reloj del servidor del agente lleva unos minutos de retraso.

La plataforma externa utiliza otra zona horaria.

Estas diferencias pueden alterar el orden aparente de los hechos. Una aprobación humana concedida después de enviar el mensaje podría parecer anterior al envío. Por ello, los registros de evidencias deben incluir:

la hora absoluta,

la zona horaria,

la fuente de tiempo,

cualquier desviación conocida del reloj.

La sincronización de los relojes también puede ser objeto de auditoría.

Evidencias en contra

El auditor no debe reunir únicamente los registros que respaldan su hipótesis inicial. También debe preguntarse: ¿qué evidencias cuestionan este dictamen? Supongamos que la afirmación es que el agente envió un mensaje sin aprobación. Las evidencias a favor podrían ser:

el mensaje enviado,

la ausencia de un registro de aprobación,

la llamada a la herramienta.

Las evidencias en contra podrían incluir:

la aprobación general de la campaña por parte de un responsable humano,

la afirmación de que ya se había concedido una autorización permanente de envío,

un registro de aprobación en otro sistema.

El auditor evalúa esas evidencias en contra. Quizá exista una aprobación general, pero no cubra este envío por sus límites en cuanto a:

destinatario u objetivo,

vigencia,

canal,

tipo de mensaje.

Hacer visibles las evidencias en contra refuerza el fundamento del dictamen.

Ausencia de evidencias e incertidumbre

Algunos hechos no se pueden reconstruir con certeza. Puede que se hayan borrado los registros, que se haya cerrado la cuenta de un antiguo empleado o que el proveedor externo no conserve registros. El auditor no debe llenar esos vacíos con conjeturas. Puede utilizar los siguientes estados:

Verificado

Sólidamente respaldado

Parcialmente respaldado

Evidencias contradictorias

Evidencias insuficientes

No se pudo verificar

Pérdida de evidencias

«No se pudo verificar» no equivale a «no ocurrió». «Evidencias insuficientes» no equivale a «el sistema es seguro».

La pérdida de evidencias también es un hallazgo

Si una organización no puede reconstruir más adelante un comportamiento del agente de alto impacto, no se trata solo de una dificultad para auditar. Es una deficiencia de gobernanza en sí misma. Por ejemplo:

No se sabe qué agente envió el mensaje.

No hay registro de la aprobación humana.

No se encuentra la fuente del precio utilizado.

Se desconoce la fecha de revocación del token.

No se conserva un comprobante de detención.

En tal caso, quizá no pueda determinarse con certeza si el hecho fue favorable o perjudicial. Lo que sí queda establecido es que la organización no registra el comportamiento relevante de sus agentes de forma auditable. La pérdida de evidencias puede constituir por sí sola un hallazgo.

Independencia de las evidencias

No todos los registros que produce un sistema sobre sí mismo carecen de valor. Pero verificarse únicamente a partir de sus propios registros es arriesgado. Por ejemplo, un agente de publicación web:

carga un archivo,

genera un registro que dice «Carga completada con éxito»,

lee su propio registro y declara: «Verificación en producción superada».

Los tres pasos dependen de una misma fuente de información. Una verificación independiente puede recurrir a:

una lectura posterior del sitio publicado mediante HTTPS,

otro navegador,

un punto de observación externo,

una cuenta de auditoría separada.

La independencia no siempre exige otra empresa. Otro sistema de la misma organización, separado de la acción que se comprueba, también puede aportar evidencias independientes.

Paquetes de evidencias

Se puede preparar un paquete de evidencias para cada afirmación sustancial de auditoría.

Paquete de evidencias

Por ejemplo:

PAQUETE DE EVIDENCIAS — PRICE-INCIDENT-01

Afirmación: el 8 de septiembre de 2026, a las 09.14, el agente de ventas envió un mensaje a un cliente utilizando el precio no válido de 350 USD. Información de referencia: el precio inicial general vigente era de 500 USD/mes. Evidencias originales:

PRICING-REGISTRY-v4.2

La versión de la plantilla del CRM en el momento del hecho

El registro de recuperación de información del agente de ventas

El correo electrónico enviado

La aprobación de la persona responsable del precio

Una versión archivada de la página web anterior al hecho

Realidad operativa: el registro de 350 USD estaba activo en el índice de conocimiento del agente. Resultado de la acción: el cliente recibió un mensaje con un precio de 350 USD. Evidencia en contra: la página web actual de la empresa muestra 500 USD. Evaluación de esa evidencia: la página actual muestra el estado correcto posterior al hecho; no desmiente cuál fue la entrada que recibió el agente cuando ocurrió. Registros de integridad:

Hashes de los archivos

Identificador del mensaje de correo electrónico

Marcas de tiempo

Identificadores de las versiones archivadas

Incertidumbre pendiente: no se pudo verificar quién introdujo por primera vez el precio antiguo en el CRM. Dictamen de auditoría: el precio autorizado era de 500 USD. La fuente operativa que utilizó el agente de ventas contradecía el precio de referencia. El hecho corresponde a GBO-ERR-012, GBO-ERR-016 y GBO-ERR-092.

Este paquete no hace depender el dictamen de un solo documento o una captura de pantalla. Muestra toda la cadena de comportamiento.

Registro de información de referencia

El primer documento obligatorio de este capítulo es:

Registro de información de referencia NOMOS GBO.

El registro reúne los hechos sustanciales comprendidos en el alcance de la auditoría.

Ejemplo legible para personas

REGISTRO DE UN DATO DE REFERENCIA

Identificador del dato: CANON-PRICE-MSO-2026-04

Entidad: NobleAxis Managed Site Operations

Tipo de dato: Precio inicial general

Valor de referencia: 500 USD/mes

Alcance:

Nuevos clientes directos

Servicio básico de gestión de las operaciones del sitio

No incluye hosting ni licencias de terceros

Los impuestos se consideran por separado según el contrato

Fuera del alcance:

Hosting Core por 200 USD/año

Contratos de mantenimiento específicos de cada cliente

Contratos que conservan un precio anterior

Responsable humano: Responsable de Operaciones Comerciales

Fuente con autoridad: Pricing Registry v4.2

Representaciones dirigidas a personas:

Página del servicio en inglés

Página del servicio en turco

Plantilla de propuesta v5.1

Representaciones dirigidas a sistemas:

Service Catalog v4.2

Structured Data v3.8

Sales Agent Knowledge Index v7.1

Inicio de vigencia: 1 de septiembre de 2026

Fin de vigencia: Cuando se publique una nueva versión autorizada

Hechos que invalidan el registro:

Aprobación de un precio nuevo

Cambio en el alcance del servicio

Cambio en la política legal de precios aplicable

Excepciones:

Contrato firmado específico del cliente

Registro de campaña fechado

Registro al que sustituye: CANON-PRICE-MSO-2026-03 — 450 USD/mes

Última verificación: 8 de septiembre de 2026, 08.42

Contradicción pendiente: El precio antiguo de 350 USD en CRM Template v2.8

Estado: Activo; propagación operativa incompleta

Registro de información de referencia legible por máquinas

canonical_fact:
  fact_id: CANON-PRICE-MSO-2026-04

  entity:
    entity_id: SERVICE-MSO-001
    canonical_name: Managed Site Operations

  fact_type: starting_price

  value:
    amount: 500
    currency: USD
    billing_period: month

  scope:
    customer_type:
      - new_direct_customer
    included:
      - managed_site_operations_base_scope
    excluded:
      - hosting_core
      - third_party_licenses
      - taxes_unless_contractually_included

  owner:
    human_role: commercial_operations_owner
    approval_record: APPROVAL-PRICE-2026-104

  authoritative_source:
    source_id: PRICING-REGISTRY-4.2
    source_role: canonical_authority

  representations:
    human:
      - SERVICE-PAGE-EN-v6.1
      - SERVICE-PAGE-TR-v6.1
      - PROPOSAL-TEMPLATE-5.1
    machine:
      - SERVICE-CATALOG-4.2
      - STRUCTURED-DATA-3.8
      - SALES-KNOWLEDGE-INDEX-7.1

  validity:
    effective_from: 2026-09-01T00:00:00+03:00
    effective_until: null
    invalidate_on:
      - authorized_price_change
      - service_scope_change
      - applicable_legal_pricing_policy_change

  exceptions:
    allowed_only_when:
      - signed_customer_contract
      - approved_time_limited_campaign

  supersedes:
    fact_id: CANON-PRICE-MSO-2026-03

  conflicts:
    - source_id: CRM-TEMPLATE-2.8
      conflicting_value: 350
      status: obsolete_unresolved_copy

  status: active_with_propagation_gap

Este registro no se limita a guardar el valor de 500 dólares. También muestra:

quién es responsable de ese valor,

cuál es su alcance,

dónde se representa,

qué vigencia tiene,

qué contradicción presenta.

Registro de evidencias

El segundo documento obligatorio de este capítulo es:

Registro de evidencias NOMOS GBO.

Cada registro de evidencias indica qué afirmación o hallazgo respalda y cuáles son sus límites. El incidente de precios de este capítulo es un caso didáctico separado del registro de precios antiguo v3.7 del ejemplo de búsqueda de clientes. Aquí se utilizan PRICING-REGISTRY-v4.2 y GBO-AUDIT-PRICING-2026-001. Las evidencias de ambos expedientes no se combinan como si pertenecieran a un mismo alcance congelado.

Registro de evidencia legible para personas

Identificador de la evidencia: EVID-PRICE-INCIDENT-004

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

Tipo de evidencia: Comprobante de la acción del agente y rastro de la fuente

Sistema de origen: Sales Agent v2.4

Función de la fuente: Evidencia de comportamiento

Hecho relacionado: Correo con el precio enviado a las 09.14

Fecha y hora de obtención: 8 de septiembre de 2026, 10.12

Recopilado por: Auditor AUDITOR-02

Registro original: ACTION-EMAIL-8841

Registro de integridad: Se guardaron el hash y el identificador del mensaje

Qué muestra:

El agente de ventas envió el correo electrónico.

En el mensaje se utilizó un precio de 350 USD.

Se guardó CRM-TEMPLATE-2.8 como identificador de la fuente.

No se encontró un registro de aprobación humana.

Qué no muestra:

Quién creó originalmente la plantilla del CRM

Si el responsable humano concedió por otro canal una aprobación general de envío

Si el cliente aceptó la oferta en términos jurídicos

Transformaciones aplicadas:

Se enmascaró la dirección de correo electrónico del cliente.

Se retiraron los datos personales de la firma y se conservó el cuerpo del mensaje.

Ubicación del registro original: Repositorio cifrado de evidencias

Hallazgos que respalda:

FINDING-AUTH-03

FINDING-CANON-02

Evidencia en contra:

La página web actual muestra 500 USD.

Estado: Verificado

Plazo de conservación: 180 días; reevaluar si hay una controversia en curso

Registro de evidencias legible por máquinas

evidence_record:
  evidence_id: EVID-PRICE-INCIDENT-004
  audit_id: GBO-AUDIT-PRICING-2026-001

  evidence_type:
    - action_receipt
    - source_trace

  source:
    system_id: SALES-AGENT-2.4
    record_id: ACTION-EMAIL-8841
    source_role: behavioral_evidence

  acquisition:
    collected_by: AUDITOR-02
    collected_at: 2026-09-08T10:12:00+03:00
    method: read_only_export

  integrity:
    hash_algorithm: SHA-256
    hash_value: recorded_in_secure_vault
    source_message_id: MSG-928472
    integrity_status: verified

  temporal_relevance:
    event_time: 2026-09-08T09:14:00+03:00
    time_alignment: direct

  observations:
    - email_was_sent
    - stated_price_was_350_USD
    - source_id_was_CRM_TEMPLATE_2_8
    - explicit_human_approval_not_present_in_record

  limitations:
    - does_not_identify_original_creator_of_CRM_template
    - does_not_exclude_approval_existing_in_unreviewed_channel
    - does_not_establish_contract_acceptance

  transformations:
    - customer_email_masked
    - personal_signature_removed

  supports:
    findings:
      - FINDING-AUTH-03
      - FINDING-CANON-02

  counter_evidence:
    - EVID-WEB-CURRENT-001

  storage:
    location: encrypted_evidence_vault
    access:
      - lead_auditor
      - authorized_client_reviewer

  retention:
    days: 180
    deletion_receipt_required: true
    review_on_ongoing_dispute_or_preservation_duty: required
    example_duration_not_universal_legal_rule: true

  status: verified

Estados del Registro de evidencias

El historial de tratamiento de la evidencia, su estado de verificación, las objeciones y las condiciones de acceso deben seguirse por separado. Varias de las siguientes etiquetas pueden aplicarse a la vez. Por ejemplo, un registro puede tener la integridad verificada, el acceso restringido y el contenido cuestionado:

Recopilado

Integridad verificada

Autenticidad verificada

Verificado parcialmente

Contradictorio

Cuestionado

Invalidado

Sustituido por nueva evidencia

Vencido

Pérdida de evidencias

Acceso restringido

Archivado

Eliminado y con comprobante emitido

Si más adelante se descubre que una evidencia es incorrecta o incompleta, su registro no debe borrarse en silencio. Debe cambiarse su estado para que se entienda por qué cambió el dictamen anterior.

Matriz de afirmaciones y evidencias

Cada afirmación importante de la auditoría debe vincularse con las evidencias que la respaldan y con las que la cuestionan.

Esta matriz impide que el auditor afirme más de lo que permiten sostener las evidencias.

Campos mínimos de un paquete de evidencias

Cada hallazgo de alto impacto debe incluir, como mínimo, los siguientes campos:

claim expected_state observed_state canonical_fact raw_evidence operational_evidence action_evidence outcome_evidence counter_evidence time_alignment transformations limitations uncertainties reviewer judgment

Si un hallazgo se basa solo en una captura de pantalla, una declaración humana o una explicación del agente, debe indicarse expresamente.

Conservación de evidencias y minimización de datos

Las evidencias de auditoría no deben conservarse para siempre. El plazo de conservación puede variar según:

el nivel de riesgo,

la situación de la controversia,

el contrato,

los requisitos de protección de datos,

la necesidad de repetir pruebas,

el estado de cierre del incidente.

Siempre que sea posible, se debe:

enmascarar los datos personales,

retirar el contenido innecesario,

restringir el acceso a las evidencias originales,

presentar un resumen en el informe público,

emitir un comprobante al terminar la eliminación.

Pero la minimización de evidencias no debe hacer desaparecer el contexto crítico. Por ejemplo, podría conservarse solo el cuerpo del mensaje y eliminar:

el destinatario,

la hora,

el identificador de la fuente,

el registro de aprobación.

Eso puede hacer que el hecho deje de ser auditable.

Repositorio de evidencias y acceso

Las evidencias críticas pueden guardarse en un repositorio separado que disponga de:

control de acceso,

registro de cambios,

cifrado,

verificación de integridad,

gestión de versiones,

política de eliminación,

registro de quién consultó cada entrada.

El auditor no debe copiar todas las evidencias a su dispositivo personal ni a una herramienta en la nube no aprobada. Las herramientas de IA que las analicen también deben estar autorizadas.

Análisis de evidencias con ayuda de IA

Un agente de auditoría puede:

clasificar miles de registros,

construir una cronología,

agrupar hechos similares,

comparar versiones lingüísticas,

señalar fuentes contradictorias.

Esto resulta útil, con los siguientes límites:

La salida de la IA no debe sustituir las evidencias originales.

La clasificación de la IA no debe considerarse una verificación independiente.

La salida de la IA no debe determinar por sí sola el hallazgo definitivo.

Por ejemplo, el agente de auditoría podría decir: «Este registro parece indicar una vulneración de los límites de autorización». El auditor humano debe examinar:

el acuerdo de autorización real,

el alcance de la operación,

las evidencias en contra.

La cadena de evidencias también debe mostrar los siguientes datos del sistema de IA utilizado en la auditoría:

su versión,

su acceso a los datos,

su método de transformación.

Contaminación de evidencias

Los registros sintéticos generados durante una auditoría pueden mezclarse con los datos operativos reales. Por ejemplo:

Un registro de cliente creado para la auditoría se añade a la lista de clientes reales.

Un precio de prueba se introduce en el catálogo de ventas.

Un escenario de ataque permanece en la memoria del agente como una instrucción real.

Una dirección de correo usada para auditar se convierte después en objetivo comercial.

Un registro sintético de consentimiento se vincula a una persona real.

Podemos denominarlo:

Contaminación de evidencias y pruebas

Los datos de auditoría deben identificarse claramente. Al finalizar la prueba, se debe:

retirarlos del sistema activo,

conservar la copia de evidencias necesaria,

limpiar los efectos que hayan quedado en la memoria,

emitir un comprobante de eliminación o archivo.

La auditoría no debe modificar el sistema sin que se advierta mientras lo examina.

Doce pasos para auditar la información de referencia

1. Identificar las afirmaciones sustanciales

Enumerar los hechos que influyen en el comportamiento: precio, autorización, consentimiento, alcance, capacidad y resultado, entre otros.

2. Identificar la entidad de forma inequívoca

Evitar confusiones con otra persona, empresa, servicio o agente.

3. Clasificar el tipo de dato

Asignar cada afirmación a la familia de datos que corresponda.

4. Identificar al responsable humano

¿Quién responde de que el dato esté actualizado y sea correcto?

5. Identificar la fuente con autoridad

¿Qué registro está autorizado a establecer el criterio definitivo para este tipo de dato?

6. Localizar las fuentes operativas

¿Qué copia o índice utiliza realmente el agente?

7. Fijar el tiempo y el alcance

¿Qué valor era válido en el momento del hecho, para qué usuario y para qué operación?

8. Distinguir las excepciones de las contradicciones

¿Se trata de un contrato especial, una campaña o un registro histórico?

9. Comprobar la equivalencia entre lo que ven las personas y los sistemas, y entre idiomas

¿Todas las representaciones mantienen el mismo acuerdo sobre los hechos?

10. Construir la cadena de evidencias

Vincular la fuente original, la integridad, la transformación, la observación y las evidencias en contra.

11. Verificar la propagación

¿La corrección del dato de referencia ha llegado a todos los sistemas pertinentes?

12. Volver a probar el comportamiento

¿El agente actúa ahora correctamente a partir del dato correcto?

Puerta de información de referencia y cadena de evidencias

Antes de convertir una afirmación en un dictamen de auditoría, deben evaluarse las siguientes puertas:

1. Puerta de la entidad

¿El dato corresponde a la persona, organización, servicio o agente correcto?

2. Puerta del tipo de dato

¿La fuente está autorizada para decidir sobre este asunto?

3. Puerta de la responsabilidad humana

¿Se sabe quién es la persona responsable del dato?

4. Puerta del alcance

¿Se han distinguido la regla general, la excepción y la operación específica?

5. Puerta del tiempo

¿La evidencia corresponde al momento del hecho y al periodo de vigencia?

6. Puerta de equivalencia entre representaciones

¿Las representaciones para personas, para sistemas y en distintos idiomas transmiten el mismo hecho sustancial?

7. Puerta del acceso operativo

¿Se conoce la fuente que el agente utilizó realmente?

8. Puerta de la procedencia

¿Son visibles la fuente inicial de la evidencia y la cadena de transformaciones de la que procede?

9. Puerta de la integridad

¿Se puede verificar que la evidencia no ha cambiado y que sus transformaciones están registradas?

10. Puerta de la independencia

¿El resultado se basa únicamente en la declaración del propio sistema auditado?

11. Puerta de las evidencias en contra

¿Se han evaluado los registros que contradicen el dictamen?

12. Puerta de la privacidad

¿Se han recopilado más datos de los necesarios para la auditoría?

13. Puerta de la reproducibilidad

¿Otro evaluador podría llegar a un resultado similar a partir del mismo registro?

14. Puerta de la conservación y la vigencia

¿Durante cuánto tiempo se conservará la evidencia y bajo qué condiciones de acceso? En términos sencillos:

REALIDAD AUDITABLE = ENTIDAD CORRECTA Y TIPO DE DATO CORRECTO Y RESPONSABLE HUMANO AUTORIZADO Y ALCANCE DEFINIDO Y VIGENCIA TEMPORAL Y EQUIVALENCIA ENTRE REPRESENTACIONES Y TRAZABILIDAD DE LA FUENTE OPERATIVA Y PROCEDENCIA DE LA EVIDENCIA E INTEGRIDAD Y VERIFICACIÓN INDEPENDIENTE Y REVISIÓN DE EVIDENCIAS EN CONTRA Y USO PROPORCIONADO DE LOS DATOS

Incertidumbres críticas sobre los hechos

Algunas incertidumbres pueden exigir suspender temporalmente el comportamiento antes de comenzar las pruebas de escenarios. Por ejemplo:

No se sabe qué precio es válido.

Hay información contradictoria sobre quién tiene la autorización.

No se encuentra el registro de consentimiento.

Se desconoce la fuente de datos que utiliza el agente.

Las representaciones para personas y para sistemas muestran alcances diferentes.

No se puede determinar en qué cuenta se produjo el resultado del envío.

Se sospecha que la evidencia se modificó después del hecho.

La salida de un subagente se utiliza como fuente independiente.

Solo se dispone de una captura de pantalla actual para una operación con un riesgo cercano al nivel crítico.

La respuesta de auditoría adecuada no es: «No hay evidencias suficientes; continuemos de todos modos». Podría ser: «Debe restringirse el comportamiento de alto impacto correspondiente hasta que se aclaren los hechos y la ruta de las evidencias».

¿Qué debe hacer el agente si falta información de referencia?

Cuando un agente encuentra dos registros contradictorios de precios, funciones o consentimiento, no debe inventar un dato nuevo. La actuación adecuada puede variar según el riesgo:

Riesgo bajo

Explicar la incertidumbre y presentar las opciones posibles.

Riesgo medio

Buscar la fuente con autoridad o al responsable humano.

Riesgo alto

Detener la acción y trasladar la decisión a una persona. El agente podría decir: «Hay dos registros activos para el servicio: 500 y 350 USD. El precio de 500 USD aparece en el registro de precios; el de 350 USD, en una plantilla antigua del CRM. No enviaré un precio al cliente sin la confirmación del responsable comercial de la información de referencia». Esta respuesta puede dar la impresión de que la tarea quedó sin terminar. En realidad, es un comportamiento acertado.

¿Qué debe hacer el auditor si falta la cadena de evidencias?

Si el auditor no encuentra evidencias suficientes para verificar una afirmación, puede optar por una de estas tres respuestas:

1. Limitar la afirmación

«Se verificó que la política contiene esta regla; no se pudo verificar que se aplique en el comportamiento».

2. Solicitar más evidencias

Registros originales

Registro de versión

Prueba independiente

Aprobación del responsable humano

3. Registrar un hallazgo de evidencias insuficientes

«Dentro del alcance examinado, no se obtuvieron registros suficientes para reconstruir a posteriori la aprobación humana de la acción de alto impacto. Aún no se ha determinado si el registro nunca se creó, se perdió o no se presentó para su revisión». El auditor no debe llenar ese vacío suponiendo que el sistema es fiable.

Documentos obligatorios de este capítulo

Al terminar este capítulo, el expediente de auditoría debe contener dos estructuras:

1. Registro de información de referencia

Incluye todos los hechos sustanciales dentro del alcance de la auditoría relativos a identidad, precio, alcance, capacidad, consentimiento, autorización y resultado.

2. Registro de evidencias

Muestra qué evidencias sustentan cada afirmación, prueba, hallazgo, resultado y dictamen de recuperación. Recoge la procedencia, el momento, la integridad, las transformaciones y los límites de esas evidencias. Ambos registros deben vincularse al Mapa de comportamiento. Cada nodo importante del mapa debe dar acceso a lo siguiente:

el dato de referencia,

la evidencia correspondiente,

el responsable humano.

Resultado conjunto de los cuatro primeros capítulos

Ya está construida la base de la auditoría. Contamos con:

Ficha de la afirmación que se audita

Muestra qué intentamos demostrar.

Documento de autorización de la auditoría

Muestra qué puede hacer el auditor y dentro de qué límites.

Registro de fijación del alcance

Fija qué versión del sistema se está auditando.

Mapa de comportamiento de personas, agentes y herramientas

Muestra todas las rutas de comportamiento, desde el propósito humano hasta la acción externa, las evidencias y la detención.

Registro de información de referencia

Determina la fuente con autoridad, el responsable, el alcance, el tiempo y la excepción de cada hecho sustancial.

Registro de evidencias

Permite reconstruir cómo se llegó al dictamen de auditoría. Es posible pasar directamente a los escenarios de prueba sin estas estructuras. Pero entonces las pruebas pueden examinar el sistema equivocado, el dato equivocado o una autorización que no corresponde.

Dictamen del capítulo

Que la web de una organización contenga información correcta no demuestra que el agente la haya utilizado. Que un precio sea correcto en el registro autorizado no indica que todas las fuentes operativas estén actualizadas. Disponer de una captura de pantalla no reconstruye el sistema en el momento del hecho. La comparación de hashes permite comprobar cambios respecto de un registro anterior fiable; no demuestra que el contenido del archivo sea verdadero. Una firma digital puede identificar al firmante, pero no demostrar que el contenido sea siempre correcto. Una cita puede mostrar un vínculo con una fuente, pero no que esta respalde realmente la afirmación. Una explicación de IA muestra qué dijo el sistema; por sí sola no prueba la causa real del comportamiento. El primer dictamen de este capítulo es el siguiente: la información de referencia no es solo un valor. Es la relación entre la entidad correcta, el tipo de dato, el responsable autorizado, el alcance, el tiempo, la excepción y la versión.

Segundo: la fuente de referencia no tiene por qué ser un único archivo que lo contenga todo. Debe saberse qué fuente tiene autoridad para cada tipo de hecho sustancial. Tercero: la regla general, la excepción temporal y la operación específica no deben sobrescribirse entre sí en un mismo campo de datos. Cuarto: el registro correcto de hoy no demuestra automáticamente qué vio el agente en el pasado ni en qué se basó para actuar. Quinto: las representaciones para personas, para sistemas y en distintos idiomas deben mantener el mismo acuerdo sobre los hechos que rigen el comportamiento. Sexto: no basta con que exista evidencia; hay que conocer su procedencia, momento, integridad, transformaciones, independencia y límites. Séptimo: la ausencia de evidencias no es ausencia de errores. No poder reconstruir un comportamiento importante constituye un hallazgo de gobernanza independiente.

Octavo: la cadena de evidencias no es una cadena privada de pensamiento. Es un rastro observable de fuentes, autorización, acción, resultado y recuperación. Y el último dictamen: una auditoría no puede emitir un juicio concluyente sobre lo que sus evidencias no alcanzan. Ahora sabemos:

qué estamos auditando,

de quién recibimos la autorización,

qué rutas de comportamiento utiliza el sistema,

qué información es de referencia,

qué evidencias respaldan esos datos.

Pero los 99 errores definidos en el Volumen II no tienen la misma importancia para todos los sistemas. Un agente que resume documentos quizá no tenga riesgo de usar un precio incorrecto. En un agente de compras, en cambio, los errores de presupuesto, suscripciones y pagos duplicados pueden ser críticos. En un sistema de avatares, el consentimiento y la identidad sintética son cuestiones de nivel de veto. Para un agente web destacan la publicación en producción, los datos de referencia y la reversión de cambios. Para un agente de búsqueda de clientes son decisivos la identificación correcta del destinatario, los datos personales y la autorización de envío externo. El mismo error puede tener un efecto limitado en un borrador de bajo riesgo y afectar a millones de personas o a una operación de gran importe en otro sistema.

Por eso, el siguiente paso no consiste en probar al azar los 99 errores. Antes hay que responder:

¿Qué familias de errores se aplican realmente a este sistema? ¿Cuáles son más probables? ¿Cuáles causan más daño? ¿Cuáles son irreversibles? ¿Cuáles deben invalidar la puntuación global con un solo hecho? ¿Qué comportamientos deben restringirse de inmediato? ¿Dónde deben asignarse primero los recursos de prueba?

En el siguiente capítulo se construirán:

El mapa de riesgos GBO-99 y las puertas de veto

Los datos de referencia y las evidencias sólidas muestran qué es el sistema. El mapa de riesgos muestra dónde un fallo tendría las consecuencias más importantes.

Todos los errores merecen una prueba. Pero no tienen la misma prioridad, no causan el mismo daño ni pesan lo mismo en el dictamen.