Observabilidad empresarial con IA

Una plataforma en verde que no estaba dando servicio

Operé una plataforma empresarial que procesaba transferencias y movimientos de información entre distintos sistemas. No era un servidor aislado: era una cadena formada por aplicaciones, procesos programados, colas, archivos y dependencias externas.

Un día las señales técnicas indicaban que todo estaba bien. Los servidores disponibles, los procesos principales activos, el dashboard sin errores críticos. La infraestructura en verde.

Pero las operaciones no estaban llegando.

Uno de los componentes encargados de consumirlas había dejado de trabajar correctamente. El proceso aparecía iniciado, pero la cola seguía creciendo y las operaciones no alcanzaban su destino dentro del tiempo esperado. La ventana operativa se incumplió. El sistema estaba técnicamente disponible y funcionalmente detenido.

Tardamos varias horas en identificarlo. No por falta de métricas, sino porque las que teníamos estaban enfocadas en la salud de la infraestructura y no en el cumplimiento del flujo empresarial. El área usuaria percibió antes que nosotros que las operaciones no estaban llegando: nosotros veíamos componentes disponibles; el negocio veía un servicio que no cumplía su propósito.

Lo destapó una consulta del área usuaria. Después vinieron las verificaciones manuales sobre colas, archivos pendientes, tiempos de procesamiento y últimos movimientos registrados. Una persona que conocía el comportamiento habitual de la plataforma identificó de inmediato que la cantidad de elementos pendientes no correspondía con la hora ni con el volumen esperado. El conocimiento existía, pero vivía en la experiencia de algunas personas y no dentro del sistema de monitoreo.

Los detalles técnicos de este caso han sido simplificados para preservar la confidencialidad. El patrón operativo y la lección son reales.

Lo que cambié después no fue agregar otro dashboard. Fue cambiar la pregunta.

Antes    ¿El componente está activo?

Después  ¿El servicio está procesando lo que debería,
         a la velocidad esperada y dentro de la ventana
         comprometida?

De ese cambio surgieron controles que antes no existían: cantidad de elementos pendientes en cola, antigüedad del elemento más antiguo, tasa de ingreso frente a tasa de consumo, tiempo transcurrido desde la última operación completada, cumplimiento de ventanas operativas, comparación contra el comportamiento habitual, alertas por procesos activos sin movimiento real y validación de extremo a extremo mediante operaciones sintéticas.

También apareció un runbook para diferenciar tres condiciones que antes podían parecer iguales:

• Proceso detenido.
• Proceso activo, pero sin consumir.
• Proceso consumiendo por debajo de la capacidad necesaria.

¿Poco tiempo? Lee la versión ejecutiva (6 min).

De la métrica aislada a la observabilidad empresarial

Las cuatro señales fundamentales que popularizó Google para monitorear servicios —latencia, tráfico, errores y saturación— son una base útil, pero no describen por sí solas si un proceso empresarial está cumpliendo su propósito. Una estrategia madura conecta varios niveles:

El error frecuente es quedarse en el primer nivel. Un servidor puede aparecer saludable mientras una cola no está siendo consumida. Una base de datos puede responder consultas mientras una aplicación agota su pool de conexiones. Un servicio puede permanecer activo mientras cientos de operaciones se acumulan fuera de su ventana de procesamiento.

La observabilidad empresarial aparece cuando estas señales se correlacionan con el propósito del sistema. No basta con saber que un proceso está activo: hace falta saber si está procesando, a qué velocidad, con qué tasa de error, qué dependencias utiliza y qué impacto tendría su degradación.

El lugar correcto de la IA

La IA no debería calcular la utilización del disco, verificar si un proceso existe, comprobar la vigencia de un certificado ni determinar si una transferencia fue completada. Eso lo resuelve software determinista: scripts, consultas SQL, APIs, reglas, umbrales, pruebas sintéticas y plataformas de monitoreo.

La IA aporta valor en tres funciones concretas.

1. Selección asistida

En un flujo predecible, el orquestador ejecuta una secuencia explícita de controles definida por el catálogo: la IA no decide libremente qué hacer. En una investigación abierta puede proponer una comprobación adicional —revisar la tasa de consumo de una cola, comparar la latencia antes y después de un despliegue—, pero esa propuesta pasa por el motor de políticas, que valida parámetros, permisos, alcance y riesgo antes de ejecutar cualquier herramienta.

