Monitoring en la era de la IA: qué cambia cuando tu app usa LLM

El monitoring tradicional se rompe con la IA#

Antes tu app funcionaba así:

Petición → Tu código → Base de datos → Respuesta (determinista)

Sencillo de monitorizar: ¿se está ejecutando el código? ¿Responde la base de datos? ¿Son rápidas las respuestas?

Ahora tiene esta pinta:

Petición → Tu código → API LLM → El LLM procesa token a token →
Base de datos → Respuesta (no determinista)

Tres problemas nuevos:

1. El coste es impredecible: las API LLM cobran por token. La petición de un usuario puede costar $0,01 o $1,00 según la longitud de la salida.
2. La calidad es difícil de medir: el monitoring tradicional dice "petición correcta". Pero ¿la IA ha dado un resultado útil o una alucinación?
3. La latencia es variable: las respuestas de los LLM pueden tardar 500 ms o más de 30 segundos según el modelo y el número de tokens.

El monitoring tradicional no detecta estos problemas.

---

Qué debe rastrear el monitoring en la era de la IA#

1. Coste y presupuesto de la API LLM#

El problema:

Día normal:
- 10.000 peticiones a OpenAI
- Media de 500 tokens de entrada, 200 tokens de salida
- Coste: 10.000 × ($0,005 + $0,015) = $200/día

Día malo (inesperado):
- 50.000 peticiones a OpenAI
- Media de 2.000 tokens de entrada, 1.000 tokens de salida
- Coste: 50.000 × ($0,05 + $0,15) = $10.000/día

Sin monitoring: no te enteras hasta que llega la factura de AWS

Qué monitorizar:

✅ Tokens usados por petición
✅ Total de tokens usados hoy (vs. presupuesto diario)
✅ Coste por petición
✅ Gasto total (vs. presupuesto mensual)
✅ Coste por usuario (identifica usuarios pesados)
✅ Tendencia del coste (¿está subiendo? ¿Por qué?)

Umbrales de alerta:

• Coste >2x lo normal en una hora → Aviso
• Coste >5x lo normal en una hora → Alerta crítica
• Gasto mensual >80 % del presupuesto → Alerta

2. Calidad de la salida de la IA#

El problema:

El monitor tradicional dice: "Petición correcta, tiempo de respuesta 2s, status 200"
Realidad: la IA alucinó (dio información falsa)
Experiencia del usuario: usuario frustrado

Qué monitorizar:

✅ Detección de alucinaciones
  - ¿La IA se inventó hechos? (Compara con la base de conocimiento)
  - ¿La IA se contradijo? (Comprueba la consistencia)
  - ¿La IA citó documentos inexistentes? (Valida)

✅ Métricas de calidad de la respuesta
  - ¿La respuesta resolvió la pregunta del usuario?
  - ¿La respuesta incluyó las secciones requeridas?
  - ¿La respuesta cumplió el umbral mínimo de precisión?

✅ Feedback del usuario
  - ¿El usuario calificó la respuesta como útil?
  - ¿El usuario reportó la respuesta como errónea?
  - ¿El usuario hizo una pregunta de seguimiento (sugiere confusión)?

Ejemplo de implementación:

Después de que el LLM genere la respuesta:
1. Comprueba: ¿la respuesta cita un documento concreto?
2. Verifica: ese documento existe en la base de conocimiento
3. Alerta si: la respuesta cita una fuente inexistente (alucinación)

Después de que el usuario reciba la respuesta:
1. Recoge: feedback 👍 / 👎
2. Rastrea: % de respuestas valoradas como útiles
3. Alerta si: la valoración de utilidad cae >10 % (degradación de calidad)

3. Latencia y rate limits del LLM#

El problema:

Rate limit de OpenAI: 3.500 peticiones por minuto
Tu app: 4.000 peticiones por minuto en pico
Comportamiento: 500 peticiones en cola o rechazadas

Sin monitoring: los usuarios ven timeouts y no saben por qué

Qué monitorizar:

