Monitorización y señalización suena como un panel de control. Por lo general es otra cosa: un sistema que recibe datos de forma continua, los compara con una expectativa o un valor umbral, y emite una señal en cuanto algo se desvía. Puede ser una máquina que vibra de forma distinta a lo normal, una existencia que disminuye más rápido de lo previsto, una red por la que pasa tráfico inusual, o un proceso de cliente cuyo plazo de tramitación se alarga. El componente de IA está en reconocer patrones que con reglas fijas no se pueden captar — no en sustituir a la persona que reacciona ante la señal.
Un sistema de monitorización aporta tres cosas: una medición continua, una norma con la que se compara esa medición, y una señal cuando la desviación supera un límite determinado. Lo que ocurre después depende de cómo esté configurado. En su forma más simple, se envía un aviso a una persona, que lo evalúa y actúa. En una forma más avanzada, la señal inicia automáticamente un paso siguiente — un aviso a un proveedor, un ajuste en una planificación, un bloqueo de una transacción. Esta segunda forma toca el terreno de las cadenas en las que los pasos se suceden: la monitorización se convierte entonces en el punto de partida de un proceso que continúa sin intervención, y eso requiere un tipo de confianza distinto al de un aviso que alguien todavía puede descartar.
La diferencia entre estas dos formas no es trivial. Una señal que llega a una persona puede ser errónea sin que provoque daño inmediato — la persona filtra. Una señal que desencadena una acción debe ser correcta, o la organización debe disponer de una forma de revertir la acción. Muchas organizaciones empiezan por eso con la primera forma y solo avanzan hacia la segunda cuando la señal ha demostrado su fiabilidad.
La monitorización y señalización exige, en primer lugar, datos continuos y fiables. Un sistema que recibe cada semana una exportación de otro sistema no puede emitir una señal — solo puede informar a posteriori. Debe existir un flujo: sensores, registros, transacciones, eventos, que lleguen de forma continua y cuya calidad no varíe según quién realice la entrada.
Además, exige una norma. Una desviación solo es una desviación respecto a algo. En las máquinas suele ser una especificación técnica; en los procesos suele ser más bien un promedio histórico o un valor objetivo que alguien ha fijado. Donde esa norma falta o es inestable — un proceso que cambia constantemente, un mercado que fluctúa — el sistema emite demasiadas señales o demasiado pocas. Ambas cosas erosionan la confianza en él.
En tercer lugar, exige una ruta establecida para lo que ocurre con una señal. Quién recibe el aviso, en qué plazo se evalúa, cuál es la escalada si no se responde. Sin esa ruta, una señal termina en una bandeja de entrada que nadie lee, y el sistema pierde su función. Esto toca la misma cuestión que en las conversaciones que se registran y se les da seguimiento: registrar sin dar seguimiento solo produce un archivo, no una mejora.
El fallo más frecuente es un sistema de monitorización que emite demasiadas señales. Si cada pequeña desviación genera un aviso, las personas aprenden a ignorarlo — el efecto contrario al que el sistema pretendía. Ajustar el valor umbral es, por eso, una ponderación continua entre demasiado ruido y avisar demasiado tarde, y esa ponderación cambia a medida que entran más datos.
Un segundo fallo es que la señal se emite, pero nadie es responsable del seguimiento. Esto ocurre a menudo cuando la monitorización se configura como un proyecto de TI sin que el departamento que debe trabajar con las señales esté involucrado. La técnica funciona, la organización no.
Un tercer fallo surge cuando la señal requiere una decisión que en realidad es trabajo humano — ¿es aceptable esta desviación, hay que llamar al cliente, vale la pena detener esto por este riesgo? Donde esa ponderación se vuelve más compleja de lo que una regla fija puede gestionar, la monitorización se desplaza hacia el apoyo a la decisión, y se aplican otros requisitos de fundamentación y explicabilidad que en el caso de una simple señal de umbral.
La mayoría de los proyectos de monitorización que no despegan se atascan en el flujo de datos, no en el modelo. Sensores que fallan, registros inconsistentes, sistemas que no se comunican entre sí — no son problemas de IA, son problemas de infraestructura que primero deben resolverse. La coordinación también influye: una señal que surge en un departamento a menudo debe llegar a otro departamento para significar algo, y eso toca la cuestión de cómo está organizada la coordinación entre departamentos.
Esta página describe qué puede aportar la monitorización y señalización, y qué debe tener resuelto la organización antes de que funcione. Otra pregunta es qué parte del trabajo relacionado con esas señales — evaluarlas, darles seguimiento, escalarlas — puede realmente asumir la IA. Esa es una pregunta de nivel de tarea, y a esa la responde el escaneo de trabajo de FTE TO AI: este calcula por tarea qué parte del trabajo se puede asumir, en lugar de hacerlo al nivel de todo un proceso o de toda una función.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.