Mejores prácticas de logging de LLM: 9 reglas que seguimos en producción [2026]

Mejores prácticas de logging de LLM: 9 reglas que seguimos en producción [2026]

Estas nueve mejores prácticas de logging de LLM son las reglas que nuestro stack de producción ejecuta de verdad: registramos 1,2 millones de requests de LLM al mes en cuatro servicios, y cada uno aterriza en Grafana Loki como una única línea JSON con modelo, tokens, latencia, cost_usd y trace_id. structlog 25.4.0 escribe el registro, Presidio elimina primero los PII, y todo el pipeline es la mitad de logging de nuestro stack de observabilidad.

Puntos clave

• Registra cada request de LLM como JSON estructurado con más de 14 campos con nombre, nunca como texto libre.
• Enmascara los PII antes de escribir el log con Presidio o equivalente, no después.
• Adjunta los atributos de las convenciones semánticas GenAI de OpenTelemetry a cada traza.
• Con 1M de requests al día, los mismos 60 GB cuestan $108/mes en Datadog, $30 en Loki y $1,20 en ClickHouse.

Qué significa realmente el logging de LLM (y por qué «registra todo» falla)

El logging de LLM consiste en capturar un registro estructurado de cada request y cada respuesta del modelo: el prompt, el completion, el conteo de tokens, la latencia, el coste y la traza que lo une todo a una sesión de usuario. No es logging de infraestructura. La CPU, la memoria y los reinicios de pods pertenecen a tu stack de métricas; este post solo cubre el registro a nivel de request que te permite depurar, costear y auditar el comportamiento del modelo.

El instinto de «registrarlo todo» es difícil de matar, y sale caro. Los prompts y completions completos con 1M de requests al día producen unos 60 GB de texto al mes, y una parte de ese texto son PII de clientes que ahora almacenas indefinidamente. El principio de minimización de datos del Artículo 5 del RGPD exige que los datos personales sean «adecuados, pertinentes y limitados a lo necesario», y un volcado de prompts en bruto no pasa esa prueba desde el día uno. Registrarlo todo no es una estrategia; es un pasivo con factura mensual.

¿Cuáles son las 9 reglas de logging de LLM?

Nueve reglas, en el orden en que las implementaríamos: registrar prompts y respuestas completos con identificadores hasheados, emitir JSON estructurado, capturar tokens y coste por request, adjuntar el contexto de traza de OpenTelemetry, enmascarar los PII antes de escribir, muestrear a alto volumen, definir niveles de retención, separar los eventos de seguridad y hacer que el resultado sea consultable. Cada regla viene abajo con el código o la tabla que la hace cumplir.

Regla 1: registra el prompt y la respuesta completos (con hashes, no PII en bruto)

Registra el prompt completo y el completion completo de cada request, porque los logs parciales son la razón por la que terminas mirando un incidente sin ningún registro de lo que el modelo vio realmente. La única excepción es la identidad: nunca escribas IDs de usuario, correos o nombres en bruto dentro del registro. En su lugar, guarda un hash SHA-256 del ID de usuario. Un hash te permite reconstruir el historial completo de sesiones de un usuario con una búsqueda offline, mientras que la línea de log en sí misma resulta inútil para cualquiera que no deba leerla. La misma lógica aplica a los system prompts: hashéales, registra el hash y guarda el texto plano en tu registro de prompts, donde ya tiene control de versiones.

Regla 2: usa JSON estructurado: cada campo con nombre, nada de texto libre

Para las mejores prácticas de logging de LLM en Python o cualquier otro lenguaje, el logging estructurado en JSON es la regla innegociable: cada campo con nombre, con tipo y consultable, nada volcado como una cadena con formato. Una línea de texto libre como INFO called gpt-4o, took 812ms solo se puede buscar con grep. Un registro JSON se puede agregar por modelo, sumar por coste y unir a una traza. Las propias mejores prácticas de producción de OpenAI empujan la misma idea: capturar metadatos estructurados en la capa del SDK en lugar de con sentencias print.