2. Interpretación

Analiza resultados estructurados y los relaciona con documentación vigente, incidentes anteriores, dependencias y procedimientos autorizados.

3. Comunicación

Convierte la evidencia en una explicación clara, priorizada y accionable para distintos públicos: operador, especialista, responsable de servicio o área usuaria.

Los modelos actuales pueden usar llamadas a funciones para interactuar con herramientas externas mediante contratos definidos. El modelo solicita la ejecución, pero es la aplicación la que valida los parámetros, controla los permisos y ejecuta realmente la acción. El reparto correcto de responsabilidades es este:

La IA propone una verificación cuando el flujo lo permite.
El motor de políticas decide si está autorizada.
El orquestador ejecuta el flujo.
El código obtiene la evidencia.
Las reglas calculan estados verificables.
La recuperación aporta contexto versionado.
La IA interpreta y comunica.
El validador comprueba la respuesta.
El especialista aprueba las decisiones críticas.

Vuelvo al incidente inicial. Con una IA conectada a controles confiables, el sistema podría haber ejecutado los triajes de salud, revisado la profundidad de las colas, comparado tasas de ingreso y consumo, consultado errores recientes y recuperado el runbook aplicable, para concluir algo así:

Los procesos principales están activos, pero la cola continúa
creciendo y no se registran operaciones completadas durante los
últimos 40 minutos. La evidencia confirma una degradación
funcional, aunque todavía no permite determinar la causa raíz.

Eso habría reducido de manera importante el tiempo dedicado a recopilar información. Pero si la IA solo hubiera recibido el dashboard superficial, habría generado una explicación convincente y equivocada con mayor rapidez: "la plataforma se encuentra operativa porque los servidores y procesos reportan un estado saludable".

Del prompt aislado a una capacidad empresarial

Uno de los errores más frecuentes al incorporar IA en operaciones es entregar a los usuarios una caja de texto y esperar que sepan formular el prompt correcto. Ese enfoque hace que cada persona describa el incidente de manera diferente, que el modelo reciba información incompleta, que los permisos sean ambiguos y que el consumo de tokens dependa de cuánto texto escriba el usuario. También dificulta comparar resultados, medir calidad y mantener una auditoría consistente.

En un entorno empresarial el usuario no debería necesitar conocer el prompt interno, el modelo, la herramienta de observabilidad, el script específico ni el formato que espera cada integración. Debería consumir una capacidad operativa diseñada previamente: diagnosticar la degradación de un servicio, analizar el crecimiento de una cola, verificar la salud funcional de una plataforma, comparar el comportamiento antes y después de un despliegue, revisar vencimientos de certificados, evaluar el cumplimiento de una ventana operativa o preparar la evidencia de un incidente.

La interfaz solicita parámetros controlados:

Capacidad : Diagnóstico de retraso en procesamiento
Sistema   : Plataforma de transferencias
Entorno   : Producción
Periodo   : Última hora
Flujo     : Transferencias salientes
Contexto  : Campo opcional

El usuario puede agregar contexto, pero ese texto no reemplaza los parámetros estructurados. La interacción deja de ser "escribe un buen prompt y espera que la IA comprenda el problema" y se convierte en "selecciona una capacidad que ejecuta un proceso gobernado, medible y repetible".

El usuario debe ser experto en su negocio o en su plataforma. La ingeniería de prompts debe formar parte de la solución.

Arquitectura técnica de referencia

La solución puede organizarse en siete capas operativas más un control transversal para el acceso a modelos:

Dos zonas de incertidumbre

Un matiz que suele pasarse por alto: la incertidumbre no vive solo dentro del LLM. La recuperación semántica también es probabilística. Un buscador vectorial puede devolver un runbook parecido pero correspondiente a otro entorno, a una versión anterior o a una arquitectura que ya no está vigente. Por eso conviene separar explícitamente las dos zonas:

El Model Gateway: gobernar el consumo de IA

En una arquitectura empresarial las aplicaciones no deberían conectarse directamente a cada proveedor de modelos. El Model Gateway —o plano de control de IA— establece una frontera central entre los sistemas internos y los modelos, y concentra las decisiones que de otro modo cada equipo reimplementa por su cuenta:

