Cada acción administrativa dentro de AI Suite genera una fila de auditoría JSONL. La fila registra la marca de tiempo, el correo electrónico del actor, el verbo de la acción, el recurso afectado, el X-App-Id del cliente originario, y un hash estable que permite a un revisor correlacionar la fila con eventos posteriores. La fila registra ninguno de los datos de entrada o salida del modelo. Sin texto de prompt, sin texto de completado, sin contenido de documento, sin entidades extraídas. Esa elección — sin contenido por diseño — es lo que hace que la fila de auditoría sea útil para revisores de adquisiciones y cumplimiento, y vale la pena explicar por qué.

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

Una fila representativa, ligeramente redactada:

{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
 "subject":"user@bank.example","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

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

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

Por qué el contenido se mantiene fuera de la fila

Dos razones, una regulatoria y otra operativa.

Regulatoria: la Ley de IA de la UE exige a los implementadores de IA de alto riesgo mantener registros "por un período apropiado", para monitorear la operación del sistema y demostrar cumplimiento cuando se solicite [1]. La obligación recae en el implementador de evidenciar lo ocurrido. Las API de LLM en la nube responden a esto almacenando el prompt y la respuesta en la infraestructura del proveedor, lo que transfiere el problema del manejo de datos al proveedor — y crea un segundo perímetro de cumplimiento que el implementador no controla. La auditoría local sin contenido responde a la misma cuestión regulatoria sin esa transferencia: el implementador mantiene el contenido, en el almacenamiento propio del implementador, bajo las reglas de retención del implementador.

Operativa: cada byte de contenido del modelo almacenado es un byte que necesita ser cifrado, controlado en acceso, retenido, eliminado según cronograma y producido bajo descubrimiento electrónico. Las filas sin contenido son pequeñas (unos pocos cientos de bytes), de forma fija, solo se añaden datos y son trivialmente serializables en el SIEM existente del implementador. Son la unidad probatoria más pequeña que aún satisface la obligación.

A qué corresponde esto en los principales marcos

NIST AI RMF 1.0 nombra la auditabilidad como una dimensión central de la IA confiable y pide a los implementadores mantener "registros de acciones del sistema suficientes para reconstruir decisiones" [2]. "Suficientes para reconstruir" es la frase clave: la fila debe permitir a un revisor reconstruir lo ocurrido. Una fila sin contenido hace eso para acciones administrativas (se emitió una licencia, se cambió una política, se inscribió un servidor) sin retener el contenido de una inferencia. Para el lado del contenido de la inferencia de la obligación, el almacenamiento local propio del implementador es lo que responde a la pregunta.

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

La forma en que entregamos — la AI Admin Console interfaz de usuario, el aisuite-server daemon con auditoría JSONL, y el gancho de reenvío SIEM por organización — implementan esto directamente. Cada evento administrativo queda registrado en una fila legible para el desplegador; en la ruta local o alojada por el cliente para inferencia, el contenido de las indicaciones y respuestas no llega al plano de control de Software Tailor.

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

La pregunta de compras que detiene a los proveedores de IA en la nube es: "¿dónde reside el contenido de la inferencia y puede nuestro equipo de cumplimiento producirlo bajo demanda?" La auditoría sin contenido responde a la misma pregunta, con dos respuestas claras: el contenido reside en su hardware, y su equipo lo produce porque ya lo tiene. La fila de auditoría de nuestro lado prueba que la acción ocurrió; el contenido de su lado prueba qué hizo la acción.

Para el marco más amplio de compras — incluyendo cómo liderar el cuestionario al proveedor con estas propiedades en lugar de certificaciones del lado del proveedor — consulte Por qué los despliegues de IA on-premises se estancan en compras y el artículo sobre cumplimiento con el Acta de IA de la UE.

Lo que sigue siendo responsabilidad del desplegador

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

  • Definir qué significa "suficiente para reconstruir" para sus propios flujos de trabajo — período de retención, reglas de enmascaramiento, postura de descubrimiento electrónico.
  • Operar el almacén local de contenido (lo que el desplegador elija — sistema de archivos, base de datos documental, almacén de blobs cifrados) y reenviar las filas de auditoría de nuestro lado al SIEM donde las correlacionan con sus propios registros.
  • Redactar el memorando de obligaciones del implementador que señala esta arquitectura durante la adquisición.

Nuestro lado entrega la arquitectura y el formato de fila de auditoría. Todo lo que sigue a eso — incluyendo la política de retención del contenido — es donde el equipo de cumplimiento del implementador aplica sus propias reglas.

Referencias

  1. Comisión Europea. "Ley de IA — Marco regulatorio sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultado el 03-06-2026.
  2. NIST. "Marco de Gestión de Riesgos de IA (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Consultado el 03-06-2026.
  3. ENISA. "Ciberseguridad en Inteligencia Artificial." https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Consultado el 03-06-2026.