✅ Profundidad de la cola de peticiones
  - ¿Cuántas peticiones esperan respuesta del LLM?
  - Una cola que crece = capacidad insuficiente

✅ Estado del rate limit
  - ¿Te estás acercando al rate limit de OpenAI?
  - ¿Estás recibiendo errores 429 (Too Many Requests)?

✅ Distribución de la latencia
  - Latencia en el percentil 95
  - Latencia en el percentil 99
  - ¿Están creciendo los outliers?

✅ Diferencias de rendimiento entre modelos
  - GPT-4 es más lento pero más preciso
  - GPT-3.5 es más rápido pero menos preciso
  - ¿Están divergiendo los tiempos de respuesta entre modelos?

Umbrales de alerta:

• Profundidad de cola >1.000 peticiones → Aviso (se acumula backlog)
• Errores 429 >1 % → Crítico (rate limit alcanzado)
• Latencia P95 >10 s → Aviso (degradación)
• Latencia P99 >30 s → Crítico (timeouts probables)

---

Patrones de monitoring específicos para IA#

Patrón 1: Detección de anomalías de coste#

Presupuesto diario: $500
Gasto diario normal: $200

Monitoring:
- Rastrea el gasto en tiempo real
- Detecta cuando el gasto supera lo normal en un 50 %
- Si lo normal es $200/día y a las 14:00 vas por $300/día → Alerta
- Causa raíz: o más usuarios O cada petición es más cara

Patrón 2: Detección de degradación de calidad#

Métricas base:
- Tasa de alucinaciones: <2 %
- Valoración de utilidad por el usuario: 85 %
- Longitud media de la respuesta: 300 tokens

Después del deploy:
- Tasa de alucinaciones: 8 %
- Utilidad para el usuario: 72 %
- Respuesta media: 500 tokens

Alerta: la calidad se ha degradado (alucinaciones al alza, utilidad a la baja)

Patrón 3: Seguimiento del rendimiento por modelo#

En producción usas 3 modelos:
- GPT-4: caro, preciso, lento
- GPT-3.5: barato, suficiente, rápido
- Claude-Haiku: muy barato, bueno, intermedio

El monitoring rastrea por modelo:
- Latencia
- Coste
- Calidad (vía feedback de usuario)
- Número de usos

Si Claude-Haiku se vuelve más rápido/barato con la misma calidad → plantéate usarlo más
Si la latencia de GPT-4 sube un 50 % → alerta, posible problema en la API

Patrón 4: Tendencias de uso de tokens#

Base:
- Tokens de entrada por petición: 500
- Tokens de salida por petición: 200
- Total diario: 10M de entrada, 2M de salida

Tras un cambio de funcionalidad (se añadió contexto):
- Tokens de entrada por petición: 2.000 (4x más)
- Tokens de salida por petición: 200
- Total diario: 40M de entrada, 2M de salida (4x más coste)

Alerta: el coste ha subido inesperadamente. Revisa qué cambió.

---

Implementación: cómo configurar el monitoring de IA#

Paso 1: Instrumenta tus llamadas al LLM (2 horas)#

Añade monitoring a cada llamada a la API LLM:

import time
from openai import OpenAI

def call_llm_monitored(prompt, user_id, request_type):
    start_time = time.time()

    try:
        response = openai.ChatCompletion.create(
            model="gpt-3.5-turbo",
            messages=[{"role": "user", "content": prompt}]
        )

        latency = time.time() - start_time
        tokens_input = response.usage.prompt_tokens
        tokens_output = response.usage.completion_tokens
        cost = (tokens_input * 0.0005 + tokens_output * 0.0015) / 1000

        # Send metrics to monitoring
        monitor.track({
            "event": "llm_call",
            "model": "gpt-3.5-turbo",
            "latency_ms": latency * 1000,
            "input_tokens": tokens_input,
            "output_tokens": tokens_output,
            "cost_cents": cost * 100,
            "user_id": user_id,
            "request_type": request_type,
            "status": "success"
        })

        return response.choices[0].message.content

    except Exception as e:
        monitor.track({
            "event": "llm_call",
            "status": "error",
            "error": str(e),
            "user_id": user_id
        })
        raise

