Una automatización de la que no se puede saber qué hizo, cuándo, con qué datos y por qué, no se está operando: se está soportando. La diferencia aparece el día que algo sale mal, y en ese momento ya no hay forma de reconstruir lo ocurrido: los datos que harían falta no se guardaron porque nadie decidió guardarlos.
Este es probablemente el fallo de diseño más extendido en los sistemas con componentes de IA que auditamos, y el más barato de evitar si se decide al principio.
Monitorizar es comprobar que el sistema está vivo: responde, no da errores, la latencia es aceptable. Es necesario y no es suficiente.
Observar es poder responder a preguntas que no anticipaste. Por qué este caso concreto se resolvió así. Qué versión del modelo intervino el martes pasado. Cuántas veces el sistema tuvo que reintentar antes de responder. Qué porcentaje de las propuestas del agente se están corrigiendo antes de aprobarse.
La distinción importa especialmente con componentes probabilísticos, porque un sistema de IA puede estar perfectamente sano en términos de infraestructura —cero errores, latencia baja, disponibilidad total— y estar produciendo resultados progresivamente peores. Un panel de monitorización clásico no detecta eso. Muestra todo en verde.
Lo hemos desarrollado con más detalle en observabilidad de LLMs, la métrica que nadie está midiendo
|
Capa |
Qué se registra |
Para qué sirve |
|
Entrada |
Qué datos y qué contexto recibió el sistema |
Reproducir el caso y detectar datos anómalos |
|
Decisión |
Qué produjo el modelo, con qué versión y qué configuración |
Explicar el resultado y detectar deriva |
|
Acción |
Qué se ejecutó realmente sobre qué sistema |
Auditoría, reversión y responsabilidad |
|
Validación |
Qué persona revisó, qué cambió y cuándo |
Medir calidad real y cumplir supervisión humana |
|
Coste |
Consumo por ejecución y por caso de negocio |
Controlar el coste unitario a escala |
La capa de validación es la que más se omite y la que más valor produce. Registrar qué corrigió la persona antes de aprobar convierte la supervisión humana en un flujo de datos sobre la calidad del sistema. Sin ese registro, la única señal disponible es la queja del cliente, que llega tarde y sesgada.
La capa de coste es la segunda más omitida. Un sistema de IA tiene coste variable por ejecución, algo poco habitual en software empresarial. Si no se registra por caso de negocio, es imposible saber si el proceso automatizado sale rentable, y esa pregunta llega siempre, normalmente en la revisión presupuestaria del trimestre siguiente.
Los indicadores técnicos —latencia, tokens, tasa de error de la API— sirven al equipo que opera. En un comité de dirección solo funcionan cuatro:
Tasa de aceptación sin cambios. De las propuestas que genera el sistema, qué porcentaje se aprueba tal cual. Es el indicador de calidad más honesto que existe, porque lo produce el uso real y no una evaluación de laboratorio.
Tasa de escalado a humano. Qué porcentaje de casos el sistema no puede resolver. Debe tener un valor objetivo: si es demasiado alto, el sistema no aporta; si es cero, probablemente está resolviendo casos que no debería.
Coste por caso resuelto. El coste total dividido entre los casos efectivamente cerrados, no entre los intentos. Es el número que se compara con el coste del proceso anterior.
Tiempo de detección de un fallo. Cuánto tarda la organización en enterarse de que el sistema está produciendo resultados incorrectos. Si nadie ha medido esto, la respuesta real suele ser «cuando se queja un cliente».
Estas cuatro métricas se pueden presentar en una diapositiva y responden a la única pregunta que le importa a un consejo: ¿esto funciona, cuánto cuesta y cuánto tardamos en enterarnos si deja de funcionar?
Hasta hace poco, la trazabilidad se defendía por razones de ingeniería. Desde 2025 hay un segundo argumento y es más difícil de rebatir en un comité.
El Reglamento europeo de IA exige, para determinadas categorías de sistemas, registro de eventos, documentación técnica y supervisión humana demostrable. El AI Risk Management Framework del NIST estructura la gestión de riesgo alrededor de la capacidad de medir y monitorizar. La norma ISO/IEC 42001 exige evidencia de control continuo para poder certificar un sistema de gestión de IA.
Los tres marcos piden lo mismo con vocabularios distintos: poder demostrar qué hizo el sistema. Un sistema que no lo registró no puede demostrarlo, y añadirlo después obliga a tocar la arquitectura.
Conviene decirlo con claridad porque cambia el orden de prioridades: la observabilidad ha dejado de ser una tarea de operaciones para convertirse en un requisito de diseño.
No hace falta reescribirlo. El camino habitual tiene tres pasos y se puede ejecutar sin parar la operación:
El error a evitar es intentar instrumentarlo todo a la vez. Un sistema con dos capas bien registradas es infinitamente más gobernable que uno con cinco capas registradas a medias.
Antes de dar por terminado un proyecto de automatización, conviene hacer una prueba concreta: elige un caso al azar de hace tres semanas y pide que te expliquen exactamente qué ocurrió.
Si el equipo puede reconstruirlo —qué datos entraron, qué versión del modelo intervino, qué se ejecutó y quién lo validó—, el sistema es operable. Si la respuesta empieza con «habría que mirar los logs, aunque no sé si guardamos eso», el sistema está en producción sin estar terminado.
Es la capacidad de responder a preguntas que no se anticiparon sobre el comportamiento del sistema: por qué un caso concreto se resolvió así, qué versión del modelo intervino, cuántos reintentos hubo o qué proporción de propuestas se está corrigiendo. Se diferencia de la monitorización, que solo comprueba que el sistema está disponible y responde.
Cinco capas: la entrada (datos y contexto recibidos), la decisión (salida del modelo, versión y configuración), la acción (qué se ejecutó y sobre qué sistema), la validación (qué corrigió la persona que revisó) y el coste por ejecución y por caso de negocio.
Cuatro: tasa de aceptación sin cambios, tasa de escalado a humano, coste por caso resuelto y tiempo de detección de un fallo. Las métricas técnicas como latencia o consumo de tokens sirven al equipo de operaciones, no a la decisión de negocio.
Sí. El Reglamento europeo de IA exige registro de eventos, documentación técnica y supervisión humana demostrable para determinadas categorías de sistemas. El NIST AI RMF estructura la gestión de riesgo sobre la capacidad de medir y monitorizar, y la ISO/IEC 42001 requiere evidencia de control continuo para certificar.
Sí, sin reescribirlo. El orden eficaz es instrumentar primero entrada y acción —que permiten reconstruir un incidente—, añadir después el registro de validación humana y definir los umbrales de alerta antes de disponer de los datos, no después.
Porque los indicadores de infraestructura (disponibilidad, latencia, errores) pueden estar en verde mientras la calidad de los resultados se degrada. La calidad de un componente probabilístico no se mide con las herramientas de monitorización clásicas, sino con métricas de resultado sobre uso real.
|
¿Podrías reconstruir hoy qué hizo tu sistema de IA hace tres semanas? Si la respuesta es dudosa, conviene revisarlo antes de que la pregunta la haga un cliente o un auditor. Analizamos tu caso en dos horas, sin compromiso. Hablemos → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
