Registro, seguimiento de auditoría y comprobabilidad

Ganancias:

• Capacidad para diseñar un esquema mínimo de seguimiento de auditoría suficiente para reconstruir el evento.
• Capacidad para evitar que el registro sea una fuente de fuga al enmascarar el mensaje/respuesta
• Capacidad para establecer registros verificables con identidad de correlación, inmutabilidad y período de retención.

En un sistema de IA, un día seguramente se planteará la pregunta: "¿Por qué se tomó esta decisión de esta manera? ¿Qué pasó exactamente ese día?". Esta pregunta puede ser formulada por un cliente, un auditor, un regulador o un tribunal. Su respuesta será una pista de auditoría verificable o "no lo sabemos". Esto último es inaceptable en un entorno corporativo. En esta unidad, aprenderemos qué se debe y qué no se debe registrar específicamente para la IA, cómo establecer un registro de auditoría y cómo mantener los registros en equilibrio con la seguridad y la privacidad.

¿Por qué el registro es diferente en la IA?

En el software clásico, se registra "quién hizo qué". En IA, a esto se agregan tres nuevas dimensiones: qué modelo/versión se utilizó, qué mensaje se envió y qué respuesta se produjo. Cuando se produce un error o una queja, no se puede reconstruir el incidente sin estos tres. Pero este mismo mensaje/respuesta puede contener PII, como vimos en la unidad 2, lo que significa que el registro en sí puede convertirse en una fuente de filtraciones. Este es el arte del equilibrio.

Precaución: El registro no es "registrar todo". Demasiado registro crea un riesgo para la privacidad y muy poco registro genera falta de evidencia. El objetivo es conservar suficiente PII para reconstruir el evento enmascarándolo.

¿Qué se debe registrar? Esquema de seguimiento de auditoría

Una pista de auditoría de IA sólida incluye, como mínimo:

• Quién: ID de usuario y rol (o ID de servicio).
• Cuándo: marca de tiempo (agregar solo si es posible).
• Qué: Acción deseada y herramientas convocadas.
• Qué modelo: nombre y versión del modelo (por ejemplo, claude-opus-4-8), parámetros críticos como la temperatura.
• Resumen de entrada/salida: una versión enmascarada o un resumen/hash de la solicitud y la respuesta.
• Decisión: ¿Se procesó automáticamente, pasó a un humano, fue aprobado o rechazado?
• Resultado: ¿La operación fue exitosa o hubo un error? ¿Qué recurso se ve afectado?

Paso a paso: establecer una pista de auditoría

1. Establece una meta. ¿Quién leerá estos registros y por qué? (Respuesta a incidentes, auditoría de cumplimiento, depuración). El propósito determina lo que conserva.
2. Hacer cumplir la política de PII. Enmascare el mensaje/respuesta antes de iniciar sesión (unidad 2).
3. Proporcionar inmutabilidad. Permita que los registros críticos sean solo para agregar; Nadie debería poder borrar el pasado en silencio.
4. Definir el período de retención. Determinar la duración de acuerdo con el equilibrio entre exigencia legal y confidencialidad; Eliminar automáticamente cuando expire el tiempo.
5. Limitar el acceso. El acceso a los registros también debe protegerse con RBAC; También se debe registrar la lectura del registro.
6. Agregue ID de correlación (ID de seguimiento). Conecte todos los pasos de una solicitud (entrada, llamada de herramienta, verificación, salida) con una única identidad.

Cuatro plantillas copiables

Esquema de registro de auditoría (JSON):

{ "trace_id": "...", "time": "AAAA-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary": "<masked>", "response_summary": "<masked>", "tools": ["tool_a", "tool_b"], "decisión": "auto|aprobación_humana", "aprobación": "aprobado|rechazado|ninguno", "resultado": "éxito|error", "recurso_afectado": "..."}

Solicitud de control de registro de PII:

Consulte los ejemplos de registro a continuación. ¿Están completos los campos requeridos para la pista de auditoría (quién, cuándo, modelo, decisión, resultado)? ¿También se ha filtrado PII sin procesar? Para cada fila, informe como: "espacio insuficiente/faltante:... /fuga de PII:..." <logs>{{ ejemplos }}</logs>

Mensaje de reconstrucción de eventos:

Los siguientes registros de auditoría pertenecen a un único trace_id. Convierta el evento en una narrativa en orden cronológico: ¿qué quería el usuario, qué hizo el modelo, qué validaciones se realizaron, cómo se tomó la decisión, cuál fue el resultado? Marcar pasos faltantes o inconsistentes.<records>{{ trace_registers }}</records>