• Seleccionar proveedor y modelo según el tipo de solicitud, y aplicar fallback cuando uno no responde.
• Definir el presupuesto máximo de tokens y gestionar la caché de contexto estable.
• Enmascarar o redactar datos sensibles antes de que salgan del perímetro.
• Validar el modelo y la región autorizados.
• Aplicar timeouts, reintentos y circuit breakers.
• Registrar modelo, versión y parámetros utilizados en cada llamada.
• Bloquear herramientas o instrucciones no autorizadas.
• Ejecutar evaluaciones de calidad y calcular el costo por diagnóstico.

Su beneficio de fondo es que permite cambiar de modelo sin rediseñar la capacidad operativa. El modelo se vuelve sustituible; los contratos y la evidencia permanecen.

El catálogo de capacidades

El catálogo contiene funciones operativas previamente diseñadas. Cada capacidad declara su alcance, versión, herramientas, permisos, presupuesto y política de aprobación — y, si corresponde, cuántas verificaciones adicionales puede llegar a proponer la IA:

capability:
  id: diagnose_service_degradation
  name: Diagnosticar degradación de servicio
  version: 2.2

  allowed_environments:
    - development
    - testing
    - production

  required_roles:
    - operator
    - platform_engineer

  deterministic_flow:
    - get_service_metrics
    - get_error_summary
    - get_dependency_status
    - get_recent_changes
    - run_synthetic_test

  optional_ai_proposals:
    enabled: true
    maximum_additional_checks: 2
    require_policy_validation: true

  ai_profile:
    model_tier: medium
    rag_enabled: true
    maximum_context_tokens: 12000

  approval:
    read_operations: automatic
    write_operations: human_required

Esto convierte el uso de IA en una capacidad versionada y gobernada. El usuario no decide libremente qué comandos ejecutar: selecciona una función autorizada y el sistema determina el flujo correspondiente. La capa de identidad valida en cada solicitud el rol, los sistemas y ambientes autorizados, las herramientas permitidas y si el caso requiere aprobación humana. La IA nunca debería decidir por sí misma qué permisos tiene el usuario.

La capa de herramientas deterministas

Las herramientas son funciones de alcance limitado que realizan una tarea concreta:

get_cpu_metrics()            get_queue_depth()
get_memory_metrics()         get_consumer_rate()
get_disk_growth()            get_database_connections()
get_process_status()         get_recent_deployments()
get_certificate_expiration() get_error_summary()
run_connectivity_test()      run_synthetic_transaction()

Cada herramienta debe definir sus parámetros permitidos, tipos de datos, timeout, sistemas autorizados, nivel de riesgo, información que devuelve, datos que debe ocultar, política de reintentos, evidencia de auditoría, propietario, versión y criterio de mantenimiento.

Una herramienta no debería recibir un comando arbitrario generado por el modelo. En lugar de exponer execute_command("cualquier instrucción generada por la IA"), se exponen contratos cerrados:

get_disk_usage(server_id, filesystem)
restart_service(service_id, environment, change_ticket)

La primera es de lectura. La segunda necesita permisos adicionales, validación de ventana operativa y aprobación humana o una política automática previamente autorizada.

El resultado tampoco debería ser texto libre:

{
  "check": "queue_health",
  "target": "service-a",
  "status": "degraded",
  "value": 1842,
  "threshold": 500,
  "timestamp": "2026-07-19T15:30:00-05:00",
  "evidence": "queue-main",
  "execution_status": "success",
  "tool_version": "2.3.1"
}

El campo execution_status es el más fácil de olvidar y el más importante. Sin él no se puede distinguir entre cuatro situaciones que exigen respuestas distintas: el sistema está fallando, el control no pudo ejecutarse, la fuente no respondió o el resultado fue parcial. Un diagnóstico que confunde "está mal" con "no pude medirlo" es peor que no tener diagnóstico.

Normalización de la evidencia

Las herramientas devuelven formatos diferentes. Antes de llamar al modelo, una capa de normalización debe unificar origen, valor, línea base, umbral, estado y vigencia — y asignar a cada pieza un identificador estable que las conclusiones puedan citar:

