Cuando una empresa decide “integrar IA”, el camino más rápido suele ser el mismo: tomar la API de OpenAI, envolver unas llamadas en Python o Node, montar una interfaz y llamarlo producto. En dos semanas tienes algo que impresiona en una demo. En cuatro meses tienes un problema de infraestructura que nadie anticipó.
No es un problema de la API de OpenAI. Es un problema de arquitectura. Y en el mercado B2B de LatAm, donde los equipos de tecnología son pequeños y los presupuestos no perdonan retrabajos, ese error tiene un costo concreto.
Qué hace exactamente un wrapper y dónde se rompe
Un wrapper de ChatGPT, en su forma más común, hace tres cosas: recibe un input del usuario, lo manda a la API con un system prompt fijo y devuelve el output. Sin estado. Sin memoria. Sin lógica de negocio real entre el input y el modelo.
Eso funciona cuando el caso de uso es simple y el volumen es bajo. Un asistente interno que responde preguntas del manual de RH para 8 personas: funciona. El problema aparece cuando el negocio empieza a depender de esa herramienta y el volumen sube.
Los puntos de quiebre más comunes son:
- Rate limits sin manejo: la API de OpenAI tiene límites por minuto y por día. Un wrapper básico no tiene cola de reintentos, así que cuando el límite se alcanza, la herramienta simplemente falla.
- Sin caché semántico: si 30 vendedores hacen variaciones de la misma pregunta sobre el catálogo, el wrapper llama a la API 30 veces. Con caché semántico, la segunda pregunta similar no cuesta un solo token.
- Contexto que no persiste: cada sesión empieza desde cero. Para un chatbot de soporte o un agente que trabaja con historial del cliente, eso hace el producto inútil en la práctica.
- Costos que escalan linealmente: sin optimización, el gasto en tokens crece 1:1 con el uso. Una manufactura en Monterrey con 150 operarios usando una herramienta así puede ver su factura de API multiplicarse por 10 en un trimestre sin que nadie lo haya proyectado.
El patrón que vemos repetirse en proyectos B2B
Lo que estamos viendo en Eurema con empresas medianas de manufactura y servicios profesionales es siempre la misma secuencia: un proveedor entrega un wrapper funcional, la empresa lo adopta internamente, el uso crece, y entre el mes 3 y el mes 6 aparecen dos problemas simultáneos — el costo de la API sube más de lo presupuestado y la herramienta empieza a comportarse de forma inconsistente bajo carga.
En ese punto, la empresa tiene que decidir entre dos opciones malas: pagar por reescribir la arquitectura desde cero o seguir con una herramienta que no escala. Ninguna es barata.
El problema no es que el proveedor inicial haya hecho mal trabajo. Es que un wrapper es la respuesta correcta a la pregunta equivocada. La pregunta correcta no es “¿cómo integro ChatGPT rápido?” sino “¿qué arquitectura sostiene este caso de uso a 12 meses?”.
Qué diferencia un wrapper de software IA con arquitectura real
La diferencia no está en el modelo de lenguaje — puede ser el mismo GPT-4o en ambos casos. Está en las capas alrededor del modelo.
Capa de orquestación: herramientas como LangChain o LlamaIndex, o un orquestador propio, permiten encadenar llamadas, manejar errores con reintentos, enrutar entre modelos según el tipo de tarea y controlar el flujo de la conversación con lógica de negocio real.
Memoria persistente: una base de datos (vectorial o relacional, según el caso) que almacena el historial de sesiones, el contexto del usuario y los documentos relevantes. Esto hace que el sistema recuerde, aprenda del uso y personalice respuestas sin mandar el historial completo en cada llamada.
Caché semántico: antes de llamar a la API, el sistema revisa si ya existe una respuesta suficientemente similar a la pregunta. En casos de uso con preguntas repetitivas — soporte técnico, consultas de inventario, preguntas sobre políticas internas — el caché puede reducir las llamadas a la API en un 40–60%.
Monitoreo de costos por sesión: saber cuánto cuesta cada tipo de interacción permite optimizar prompts, identificar usuarios o flujos que consumen desproporcionadamente y proyectar el gasto con precisión.
El criterio que usamos en Eurema para decidir si un proyecto necesita esta arquitectura desde el inicio es simple: si el caso de uso va a tener más de 20 usuarios activos diarios o va a tocar datos propietarios de la empresa (catálogos, CRM, historial de clientes), la arquitectura robusta no es opcional — es el camino más barato a largo plazo.
El costo real de empezar con un wrapper y migrar después
La migración de un wrapper a una arquitectura escalable no es una actualización — es una reescritura. El código del wrapper no tiene las abstracciones necesarias para agregar orquestación, memoria o caché encima. Hay que partir de cero en la capa de backend.
En proyectos que hemos analizado, el costo de esa reescritura suele estar entre el 80% y el 120% del costo del proyecto original. Es decir, pagas el proyecto dos veces. Más el tiempo perdido y la fricción interna de tener una herramienta inestable durante meses.
La inversión inicial en arquitectura correcta — que en un proyecto típico de Software a la medida toma entre 8 y 14 semanas — se recupera generalmente antes de los 8 meses de operación, considerando solo el ahorro en tokens y el tiempo de ingeniería evitado.
Esto no significa que los wrappers sean siempre un error. Para validar una hipótesis en 2 semanas antes de comprometer presupuesto, son la herramienta correcta. El error es tratarlos como producto final.
Cómo evaluar si tu proyecto actual tiene este problema
Si ya tienes una herramienta de IA corriendo en tu empresa, hay cuatro preguntas que revelan si estás en zona de riesgo:
- ¿Sabes cuánto te cuesta por usuario activo por mes en tokens de API? Si la respuesta es “no exactamente”, la herramienta no tiene monitoreo de costos.
- ¿El sistema recuerda el contexto entre sesiones del mismo usuario? Si no, estás mandando contexto repetido en cada llamada o perdiendo continuidad útil.
- ¿Qué pasa cuando la API de OpenAI tiene un timeout? Si la respuesta es “la herramienta falla”, no hay manejo de errores.
- ¿El proveedor puede mostrarte el costo proyectado a 500 usuarios activos? Si no hay una respuesta con números, el sistema no fue diseñado para escalar.
Tres o cuatro respuestas problemáticas indican que el proyecto necesita revisión de arquitectura antes de escalar, no después.
Si tu empresa está evaluando construir software con IA o ya tiene algo corriendo y quieres entender qué tan sólido es, revisar la arquitectura antes de escalar es el paso que más frecuentemente se salta — y el que más caro sale cuando se omite.