Normalizar eventos de modelo y de herramientas

Normalizar es traducir los eventos de todas las fuentes a un esquema común: los mismos nombres de campo, el mismo formato de hora y los mismos valores para lo mismo. Así una regla escrita una vez vale para todas las fuentes, y una consulta puede unir la pasarela con las herramientas por el identificador de la petición sin saber cómo lo llama cada equipo.

Para los eventos de modelo no hace falta inventar los nombres. Las convenciones semánticas de OpenTelemetry para IA generativa, todavía en desarrollo, proponen atributos como el modelo pedido, el modelo que respondió, los tokens o la herramienta ejecutada. Adoptarlos en el SIEM tiene una ventaja práctica: el día que la aplicación se instrumente con esas convenciones, los eventos llegan ya con el nombre correcto.

En las herramientas de un asistente casi siempre hay dos identidades. Una es técnica: la cuenta de servicio con la que el servicio de herramientas ejecuta, que es la misma para todas las llamadas. La otra es la persona para quien se hizo la llamada. Si el campo de usuario del esquema común se llena con la identidad técnica, todas las acciones del asistente parecen hechas por la misma cuenta, y cualquier regla «por usuario» deja de servir.

Compara el registro crudo de herramientas con el mapeo y con la salida normalizada.

Un registro con la hora en la zona local, sin indicarla, se convierte en un error silencioso al normalizar: si el mapeo la toma por UTC, el evento queda desplazado tantas horas como la diferencia de zona. En la salida aparece entonces un veredicto del filtro horas antes del mensaje que lo provocó, y una correlación por ventana de tiempo nunca lo encuentra.

Lee la línea del filtro de entrada, el comentario del archivo y lo que dice el leeme.txt sobre la zona horaria.

En los módulos de registro y de observabilidad viste que el modelo pedido y el que respondió no siempre coinciden: la pasarela recibe un alias y, si el proveedor principal limita la tasa, manda la llamada a un modelo de respaldo. Aquí el riesgo es otro: que la fuente sí lo registre y la normalización lo pierda. Un mapeo que copia el alias en los dos campos borra esa diferencia en el SIEM, y ninguna regla posterior la puede recuperar.

El texto de los mensajes es lo más tentador de llevar al SIEM y lo más delicado: contiene datos personales, a veces secretos que el cliente pegó sin pensar, y el SIEM lo puede consultar mucha gente durante mucho tiempo. La práctica habitual es dejar el texto donde está más protegido y llevar al SIEM lo que permite detectar e ir a buscarlo: metadatos, veredictos e identificadores.