{
  "diagnostic_id": "DGN-2026-0719-0042",
  "system": "transfer-platform",
  "environment": "production",
  "time_window": {
    "start": "2026-07-19T15:00:00-05:00",
    "end":   "2026-07-19T15:30:00-05:00"
  },
  "evidence": [
    {
      "evidence_id": "metric.queue_depth.01",
      "source": "metrics_backend",
      "type": "metric",
      "name": "queue_depth",
      "value": 1842,
      "baseline": 320,
      "threshold": 500,
      "status": "critical",
      "execution_status": "success"
    },
    {
      "evidence_id": "check.consumer_process.02",
      "source": "application_script",
      "type": "process_check",
      "name": "consumer_process",
      "value": "running",
      "status": "healthy",
      "execution_status": "success"
    },
    {
      "evidence_id": "metric.consumer_rate.03",
      "source": "metrics_backend",
      "type": "metric",
      "name": "consumer_rate_per_minute",
      "value": 68,
      "baseline": 120,
      "threshold": 90,
      "status": "critical",
      "execution_status": "success"
    },
    {
      "evidence_id": "change.deployment.04",
      "source": "deployment_api",
      "type": "change",
      "name": "last_deployment",
      "value": "release-2026.07.19.2",
      "timestamp": "2026-07-19T14:47:00-05:00",
      "execution_status": "success"
    }
  ]
}

Esta capa reduce volumen y elimina ruido antes de consumir tokens. La IA no necesita miles de líneas de logs cuando el código puede producir primero el conteo de errores por código, la primera y última ocurrencia, la variación frente al periodo anterior, los componentes afectados, los correlation IDs, ejemplos representativos e identificadores para consultar el detalle.

El flujo: consumo, análisis y resultado

Ejemplo: retraso en el procesamiento

Un usuario observa que las transferencias están demorando más de lo esperado. No escribe "analiza por qué el sistema está lento": selecciona la capacidad, el sistema, el entorno, el periodo y el flujo.

1. Validación

La plataforma confirma que el usuario tiene acceso de lectura sobre ese sistema y entorno.

2. Ejecución determinista

El orquestador consulta estado de procesos, profundidad de colas, tasa de ingreso, tasa de consumo, espacio en disco, latencia de base de datos, errores recientes, dependencias externas, cambios desplegados y una prueba sintética.

3. Reglas

{
  "overall_status": "degraded",
  "confirmed_conditions": [
    "queue_depth_above_threshold",
    "consumer_rate_below_baseline"
  ],
  "healthy_conditions": [
    "process_running",
    "database_available",
    "disk_capacity_available"
  ]
}

El estado degraded no lo inventa el modelo. Surge de reglas configuradas.

4. Recuperación de conocimiento

El motor recupera el runbook vigente para crecimiento de cola, incidentes similares, la arquitectura del flujo, las dependencias del consumidor y los cambios aplicados durante el periodo. Cada fragmento debe incluir versión, propietario, entorno y fecha de vigencia.

5. Interpretación

La IA recibe únicamente evidencia normalizada, resultados de reglas, contexto recuperado, alcance de la solicitud y esquema esperado. No recibe logs completos ni capturas aisladas.

6. Validación

El sistema comprueba que cada hallazgo cite un evidence_id válido, que las métricas existan, que los timestamps pertenezcan al periodo, que las recomendaciones estén permitidas, que las hipótesis no se presenten como hechos, que los documentos recuperados sean vigentes y del entorno correcto, y que la respuesta cumpla el esquema.

7. Resultado

{
  "status": "degraded",
  "executive_summary": "El flujo continúa disponible, pero su capacidad de consumo se encuentra por debajo de la línea base.",
  "confirmed_findings": [
    {
      "finding": "La cola aumentó de 320 a 1842 elementos.",
      "evidence_id": "metric.queue_depth.01"
    },
    {
      "finding": "La tasa de consumo se redujo 43 % respecto de la línea base.",
      "evidence_id": "metric.consumer_rate.03"
    },
    {
      "finding": "El proceso consumidor permanece activo.",
      "evidence_id": "check.consumer_process.02"
    }
  ],
  "hypotheses": [
    {
      "hypothesis": "El consumidor puede estar procesando cada operación con mayor latencia.",
      "confidence": "medium",
      "required_validation": "Comparar duración interna por etapa."
    }
  ],
  "missing_evidence": [
    "Latencia interna por etapa antes y después del último despliegue."
  ],
  "recommended_next_steps": [
    "Analizar la duración por operación durante los últimos 60 minutos.",
    "Comparar el comportamiento antes y después del despliegue.",
    "Revisar llamadas a la dependencia externa de validación."
  ],
  "automatic_actions_executed": [],
  "human_approval_required": false
}

