Guía · Arquitectura
¿Y si la IA se inventa un dato?
Es el primer miedo de cualquiera que se plantea meter agentes en su empresa, y casi siempre se contesta con una promesa. Tiene respuesta de ingeniería, y son dos decisiones que se toman antes de escribir la primera línea.
Un modelo se puede inventar un número porque su trabajo es producir texto que encaje, no consultar una base de datos. La forma de evitarlo no es pedirle que no lo haga: es quitarle el trabajo. Las cifras las calcula un script sobre la base de datos, no un modelo. Y ninguna acción que cambie algo se ejecuta sin que una persona la confirme.
Por qué un modelo se inventa un número
Un modelo de lenguaje completa texto. Cuando le falta el dato no se detiene: produce algo con la forma correcta. Y un número con la forma correcta es un número.
Ese es el problema real, y no es la tasa de acierto. Es que la cifra inventada se parece exactamente a la buena. Un texto raro se detecta al leerlo. Un saldo de caja con un dígito cambiado no lo detecta nadie sin ir a comprobarlo. Y si hay que comprobarlo cada vez, el sistema no ahorra trabajo: lo desplaza.
Y lo que dice el sistema obliga a la empresa. En febrero de 2024 el Civil Resolution Tribunal de Canadá condenó a Air Canada a indemnizar a un pasajero porque su chatbot le explicó que podía pedir la tarifa por duelo después de volar, algo que la política de la compañía no contemplaba. El tribunal resolvió que la aerolínea no había puesto un cuidado razonable en que su chatbot fuera preciso. No se discutió si la máquina se equivocó, sino quién respondía. Respondió la empresa.
De ahí sale el criterio con el que construimos: la pregunta no es cuánto acierta el modelo. Es qué pasa el día que falla.
La cifra la calcula un script
La primera es la más aburrida y la que resuelve la mayor parte del problema: un modelo no tiene permiso para producir una cifra.
Los dos caminos salen del mismo sitio y terminan en cosas distintas. Por el de arriba, un script recorre la base de datos, cuenta y suma. El resultado es la cifra, cerrada, y no pasa por ningún modelo. Por el de abajo, el agente lee y redacta. Lo que produce es texto, y ese texto no sale hasta que alguien lo aprueba.
Nuestro agente de Informes manda un briefing por WhatsApp cada mañana y el informe del embudo los viernes. Ninguno de esos números se le pregunta a un modelo: llegan ya calculados y el agente solo escribe la frase que los envuelve. Las cifras las calcula un script sobre la base de datos, no un modelo, precisamente para que no se inventen números.
El efecto es el que buscábamos. Como el modelo nunca es la fuente del número, cuando algo sale mal, sale mal el texto. La cifra no se mueve.
Agente lee, humano aprueba
La segunda cubre lo que el script no alcanza, porque no todo es un número. Un agente también propone a quién escribir o qué gasto registrar, y ahí hay criterio.
La regla es la misma en los cuatro agentes: agente lee, humano aprueba. Y no es un eslogan, los permisos lo impiden en el código. Toda acción que cambia algo pide confirmación y queda auditada.
- El Asistente 24/7 responde en vivo por WhatsApp y puede crear tareas, gastos o facturas en borrador. Nada de eso queda firme sin una confirmación.
- El agente de Prospección puntúa el encaje y redacta un borrador de primer mensaje. Una persona acepta cada empresa y hace el contacto a mano. El sistema nunca escribe en frío.
- El agente de Seguimiento detecta lo que se está enfriando y genera el trabajo. La decisión sigue siendo de una persona.
Contra las alucinaciones, esta capa hace algo concreto: cambia dónde aterriza el fallo. Un dato inventado que se queda en un borrador es una molestia de treinta segundos. El mismo dato ejecutado sobre la base de datos, o enviado a un cliente, es lo de Air Canada.
Hay además un motivo que ya no depende de nosotros. En febrero de 2026 la Agencia Española de Protección de Datos publicó unas orientaciones sobre IA agéntica que piden supervisión humana sobre lo que el agente ejecuta, acceso limitado a los datos necesarios y registro de lo que hace. Son los tres puntos de arriba, escritos por otros. Lo desarrollamos en la guía sobre qué obliga el RGPD a una empresa que usa IA con datos de clientes.
Estas dos decisiones no son nuestras solo sobre el papel: el sistema con el que llevamos BBLAST está montado así, y es el mismo criterio que aplicamos cuando construimos e implantamos el sistema de un cliente.
Lo que esto no arregla
Nada de esto consigue que un modelo no falle nunca. Consigue que el fallo caiga donde no cuesta dinero. Conviene decir qué queda fuera.
- Si el dato de origen está mal, el script lo devuelve mal. Un cálculo exacto sobre una base de datos sucia da un número exacto y falso. Por eso el orden importa: primero ordenar la información, después automatizar.
- El registro de auditoría solo sirve si alguien lo mira. Guardar quién aprobó qué y cuándo es barato. Revisarlo de vez en cuando es lo que lo convierte en un control.
- Una persona que aprueba sin leer no es supervisión. Es un botón. La capa de permisos obliga a que haya un humano; que ese humano mire de verdad ya no lo puede forzar el código.
La diferencia entre un sistema que se inventa cosas y uno que no está menos en el modelo de lo que la gente supone, y mucho más en dónde pusiste las paredes.