Este es el esquema que emite cada servicio de Techsy, catorce campos:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Tres campos merecen una nota. cost_usd se calcula en el momento del request a partir del conteo de tokens y la tarifa publicada del modelo, nunca se rellena después con un job nocturno. Los dos campos de hash son el compromiso de la Regla 1: correlacionables offline, opacos en el log. Y trace_id y span_id son valores de trace-context del W3C, que es exactamente de lo que trata la Regla 4.

Si cuatro servicios llamando directamente a proveedores te suena a cuatro lugares que instrumentar, un proxy de LiteLLM lo centraliza: un único hook de logging delante de cada proveedor.

Regla 3: captura el conteo de tokens y el coste por request

El seguimiento del uso de tokens pertenece a la propia línea de log, no a un job del warehouse que se ejecuta mañana. Cada proveedor devuelve el conteo de tokens de entrada y de salida en la respuesta; multiplícalo por la tarifa por token del modelo en ese momento exacto y escribe cost_usd en el registro. Las tarifas cambian, y difieren entre tokens de entrada en caché y tokens nuevos, así que calcular el coste más tarde con una tabla de precios estática reescribe la historia en silencio. Con el coste en cada línea, «¿qué funcionalidad es cara?» se convierte en una consulta de una línea en vez de un proyecto de finanzas, y alimenta directamente el trabajo de reducir tu gasto en API de LLM.

Regla 4: adjunta el contexto de traza (Semconv GenAI de OpenTelemetry)

Una línea de log sin trace ID es huérfana: puedes leerla, pero no puedes saber qué reintento, qué paso de RAG o qué turno de usuario la produjo. La solución son las convenciones semánticas GenAI de OpenTelemetry, los nombres de atributo estándar para instrumentar llamadas a modelos. Emite el log dentro de un span activo y el trace_id y el span_id se adjuntan solos, de modo que un clic en Grafana te lleva del waterfall de la traza directamente al registro en bruto.

Los atributos que vale la pena definir en cada span gen_ai:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Regla 5: enmascara los PII antes de escribir el log

El enmascaramiento de PII tiene que ocurrir antes de que se escriba el registro, no limpiarse después. Una vez que una dirección de correo está en Loki, también está en tus backups de object storage, y «lo borramos después» no es una respuesta válida para el RGPD. En nuestra configuración, Microsoft Presidio se ejecuta como un procesador de structlog y detecta el 94% de los correos y números de teléfono antes de que lleguen a Loki; los que se escapan son casi todos formatos raros, que vamos parcheando en recognizers personalizados a medida que los encontramos.

El hook completo son quince líneas:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

El enmascaramiento se sitúa en la misma capa del pipeline que tus filtros de entrada y salida, y debe probarse de la misma manera. Nuestro pipeline de guardrails trata un correo filtrado en un log como una eval fallida, no como una nota al pie de operaciones.

Regla 6: muestrea con inteligencia a alto volumen

Por debajo de unos 100K requests al día, regístralo todo. Por encima, el logging a volumen completo es un impuesto de almacenamiento sobre datos que nunca vas a leer, y el muestreo es la forma de quedarte con los registros que importan. La trampa: el muestreo aleatorio es la peor opción para el tráfico de LLM, porque los fallos, los rechazos y los requests de cinco dólares son raros por definición, así que una tasa uniforme del 10% descarta exactamente los eventos que depuras. Muestrea por resultado, no a cara o cruz.

Una configuración habitual es basado en reglas en los extremos (producción y tenants enterprise: registrar siempre) más basado en cola en el medio. El ángulo específico de logging en este marco: tus campos guardrail_result y cost_usd son las señales de muestreo, ya presentes si seguiste las Reglas 2 y 8.

Regla 7: define una política de retención antes de necesitarla

Una política de retención de logs es una decisión que tomas con calma, porque la alternativa es tomarla durante una revisión de costes con el doble de volumen. El principio de limitación del plazo de conservación del Artículo 5 del RGPD dice que los datos personales deben conservarse «no más tiempo del necesario», lo que en la práctica significa retención por niveles:

