Producto Publicado el 2026-06-05 · 6 min de lectura

Registros de auditoría sin contenido: cómo demostramos lo que hizo el modelo sin conservar los prompts

Cada acción administrativa dentro de AI Suite produce una fila JSONL de auditoría que registra marca temporal, actor y acción, y ningún contenido de prompt ni de respuesta. El deployer conserva el contenido; nosotros conservamos la prueba de que la acción ocurrió.

Cada acción administrativa dentro de AI Suite produce una fila JSONL de auditoría. La fila registra la marca temporal, el correo electrónico del actor, el verbo de acción, el recurso afectado, el X-App-Id del cliente de origen y un hash estable que permite a un revisor correlacionar la fila con eventos posteriores. La fila no registra ninguna entrada ni salida del modelo. Ningún texto de prompt, ningún texto de finalización, ningún contenido de documento, ninguna entidad extraída. Esa elección —sin contenido por diseño— es lo que hace útil la fila de auditoría a los revisores de compras y cumplimiento, y vale la pena explicar por qué.

Qué contiene una fila de auditoría, y qué no

Una fila representativa, ligeramente censurada:

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Lo que tiene: suficientes metadatos para responder a las preguntas sobre obligaciones del deployer que plantean los auditores: quién hizo qué, cuándo, contra qué recurso, desde qué cliente. Lo que no tiene: ninguna carga útil del flujo de trabajo de IA. Si la acción invocó un modelo (no lo hizo en este ejemplo, pero podría haberlo hecho), habría una fila que registra el evento de invocación, pero ningún registro del prompt o de la respuesta en nuestra infraestructura.

Esa separación es deliberada. La fila de auditoría es la prueba de que ocurrió una acción. El contenido de la acción —el prompt enviado al modelo, la respuesta devuelta— vive en el propio hardware del deployer, regido por la propia política de retención del deployer. Nosotros nunca lo vemos.

Por qué el contenido se mantiene fuera de la fila

Dos razones, una regulatoria y otra operativa.

Regulatoria: la EU AI Act exige a los deployers de IA de alto riesgo que conserven registros «durante un periodo apropiado», que monitoricen el funcionamiento del sistema y que demuestren el cumplimiento cuando se solicite ^[1]. La obligación recae sobre el deployer para evidenciar lo que ocurrió. Las APIs LLM en la nube responden a esto almacenando el prompt y la respuesta en la infraestructura del proveedor, lo que traslada el problema de tratamiento de datos al proveedor y crea un segundo perímetro de cumplimiento que el deployer no controla. La auditoría local sin contenido responde a la misma pregunta regulatoria sin esa transferencia: el deployer conserva el contenido, en su propio almacenamiento, bajo sus propias reglas de retención.

Operativa: cada byte de contenido de modelo almacenado es un byte que hay que cifrar, controlar el acceso, retener, eliminar según calendario y producir bajo e-discovery. Las filas sin contenido son pequeñas (unos pocos cientos de bytes), de forma fija, sólo de adición y trivialmente serializables al SIEM existente del deployer. Son la unidad probatoria más pequeña que aún satisface la obligación.

Con qué se corresponde esto en los marcos principales

NIST AI RMF 1.0 nombra la auditabilidad como una dimensión central de la IA fiable y pide a los deployers que mantengan «registros de acciones del sistema suficientes para reconstruir decisiones» ^[2]. «Suficientes para reconstruir» es la expresión clave: la fila debe permitir a un revisor reconstruir lo que ocurrió. Una fila sin contenido lo hace para acciones administrativas (se emitió una licencia, se cambió una política, se dio de alta un servidor) sin retener el contenido de una inferencia. Para el lado de la obligación referente al contenido de la inferencia, el almacenamiento local propio del deployer es lo que responde a la pregunta.

La orientación sobre ciberseguridad de IA de ENISA enmarca esto desde el ángulo del modelado de amenazas ^[3]: cada prompt y respuesta almacenado en la infraestructura de un proveedor amplía la superficie de ataque del deployer para incluir la del proveedor. Eliminar el contenido del modelo del lado del proveedor reduce esa superficie a lo que el deployer ya controla.

La forma en la que distribuimos —la interfaz de AI Admin Console, la auditoría JSONL del daemon aisuite-server y el hook de reenvío al SIEM por organización— implementa esto directamente. Cada evento administrativo aterriza en una fila legible por el deployer; ningún contenido de prompt ni de respuesta sale jamás del perímetro del deployer.

Cómo se ve esto en una revisión de compras

La pregunta de compras que atasca a los proveedores de IA en la nube es: «¿dónde vive el contenido de la inferencia, y puede nuestro equipo de cumplimiento producirlo cuando se le solicite?». La pregunta de compras a la que responde la auditoría sin contenido es la misma, con dos respuestas claras: el contenido vive en su hardware, y su equipo lo produce porque ya lo tiene. La fila de auditoría de nuestro lado demuestra que la acción ocurrió; el contenido de su lado demuestra qué hizo la acción.

Para el enfoque de compras más amplio —incluido cómo encabezar el cuestionario al proveedor con estas propiedades en lugar de con certificaciones del lado del proveedor— véase Por qué los despliegues de IA on-premises se atascan en compras y el artículo sobre el cumplimiento de la EU AI Act.

Qué sigue siendo responsabilidad del deployer

La auditoría sin contenido es una propiedad estructural del despliegue, no una solución de cumplimiento de extremo a extremo. El deployer sigue siendo propietario de:

Definir qué significa «suficiente para reconstruir» para sus propios flujos de trabajo: periodo de retención, reglas de enmascaramiento, postura de e-discovery.
Operar el almacén de contenido local (lo que el deployer elija: sistema de ficheros, base de datos documental, almacén de blobs cifrado) y reenviar las filas de auditoría desde nuestro lado al SIEM donde las correlaciona con sus propios registros.
Redactar el memorando de obligaciones del deployer que señale esta arquitectura durante el proceso de compras.

Nuestro lado entrega la arquitectura y el formato de fila de auditoría. Todo lo que está aguas abajo de eso —incluida la política de retención sobre el contenido— es donde el equipo de cumplimiento del deployer aplica sus propias reglas.

Referencias

European Commission. «AI Act — Regulatory framework on AI.» digital-strategy.ec.europa.eu. Consultado el 2026-06-03.
NIST. «AI Risk Management Framework (AI RMF 1.0).» nist.gov/itl/ai-risk-management-framework. Consultado el 2026-06-03.
ENISA. «Artificial Intelligence Cybersecurity.» enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Consultado el 2026-06-03.

Vea la auditoría sin contenido ejecutándose sobre una carga de trabajo real.

Un piloto gratuito de 1 semana coloca el modelo en el hardware del cliente y reenvía las filas de auditoría al SIEM del cliente, de modo que el equipo de cumplimiento pueda redactar el memorando de obligaciones del deployer sobre sus propios registros.

Iniciar un piloto gratuito de 1 semana