Arquitectura de un asistente de IA que consulta tus sistemas

Cuando un asistente de IA responde bien en una demo, la conversación suele saltar directo a qué modelo usar. Es la decisión menos importante. Lo que separa un asistente que funciona en producción de uno que se apaga al mes está alrededor del modelo: cómo se conecta con tus sistemas, qué puede hacer, con qué permisos y cómo se sabe si se equivocó.

La diferencia entre un chatbot y un agente ya la tratamos en agente de IA empresarial frente a chatbot. Este artículo va un nivel más abajo: qué piezas tiene por dentro un asistente que consulta tu ERP, tu CRM y tus documentos, qué hace cada una y qué pasa cuando falta.

¿Qué hay dentro de un asistente de IA que consulta tus sistemas?

Visto desde fuera, el usuario escribe una pregunta y recibe una respuesta. Por dentro ocurre una secuencia: el modelo interpreta la pregunta, decide qué información necesita, llama a una o varias herramientas, recibe resultados, decide si le falta algo y redacta la respuesta. Cada paso pasa por capas que no son el modelo.

Son siete capas y, en un entorno empresarial, ninguna es opcional. La tabla resume qué hace cada una.

¿Qué papel juega el modelo de lenguaje?

El modelo es el que razona: entiende la intención, elige herramientas y redacta. Pero no es la fuente de verdad de nada. No debe saber de memoria el saldo de un cliente ni el inventario de un almacén; debe saber dónde preguntarlo. Todo dato de negocio que aparezca en una respuesta tiene que venir de una herramienta o de un documento recuperado, nunca de lo que el modelo recuerda.

Esa separación tiene una consecuencia práctica: el modelo se puede cambiar. Si la arquitectura está bien hecha, sustituir un modelo por otro más barato o más capaz es un cambio de configuración seguido de una ronda de evaluación, no una reconstrucción. Cuando la lógica de negocio vive dentro de las instrucciones del modelo, cada cambio de proveedor rompe algo.

¿Cómo se conecta con el ERP y el CRM sin darle acceso total?

Con herramientas acotadas. Una herramienta es una acción con nombre, descripción y parámetros definidos: consultar el estatus de un pedido por folio, listar las facturas vencidas de un cliente, obtener la existencia de un producto en un almacén. El modelo solo puede usar las herramientas que se le exponen, y solo con los parámetros que cada una acepta.

Lo que no se hace es darle al modelo una conexión directa a la base de datos para que escriba sus propias consultas. Parece más flexible, pero abre la puerta a consultas costosas, a datos que no debería ver y a resultados que nadie validó. Una lista cerrada de acciones, cada una con validación de entrada y salida, es más limitada y mucho más segura.

• Cada herramienta hace una sola cosa y la describe con claridad, porque el modelo elige a partir de esa descripción.
• Los parámetros se validan antes de llegar al sistema: un folio con formato incorrecto se rechaza sin tocar el ERP.
• Las respuestas se recortan a lo necesario; devolver el registro completo de un cliente cuando se pidió su saldo desperdicia contexto y expone datos.
• Las herramientas de lectura y las de escritura se separan desde el diseño, porque tendrán reglas distintas.

En la práctica, estas herramientas son una capa de APIs internas sobre tus sistemas, y su calidad depende de esa capa. Si tu ERP no expone servicios limpios, el primer trabajo es construirlos; lo explicamos en desarrollo de APIs. Hoy existen estándares abiertos para describir herramientas de forma que distintos modelos las entiendan, lo que reduce la dependencia de un proveedor, pero el diseño de cada acción sigue siendo trabajo propio.

¿Y los documentos que no están en ningún sistema?

Buena parte de las preguntas de una empresa se responden con documentos, no con registros: políticas de crédito, contratos, procedimientos, manuales técnicos. Para eso el asistente usa recuperación de documentos, el mismo mecanismo que describimos en segundo cerebro empresarial con RAG.

En una arquitectura de agente, la recuperación es una herramienta más. El modelo decide cuándo consultar un sistema, cuándo buscar en documentos y cuándo combinar ambos: ver en el CRM que un cliente tiene 45 días de atraso y buscar en la política de crédito qué procede en ese caso. La respuesta útil casi siempre cruza las dos fuentes.

