Agentes de IA en LatAm: costos y frenos

La conversación sobre agentes de IA ya no gira solo alrededor de lo que pueden hacer, sino de lo que cuesta ponerlos a trabajar dentro de una empresa real. La encuesta de Numoru sobre el estado de los agentes de IA en empresas de Latinoamérica en 2026 deja una señal bastante clara: el interés existe, pero la adopción sigue frenada por tres cosas muy concretas, integración con sistemas existentes, costos de inferencia y dudas sobre el ROI.

Si tú trabajas en producto, tecnología o innovación, esto te suena familiar. El piloto arranca rápido, el demo impresiona, pero cuando toca conectarlo con CRM, ERP, data warehouse, flujos de aprobación y controles de seguridad, la historia cambia. Y si además cada interacción del agente consume tokens y modelos externos, el presupuesto empieza a doler antes de que el negocio vea resultados medibles.

Lo que esta encuesta pone sobre la mesa

La encuesta de Numoru sirve porque aterriza una discusión que muchas veces se queda en opinión. En empresas latinoamericanas, los agentes de IA no están chocando con una sola barrera, sino con una combinación de fricciones operativas y financieras. El resultado es bastante predecible: hay experimentación, pero poca escalabilidad.

La primera lectura útil es que la adopción no depende solo de la calidad del modelo. Depende de si el agente puede operar sobre datos confiables, respetar permisos, consultar sistemas internos y devolver respuestas útiles sin romper procesos ya existentes. En otras palabras, el problema no es “si responde bien”, sino “si responde bien dentro de tu stack”.

La segunda lectura es económica. Un agente que consulta varias fuentes, hace tool calling, resume contexto largo y ejecuta más de una inferencia por tarea puede multiplicar costos rápido. Para una empresa grande en México, Colombia, Chile o Ecuador, eso no es un detalle técnico: es una línea en el presupuesto que compite con licencias, nube, soporte y desarrollo.

Por qué importa el contexto LatAm

Latinoamérica tiene una realidad distinta a la de los mercados donde nacen muchos productos de IA. Hay más heterogeneidad de sistemas legados, más variación en madurez digital y, en muchos casos, más presión por justificar cada dólar invertido. Eso hace que un caso de uso que en Estados Unidos se aprueba con facilidad aquí pase por más comités, más validación y más preguntas sobre seguridad y retorno.

También hay una diferencia en cómo se compra tecnología. En muchas empresas de la región, la decisión no la toma solo tecnología. Participan finanzas, legal, operaciones y negocio. Si el agente toca datos sensibles o procesos críticos, la adopción se vuelve un proyecto transversal, no un experimento aislado.

Por eso esta encuesta no se lee como una lista de obstáculos técnicos, sino como una radiografía de madurez empresarial. Los agentes de IA sí interesan, pero todavía no se compran como una pieza estándar de software. Se evalúan como una apuesta que puede ahorrar horas, pero también puede sumar complejidad y gasto si se implementa mal.

Integración: el freno más repetido

La integración aparece como el primer gran cuello de botella porque un agente útil no vive solo en el chat. Tiene que leer tickets, consultar inventario, revisar políticas, abrir casos, escribir en un CRM, disparar workflows y, en algunos casos, pedir aprobación humana. Si no puede hacer eso, termina siendo una interfaz bonita sobre datos incompletos.

En empresas latinoamericanas esto pega más fuerte por dos razones. La primera es la coexistencia de sistemas viejos con plataformas nuevas. La segunda es que muchas integraciones no están bien documentadas, o dependen de equipos pequeños que ya tienen demasiadas prioridades. El resultado es que el proyecto de IA se convierte en un proyecto de integración, y eso cambia plazos y costo total.

El problema no es el modelo, es el sistema

Un agente de IA empresarial rara vez falla por no entender lenguaje natural. Falla porque no tiene acceso al dato correcto, porque el permiso está mal configurado o porque el sistema destino no expone una API limpia. Ahí es donde la promesa se vuelve operativa: necesitas autenticación, observabilidad, trazabilidad y manejo de errores.

Piensa en un caso simple: un agente de soporte que debe responder sobre estado de pedidos. Si el agente consulta tres sistemas distintos, uno de ellos tarda 4 segundos, otro devuelve datos incompletos y el tercero requiere validación manual, la experiencia ya no es fluida. El usuario no percibe IA, percibe demora.

