Llevamos ya tiempo con la IA metida en nuestras vidas y en nuestro trabajo del día a día, en cada herramienta que tocamos, y los que nos dedicamos a monitorizar e implementar observabilidad en sistemas siempre acabamos pensando que esta va a ser la vez que llega la herramienta definitiva: la que por fin te dice qué ha pasado sin que tengas que perseguir la causa tú mismo entre logs, métricas y trazas a las tres de la madrugada. Pero no es tan sencillo como parece.
Es el escenario de siempre, y es exactamente el que todo el marketing de 2026 lleva un año prometiendo resolver por ti en segundos.
No lo resuelve en segundos. Pero tampoco es mentira del todo. Vamos a separar las dos cosas.
El rebranding: de «Davis AI» a «IA causal» como estándar de la industria
Si sigues Dynatrace de cerca, ya sabes que Davis AI y Davis CoPilot se fusionaron bajo el paraguas «Dynatrace Intelligence», con una capa agéntica encima que no solo diagnostica sino que puede actuar dentro de límites deterministas. Lo que quizá no habías notado es que ya no es un discurso exclusivo de Dynatrace. New Relic lanzó en febrero de 2026 su propio motor, iRCA, con el mismo argumento de venta casi palabra por palabra: los métodos basados en correlación estadística confunden síntomas con causas, y su alternativa usa un grafo de topología y modelos causales para señalar la causa probable en segundos. Datadog lleva ese lenguaje en Watchdog desde hace más tiempo, aunque su mecanismo de base sigue apoyándose más en correlación de métricas etiquetadas que en un grafo de dependencias explícito construido en tiempo real.
En dos años, «IA causal» pasó de ser una ventaja diferencial real de un solo vendor a ser el vocabulario obligatorio de cualquier plataforma APM que quiera parecer seria en 2026. Eso, por sí solo, ya te dice algo: cuando todo el mundo vende lo mismo con las mismas palabras, conviene mirar debajo de la alfombra.
Lo que sí hay debajo de la alfombra — y sus límites reales
La distinción técnica es legítima. Un motor que recorre un mapa de dependencias ya conocido (quién llama a quién, qué depende de qué infraestructura) no está adivinando por estadística: sigue relaciones de causa-efecto que ya tiene modeladas. Eso es genuinamente distinto de «estas cuatro métricas se movieron a la vez, deben de estar relacionadas». Y sí, puede ser determinista — mismos datos de entrada, mismo resultado — porque no depende de un modelo probabilístico que varía cada vez que lo consultas.
Pero determinista no es sinónimo de infalible. El grafo solo conoce lo que la plataforma logra instrumentar. Si la causa real vive en una capa que el agente no cubre bien —contención de red, saturación de storage, un proveedor cloud de terceros— el «razonamiento causal» se detiene justo donde se acaba el mapa. Es reproducible dentro de lo que ve, no omnisciente fuera de ello. Y ese matiz es precisamente el que el marketing tiende a difuminar.
Lo que dice la gente que ya lo ha probado
Aquí es donde el relato se vuelve más interesante que cualquier nota de prensa. En junio de 2025, Honeycomb publicó un post titulado «Es el fin de la observabilidad tal y como la conocíamos (y estoy tranquilo)» — en el original, «It’s the end of observability as we know it (and I feel fine)» —, defendiendo que un agente de IA había investigado un pico de latencia complejo en 80 segundos por 60 centavos de dólar. El título ya deja claro el tono: no es una nota técnica cautelosa, es una declaración de intenciones. El hilo de Hacker News que generó (más de 200 comentarios) es un buen termómetro del sector, y no es unánime en ninguna dirección.
Un lado del hilo defendía algo razonable: la ventaja real no es que la IA «reemplace» la observabilidad, sino que puede cruzar deducciones entre fuentes de datos distintas —trazas, logs, métricas— sin que esas herramientas estén integradas entre sí, generando hipótesis combinadas que ningún dashboard aislado te da solo. El otro lado —y este comentario se llevó bastante peso en la conversación— señalaba un riesgo distinto: si la herramienta se equivoca con total confianza una de cada diez veces, el problema no es solo la tasa de error, es que compañeros con menos experiencia van a aceptar esa respuesta sin cuestionarla en lugar de admitir en voz alta que no saben algo. Sería un problema mucho menor si el propio sistema buscara activamente refutar su primera hipótesis antes de darla por buena, en vez de presentarla como conclusión.
Y luego está el matiz que más se repite en foros técnicos, casi como sentido común compartido: nada de esto sustituye tu stack de observabilidad. Sigues necesitando la misma telemetría, los mismos logs bien estructurados, las mismas trazas. Lo que cambia es que dejas de pasar tanto tiempo mirando fijamente las gráficas tú mismo. Es un acelerador, no un sustituto.
El dato incómodo: el cuello de botella no es el modelo, es lo que le das de comer
Un ejemplo concreto, de un caso técnico publicado por el equipo de Coroot (herramienta open source de observabilidad basada en eBPF): un servicio empieza a dar timeouts contra su base de datos Postgres, y el front-end devuelve 502. Todo apunta a que la base de datos se ha vuelto lenta. La causa real era un experimento de caos inyectando latencia de red entre el servicio y la base de datos — Postgres mide el tiempo de una consulta desde el primer byte recibido hasta el último enviado, así que un retraso de red se cuenta como si fuera lentitud de la propia query. El síntoma apuntaba a un sitio; la causa vivía en otro. Es justo el tipo de zona gris que ninguna traza de aplicación va a mostrarte por sí sola.
Lo revelador no fue que un modelo de IA acertara la causa. Fue que, dándole exactamente el mismo contexto a once modelos distintos, los tres modelos de última generación acertaron sin problema, y entre los modelos más pequeños que uno podría autoalojar el tamaño apenas marcó diferencia — el más pequeño de todos fue, de hecho, el único que encontró la causa correcta. La conclusión práctica no es «hace falta un modelo más grande». Es que el razonamiento en sí ya está prácticamente resuelto en los modelos actuales, y el verdadero cuello de botella es si el sistema te entrega —o te oculta— el dato correcto entre el ruido.
Y aquí conecta con algo que cualquier SRE que gestione presupuesto de logging ya sabe de forma dolorosa: para mantener bajo control el coste de ingesta, es habitual eliminar justo los campos de alta cardinalidad —IDs de usuario, IDs de sesión, request IDs, códigos de error finos— porque disparan el tamaño de los índices. Son exactamente los campos que una IA necesitaría para correlacionar bien un incidente real. Le pides al modelo que encuentre la aguja después de haber tirado la aguja a la basura para ahorrar en la factura.
La foto de agosto de 2026, sin bombo
Quitando los vídeos de YouTube con «así resolví un incidente en 40 segundos con IA» y las notas de prensa de cada dash/keynote del sector, esto es lo que hay:
- El vocabulario de «IA causal» ya no diferencia a nadie — lo usan todos los grandes APM, con matices técnicos distintos detrás.
- La parte de razonamiento del problema está bastante resuelta con los modelos actuales, incluso con modelos pequeños, si el contexto que reciben es el correcto.
- La parte que sigue sin resolverse es de ingeniería de datos, no de inteligencia artificial: qué telemetría conservas, con qué cardinalidad, y si tu pipeline de logs sobrevive al recorte de costes sin perder justo lo que hace falta para investigar un incidente real.
- El escepticismo de la comunidad técnica (no de los vendors) no es rechazo, es cansancio con la sobreventa — la mayoría de los ingenieros que lo han probado en serio coinciden en que ayuda, pero no en la magnitud que promete el titular.
- El agente que cruza fuentes de datos dispares sin integración previa es, probablemente, el avance más honesto y menos discutido de todo esto — más que cualquier «motor causal» propietario.
- Y el punto que casi nadie vende porque no es tan vistoso en un keynote: la herramienta importa menos de lo que parece si lo que hay detrás —qué instrumentas, cómo etiquetas, qué cardinalidad conservas, qué se descarta antes de llegar al índice— está mal planteado. Puedes tener el motor de IA causal más sofisticado del mercado y seguir sin encontrar nada si tu pipeline de ingesta ya decidió, sin que te dieras cuenta, qué preguntas nunca vas a poder responder.
La frase que mejor resume dónde estamos, para mí, es esta: ya no tienes que pasar tanto tiempo mirando fijamente las gráficas tú mismo — es un acelerador, no un sustituto. No es el fin de la observabilidad como la conocíamos. Es, simplemente, una herramienta más rápida para hacer lo que un técnico de guardia con criterio ya sabía hacer — siempre que le sigas dando los datos que necesita para hacerlo bien.
Para seguir leyendo:
- Honeycomb, «It’s the end of observability as we know it (and I feel fine)»
- Discusión completa en Hacker News
- Coroot, el caso técnico del experimento de caos y el benchmark de modelos
