Capítulo 11 — Observabilidad, registro y respuesta a incidentes

Undécima entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que trata el logging, el alertado y la respuesta a incidentes como la capa que convierte las defensas arquitectónicas en un sistema que los operadores pueden realmente operar.

Por qué existe este capítulo

Un sistema con la estructura correcta pero sin visibilidad falla de forma invisible. El capítulo 11 recorre la capa de observabilidad para sistemas LLM — qué registrar, cómo detectar abuso y anomalía, cómo alertar sin producir ruido, cómo ejecutar un playbook de respuesta a incidentes cuando algo va mal y cómo aprender de lo ocurrido. Las disciplinas generales se transfieren de la ingeniería operacional en otros ámbitos, con extensiones específicas para LLM: las salidas probabilísticas hacen que la reproducción de incidentes requiera capturar más estado que en sistemas deterministas; las convenciones semánticas OpenTelemetry GenAI, desarrolladas desde 2024, dan el vocabulario neutral al proveedor para ese estado.

11.1 Qué registrar es una decisión de política, no un valor por defecto

Registrar demasiado poco deja al equipo sin capacidad de investigar. Registrar demasiado crea problemas de cumplimiento, coste y privacidad que eventualmente fuerzan a reducir. La posición defendible es el mínimo que sostenga los casos de uso operativos que el equipo ha identificado, en una forma estructurada que soporte cada uno. Los propósitos incluyen típicamente alertado en tiempo real sobre abuso o anomalía, investigación posterior de incidentes, planificación de capacidad y análisis de coste, reporting de cumplimiento y evaluación continua del comportamiento del modelo. Cada propósito exige cosas distintas al esquema; un log diseñado para uno es inadecuado para los demás. Las convenciones semánticas OpenTelemetry GenAI definen spans y atributos para la llamada al LLM — nombre del modelo, proveedor, parámetros de petición, contenido del prompt, contenido de la respuesta, conteos de tokens, latencia, coste — que permiten al tooling downstream parsear la misma telemetría con independencia del SDK específico. Langfuse, Helicone, Arize Phoenix y Datadog LLM Observability consumen todos esta forma. Una entrada de log de producción incluye típicamente el request ID, el principal autenticado, el inquilino, la versión del modelo y el proveedor, el prompt ensamblado completo (con contexto recuperado y su procedencia), las llamadas a herramientas y sus salidas, el contenido de la respuesta, las puntuaciones del clasificador de seguridad en entrada y salida, y la contabilidad de latencia y tokens. Almacenar esto de forma responsable significa ser explícito sobre las ventanas de retención, el manejo de PII y los controles de acceso sobre el propio store de logs.

11.2 La detección compone señales de firma, estadísticas y conductuales

Una vez la telemetría está estructurada, la siguiente pregunta es qué patrones indican que algo va mal. La coincidencia por firma es la primera línea más barata — frases conocidas de inyección de prompts, preámbulos de estilo DAN, cargas útiles codificadas en base64, montajes de role-play observados antes. La lista se construye a partir de la investigación pública, el trabajo interno de red team y los incidentes pasados. Las firmas capturan variantes conocidas; los adversarios se adaptan una vez aprenden qué frases están marcadas. La detección de anomalías estadística vigila la divergencia de la línea base: distribuciones inusuales de tokens, ratios atípicos de latencia a longitud, picos súbitos en la tasa de rechazo o en la tasa de invocaciones específicas de herramientas. Las líneas base derivan lentamente en condiciones normales y se desplazan bruscamente en las anormales. La detección de patrones conductuales encaja perfiles de abuso incluso cuando peticiones individuales no son abiertamente maliciosas — un único principal que emite miles de variantes parafraseadas de la misma petición restringida, un pico en peticiones que combinan contenido legítimo con un sufijo específico, un drift lento en las distribuciones de respuesta por usuario. La detección solo es útil si conduce a alertas a las que los operadores realmente responden. La taxonomía distingue típicamente crítica (abuso activo a escala, avisar a un ingeniero de guardia), alta (patrón notable con daño acotado, notificación en horario laboral) y media/baja (dashboards y revisión semanal). La fatiga de alertas es el modo de fallo; la disciplina estricta de severidad es lo que la previene.

11.3 La respuesta a incidentes es un playbook, no improvisación

NIST SP 800-61 Revision 2 da el marco — preparación, detección y análisis, contención, erradicación, recuperación, actividad post-incidente — que el playbook específico para LLM extiende. La preparación significa que los runbooks, los turnos de guardia y el acceso al tooling relevante existen antes del incidente. La detección y análisis es donde la observabilidad de la sección 11.1 rinde fruto. La contención para un incidente LLM puede significar activar un feature flag para deshabilitar una herramienta, bajar a una versión más conservadora del modelo, apretar límites de tasa sobre un principal o inquilino específico, o redirigir tráfico a un stack alternativo. La erradicación depende del tipo de incidente: un jailbreak puede necesitar una regla de filtro añadida, un documento RAG comprometido puede necesitar retirarse del índice, una credencial filtrada puede necesitar rotación. La recuperación es cuando el sistema vuelve a la normalidad, con la contención revertida y la erradicación verificada. La actividad post-incidente es donde se concentra el trabajo específico de modelo: reproducir el comportamiento si es posible, caracterizar la frontera del fallo, decidir si el incidente refleja algo del modelo que debería cambiar cómo se usa, y realimentar el resultado a la suite de evaluación de modo que las regresiones futuras se capturen antes del despliegue. La reproducción no siempre es posible bajo sampling de temperatura no nula, pero el objetivo es definir cuándo ocurre el comportamiento no deseado.

Lo que prepara el Capítulo 11

El capítulo 12 cierra la parte IV con la capa de identidad y acceso — quién tiene permiso para interactuar con el sistema, bajo qué términos y cómo se estructura la aplicación a lo largo de los componentes. Las disciplinas tradicionales se aplican: autenticación con claves de API, OAuth y mTLS; autorización con RBAC y ABAC; aislamiento multi-tenant; límites de tasa y cuotas; capas de gobernanza empresarial. Las extensiones específicas para LLM afectan al modelo como principal — un agente actuando en nombre de un usuario tiene su propia identidad y sus propios permisos — al papel de los tokens de capacidad para invocación de herramientas y a la configuración por inquilino del comportamiento del modelo que las plataformas LLM multi-tenant tienen que soportar. El capítulo 13 abre después la parte V con el panorama regulatorio, donde los controles técnicos que este libro ha desarrollado tienen que mapearse al Reglamento de IA, al RGPD, a las leyes estatales de EE. UU. y a los marcos que los rodean.

Próximamente — Capítulo 12: Control de acceso e identidad. Autenticación, RBAC frente a ABAC, aislamiento multi-tenant, límites de tasa y la capa de gobernanza empresarial que hace usables los sistemas LLM en entornos regulados.