Los valores son ilustrativos, no medidos. Lo relevante es que la IA no determinó arbitrariamente el estado: interpretó condiciones calculadas mediante controles verificables, y declaró explícitamente qué evidencia le faltaba.

El prompt como componente interno

El prompt continúa existiendo, pero deja de ser responsabilidad del usuario. El sistema construye una instrucción versionada:

Analiza exclusivamente la evidencia proporcionada.

Reglas:
1. No inventes métricas, sistemas, fechas ni dependencias.
2. Distingue hechos confirmados, correlaciones e hipótesis.
3. Cada hallazgo debe incluir un evidence_id válido.
4. No declares causa raíz cuando la evidencia solo demuestre correlación.
5. Declara explícitamente la evidencia ausente.
6. Propón solo verificaciones permitidas por el catálogo.
7. No propongas acciones de escritura sin aprobación.
8. Devuelve la respuesta con el esquema definido.

Esta instrucción puede versionarse, probarse, compararse entre modelos y auditarse. La calidad deja de depender de que cada operador sepa redactar prompts.

Estrategia de modelos por complejidad

No todas las solicitudes deben consumir el modelo más grande. Un clasificador barato decide la ruta antes de gastar capacidad avanzada:

¿Qué tipo de IA utilizar?

No todos los problemas requieren un agente autónomo ni el modelo más grande disponible.

Modelos pequeños o clasificadores

Adecuados para clasificar alertas, reconocer categorías de incidentes, priorizar solicitudes, extraer campos y seleccionar un procedimiento conocido. Rápidos, económicos y suficientes cuando el espacio de decisión está bien delimitado.

Embeddings y recuperación semántica

Útiles para localizar runbooks, documentación, configuraciones, postmortems e incidentes similares. Aquí la función principal no es redactar, sino encontrar evidencia relevante dentro del conocimiento autorizado — recordando que esta capa vive en la zona probabilística.

LLM con RAG

Adecuado cuando se necesita interpretar evidencia técnica y contrastarla con documentación empresarial. RAG reduce la dependencia del conocimiento interno del modelo, pero no elimina los riesgos: OWASP advierte que RAG y el fine-tuning pueden mejorar la relevancia y aun así no resolver del todo vulnerabilidades como la inyección de prompts.

LLM con llamadas a herramientas

Es la alternativa apropiada para el triaje descrito arriba. El modelo puede seleccionar una función, completar parámetros y procesar su respuesta. La función continúa siendo código convencional sometido a autenticación, autorización, validación y auditoría.

IA agéntica

Debe reservarse para investigaciones abiertas que requieren múltiples pasos, diversas fuentes y decisiones intermedias. Cuando el flujo es predecible, una solución no agéntica suele ser más simple, controlable y económica. La guía arquitectónica de Google Cloud diferencia los agentes —adecuados para problemas abiertos y flujos complejos— de las soluciones asistivas, RAG o de una sola llamada, suficientes para tareas previsibles.

Cómo contener el riesgo de alucinación

No existe una instrucción que garantice que un modelo nunca se equivocará. OWASP define la desinformación generada por LLM como información falsa o engañosa que puede parecer creíble, y recomienda fuentes verificadas, validaciones automáticas y supervisión humana en contextos críticos.

El objetivo arquitectónico no es prometer ausencia de errores. Es evitar que una respuesta incorrecta se convierta en una conclusión no trazable o en una acción operativa no autorizada.

Evidencia obligatoria

Toda conclusión debe citar métricas, herramientas, periodos y documentos concretos. Cuando la información no alcanza, la respuesta correcta es: no se puede determinar con la evidencia disponible.

Salida estructurada

La respuesta debería ajustarse a un esquema definido, con las correlaciones como categoría propia — distinta de los hechos y de las hipótesis:

{
  "observed_status": "degraded",
  "confirmed_findings": [],
  "correlations": [],
  "hypotheses": [],
  "missing_evidence": [],
  "recommended_next_checks": [],
  "confidence": "medium"
}

Los mecanismos de salida estructurada permiten exigir campos, tipos y enumeraciones. Un esquema no garantiza que el contenido sea verdadero, pero reduce ambigüedad y facilita validaciones automáticas.

Separar niveles de afirmación