El nivel caliente responde a «¿qué pasó hace diez minutos?» de forma rápida y cara; el frío responde a «¿qué le dijimos a este cliente en marzo?» de forma lenta y barata. Borra según el calendario, automáticamente, o los niveles son solo un diagrama.

Regla 8: registra los eventos de guardrail y seguridad por separado

Los eventos de seguridad (bloqueos de guardrail, rechazos, violaciones de política) no son telemetría; son registros de auditoría, y pertenecen a su propio stream. Tres razones. Alertas: un pico de inyecciones de prompt bloqueadas debería despertar a alguien, y no puedes afinar esa alerta contra 1M de líneas rutinarias. Retención: el cumplimiento puede exigir que los registros de seguridad sobrevivan a los logs de depuración por años. Acceso: los auditores reciben el stream de seguridad, no toda tu manguera de datos. Etiqueta el veredicto en el registro principal (guardrail_result: "block") y enruta el registro completo al stream separado. Lo que cuenta como evento de seguridad se cubre en nuestra guía de eventos de guardrail.

Regla 9: haz que los logs sean consultables, no solo almacenables

Un log que no puedes consultar en menos de un minuto es un backup, no una señal de observabilidad. Consultable significa campos indexados, un lenguaje de consultas que tu equipo de guardia realmente conozca, y dashboards construidos antes del incidente. Nosotros usamos Loki y lo consultamos más de 30 veces por semana por anomalías de coste, regresiones de latencia y «muéstrame cada rechazo del tenant X ayer». La documentación de Grafana Loki es la referencia para la sintaxis; el patrón que justifica su coste es filtrar directamente sobre campos JSON parseados:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Cinco líneas, sin exportar a un notebook. Si tu almacén actual no puede hacer eso, es el problema que arreglar primero.

Lo que realmente registramos en producción

Basta de teoría. Aquí está la configuración editada de nuestro pipeline de AI SDR, el servicio detrás de la cifra de 1,2 millones de requests al mes de la introducción. Usa structlog 25.4.0 renderizando JSON, enviado a Grafana Cloud Loki vía Promtail. El modelo en este pipeline es claude-sonnet-4-20250514, y cada llamada pasa exactamente por la cadena de procesadores de las Reglas 2 y 5:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Dos cifras del primer trimestre con esta configuración. La ingesta mensual se estabilizó en 47 GB en cuatro servicios, y la latencia p95 de escritura de log es de 3 ms, es decir, el pipeline no añade nada medible al tiempo del request.

El cambio de configuración que se pagó solo: añadimos cost_usd a cada entrada de log en marzo de 2026. En una semana encontramos una plantilla de prompt que quemaba $340/mes en bucles de reintentos. Un error transitorio de la API disparaba tres reintentos, y cada uno reenviaba el contexto completo de 4.000 tokens. Los logs lo convirtieron en una consulta de una línea; sin el coste por request, habría aparecido como una partida inexplicada en la siguiente revisión presupuestaria trimestral.

¿Cuánto cuesta el almacenamiento de logs de LLM a escala?

Con 1M de requests al día, el almacenamiento de logs de LLM cuesta entre aproximadamente $1,20 y $108 al mes por los mismos datos, según el almacén. Las cuentas: un registro estructurado completo promedia unos 2 KB, así que 1M de requests al día son 2 GB al día, o 60 GB al mes. Los precios publicados por los proveedores que siguen abajo (julio de 2026) son lo que cuestan esos 60 GB en tres backends habituales.

Fuentes: precios de Datadog, Grafana Loki y la documentación de observabilidad de ClickHouse.

