Cómo saber si tu sistema de IA está funcionando bien

El sistema nunca se cayó y aun así dejó de servir

En software tradicional, la pregunta “¿está funcionando?” tiene una respuesta binaria y barata de obtener: el servicio responde o no responde, la transacción se registra o devuelve un error. Por eso los tableros clásicos miran disponibilidad, latencia y tasa de errores. Con un sistema de IA esa lógica se rompe. El sistema puede estar disponible el 100% del tiempo, responder en menos de un segundo, devolver una respuesta bien formada en todas las llamadas, y estar entregando contenido cada vez peor. No hay excepción, no hay log en rojo, no hay alerta. La falla no se manifiesta como caída, se manifiesta como deterioro.

Eso cambia por completo quién detecta el problema. En un sistema tradicional lo detecta el monitoreo. En un sistema de IA lo detecta el usuario, y casi nunca lo reporta. Lo que hace la gente cuando una respuesta llega mal es corregirla a mano y seguir, porque abrir un ticket toma más tiempo que arreglar el párrafo. La consecuencia es que la empresa acumula meses de degradación silenciosa mientras el tablero sigue verde, hasta que alguien de dirección pregunta por los resultados y descubre que el área abandonó el sistema hace semanas sin decirlo.

He entrado a auditar sistemas donde el proveedor mostraba métricas impecables y el equipo usuario tenía una carpeta compartida con las respuestas “buenas” que iban guardando a mano, porque no confiaban en pedirlas de nuevo. Ese es el punto en que el sistema técnicamente funciona y operativamente ya murió. Nadie mintió: midieron lo que sabían medir.

Qué significa de verdad funcionar cuando hablamos de IA

Un sistema de IA en producción tiene tres capas que fallan de forma independiente, y confundirlas es el origen de casi toda la discusión estéril entre negocio y tecnología. La primera capa es la de infraestructura: si el servicio está arriba, si las integraciones responden, si el costo por interacción se mantiene dentro de lo previsto. La segunda es la de calidad: si lo que devuelve el sistema es correcto, completo, y fiel a las fuentes que debía usar. La tercera es la de confianza operativa: si la persona que recibe la respuesta la usa tal cual, la corrige, o directamente deja de pedirla. Un sistema puede estar perfecto en la primera capa y quebrado en las otras dos.

A esta práctica se le llama observabilidad, y la palabra importa porque no es lo mismo que monitoreo. Monitorear es vigilar indicadores que ya definiste. Observar es dejar el sistema instrumentado de forma que puedas responder preguntas que todavía no te hiciste: por qué esta respuesta salió así, qué documentos consultó, qué versión del prompt estaba activa, qué modelo la generó, cuánto costó. Sin ese rastro, cuando algo falla el equipo entra en modo adivinanza y la única salida es cambiar cosas al azar hasta que parezca mejorar. Ese es el escenario más caro de todos.

Qué se mira además de que no se cayó

La lista que sigue no es un tablero técnico, es lo que un gerente puede exigir que exista aunque no lo construya él. Cada punto responde a una pregunta de negocio concreta, y si el proveedor no puede mostrar ninguno de estos datos, lo que tienes no es un sistema en producción: es un piloto que se quedó prendido.

Señales de la capa técnica

• Trazabilidad de cada interacción: entrada, salida, fecha, usuario o área, versión del prompt, modelo usado y fuentes consultadas. Sin este registro no se puede investigar ningún incidente después del hecho.
• Tasa de fallas silenciosas de integración: cuántas veces la búsqueda en la base de conocimiento devolvió vacío, cuántas veces la API interna respondió tarde o incompleta. Estas fallas no rompen el sistema, lo dejan respondiendo con menos información de la que debía.
• Costo por interacción y su tendencia: un salto en el costo suele significar que alguien cambió el modelo, que los prompts crecieron sin control o que el sistema está reintentando en silencio.
• Distribución de latencia, no el promedio: el promedio esconde el 5% de consultas que tardan quince segundos y hacen que la gente abandone el flujo.
• Volumen de consultas que caen fuera de lo previsto: preguntas que el sistema no fue diseñado para responder y que igual responde. Ese es el terreno donde nacen los errores caros.

Señales de la capa de calidad