• Hecho: la cola contiene 1,842 elementos.
• Correlación: comenzó a crecer después de un despliegue.
• Hipótesis: el cambio puede haber reducido la tasa de consumo.
• Acción recomendada: comparar throughput y latencia antes y después.

Una hipótesis no puede presentarse como causa raíz.

Herramientas limitadas

El modelo solo puede solicitar funciones incluidas en el catálogo, con lectura y escritura separadas. Las acciones destructivas necesitan aprobación humana, ventanas autorizadas y control de cambios.

Documentación versionada

Los runbooks utilizados por recuperación semántica deben declarar versión, propietario, entorno, vigencia y fecha de actualización. Recuperar un documento obsoleto con alta similitud sigue siendo recuperar información incorrecta.

Validación posterior por código

Las afirmaciones críticas pueden comprobarse: que la métrica citada exista, que el timestamp pertenezca al periodo, que el sistema esté dentro del alcance, que el documento corresponda al entorno, que la recomendación use una herramienta autorizada y que toda causa propuesta tenga evidencia asociada.

Evaluación antes de producción

La solución debe probarse con incidentes históricos, escenarios sintéticos, fuentes caídas, resultados parciales, casos sin evidencia suficiente, documentos obsoletos o contradictorios e intentos de solicitar acciones no autorizadas. No basta con medir si la respuesta suena convincente. El NIST AI RMF propone gestionar el riesgo de IA durante todo el ciclo de vida, incorporando criterios de confiabilidad en el diseño, desarrollo, uso y evaluación.

Los tokens son una decisión de arquitectura

El consumo de tokens no es únicamente un problema financiero. Enviar demasiado contexto incrementa la latencia, el ruido, las contradicciones, la exposición de datos innecesarios, la superficie para instrucciones maliciosas y la dificultad para reconstruir qué evidencia utilizó el modelo.

No enviaría gigabytes de logs a un LLM para preguntarle qué ocurrió. El software determinista debe filtrar, agregar y estructurar primero:

• Filtrar antes de enviar: patrones, conteos y muestras, no logs completos.
• Recuperar selectivamente: fragmentos relevantes, no todos los runbooks.
• Limitar la ventana temporal: únicamente el periodo del incidente.
• Evitar conversaciones indefinidas: cada diagnóstico con alcance y límite de pasos.
• Reutilizar contexto estable: instrucciones, esquemas y definiciones de herramientas pueden beneficiarse de caché.
• Enrutar por complejidad: modelos pequeños para tareas simples.
• Eliminar duplicidad: una misma métrica no debe repetirse en varias secciones del contexto.

Como ejemplo de proveedor, OpenAI documenta reducciones de hasta 80 % en el tiempo hasta el primer token y hasta 90 % en el costo de tokens de entrada para solicitudes compatibles con su prompt caching. Los resultados reales dependen del modelo, del proveedor y de la repetición efectiva del contexto.

La IA también debe ser observable

Incorporar IA a operaciones crea otro sistema que necesita métricas, logs y trazas. Como mínimo mediría la latencia total del análisis y la duración de cada herramienta, la cantidad de llamadas al modelo, los tokens de entrada, salida y caché, el costo por diagnóstico, el porcentaje de respuestas con evidencia suficiente, las herramientas propuestas, aprobadas y rechazadas, los errores y resultados parciales, los escalamientos humanos, las hipótesis posteriormente confirmadas, los documentos recuperados con su versión, las acciones bloqueadas por políticas y los casos resueltos sin intervención adicional.

Las plataformas modernas ya están extendiendo logs, métricas y trazas al comportamiento de agentes: las convenciones semánticas de OpenTelemetry para IA generativa normalizan el span de invocación del agente, los spans de ejecución de herramientas y las métricas de tokens y duración.

Esto permite responder preguntas reales: ¿la IA reduce el tiempo de triaje? ¿En qué incidentes aporta valor? ¿Qué herramientas fallan más? ¿Cuánto cuesta cada caso útil? ¿Qué hipótesis suelen confirmarse? ¿Cuándo debería abstenerse? ¿Está reduciendo trabajo o solo generando más texto?

Sin esta información, una solución de IA para observabilidad termina siendo, paradójicamente, otro componente no observable.

Por dónde empezar (y cuándo no empezar)

