Un agente de IA casi nunca escribe datos desde un solo sitio. Cotiza por WhatsApp, pero también se puede corregir desde un panel, se puede llamar por API desde otro sistema, y alguien del equipo necesita un atajo rápido para los casos urgentes. Cuatro puertas de entrada al mismo dato. La pregunta que casi nadie se hace a tiempo es si las cuatro imponen exactamente la misma regla, o si cada una se construyó por su cuenta, el día que hizo falta, sin mirar a las demás.
Nos pasó en nuestro propio sistema de gestión de proyectos y horas, y lo contamos porque el fallo no tiene nada de exótico: le puede pasar a cualquier negocio que deje escribir el mismo dato desde más de un sitio, con IA de por medio o sin ella.
El problema: la regla existía, pero solo en un sitio
En AutoBoost registramos las horas que cada colaborador dedica a cada proyecto de cliente, y esas horas se descuentan de una bolsa contratada. Hay una regla de negocio obligatoria: un registro por persona, proyecto y día, nunca dos. Esa regla estaba programada, y funcionaba, en el panel principal donde se registra la mayoría de las horas.
El problema es que ese panel no era el único sitio desde el que se podía escribir una hora. Había cuatro vías distintas:
- El panel del administrador.
- El panel que usa cada colaborador.
- Una llamada directa a la API, para integraciones.
- Un registro rápido por terminal, para cuando hace falta apuntar algo sin abrir el navegador.
La regla de "un registro por día" solo vivía, de verdad, en la primera. Las otras tres la daban por hecha, o la reimplementaban a su manera, o simplemente no la comprobaban. Hasta que una auditoría interna encontró dos huecos concretos:
- Editar un proyecto con la bolsa ya cerrada desvinculaba el registro en silencio. El desplegable para elegir proyecto solo mostraba bolsas activas, así que al mover un registro antiguo a un proyecto con la bolsa ya cerrada, el campo se quedaba vacío y el registro perdía su vínculo sin que nadie recibiera ningún aviso de error.
- La fecha por defecto salía del reloj del servidor, no del navegador de quien registraba. Como el servidor vive en otro huso horario, una hora registrada cerca de la medianoche podía quedar apuntada al día equivocado, dependiendo de qué vía se usara para registrarla.
Ninguno de los dos huecos generaba un error visible. El dato se guardaba igual, solo que en el sitio equivocado. Y así se encontraron tres bolsas de clientes distintos que se habían quedado llamando "Bolsa 1" las tres, porque la ficha que mostraba de qué cliente era cada una no se había terminado de aplicar en todas las pantallas que las listaban. Nadie lo había visto porque, para cada vía por separado, todo parecía estar en orden.
Por qué esto no es un problema de código, es un problema de negocio
Un negocio que factura por tiempo trabajado, por consumo o por bolsa de horas no detecta este tipo de fallo con una alarma. Lo detecta cuando un cliente reclama un desajuste, o cuando alguien del equipo intenta reconciliar dos informes y no le salen los mismos números. Para entonces, el dato lleva semanas o meses mal, y nadie sabe desde cuándo.
Lo mismo le pasa a cualquier agente de IA que escriba en más de un sistema o desde más de un canal:
- Un agente que cotiza por WhatsApp y que también se puede corregir desde un panel de administración.
- Un asistente que crea pedidos por voz y que también acepta pedidos por una integración con el ecommerce.
- Un proceso que contabiliza facturas automáticamente y que también permite la carga manual de una factura cuando el OCR falla.
En los tres casos, si la regla de validación (qué cliente puede ver qué, qué tarifa aplica, qué campos son obligatorios, qué duplicados están prohibidos) solo está programada en el canal principal, los demás canales son una puerta trasera. Y una puerta trasera no avisa cuando alguien la usa mal: simplemente deja pasar el dato incorrecto, con la misma cara de normalidad que el dato correcto.
La regla de decisión: una regla, un sitio, cuatro consumidores
Así quedó resuelto en nuestro caso, y es la regla que aplicamos ahora a cualquier sistema con más de una vía de escritura:
La validación no vive en cada pantalla ni en cada canal. Vive en un único sitio (una función, un servicio), y cada vía de entrada la llama a ella, nunca la vuelve a escribir por su cuenta.
| Antes (regla duplicada) | Después (regla centralizada) |
|---|---|
| Cada canal programa su propia versión de la regla | Un único punto comprueba la regla, todos los canales lo llaman |
| Un canal nuevo puede olvidarse de aplicarla | Un canal nuevo la hereda automáticamente, sin reescribirla |
| El fallo se detecta por reclamación de un cliente | El fallo se detecta al escribir, antes de guardar nada |
| Corregir la regla implica tocar cuatro sitios | Corregir la regla implica tocar uno solo |
| El dato mal guardado no da ningún error visible | El intento de guardarlo mal se rechaza en el momento |
Checklist: cómo revisar si tu propio agente tiene este agujero
Antes de dar por bueno que tu agente de IA (o cualquier integración que escriba datos de clientes) está protegido, repasa esto:
- Lista todos los sitios desde los que se puede escribir el mismo dato: paneles, API, atajos internos, integraciones con terceros, importaciones masivas.
- Para cada regla de negocio obligatoria (quién puede ver qué, qué combinaciones están prohibidas, qué campos son únicos), comprueba si está programada una vez o varias.
- Prueba a romper la regla desde el canal menos usado, no desde el principal. Es ahí donde suele faltar.
- Comprueba si un fallo al guardar genera un error visible, o si el dato simplemente se guarda mal y en silencio.
- Si vas a añadir un canal nuevo (una integración, un atajo, una API pública), verifica que llama a la regla existente en vez de reimplementarla.
Dónde entra esto en una integración con IA de verdad
Esto es justo lo que revisamos antes de dejar que un agente de IA actúe sobre datos reales de un cliente: no solo que la IA "entienda" la regla, sino que el sistema la imponga desde cualquier sitio por el que pueda entrar un dato, incluidos los que no se usan todos los días. En el comercial de IA que cotiza por WhatsApp dentro del ERP de una distribuidora industrial con más de 50.000 productos (caso completo), la validación de cliente, tarifa y stock no vive en el prompt ni en el canal de WhatsApp: vive en el ERP, y cualquier vía de entrada pasa por ahí.
Es parte del mismo trabajo de integración que hacemos en AutoBoost antes de dejar que un agente toque datos de producción: puedes ver más en /servicios.
Si tu empresa tiene más de una vía por la que se puede escribir el mismo dato (un panel, una API, una integración, un atajo interno) y no tienes claro si todas imponen la misma regla, cuéntanos tu caso y lo revisamos contigo.
