Tu IA puede tener la urgencia de cada aviso perfectamente calculada y, aun así, dejar que un problema real se quede sin resolver durante días. No porque el cálculo esté mal, sino porque el aviso llega al sitio equivocado, o llega al sitio correcto y nadie es responsable de mirarlo. Nos pasó hace poco con un sistema de avisos que vigila varios clientes a la vez, y el arreglo terminó siendo una regla de diseño que vale para cualquier negocio que use IA para vigilar algo y avisar de lo que encuentra.
El problema de partida: un solo canal para todo
El sistema mandaba todos los avisos por el mismo canal, y decidía el medio (interrumpir ya o dejarlo para revisar con calma) mirando qué predominaba en el contenido del envío. El resultado práctico: un correo con varios descuadres menores podía arrastrar dentro un aviso de una avería real, por ejemplo una conexión caída, y ese aviso urgente quedaba escondido en un mensaje pensado para leerse sin prisa.
El fallo no estaba en detectar el problema. La detección funcionaba bien. Estaba en cómo se empaquetaba y a quién le llegaba, que es justo la parte que menos se audita cuando se diseña un sistema de avisos con IA: toda la atención se va al "qué detecta", y casi ninguna al "cómo decide molestar a alguien con ello".
Primer arreglo: separar por urgencia, no por asunto
La solución inicial fue simple de describir y no tan simple de aplicar bien: dos canales independientes en vez de uno. Una avería real va por un canal que interrumpe. Un descuadre que se puede revisar con calma va por otro que no lo hace. Ya no compiten por el mismo mensaje ni por la misma atención.
La parte que de verdad importa no es tener dos canales, es cómo se decide cuál usa cada aviso. Esa lógica de reparto se sacó a una función propia, separada del proceso principal, para poder probarla sola con casos concretos ("esto es una avería, tiene que ir aquí"; "esto es un descuadre, tiene que ir allá") en vez de confiar en que el comportamiento general del sistema la cubriera por accidente. Es una regla que aplica a cualquier lógica de decisión dentro de un flujo de IA: si decide algo importante, tiene que poder probarse sola, sin levantar todo el proceso alrededor.
Segundo arreglo: la urgencia también depende de quién la recibe
Pocos días después llegó la vuelta de tuerca que de verdad cambia la regla: la urgencia de un aviso no depende solo de la gravedad del problema, depende también de en qué fase está el cliente al que afecta. Un cliente que ya opera en real necesita que se le interrumpa al momento. Un cliente que todavía está en fase de pruebas puede esperar a un canal que se revisa con calma, aunque el problema técnico sea idéntico.
Es un matiz que se pasa por alto fácilmente porque parece que complica el sistema sin necesidad. En la práctica es al revés: sin ese matiz, cada aviso de un cliente en pruebas suena con la misma fuerza que el de un cliente en producción, y eso entrena a quien lo recibe a bajar la guardia con todos por igual, incluidos los que sí importan de verdad.
Al mismo tiempo se cerró un hueco que suele pasar desapercibido: si la propia comprobación que vigila algo deja de funcionar, ahora también avisa. Antes, un fallo silencioso de la comprobación se veía exactamente igual que "todo en orden", que es el peor sitio donde puede fallar un sistema de vigilancia: en el punto ciego de sí mismo.
El número que puso la regla sobre la mesa: 3 casos sin dueño
Con los dos canales ya separados, apareció un problema distinto y menos evidente: 3 casos de baja urgencia llevaban tiempo esperando revisión en su canal, sin que nadie los tuviera asignados. No estaban perdidos, ni mal clasificados. Estaban exactamente donde tenían que estar. Simplemente no había ningún responsable concreto mirando ese canal con la regularidad que necesita algo "para cuando haya un rato".
Esa es la parte que casi nadie diseña a propósito: un canal de baja urgencia sin dueño explícito no se vacía solo, tiende a acumular. No porque nadie quiera atenderlo, sino porque nadie tiene asignada la responsabilidad de vaciarlo, y lo urgente de otros sitios siempre gana la pelea por la atención del día. Un canal así, sin revisión, se convierte con el tiempo en el sitio donde los avisos van a que nadie los vea, que es exactamente lo contrario de lo que se buscaba al separarlo del canal urgente.
La regla de decisión
Dos ideas, aplicables a cualquier negocio que use IA para vigilar algo (una integración, varias sedes, varios clientes) y avisar de lo que encuentra:
- La urgencia de un aviso depende de quién lo recibe, no solo de qué ha fallado. El mismo problema técnico puede ser urgente para un cliente y esperable para otro, según su fase o su exposición real.
- Un canal de baja urgencia sin dueño asignado se convierte en un cementerio de avisos. Separar por urgencia resuelve el ruido, pero crea un canal nuevo que, si nadie lo tiene asignado como tarea, acumula sin que se note hasta que alguien pregunta por un caso concreto.
Checklist antes de dar por bueno tu sistema de avisos con IA
| Pregunta | Por qué importa |
|---|---|
| ¿Los avisos urgentes y los que pueden esperar van por canales distintos? | Si comparten canal, uno esconde al otro. |
| ¿La lógica que decide el canal está en una función que se puede probar sola? | Si vive enterrada en el proceso principal, nadie la valida con casos concretos. |
| ¿La urgencia depende de quién recibe el aviso, o solo de la gravedad técnica? | El mismo fallo puede pesar distinto según el cliente o la fase en la que está. |
| ¿Alguien tiene asignado, por nombre, vaciar el canal de baja urgencia? | Sin dueño, ese canal acumula casos que nadie reclama. |
| ¿Qué pasa si la propia comprobación deja de funcionar? | Un chequeo que calla se ve igual que "todo en orden", y es el peor punto ciego posible. |
Por qué esto no es solo "nuestra fontanería"
Este patrón no es exclusivo de un sistema de monitorización interno. Aparece en cualquier proceso de IA que decide a quién avisar y cómo: un asistente que lee facturas y marca discrepancias, un agente que vigila stock en varias tiendas, una IA que revisa notificaciones fiscales y decide cuáles requieren respuesta inmediata. En nuestro trabajo con una asesoría, montamos una IA que lee la bandeja de notificaciones fiscales y las clasifica en 15 categorías: la parte que de verdad marca la diferencia no es solo clasificar bien, es que cada categoría tenga claro quién la revisa y con qué urgencia, o la clasificación perfecta no sirve de nada si nadie sabe que le toca mirarla a él.
La lección se repite en cualquier sistema donde una IA decide "esto hay que mirarlo ya" frente a "esto puede esperar": el diseño de a quién y cómo avisar pesa tanto como el de qué se detecta, y normalmente se le dedica una fracción del tiempo.
Si estás montando o revisando tu propio sistema de avisos con IA
Antes de dar por cerrado un proyecto de IA que vigila algo (una integración, un almacén, varias sedes, varios clientes) haz la pregunta al revés de como se suele hacer. No preguntes solo "¿qué detecta?". Pregunta "¿quién recibe cada tipo de aviso, con qué urgencia, y quién es responsable de que ninguno se quede sin revisar?". Si no tienes una respuesta concreta para las tres partes de esa pregunta, tu sistema de avisos todavía no está terminado, aunque la parte de detección funcione perfectamente.
En AutoBoost trabajamos con clientes que necesitan justo esto: no solo que la IA detecte lo que importa, sino que ese aviso llegue a quien tiene que actuar, con la urgencia correcta y con un responsable asignado. Si quieres revisar cómo está diseñado el tuyo, hablemos en una llamada.