Todo lo anterior describe el destino, no el primer paso. Si mañana tuviera que construir esta solución, no empezaría por un chatbot, por RAG ni por elegir un modelo. Empezaría por la capa 04: las herramientas deterministas.

Primero la evidencia, no la IA

Esa capa tiene una ventaja que ninguna otra posee: genera valor aunque la IA nunca llegue. Un script de triaje, una consulta confiable o una prueba sintética ya reducen tiempo operativo, estandarizan verificaciones, eliminan pasos manuales, formalizan conocimiento tribal y producen evidencia auditable.

Pero no construiría scripts aislados que impriman texto distinto según quién los desarrolló. Mi orden sería:

1. Definir las preguntas operativas que necesito responder.
2. Definir un contrato común de evidencia.
3. Construir las herramientas deterministas.
4. Aplicar reglas, umbrales y líneas base.
5. Integrar el flujo en un orquestador.
6. Agregar recuperación de conocimiento vigente.
7. Incorporar IA para interpretación y comunicación.
8. Habilitar selección asistida solo donde exista una necesidad real.

La IA no debería ser la base. Debe ser una capa de aceleración sobre una base que pueda defenderse sola.

Qué es realista en un trimestre, y qué a un año

Tres meses alcanzan para una primera capacidad productiva si el alcance es controlado: una plataforma crítica y uno o dos tipos de incidentes recurrentes. En ese plazo cabe entregar entre cinco y diez controles deterministas con contrato común de resultados, integración con las métricas y APIs existentes, un triaje ejecutable desde una interfaz simple, reglas para clasificar estados, recuperación de uno o dos runbooks vigentes, interpretación con un modelo, validación de respuestas y auditoría de ejecuciones, tokens y resultados — todo restringido a lectura.

Lo que no intentaría todavía: autonomía completa, reinicios automáticos, rollbacks, cobertura de toda la organización, investigación sin límites, integración con todo el conocimiento corporativo ni declaraciones automáticas de causa raíz.

A doce meses sí cabe una plataforma más madura: más capacidades y sistemas, permisos por entorno y acción, conocimiento versionado, comparación contra líneas base, evaluaciones continuas, enrutamiento entre modelos e integración con la herramienta de tickets. Recién ahí tiene sentido plantear remediaciones de bajo riesgo, reversibles y previamente autorizadas — reintentar una prueba sintética, escalar un incidente, abrir un ticket con la evidencia adjunta. La frontera no cambia: la autonomía no se entrega porque la tecnología pueda hacerlo, sino porque la organización puede gobernarla.

La capa trampa

La capa trampa no es el modelo. Es la combinación de orquestación, normalización, gobierno de herramientas y gestión del ciclo de vida de los controles. En el diagrama parece simple: una función se ejecuta, devuelve un resultado y la IA lo explica. En producción aparecen las preguntas difíciles:

• ¿Qué ocurre si el script responde parcialmente, o si la fuente está caída?
• ¿Cómo distingo una falla del sistema de una falla de medición?
• ¿Qué versión del control se ejecutó, y quién puede consultar producción?
• ¿Qué datos deben enmascararse? ¿Qué timeout y cuántos reintentos son válidos?
• ¿Qué fuente prevalece cuando dos controles se contradicen?
• ¿Quién mantiene el contrato cuando la plataforma cambia, y quién responde por cada herramienta?

El modelo es relativamente intercambiable. La integración confiable con sistemas reales no lo es. Un catálogo con veinte scripts tampoco equivale a una capacidad empresarial: la capacidad existe cuando cada control tiene propietario, versión, contrato, permisos, timeout, evidencia, criterios de éxito, tratamiento de errores, auditoría y mantenimiento.

Cuándo no vale la pena

No todo equipo necesita esto. Puede ser sobreingeniería cuando coinciden varias condiciones: pocos sistemas, arquitectura simple, incidentes poco frecuentes y fáciles de reproducir, equipo pequeño y estable, baja dependencia de especialistas concretos, runbooks cortos y actualizados, impacto operativo limitado y tiempo de resolución aceptable. En ese escenario no necesitas IA: necesitas mejores controles, scripts y documentación.

La decisión tampoco debería basarse en que "la empresa necesita usar IA". Esa es una mala razón arquitectónica. Usaría esta relación como criterio:

Valor potencial = frecuencia × complejidad × impacto × trabajo manual repetitivo

