Fuentes de registro de una aplicación de IA

Una aplicación con un modelo dentro tiene al menos cinco capas que escriben registros distintos. La aplicación (el orquestador) sabe quién escribió, por qué canal y en qué sesión. La pasarela de modelos sabe qué modelo se pidió, cuál respondió, cuántos tokens costó y si hubo respaldo. El filtro de contenido sabe qué entrada o salida marcó y con qué regla. Las herramientas saben qué acción se ejecutó, con qué argumentos y en nombre de quién. La nube sabe qué identidad tocó qué recurso y desde dónde.

Ninguna de estas fuentes cuenta la historia completa. Por eso el primer trabajo de detección es un inventario: qué fuente existe, qué registra, quién es su dueño, si llega al SIEM y cuánto tiempo se guarda allí.

No todas las fuentes pesan lo mismo. Las que registran acciones con efecto (mover dinero, cambiar datos de un cliente, entregar un documento) son las que una investigación necesita primero, porque son las que causan daño. Si una de ellas se queda en el servicio que la escribe, la guardia no puede escribir ni una regla sobre lo que el asistente hace de verdad.

Consulta qué fuentes no se envían al SIEM y cruza el resultado con la política de registro.

Muchos incidentes con un asistente se descubren tarde: un cliente reclama semanas después, o una auditoría de facturación encuentra un patrón raro el mes siguiente. La ventana de investigación es cuánto tiempo atrás se puede reconstruir lo ocurrido, y la fija la fuente que menos tiempo se guarda, no la que más. Basta una fuente corta para que una pregunta («¿qué modelo respondió a ese cliente el día 3?») se quede sin respuesta.

Para unir lo que vio cada capa en una misma conversación hace falta un identificador común que viaje de una pieza a otra: el de la petición. Cada equipo lo nombra a su manera, y eso se arregla al normalizar; lo que no tiene arreglo es una fuente que no lo escribe, porque entonces solo se puede unir por la hora, y en un minuto hay decenas de peticiones a la vez.

La capa de nube suele unirse por identidad y por tiempo, no por petición. Las capas de aplicación, modelo, herramientas y recuperación, en cambio, deberían llevarlo siempre.

Un inventario con huecos siempre deja más trabajo del que cabe en una semana. Se prioriza por lo que la guardia no podría ver hoy si algo pasara: primero la fuente que registra el daño, después la que permite unir las piezas, después la que limita cuánto atrás se puede mirar.