Conectar un modelo de lenguaje a tu producto es bastante más simple de lo que la gente asume técnicamente, y bastante más complicado de lo que asume en todo lo demás: costos, latencia, seguridad y comportamiento.
Las tres formas de integrarlo
Llamada directa a la API. Tu servidor le manda un mensaje al modelo y recibe una respuesta. Es la base de todo lo demás y sirve para tareas puntuales: clasificar un mensaje entrante, generar un resumen, redactar un borrador.
Consulta sobre tus propios documentos (RAG). El patrón más útil para la mayoría de los negocios. En vez de esperar que el modelo “sepa” sobre tu empresa, buscas los fragmentos relevantes en tus documentos y se los pasas junto con la pregunta. El modelo responde basándose en eso.
Resuelve los dos problemas grandes de golpe: el modelo no conoce tu información, y cuando no la conoce la inventa. Con esto responde solo sobre lo que le diste, y puedes mostrar de qué documento salió cada respuesta.
Agente con herramientas. El modelo puede invocar funciones de tu sistema: consultar un pedido, agendar, calcular. Es lo más potente y lo más difícil de hacer bien.
Para la enorme mayoría de los casos de una pyme, el segundo patrón es la respuesta correcta.
El error de arquitectura que más caro sale
Nunca pongas tu clave de API en el navegador. Parece obvio y pasa constantemente.
Si el código que llama al modelo corre en el frontend, tu clave viaja al navegador de cada visitante y cualquiera puede extraerla del código o de las peticiones de red. A partir de ahí, cualquiera puede usar tu cuenta hasta agotar tu presupuesto. Hay gente que descubrió esto con una factura de varios miles de dólares.
La arquitectura correcta es siempre: navegador → tu servidor → API del modelo. La clave vive solo en el servidor, como variable de entorno.
Los tres controles que necesitas desde el día uno
Límite de uso por usuario. Sin esto, una sola persona —o un script— puede consumir tu presupuesto mensual en una tarde. Limita por sesión, por IP o por cuenta, con un tope diario.
Tope de gasto configurado en el proveedor. Todas las plataformas permiten fijar un límite duro y alertas. Configúralo antes de publicar, no después del susto.
Registro de todo. Guarda cada consulta, cada respuesta y cuántos tokens consumió. Es lo único que te permite entender el costo real, detectar abuso y mejorar el sistema.
Cómo se calcula el costo
Se cobra por token, que es aproximadamente tres cuartos de una palabra en español. Se paga tanto lo que envías como lo que recibes, y lo que envías suele ser lo grande: si en cada consulta mandas el historial completo de la conversación más cinco fragmentos de documentos, la entrada pesa mucho más que la respuesta.
Tres formas concretas de bajar la cuenta:
Usa el modelo más chico que resuelva la tarea. Clasificar un mensaje en cinco categorías no necesita el modelo más potente. La diferencia de precio entre gamas es grande.
Corta el historial. Mandar toda la conversación en cada mensaje hace que el costo crezca cuadráticamente. Resume lo anterior o quédate con los últimos intercambios.
Cachea lo repetido. Si la misma pregunta se hace muchas veces, guarda la respuesta. Además, varios proveedores ofrecen descuentos importantes cuando el inicio del prompt se repite entre llamadas: ordena tu prompt poniendo lo fijo al principio y lo variable al final.
La latencia y qué hacer con ella
Una respuesta puede tardar varios segundos. En una interfaz, eso es una eternidad.
La solución estándar es streaming: mostrar la respuesta palabra por palabra a medida que se genera. No es más rápido, pero la percepción cambia por completo porque el usuario ve movimiento inmediato.
Para tareas que no son conversacionales —procesar un documento, generar un informe— no bloquees la interfaz: encola el trabajo y avisa cuando esté listo.
Seguridad: dos cosas que hay que asumir
Los usuarios van a intentar manipular tu sistema. Van a pedirle que ignore sus instrucciones, que revele su prompt, que hable de cualquier otra cosa. No existe una defensa perfecta. Lo que sí funciona es diseñar asumiendo que puede pasar: que el sistema no tenga acceso a nada que no debería exponerse aunque se lo pidan, y validar las salidas antes de usarlas para algo consecuente.
Nunca ejecutes directamente lo que devuelva el modelo. Si genera una consulta a base de datos, un comando o código, tiene que pasar por validación. Trata la salida del modelo como entrada de usuario no confiable, porque en la práctica lo es.
Qué hace falta para empezar
Menos de lo que parece. Un endpoint en tu servidor, la clave en variable de entorno, límites de uso, y registro. Con eso ya puedes tener una primera versión andando y aprender de uso real.
Lo que no conviene es construir la versión ambiciosa antes de saber qué preguntan realmente tus usuarios. Esa información no se puede adivinar y cambia todo el diseño.
Esto es el contenido del curso de integración de IA en web y móvil de VanttAcademy. Y si prefieres que lo implementemos nosotros en tu producto, escríbenos.