En la práctica, muchas empresas terminan haciendo una versión muy limitada del agente para evitar esa complejidad. Eso no está mal, pero sí cambia la expectativa. Si el caso de uso inicial solo resuelve una parte del proceso, entonces el valor también será parcial. Y si el valor es parcial, el ROI tardará más en aparecer.

Qué suelen pedir los equipos de TI

Antes de aprobar un agente, los equipos técnicos suelen pedir al menos estas piezas:

1. Control de acceso por rol y trazabilidad de cada acción.
2. Conectores estables con CRM, ERP, help desk o bases de conocimiento.
3. Logs para auditar qué consultó el agente y qué respondió.
4. Mecanismos de fallback cuando una herramienta externa falla.
5. Límites claros para evitar que el agente ejecute acciones no autorizadas.

Ese checklist no es burocracia vacía. Es lo que separa una demo de una implementación que puede ir a producción. Si tú no resuelves esto desde el inicio, el proyecto se queda atrapado entre el entusiasmo del negocio y la cautela de infraestructura.

Costos de inferencia: la factura que nadie quiere subestimar

El segundo gran freno es el costo de inferencia. Y aquí conviene hablar claro: un agente de IA no consume como una consulta puntual a un chatbot. Puede consumir varias llamadas al modelo por tarea, usar contexto largo, recuperar documentos, reintentar respuestas y ejecutar herramientas externas. Todo eso suma.

En un piloto pequeño, ese gasto parece manejable. Pero cuando escalas a cientos o miles de interacciones al día, la cuenta cambia. Si además usas modelos premium para tareas que podrían resolverse con modelos más livianos, el costo por tarea sube sin que el usuario final lo note demasiado.

Dónde se va el dinero

El gasto no está solo en “preguntar al modelo”. Se va en varios puntos:

• Context windows más grandes para mantener conversaciones largas.
• Retrieval augmented generation con búsquedas sobre bases internas.
• Reintentos cuando la salida no cumple el formato esperado.
• Tool calling hacia APIs internas o externas.
• Monitoreo, logging y evaluación continua.

Si tú sumas todo eso, el costo real por caso de uso puede ser bastante más alto que el precio nominal del modelo. Por eso muchas empresas se sorprenden después del piloto. El demo parecía barato; la operación a escala, no tanto.

La documentación oficial de OpenAI sobre pricing y modelos es un buen punto de partida para entender cómo cambian los costos según el tipo de uso: https://openai.com/api/pricing/. Para arquitecturas que usan tool calling, también conviene revisar la documentación oficial de funciones y herramientas: https://platform.openai.com/docs/guides/tools.

Cómo se controla el costo sin matar el caso de uso

No necesitas apagar la ambición para controlar gasto. Lo que sí necesitas es diseñar con restricciones desde el día uno. Una estrategia útil es separar tareas por complejidad. No todo requiere el modelo más caro ni el contexto más largo.

Por ejemplo, puedes usar un modelo más liviano para clasificación, enrutamiento y borradores, y reservar un modelo más robusto para casos complejos o de mayor riesgo. También puedes limitar el número de pasos por tarea, cachear respuestas frecuentes y reducir contexto innecesario.

Un enfoque práctico es medir el costo por resultado, no solo por interacción. Si un agente reduce 15 minutos de trabajo humano en un proceso que se repite 2.000 veces al mes, el costo de inferencia deja de verse aislado y pasa a compararse con ahorro operativo real. Ahí empieza la conversación seria sobre eficiencia.

ROI: la pregunta que define si el proyecto sigue

El ROI es el tercer freno porque, en empresas latinoamericanas, nadie quiere financiar una iniciativa que solo produce entusiasmo interno. Los agentes de IA tienen que demostrar ahorro, velocidad, menos errores o mejor conversión. Si no puedes conectar el proyecto con una métrica concreta, el presupuesto se enfría.

El problema es que muchas iniciativas se venden como “mejor experiencia” o “más productividad” sin una línea base clara. Eso complica todo. Si no sabes cuánto tarda hoy un proceso, cuántos casos resuelve un agente humano o cuántos errores hay por mes, no tienes con qué comparar.

Cómo medir retorno sin engañarte