Paso 2: Rastrea el coste en tiempo real#

Agrega diariamente:
- Total de peticiones: 5.000
- Total de tokens de entrada: 2,5M
- Total de tokens de salida: 500K
- Coste total: $18,50
- Coste por petición: $0,0037

Compara con el presupuesto:
- Presupuesto diario: $25
- Usado: $18,50 (74 % del presupuesto)
- Restante: $6,50

Paso 3: Mide la calidad de la salida#

Para una IA de soporte al cliente:
1. Tras generar la respuesta: pregunta al cliente "¿Te ha sido útil?"
2. Si hace clic en 👎 → marca como baja calidad
3. Rastrea: ¿qué % de respuestas se valoran como útiles?

Base: 90 % útiles
Tras el deploy: 75 % útiles
Alerta: la calidad ha caído 15 puntos

Paso 4: Configura alertas#

Crítica (avisar de inmediato):

• Coste/hora >5x lo normal (indica uso descontrolado del LLM)
• Errores 429 (rate limit en la API LLM)
• Tasa de alucinaciones >10 %
• Valoración de utilidad <50 %

Aviso (alerta en Slack):

• Coste/hora >2x lo normal
• Latencia P95 >10 segundos
• Profundidad de cola >500 peticiones
• Tasa de alucinaciones >5 %

Info (resumen diario):

• Tendencias de coste (¿está subiendo el gasto?)
• Comparativa de rendimiento entre modelos
• Tendencias del feedback de usuarios

---

Errores habituales en el monitoring de IA#

Error 1: No monitorizar el uso de tokens#

Qué pasa: tu app llama al LLM con contexto cada vez más largo. El uso de tokens crece. El coste crece. No te das cuenta hasta que la factura mensual es 10x lo esperado.

Solución: rastrea los tokens por petición. Alerta si el conteo sube más de un 50 %.

Error 2: Medir solo la velocidad de respuesta, no la calidad#

Qué pasa: optimizas para latencia. El modelo se vuelve más rápido pero genera más alucinaciones. Los usuarios pierden confianza. Caen los ingresos.

Solución: monitoriza tanto la latencia COMO la calidad (tasa de alucinaciones, feedback de usuarios).

Error 3: No rastrear el estado de la API LLM#

Qué pasa: OpenAI tiene una caída. Tus peticiones se acumulan en cola. Los usuarios esperan más de 30 segundos. Asumes que tu código está roto.

Solución: monitoriza la salud de la API de OpenAI por separado. Sabe cuándo el problema es de su lado y no del tuyo.

Error 4: Usar la misma alerta de coste para distintos modelos#

Qué pasa: configuras la alerta "Coste >$10/día". Funciona con GPT-3.5. Pero añades GPT-4 (más caro). Ahora la alerta salta sin parar.

Solución: configura alertas de coste por modelo. GPT-3.5: alerta a $10/día. GPT-4: alerta a $50/día.

Error 5: No monitorizar el feedback del usuario#

Qué pasa: la IA genera alucinaciones. El monitoring tradicional dice "todo funciona". Los usuarios reciben información incorrecta.

Solución: pide a los usuarios que valoren las respuestas. Rastrea las valoraciones. Alerta si caen.

Error 6: Ignorar el coste por usuario#

Qué pasa: las peticiones de un usuario cuestan $10/mes. Le cobras $5/mes de suscripción. Estás perdiendo dinero por usuario.

Solución: rastrea el coste por usuario. Alerta si el coste de algún usuario supera lo que aporta en ingresos.

---

Herramientas de monitoring de IA (estado en 2026)#

Monitoring LLM integrado:

• Langsmith (monitoring de LangChain) — Rastrea llamadas LLM desde LangChain
• OpenAI API dashboard — Seguimiento básico de tokens/coste
• Anthropic console — Uso de la API de Claude