• Resultado contra un conjunto fijo de casos de prueba: entre 30 y 100 preguntas reales del negocio con respuesta esperada, que se corren cada vez que algo cambia. Es la única forma barata de comparar el sistema de hoy con el de hace tres meses.
• Tasa de respuestas sin sustento: qué porcentaje de las respuestas afirma cosas que no están en las fuentes que el sistema tenía disponibles. Se mide por muestreo, no hace falta revisarlo todo.
• Revisión humana por muestreo con criterio fijo: una persona del negocio evalúa 20 o 30 respuestas al azar cada semana con una rúbrica simple de correcto, incompleto o incorrecto. Suena artesanal y es el indicador que más veces me ha salvado una implementación.
• Tasa de edición de la salida: cuánto modifica el usuario lo que el sistema produjo antes de usarlo. Si de un borrador se reescribe el 70%, el sistema está generando trabajo, no ahorrándolo.
• Comportamiento en los casos límite del negocio: excepciones, políticas nuevas, clientes atípicos. Ahí es donde el sistema deja de ser útil primero, y donde nadie mira.

Cómo se degrada la calidad sin que nadie levante la mano

Un sistema de IA no envejece como un software normal. El código puede estar intacto y el resultado empeorar igual, porque el sistema depende de cosas que se mueven fuera de tu control. El proveedor actualiza el modelo y ajusta su comportamiento. La realidad del negocio cambia y las preguntas que llegan ya no se parecen a las que se probaron. La base de conocimiento envejece y sigue respondiendo con la política del año pasado con total seguridad. Nada de esto genera una alerta, porque técnicamente todo respondió bien.

Los patrones de deterioro que aparecen una y otra vez en empresas reales son pocos y bastante identificables. Vale la pena reconocerlos antes de que el equipo abandone el sistema por su cuenta:

• Contenido desactualizado: la fuente que alimenta al sistema dejó de mantenerse. El sistema no sabe que la política cambió y responde con la anterior sin dudar ni una línea.
• Cambio en el tipo de preguntas: el sistema se diseñó para consultas de un proceso y el equipo empezó a usarlo para otro. La calidad cae y nadie lo atribuye a un cambio de uso.
• Actualización del modelo por parte del proveedor: la nueva versión responde distinto, más corto, más cauta o con otro formato, y rompe lo que estaba calibrado alrededor de la versión anterior.
• Prompts editados sin control ni versión: alguien mejoró una instrucción un viernes y nadie registró el cambio. Cuando la calidad baja, no hay forma de saber qué se tocó ni cómo volver atrás.
• Crecimiento sucio de la base de conocimiento: se cargan documentos duplicados, borradores y versiones viejas. El sistema ahora tiene más información y menos criterio para elegir la correcta.
• Usuarios que aprenden a esquivarlo: la gente descubre qué preguntas responde bien y solo hace esas. El indicador de calidad sube mientras el alcance real del sistema se encoge.

Las señales que anticipan que el equipo va a abandonar el sistema

El abandono nunca es un evento, es una pendiente. Y lo interesante es que se puede leer desde el propio sistema semanas antes de que el uso caiga, si alguien está mirando las señales correctas. No hablo de encuestas de satisfacción ni de reuniones de seguimiento donde todos dicen que va bien: hablo de comportamiento registrado. Cómo medir la adopción del lado del negocio es un tema propio, con sus métricas y su método; acá me quedo en lo que el sistema mismo te está avisando antes de que el tema llegue a la reunión de gerencia.

• Reintentos seguidos sobre la misma consulta: el usuario reformula dos o tres veces lo mismo. Está peleando con el sistema, y cada pelea acerca la decisión de no volver.
• Sesiones abandonadas a mitad de flujo: la persona pidió algo, recibió respuesta y no hizo nada con ella. No hay error registrado y aun así el resultado fue cero.
• Concentración del uso en pocas personas: si el 80% de las consultas viene de dos usuarios entusiastas, el sistema no se adoptó, se lo adoptaron dos personas. Cuando esas dos se van o cambian de foco, el uso cae a cero.
• Caída de la variedad de consultas: menos tipos de preguntas distintas mes a mes suele ser el primer síntoma de que la gente dejó de confiar en el sistema fuera de un par de tareas seguras.
• Regreso del proceso paralelo: la plantilla vieja, el correo al analista o el mensaje al grupo de WhatsApp que el sistema debía reemplazar vuelven a aparecer. Esta es la señal más clara y la que menos se instrumenta.
• Silencio total de reportes: si un sistema con uso real lleva tres meses sin un solo reporte de error, no está perfecto. Es que nadie lo está reportando, y eso suele ser peor.

Medir uso no es medir valor, y lo que el monitoreo no resuelve

