El problema que destruye la confianza

Un paciente escribe a las 11 de la noche: "Cuánto cuesta la blefaroplastia?"

El chatbot, entrenado con una Knowledge Base que se cargó hace tres meses, responde con seguridad: "La blefaroplastia tiene un costo de S/2,800. Incluye consulta previa y controles post-operatorios."

El problema: el precio cambió a S/3,200 el mes pasado. La consulta previa ya no está incluida; ahora se cobra por separado. Y los controles post-operatorios dependen del paquete que el paciente elija.

El paciente llega a la clínica esperando pagar S/2,800 con todo incluido. Se entera de que el precio real es otro. Se siente engañado. Reclama. Deja una reseña negativa. No vuelve.

Este escenario no es hipotético. Es el problema número uno que reportan las empresas que implementan chatbots con IA: la información de precios se desactualiza y el agente sigue respondiendo con la versión anterior con la misma confianza con la que respondería con la correcta. El modelo de lenguaje no sabe que no sabe. No tiene mecanismo interno para distinguir un dato vigente de uno obsoleto.

Las alucinaciones en IA generativa reciben mucha atención mediática, pero hay una categoría de error mucho más peligrosa que la alucinación pura: la respuesta que fue correcta en algún momento y ya no lo es. Porque suena plausible, porque tiene el formato correcto, porque coincide con lo que el cliente espera escuchar. Es un error invisible hasta que explota.

La solución no es "mejorar el modelo". La solución es cambiar de dónde vienen los datos.

Las tres arquitecturas posibles

Cuando un agente de IA necesita responder preguntas sobre precios, disponibilidad, estado de pedidos o cualquier dato que vive en un sistema transaccional (ERP, CRM, sistema de reservas), hay tres formas de proveer esa información. Cada una tiene implicaciones radicalmente distintas en precisión, costo y complejidad.

Arquitectura A: Tool Calling en tiempo real al ERP

El agente, en el momento en que necesita un dato transaccional, llama directamente a la API del ERP. No busca en una base de conocimiento. No consulta un caché. Va a la fuente autoritativa.

Cómo funciona en la práctica:

  1. Paciente pregunta: "Cuánto cuesta la limpieza facial profunda?"
  2. El modelo de lenguaje analiza la intención y determina que necesita un precio.
  3. El agente invoca una función (tool call) que llama a la API del ERP.
  4. En el caso de ERPx, la llamada es: GET /v2.0.3/erpx/comercial/gateway-catalogos-servicios-salud/
  5. La API retorna la estructura completa: catálogo, grupo, servicio, unidad, precio vigente.
  6. El modelo de lenguaje formula la respuesta usando los datos reales que acaba de recibir.

Ventajas:

  • Precisión máxima. El dato siempre es el vigente.
  • No hay lag de sincronización. Si el precio cambió hace 5 minutos, el agente ya lo sabe.
  • La respuesta puede ser vinculante: el precio que cotiza es el precio que el ERP registrará al generar la venta.

Desventajas:

  • Latencia. Cada consulta agrega 200-800ms de tiempo de respuesta dependiendo de la API.
  • Dependencia de disponibilidad. Si la API del ERP está caída, el agente no puede cotizar.
  • Costo de API calls. En volúmenes altos, cada llamada tiene un costo computacional.
  • Complejidad de integración. Requiere mapear las funciones del ERP cómo tools disponibles para el modelo.

Arquitectura B: Sincronización periódica ERP hacia Knowledge Base

Un proceso automatizado extrae datos del ERP cada cierto intervalo (cada hora, cada día, cada semana) y actualiza la Knowledge Base que el agente consulta.

Cómo funciona en la práctica:

  1. Un cron job se ejecuta cada 6 horas.
  2. Llama a la API del ERP y descarga el catálogo completo de precios.
  3. Actualiza los documentos en la Knowledge Base (o la base de datos vectorial).
  4. El agente consulta la Knowledge Base con datos que tienen cómo máximo 6 horas de antigüedad.

Ventajas:

  • Respuestas rápidas. El agente consulta una base de datos local, no una API externa.
  • Tolerancia a fallos. Si la API del ERP se cae, el agente sigue funcionando con los datos de la última sincronización.
  • Menor complejidad en la capa del agente. No necesita saber cómo llamar a APIs; solo busca en su Knowledge Base.

Desventajas:

Este artículo es para miembros del Club MILENIUM

Apoya el periodismo independiente y accede a todo el contenido por el precio de un café.

Únete por S/ 5/mes

Cancela cuando quieras · Sin compromisos