Dos advertencias, porque este es nuestro cálculo a partir de las tarifas de los proveedores, no un benchmark que hayamos ejecutado. Primero, la cifra de Datadog asume que indexas todo; la mayoría de los equipos indexan un subconjunto y pagan mucho menos, mientras que Loki y ClickHouse cobran principalmente por lo que almacenas. Segundo, los $1,20 de ClickHouse autoalojado esconden una factura real: el cómputo para correr el clúster y las horas de ingeniería para operarlo. Con 60 GB al mes, un servicio gestionado es casi siempre la respuesta más barata en coste total. El autoalojamiento empieza a tener sentido a partir de aproximadamente 1 TB al mes, donde la brecha por GB supera la sobrecarga operativa.

La brecha es la conclusión. Con 1M de requests al día, la diferencia entre Datadog indexado y ClickHouse autoalojado es de aproximadamente 90x: $108 frente a $1,20 por los mismos 60 GB. Elige el almacén en el momento de la arquitectura, no después de que llegue la factura.

¿Qué herramienta de logging deberías elegir?

Para la mayoría de los equipos, la elección se reduce a cuatro opciones: una plataforma nativa de LLM (Langfuse o LangSmith), una herramienta de capa de proxy (Helicone), o un pipeline simple de OpenTelemetry hacia infraestructura que ya tienes. La tabla cubre los puntos de decisión que realmente difieren; los dashboards, la reproducción y el versionado de prompts son lo mínimo esperable en las cuatro.

Nuestra opinión, sin rodeos: nosotros usamos OTel nativo más Loki porque ya teníamos el stack de Grafana para todo lo demás, y añadir una fuente de datos más ganó frente a adoptar un cuarto proveedor. Si empiezas desde cero sin ningún stack de observabilidad, el modelo de trazas de Langfuse y su plan gratuito son el camino más rápido hacia algo útil, y la opción de autoalojamiento mantiene abierta la puerta de salida. Si estás eligiendo entre los dos líderes nativos de LLM, nuestra comparativa de Langfuse vs LangSmith hace el análisis completo. Y si el logging es una pieza de una decisión de monitoreo más grande, la comparativa completa de plataformas cubre todo el espectro de opciones.

¿Cuáles son los errores más comunes de logging de LLM?

Seis errores explican la mayoría de las configuraciones rotas de logging de LLM que hemos visto. Cada uno es barato de evitar si lo detectas antes de que el volumen de logs lo haga:

• Registrar PII en bruto sin enmascarar. El más común y el más caro. Una exportación de soporte o un bucket vulnerado convierten los logs de prompts en un incidente de protección de datos. Enmascara antes de escribir (Regla 5), no al leer.
• Sin política de retención. El almacenamiento indefinido es el valor por defecto en todas partes, y duplica en silencio tu factura cada año. Si nunca borras, no tienes un sistema de logging; tienes un archivo con delirios de grandeza.
• Logs de texto no estructurados. La salida de print que solo puedes buscar con grep funciona a escala de demo y colapsa con 100K requests al día, cuando «encuentra cada request fallido del modelo X» se convierte en una tarde de scripts de shell en vez de una consulta.
• Registrar solo errores. Los requests exitosos son la línea base contra la que detectas la deriva, y son la materia prima de tu pipeline de evaluación. Registra también los aciertos, muestreados si el volumen obliga.
• Ignorar los campos de coste. Sin cost_usd por request no hay alertas de coste, no hay atribución por funcionalidad, y el bucle de reintentos de $340/mes de la sección de producción de arriba sigue invisible hasta la factura trimestral.
• Sin correlación de trazas. Los logs desconectados de los spans convierten la depuración de agentes multipaso en pura conjetura. Si a tu línea de log le falta un trace_id, la Regla 4 es la solución.

Preguntas frecuentes

¿Qué deberías registrar por cada request de LLM?

Como mínimo: el prompt y el completion completos con los PII enmascarados, el nombre del modelo, el conteo de tokens de entrada y salida, la latencia, el coste en USD, un identificador de usuario hasheado, y los IDs de traza y span de OpenTelemetry. Añade los IDs de las fuentes de RAG y el veredicto del guardrail si tu pipeline tiene esas etapas. Catorce campos con nombre, una línea JSON por request.