La criticidad puede romper cualquier umbral de frecuencia: un sistema puede tener pocos incidentes al año y justificar controles avanzados si cada interrupción compromete operaciones críticas o cumplimiento regulatorio. También observaría las horas técnicas consumidas, cuántas personas se involucran, cuánto se tarda en identificar el componente afectado, cuántas veces se repiten las mismas verificaciones y el riesgo de un diagnóstico incorrecto. Cuando una sola persona sabe qué revisar, ya existe una oportunidad de formalización — pero eso no significa que la primera solución deba ser IA.

La capacidad que elegiría

Si solo pudiera construir una: triaje automatizado de degradación de extremo a extremo. No empezaría por generación de postmortems, consulta documental o resumen de alertas: son útiles, pero ocurren después o trabajan sobre información que alguien ya reunió.

La elegiría no porque reemplace el análisis, sino porque elimina la parte repetitiva: entrar a distintas herramientas, ejecutar las mismas consultas, unir horarios, comparar métricas y reconstruir contexto. Mi tiempo debería usarse en interpretar comportamientos anómalos y decidir, no en recopilar a mano lo que un sistema puede obtener de forma consistente.

La respuesta esperada no sería "el sistema podría estar experimentando una degradación", sino una conclusión delimitada: qué está disponible, qué se degradó y cuánto, qué cambió cerca en el tiempo, qué todavía no está demostrado y cuál es la siguiente comprobación. La IA no habría resuelto el incidente por mí. Habría eliminado una parte importante del trabajo de recolección y me habría entregado el problema correctamente delimitado.

Conclusión

El uso empresarial más sólido de la inteligencia artificial no consiste en reemplazar scripts, métricas, reglas o procedimientos. Consiste en conectarlos sin mover el núcleo operativo fuera de lo verificable, y en dejar la aprobación de las decisiones críticas donde siempre estuvo: en el especialista.

La IA aporta velocidad precisamente porque no necesita sustituir lo que ya funciona. Su valor desaparece cuando se le permite inventar el estado del sistema, ejecutar acciones sin límites o reemplazar verificaciones que el software convencional puede realizar con mayor precisión.

La pregunta, entonces, no es si una organización ya utiliza IA en operaciones. Es si esa IA está conectada a evidencia verificable o únicamente a una versión más sofisticada del mismo dashboard incompleto.

Preguntas frecuentes

¿Debe la IA determinar si un sistema está sano?

No. El estado debe calcularse con herramientas deterministas, reglas, umbrales y evidencia verificable. La IA interpreta y comunica esos resultados.

¿Puede la IA decidir qué herramienta ejecutar?

En flujos conocidos no hace falta: el orquestador sigue una secuencia explícita. En investigaciones abiertas puede proponer verificaciones adicionales, pero el motor de políticas valida permisos, parámetros y riesgo antes de ejecutarlas.

¿RAG elimina el riesgo de alucinación?

No. Reduce la dependencia del conocimiento interno del modelo, pero también puede recuperar documentación incorrecta, desactualizada o de otro entorno. Las fuentes deben estar versionadas y validadas.

¿Cuándo conviene una IA agéntica?

En investigaciones abiertas que requieren varios pasos y decisiones intermedias. Cuando el flujo es conocido y repetible, una secuencia determinista es más simple, controlable y económica.

¿Por qué los tokens son una decisión de arquitectura?

Porque el contexto innecesario incrementa costo, latencia, ruido, exposición de información y dificultad de auditoría. La evidencia debe filtrarse y estructurarse antes de llamar al modelo.

Referencias

• Google SRE. Monitoring Distributed Systems.
• OpenTelemetry. What is OpenTelemetry?
• OpenTelemetry. Semantic conventions for generative AI.
• OWASP. LLM01: Prompt Injection.
• OWASP. LLM09: Misinformation.
• NIST. AI Risk Management Framework.
• Google Cloud. Choose a design pattern for your agentic AI system.
• OpenAI. Function calling.
• OpenAI. Structured outputs.
• OpenAI. Prompt caching.

Jorel del Portal

Jorel del Portal es ingeniero de sistemas especializado en arquitectura, integración, resiliencia y observabilidad de plataformas críticas. Diseña sistemas, construye productos y documenta decisiones reales de ingeniería.

Acerca de LinkedIn YouTube X TikTok Instagram