Una forma sensata de medir ROI es elegir una sola métrica principal por caso de uso. No intentes medir diez cosas a la vez. Si el agente es para soporte, mide tiempo de resolución. Si es para ventas internas, mide tiempo de respuesta a leads o calidad de calificación. Si es para operaciones, mide reducción de retrabajo.

También conviene separar ahorro directo de beneficio indirecto. El ahorro directo se ve en horas, tickets o costos de outsourcing. El beneficio indirecto puede ser mejor experiencia, más velocidad de respuesta o menos rotación de personal por tareas repetitivas. Ambos importan, pero no pesan igual cuando finanzas revisa el caso.

Una fórmula simple para aterrizarlo es esta:

ROI aproximado = (beneficio mensual - costo mensual total) / costo mensual total

El punto clave está en el costo mensual total. Ahí debes sumar inferencia, infraestructura, mantenimiento, integración y supervisión humana. Si solo miras la licencia del modelo, tu cálculo queda corto.

Qué hace que el ROI tarde más de lo esperado

Hay tres causas comunes. La primera es que el caso de uso no tenía suficiente volumen. La segunda es que el proceso estaba tan mal definido que el agente solo automatizó una parte pequeña. La tercera es que el equipo subestimó el costo de mantenimiento, que no termina con el lanzamiento.

Esto pasa mucho en organizaciones que quieren empezar por un caso muy visible, pero no necesariamente repetitivo. Un agente para una tarea rara puede verse bien en demo, pero no mover la aguja financiera. En cambio, un flujo de alto volumen y baja complejidad suele dar mejores resultados, aunque sea menos glamoroso.

En empresas de Ecuador, por ejemplo, donde los presupuestos suelen ser más vigilados y cada proyecto compite con prioridades operativas, el ROI necesita verse rápido y con datos. Si el piloto no deja una mejora medible en semanas o pocos meses, se vuelve difícil escalarlo.

Qué sí están haciendo las empresas que avanzan

Las empresas que sí logran mover agentes de IA hacia producción no están apostando por magia, sino por foco. Empiezan con un caso de uso acotado, integran lo mínimo necesario, ponen métricas desde el inicio y aceptan que el primer despliegue no será perfecto.

Eso no significa ir lento. Significa no intentar resolver toda la operación con un solo agente. Muchas veces funciona mejor un conjunto de agentes o asistentes especializados que un superagente que pretende saberlo todo. Menos ambición por versión, más claridad por proceso.

Un plan de implementación más realista

Si tú estás evaluando agentes de IA en tu empresa, este orden suele ser más sensato:

1. Elige un proceso repetitivo con volumen suficiente y dolor claro.
2. Define una métrica base antes de tocar la tecnología.
3. Identifica las integraciones mínimas necesarias, no todas las posibles.
4. Prueba con un modelo y una arquitectura simples.
5. Mide costo por tarea, no solo precisión.
6. Agrega controles humanos para casos sensibles.
7. Revisa resultados con negocio y finanzas antes de escalar.

Ese enfoque reduce la probabilidad de un piloto bonito pero inútil. También te ayuda a responder la pregunta que más importa: ¿esto ahorra dinero, tiempo o errores de una forma que vale la pena sostener?

Lo que conviene evitar

Hay errores que se repiten en casi todas las regiones, pero en LatAm pegan más por el contexto presupuestario. El primero es empezar por un caso de uso demasiado complejo. El segundo es no involucrar a seguridad y legal desde el inicio. El tercero es dejar la evaluación para el final.

Otro error común es asumir que el modelo resolverá mala documentación interna. No la resuelve. Si tu base de conocimiento está desordenada, el agente solo amplifica ese desorden. Antes de escalar, conviene limpiar fuentes, normalizar campos y definir quién es dueño de cada dato.

Tabla resumen

La encuesta de Numoru no dice que los agentes de IA estén condenados a quedarse en piloto. Dice algo más útil: que todavía no se están comprando con la lógica correcta. Si tú los evalúas como una capa más de software, subestimas integración. Si los evalúas solo por demo, subestimas costo. Y si no defines retorno desde el inicio, subestimas la paciencia del negocio.

Lo más valioso de este momento en Latinoamérica es que ya no basta con preguntar si la IA puede hacer algo. La pregunta correcta es si puede hacerlo dentro de tu operación, con tus sistemas, con tus restricciones y con un costo que tenga sentido. Ahí es donde se decide si el proyecto avanza o se queda en presentación.