Acá viene la parte incómoda. Un tablero de observabilidad puede estar impecable, con todas las señales verdes, y el sistema seguir sin aportar nada al negocio. Porque uso no es valor. Que mil consultas por semana pasen por el sistema no dice si esas consultas evitaron trabajo, si aceleraron una decisión o si simplemente reemplazaron una búsqueda en el buscador interno que ya era gratis. El monitoreo te dice cómo se comporta el sistema. No te dice si el proceso que envolviste con IA valía la pena.

Hay tres cosas que ninguna herramienta de observabilidad va a resolver por ti. La primera: si el caso de uso estaba mal elegido desde el inicio, medirlo mejor solo te da evidencia más precisa de un error que ya estaba tomado. La segunda: si el proceso de fondo es un desorden, el sistema va a reflejar ese desorden con más velocidad y el tablero lo va a mostrar como variabilidad inexplicable. La tercera: si nadie es dueño del sistema, las alertas van a llegar a un canal que nadie lee. La observabilidad no crea responsabilidad, solo la hace visible cuando existe.

Y una advertencia práctica sobre la trazabilidad: registrar cada interacción significa guardar lo que la gente escribe, y en muchos casos eso incluye datos de clientes, montos, nombres o información sensible. Un sistema de observabilidad mal diseñado se convierte en el mayor repositorio de datos sin control de la empresa. Antes de encender los registros hay que definir qué se guarda, cuánto tiempo, quién lo puede consultar y qué se enmascara. Esto no es un detalle de cumplimiento, es parte del diseño.

Errores típicos que veo en empresas con sistemas de IA en producción

• Confundir el tablero del proveedor con monitoreo real. La mayoría muestra disponibilidad, latencia y consumo. Eso es la salud del servicio, no la salud del sistema. Si no hay ninguna métrica de calidad, no hay monitoreo.
• Dejar la evaluación de calidad para después del lanzamiento. El conjunto de casos de prueba se arma antes de salir a producción, con el equipo que conoce el proceso, no cuando ya hay quejas. Después nadie tiene tiempo y nunca se hace.
• No versionar los prompts ni la configuración. Si no puedes decir qué versión estaba activa el martes pasado, cualquier análisis de una falla es especulación. Los prompts son código de negocio y merecen el mismo control de cambios.
• Medir solo lo agregado. Un promedio semanal de calidad esconde que un área específica está recibiendo respuestas malas de forma sistemática. Hay que poder segmentar por proceso, por área y por tipo de consulta.
• Alertar sobre todo y por lo tanto sobre nada. Cuando el canal de alertas emite quince avisos al día, el equipo lo silencia en dos semanas. Pocas alertas, con umbral pensado y con un dueño con nombre y apellido.
• Asumir que el proveedor va a avisar cuando algo se degrade. Nadie va a llamarte para decirte que su sistema está entregando peores respuestas. La capacidad de verificarlo tiene que quedar del lado de la empresa, escrita en el acuerdo de servicio.
• Delegar la evaluación de calidad solo a lo técnico. Si quien decide si una respuesta es correcta no conoce el negocio, la evaluación mide forma y no fondo. Un texto bien escrito y equivocado pasa cualquier revisión técnica.

Cómo saber si tu monitoreo sirve: el tablero mínimo

La prueba de que el monitoreo está bien montado no es la cantidad de gráficos. Es que puedas responder cinco preguntas concretas en menos de diez minutos, sin llamar al proveedor. Si necesitas escribir un correo y esperar dos días para saber cualquiera de estas cosas, tu sistema no está observado: está funcionando de fe.

• ¿Qué respondió el sistema en una interacción específica de hace tres semanas, con qué fuentes y qué versión de configuración?
• ¿La calidad de hoy es mejor, igual o peor que la de hace dos meses, medida contra los mismos casos de prueba?
• ¿Qué áreas usan el sistema y con qué tipo de consultas, y cuáles dejaron de usarlo?
• ¿Cuánto cuesta operar el sistema por mes y qué explica cualquier variación mayor al 20%?
• ¿Cuál fue el último cambio que se hizo en el sistema, quién lo hizo y qué pasó con los indicadores después?

El orden de implementación importa. Primero trazabilidad, porque sin registros no hay nada que analizar. Después el conjunto de casos de prueba, porque es lo que te permite comparar en el tiempo. Después la revisión humana por muestreo, que es barata y detecta lo que ninguna métrica automática ve. Y recién al final las alertas, cuando ya sabes qué umbral tiene sentido para tu operación. Montar alertas primero es la forma más rápida de tener un canal de ruido que todos silencian.