¿Cómo se respetan los permisos de quien pregunta?

El error más común es conectar el asistente con una cuenta de servicio que tiene acceso a todo. Así, cualquier usuario puede preguntarle por la nómina, los márgenes o los datos de otro cliente, y el asistente responde porque técnicamente puede. Es una fuga de información con interfaz conversacional.

La regla es que el asistente actúa con los permisos de la persona que pregunta, no con los suyos. Cada llamada a una herramienta viaja con la identidad del usuario, y el sistema de origen aplica sus propias reglas de acceso. Si un vendedor no puede ver el margen de un producto en el ERP, tampoco puede verlo a través del asistente. Por eso los accesos por rol que describimos en gobernanza de datos para empresas medianas son un prerrequisito, no un detalle.

¿Cuándo debe pedir confirmación a una persona?

Siempre que la acción escribe algo o sale de la empresa. Consultar un saldo no requiere aprobación; crear una nota de crédito, cambiar el estatus de un pedido o enviar un correo a un cliente sí. El asistente prepara la acción, la muestra con todos sus datos y espera a que la persona la confirme.

El criterio no es binario. Una acción reversible y de bajo impacto, como agendar un recordatorio interno, puede ejecutarse directo. Una irreversible o con efecto económico necesita confirmación explícita y, en algunos casos, la de alguien con más autoridad que quien pidió la acción. Esa matriz de qué requiere aprobación de quién se define con el dueño del proceso antes de construir.

¿Cómo se sabe si está respondiendo bien?

Con dos piezas que casi nunca aparecen en las demos. La primera es la bitácora: cada conversación queda registrada con la pregunta, las herramientas que se llamaron, los parámetros, los resultados y la respuesta final. Sin eso, cuando alguien reporta un error no hay forma de reconstruir qué pasó ni de distinguir si falló el modelo, la herramienta o el dato de origen.

La segunda es la evaluación continua: un conjunto de preguntas de prueba con respuestas esperadas, construido con el equipo que usa el asistente. Se ejecuta cada vez que cambia algo, sea el modelo, las instrucciones, una herramienta o una fuente de documentos. Si la calidad baja, el cambio no pasa a producción. Sin ella, cada ajuste es una apuesta.

¿Qué pasa cuando algo falla o se dispara el costo?

Un asistente que razona en varios pasos puede entrar en ciclos: llama a una herramienta, no entiende el resultado, vuelve a llamarla, y así sucesivamente. Cada paso consume tiempo y tokens. La arquitectura necesita límites explícitos para que eso no ocurra o, si ocurre, se detenga rápido.

• Número máximo de pasos por solicitud; al alcanzarlo, el asistente explica qué intentó y deriva a una persona.
• Tiempos de espera por herramienta, para que un sistema lento no deje la conversación colgada.
• Límites de consumo por usuario y por día, con alertas antes de llegar a ellos.
• Mensajes honestos cuando falta información: decir que no encontró el dato es mejor que redactar algo plausible.
• Un camino claro para escalar a una persona, con el contexto de la conversación incluido para no empezar de cero.

Para contener el costo, una práctica útil es usar modelos ligeros en tareas simples, como clasificar la intención, y reservar los más capaces para el razonamiento que lo requiere.

¿Por dónde empezar?

Por un caso acotado con dueño y métrica, no por una plataforma general. Un buen primer caso tiene preguntas frecuentes, datos que ya viven en un sistema con API o se pueden exponer con poco esfuerzo, y un equipo que hoy pierde tiempo buscando esa información. Con dos o tres herramientas de lectura, permisos heredados y bitácora desde el primer día, se puede medir si el asistente ahorra tiempo real antes de ampliarlo.

Si el reto es conectar la IA con sistemas que ya operan, sin reemplazarlos, revisa cómo abordamos la integración de IA en sistemas existentes. Y si todavía estás decidiendo qué caso atacar primero, conviene priorizar los casos de uso por impacto, datos disponibles y riesgo.

El modelo es la parte más visible de un asistente de IA y la más fácil de cambiar. Lo que cuesta construir, y lo que protege a la empresa, es todo lo que lo rodea.