Regla de decisión de la política de retención:

Para cada tipo de registro, determine:- ¿Existe una obligación legal de retención? (período mínimo si lo hubiera)- ¿Contiene PII? (si se incluye, acorte la duración, limite el acceso) - ¿Evidencia de incidente de seguridad? (la tienda no se puede cambiar)Resultado: "almacenar N días + agregar solo mi + nivel de acceso".

Aviso débil / Aviso fuerte

mal enfoque

Enfoque fuerte

No iniciar sesión en absoluto ("no es necesario")

Registro del conjunto mínimo para reconstruir el evento

Registro de mensaje/respuesta sin procesar tal como está

Resumen enmascarado + registro de ID de seguimiento

Almacene registros de forma ilimitada

Período de retención con equilibrio legal + privacidad

Cualquiera puede eliminar registros

Los registros críticos se pueden agregar únicamente y el acceso está controlado

Tres mini estuches

Caso 1: Trace ID redujo la investigación de un día a 15 minutos. "Mi solicitud fue rechazada injustamente", dijo un cliente al asistente de evaluación previa de crédito de un banco. Gracias a la identificación de correlación, el equipo reconstruyó la entrada de esa aplicación, las verificaciones de los empleados y la decisión en 15 minutos; mostró que el error fue causado por un umbral incorrecto en una validación de regla y lo solucionó.

Caso 2: Durante la auditoría se descubrió un registro excesivo. Una empresa de comercio electrónico estaba escribiendo todas las indicaciones/respuestas en registros sin procesar para su depuración. Durante la auditoría anual, se vio que estos registros contenían direcciones y números de teléfono de clientes y se conservaron durante 2 años. El hallazgo se cerró cambiando a una política de enmascaramiento + retención de 90 días; Se mantuvo la función de seguimiento de auditoría.

Caso 3: El registro de solo agregar reveló abuso interno. Un empleado de un proveedor intentó eliminar registros para ocultar un lote erróneo que había realizado. Dado que los registros son solo para agregar y los intentos de lectura/eliminación de registros se registran, el intento fue visible de inmediato; El incidente resultó en una corrección disciplinaria y de proceso.

Consejo: Asigne un ID de correlación (ID de seguimiento) a cada solicitud y siga todos los pasos. Cuando ocurre un problema, poder recopilar "todo lo relacionado con esa solicitud" con una sola consulta es el mayor acelerador de la respuesta a incidentes.

Errores comunes

• No registrar nada o registrar tan poco que no se puede reconstruir el evento.
• Registrar la solicitud/respuesta sin procesar sin máscara y convertir el registro en una fuente de fuga.
• No registrar el nombre/versión del modelo ni la decisión (automática/humana).
• Almacenar registros durante un período de tiempo ilimitado aumenta el riesgo de privacidad.
• Dejar registros críticos sujetos a cambios; No registrar el acceso al registro.
• No poder conectar los pasos entre sí porque no utiliza un ID de correlación (ID de seguimiento).

En resumen

• El registro de IA añade tres dimensiones a “quién hizo qué”: qué modelo/versión, qué mensaje, qué respuesta.
• El objetivo es mantener la PII lo suficientemente mínima como para reconstruir el evento enmascarándolo, ni más ni menos.
• La pista de auditoría debe incluir campos de quién/cuándo/qué/qué modelo/decisión/resultado.
• Los registros críticos deben ser solo para agregar, el acceso debe ser limitado y el acceso a los registros también debe registrarse.
• El ID de correlación (ID de seguimiento) conecta todos los pasos de una solicitud y acelera la investigación de incidentes.

Tarea de aplicación

Seleccione una solicitud de su propio flujo de IA y escriba la pista de auditoría ideal para ella con el esquema JSON anterior. Luego haz dos pruebas: (1) ¿Puedes contar la historia de principio a fin solo con esta grabación? (2) ¿Hay PII sin procesar en el registro? Si falta un campo, agréguelo, si hay PII, enmascarelo. Finalmente, establezca un período de retención y un nivel de acceso.

lista de verificación

• [] El seguimiento de auditoría incluye campos quién/cuándo/qué/patrón/decisión/resultado.
• [] El mensaje/respuesta está enmascarado antes de los registros (sin PII).
• [] Se asigna un ID de correlación (ID de seguimiento) a cada solicitud.
• [] Los registros críticos se pueden agregar únicamente y el acceso está controlado.
• [ ] El período de almacenamiento está definido por el equilibrio legal + confidencialidad y se elimina al final del período.
• [ ] Con registros puedo reconstruir un evento en menos de 30 minutos.