¿Cuál es el mejor formato para los logs de LLM?

JSON estructurado, un objeto por request, con cada campo explícitamente nombrado. Los logs de texto libre solo se pueden buscar con grep; los registros JSON se pueden agregar por modelo, sumar por coste y unir a trazas. Emite el registro con un logger estructurado como structlog en Python o pino en Node, y renderízalo con un serializador JSON, nunca con formato de cadenas.

¿Cómo se manejan los PII en los logs de LLM?

Enmascara antes de escribir el log, no después. Pasa el prompt y el completion por un detector como Microsoft Presidio dentro de tu pipeline de logging, reemplazando nombres, correos y números de teléfono por tokens como <EMAIL_ADDRESS>. Una vez que los PII en bruto llegan a tu almacén de logs, también están en tus backups, y el borrado retroactivo rara vez satisface la prueba de minimización del RGPD.

¿Cuánto cuesta el almacenamiento de logs de LLM a escala?

Para 1M de requests al día, unos 60 GB al mes a 2 KB por registro, espera aproximadamente $108/mes con los precios indexados de LLM Observability de Datadog, $30/mes en Grafana Cloud Loki, o unos $1,20/mes en almacenamiento S3 comprimido para ClickHouse autoalojado más cómputo. Esas son las tarifas publicadas por los proveedores a julio de 2026; el autoalojamiento añade tiempo de ingeniería encima.

¿Qué son las convenciones semánticas GenAI de OpenTelemetry?

Son los nombres de atributo estándar de OpenTelemetry para instrumentar llamadas a LLM: gen_ai.system para el proveedor, gen_ai.request.model para el modelo, gen_ai.usage.input_tokens y output_tokens para el conteo de tokens, y gen_ai.response.finish_reasons para el motivo por el que se detuvo la generación. Usarlos significa que cualquier backend compatible con OTel, desde Jaeger hasta Tempo pasando por Langfuse, lee tus trazas sin parsers personalizados.

¿Cómo se muestrean los logs de LLM con tráfico alto?

Conserva cada error, cada bloqueo de guardrail y cada request por encima de un umbral de coste, y después muestrea el resto. Este enfoque basado en cola preserva los eventos raros que realmente depuras, mientras que el muestreo aleatorio uniforme los descarta a la misma tasa que el tráfico aburrido. Por debajo de 100K requests al día, omite el muestreo por completo y regístralo todo.

¿Cuánto tiempo deberías retener los logs de LLM?

Divídelo en niveles: 7 días en caliente para depuración en vivo, 30 días en tibio para revisión de incidentes y análisis de costes, y hasta 1 año en frío en object storage comprimido para cumplimiento y auditorías. El principio de limitación de conservación del RGPD prohíbe conservar datos personales más tiempo del necesario, así que acompaña cada nivel con borrado automático en vez de limpieza manual.

¿Cuál es la diferencia entre logging de LLM y tracing de LLM?

Un log es un registro plano de un evento: este request ocurrió, con estos campos. Una traza es un árbol causal de spans a lo largo de todo el camino del request, digamos el retrieval, luego la llamada al modelo, luego dos llamadas a herramientas. Los logs te dicen qué; las trazas te dicen dónde y por qué. Las configuraciones de producción emiten ambos, unidos por trace_id.

Conclusión

Resumen: registra cada request como JSON con campos con nombre, calcula el coste en el momento del request, adjunta el contexto de traza de OTel, enmascara los PII antes de escribir, muestrea por resultado una vez que superes los 100K requests al día, y elige un almacén que realmente puedas consultar. Las nueve reglas están ordenadas para que puedas adoptar una por sprint, y las Reglas 2, 4 y 5 son las tres que se amortizan más rápido. Si estás eligiendo el stack de monitoreo más amplio alrededor de los logs, empieza con nuestro resumen de las mejores plataformas de observabilidad de IA. Y si necesitas ayuda para conectar el logging estructurado de tu stack de LLM, consigue una consulta gratuita.