Cuando un agente de IA tarda más de la cuenta en responder, casi todo el mundo mira primero al modelo: que si hay que probar otro, que si hay que pagar el plan más caro, que si hace falta un modelo "más rápido". En dos aplicaciones internas de AutoBoost la lentitud no tenía nada que ver con el modelo. Tenía que ver con dónde vivía el código y con cuánto dato le mandábamos de golpe a una pantalla. Dos causas que no salen en ningún registro de errores porque, técnicamente, nada falla: todo simplemente va más lento de lo que debería.
Si tu agente de IA (o cualquier aplicación que dependa de una base de datos) va lento sin motivo aparente, antes de tocar el modelo revisa estas dos cosas.
Causa 1: el código vive lejos de su propia base de datos
Tres aplicaciones internas de AutoBoost llevaban meses corriendo su código en una región de nube en Estados Unidos, mientras que la base de datos a la que consultaban vivía en Europa. El resultado: cada consulta, sin excepción, tenía que cruzar el Atlántico de ida y de vuelta antes de poder devolver una respuesta. Nada estaba roto. No había ningún error en ningún panel. Simplemente, cada petición llevaba pegado un peaje de distancia que nadie había medido.
Se diagnosticó mirando una sola cosa: en qué región corre el código de cada aplicación frente a en qué región vive la base de datos que usan las tres. Al moverlas a la misma región, el peaje desapareció. Las tres se corrigieron el mismo día, sin tocar ni una línea de lógica de negocio.
Esto es exactamente lo que le pasa a un agente de IA que consulta tu ERP, tu CRM o tu base de datos de inventario para responder: cada llamada que hace (comprobar stock, validar un cliente, mirar una tarifa) es un viaje de ida y vuelta a esos datos. Si el agente corre en un proveedor de nube distinto, en una región distinta, de donde vive tu sistema real, estás pagando ese peaje en cada respuesta, aunque el modelo sea instantáneo.
La pregunta que hay que hacerle a tu proveedor de IA no es solo "qué modelo usáis". Es "dónde corre el código que llama a mi sistema, y dónde vive mi sistema".
Causa 2: la pantalla que alimenta al agente manda todo de golpe
La segunda causa es menos sobre el agente y más sobre lo que lo rodea, pero pega igual de fuerte en la experiencia de quien lo usa. Una pantalla interna de AutoBoost (el histórico de jornadas registradas de un cliente) enviaba todo el historial completo en una sola carga. Cuanto más tiempo llevaba activo un cliente, más jornadas tenía acumuladas, y más lenta se volvía justo su propia pantalla: el cliente más antiguo, el más fiel, era quien peor lo sufría.
El cambio fue simple: cargar un primer bloque y pedir el resto solo si hace falta, con un botón de "mostrar más", sin perder los totales del filtro aunque no esté todo cargado todavía. En números: de 93 registros cargados de golpe a 40 por tanda, y el peso de esa pantalla bajó de 179 KB a 74 KB.
La misma lógica aplica a cualquier pantalla o respuesta que alimenta a una IA con contexto: si le mandas todo el histórico de un cliente para que "tenga contexto", cuanto más crece ese cliente, más lenta (y más cara, si pagas por tokens) se vuelve cada respuesta. Paginar o resumir no es una optimización prematura. Es evitar que crecer sea, literalmente, un castigo de rendimiento para tu mejor cliente.
Checklist: antes de culpar al modelo
| Síntoma | Qué comprobar | Qué NO hacer todavía |
|---|---|---|
| El agente tarda en cada respuesta, de forma constante | Región de la nube donde corre el agente frente a región donde vive tu base de datos o tu ERP | Cambiar de modelo o de proveedor de IA |
| Va más lento con los clientes más antiguos o con más datos | Cuánto histórico le mandas de golpe al agente como contexto | Subir el plan de pago por tokens |
| Va lento solo en una pantalla o un flujo concreto | Si esa pantalla pagina o manda todo de una vez | Reescribir toda la integración desde cero |
| Va lento en todas partes, incluso con poco dato | Ahí sí, revisa el modelo y el proveedor | - |
La regla de decisión es corta: si la lentitud crece con el tamaño del dato o con la distancia a tu sistema, no es el modelo. Si es lenta incluso con una consulta pequeña y sin histórico de por medio, entonces sí toca mirar el modelo.
Por qué esto no sale en ningún panel de errores
Lo incómodo de las dos causas de arriba es que ninguna da error. El sistema responde, solo que tarde. No hay ninguna alarma roja que avisar porque, en sentido estricto, nada falla: la consulta vuelve, el dato es correcto, solo que tres segundos después de lo que debería. Es el mismo tipo de problema silencioso que ya hemos contado en otros fallos reales: lo que no rompe nada no genera ningún aviso, y sin un aviso, nadie mira.
Por eso la revisión no puede depender de "si algo va mal, saltará un error". Tiene que ser una pregunta que te hagas tú, activamente, cuando notes que tu agente de IA "va lento" sin más explicación: ¿dónde corre, respecto a dónde vive tu dato? ¿Cuánto le estás mandando de golpe?
Dónde se nota esto de verdad
En un agente que solo responde preguntas desde un chat, unos cientos de milisegundos de más pasan casi desapercibidos. En un agente que trabaja en tiempo real con un cliente al otro lado, como el comercial de IA que cotiza por WhatsApp dentro del ERP de una distribuidora industrial (caso completo), cada peaje de distancia se nota en cada mensaje: validar cliente, comprobar stock, aplicar tarifa y crear la oportunidad son varias llamadas seguidas, y si cada una cruza un océano de más, el cliente lo percibe como un comercial lento, no como una IA.
Si tu empresa ya tiene (o está evaluando) un agente de IA conectado a tu sistema real, estas dos preguntas (dónde corre frente a dónde vive tu dato, y cuánto contexto le mandas de golpe) son parte del mismo trabajo de integración que hacemos en AutoBoost antes de dejar que un agente toque datos de producción: ver más en /servicios.
Si notas que tu agente de IA va lento y no sabes por cuál de las dos causas es, cuéntanos tu caso y lo revisamos contigo.