Herramientas APM generales (con tracking de IA añadido):

• Datadog — Añadió monitoring de LLM (coste, latencia, calidad)
• New Relic — Añadió tracking de LLM
• Dynatrace — Añadió monitoring de IA

Monitoring de IA especializado:

• Arize — Monitoring de modelos de IA (detección de alucinaciones, data drift)
• Whylabs — Monitoring de calidad de modelos
• Arthur.ai — Gobierno y monitoring de IA

Mejor configuración: Langsmith o Anthropic console para tracking específico de LLM + Datadog para correlacionar con métricas de aplicación.

---

Ejemplo real de monitoring de IA#

Escenario: chatbot de soporte al cliente usando GPT-4

Métricas base:

• Peticiones/día: 10.000
• Media de tokens de entrada: 1.500
• Media de tokens de salida: 300
• Coste: $65/día
• Valoración del usuario: 88 % útiles
• Tasa de alucinaciones: 1 %

Tras una actualización del producto (se añadió contexto):

• Peticiones/día: 10.000 (igual)
• Media de tokens de entrada: 3.500 (sube 133 %)
• Media de tokens de salida: 300 (igual)
• Coste: $116/día (sube 78 %)
• Valoración del usuario: 92 % útiles (sube 4 %)
• Tasa de alucinaciones: 0,5 % (baja 50 %)

Análisis:

• El coste subió un 78 % pero la calidad mejoró
• Cálculo de ROI: $51/día extra × 30 días = $1.530/mes
• Beneficio: un 4 % más de usuarios considera útil la respuesta
• Si hay 10.000 usuarios/día, una mejora del 4 % = 400 usuarios satisfechos más al día
• Valor: evitar escalados de soporte (ahorra $5 por escalado evitado)
• Punto de equilibrio: 306 escalados evitados/mes = $1.530

Decisión: la subida de coste está justificada. La actualización aumentó la satisfacción del cliente lo suficiente como para compensar el mayor coste de LLM.

Sin monitoring de IA: la decisión se toma a ciegas, por intuición.

---

Resumen: monitorizar aplicaciones de IA#

Las apps con IA requieren monitoring más allá de las métricas tradicionales de rendimiento:

1. Monitoring de coste — Rastrea el uso de tokens y el gasto en tiempo real. Alerta ante anomalías de coste.
2. Monitoring de calidad — Mide la calidad de la salida (tasa de alucinaciones, feedback de usuarios).
3. Monitoring de latencia — Rastrea los tiempos de respuesta del LLM y la profundidad de la cola.
4. Alertas de presupuesto — Avisa antes de pasarte de gasto en llamadas a la API LLM.
5. Feedback de usuario — Recoge valoraciones para medir la calidad sin revisión manual.

Checklist rápido de implementación:

• ✅ Instrumenta todas las llamadas LLM con tracking de tokens
• ✅ Calcula y monitoriza el coste por petición
• ✅ Rastrea el gasto diario/mensual total vs. presupuesto
• ✅ Monitoriza la latencia y los rate limits de la API LLM
• ✅ Recoge feedback de usuarios sobre la calidad de la respuesta
• ✅ Alerta ante anomalías de coste (>2x lo normal)
• ✅ Alerta ante degradación de calidad (subida de la tasa de alucinaciones)
• ✅ Rastrea las diferencias de rendimiento entre modelos
• ✅ Monitoriza cambios en el sentimiento del usuario
• ✅ Define presupuestos de coste por funcionalidad/usuario/modelo

El monitoring de IA es crítico para controlar costes manteniendo la calidad. La diferencia entre una funcionalidad de IA rentable y otra que no lo es suele ser una mejora del 1-2 % en calidad combinada con monitoring de coste.

¿Listo para monitorizar aplicaciones de IA? Empieza con el uptime monitoring de Nova Uptime para tu API y luego añade monitoring específico de LLM con Langsmith o Datadog.