Agentes de IA para empresas: el coste cambia cuando empiezan a actuar
En este artículo usamos una definición operativa: un agente puede ejecutar acciones en tus sistemas, mientras que un chatbot se limita a responder. Esa frontera práctica ayuda a ordenar permisos, pruebas y alcance, pero no es una definición universal. Construirlo no tiene un precio único: depende de los sistemas que toca, las acciones permitidas y las pruebas necesarias.
Por Reynier RiveroIngeniero de software
A las 9:14 de un lunes, una clienta pregunta si puede mover su cita. El sistema consulta la agenda y propone un hueco; cuando recibe aprobación, cambia la reserva. En la misma bandeja, otra persona pregunta por los horarios y recibe la información.
Escena hipotética: no es el relato de una empresa concreta. La primera interacción necesita permiso para escribir en la agenda; la segunda, no.
Si esa barrera falla, no estamos ante una respuesta mal redactada: hay una reserva modificada en otro sistema y un equipo que debe reconstruir qué pasó. La diferencia aparece en la capacidad de actuar y en los controles que la acompañan.
Qué separa un agente de un chatbot
La pregunta importante no es cómo llamarlo, sino qué puede hacer: ¿solo redacta una respuesta o puede usar una herramienta para actuar en un sistema real? No es una frontera universal ni una categoría jurídica; sirve para ordenar esta conversación.
En ese marco, la diferencia se vuelve operativa: crear un pedido, mover una cita o abrir un ticket exige permisos, pruebas y límites concretos. El precio y la responsabilidad también dependen del alcance.
Conviene decirlo porque «agente» se usa para cosas muy distintas. La pregunta que lo resuelve en una reunión es corta: enséñame una acción que ejecute en un sistema real.
Si la respuesta es que no ejecuta ninguna, en este marco lo llamaremos chatbot, y probablemente esté bien. Al no ejecutar acciones, su alcance aquí queda limitado a responder y no modifica tus sistemas directamente.
Cuánto cuesta construir uno
No hay una cifra única, y una cifra aislada sería engañosa. Para estimarlo, conviene mirar el número de sistemas que toca, las acciones que puede ejecutar y el trabajo necesario para preparar contenido, permisos y pruebas.
Un asistente que responde desde tu contenido, en un canal y sin capacidad de cambiar nada, representa el alcance más acotado.
Las acciones reales suelen añadir superficies de diseño y control. Con varios sistemas, idiomas y un panel para soporte, el proyecto puede parecerse más a una plataforma que a una respuesta automatizada.
Un rango de precio sin metodología no ayuda a decidir. Lo que sí conviene publicar es el modelo de estimación, porque se puede comprobar contra tu caso.
Una tarifa por hora, por sí sola, no basta para comparar proveedores: un alcance definido necesita detallar integraciones, acciones, pruebas y mantenimiento. Después del Discovery, lo importante es que el precio se pueda explicar por ese alcance.
| Variable | Efecto en el precio | Por qué |
|---|---|---|
| Sistemas conectados | Suele añadir complejidad | Cada integración suele requerir autenticación, manejo de errores y pruebas |
| ¿Ejecuta acciones? | Puede exigir más diseño y control | Cada acción se define, se prueba y se acota por separado |
| Estado de tu contenido | Puede añadir trabajo de preparación | Si las respuestas solo viven en la cabeza de alguien, hay que escribirlas |
| Canales adicionales | Suelen añadir trabajo de superficie | La lógica puede estar hecha; cambia la forma de usarla |
| Idiomas adicionales | Suelen exigir revisión de contenido | El coste está en adaptar y revisar el contenido |
El modelo no es todo el sistema
El modelo no es el único punto que hay que revisar: también importan la integración y el encaje con el proceso.
Cambiar de modelo no sustituye una decisión previa sobre qué proceso se automatiza, qué acciones se permiten y cómo se mide que funcionó.
Una demo suele enseñar el camino feliz; los casos límite y las integraciones quedan fuera si no los pruebas.
Cómo se demuestra que funciona antes de exponerlo
La forma de demostrarlo es contar con un conjunto de casos representativos escrito antes de construir, un umbral acordado por escrito y verificación por estado del sistema en vez de por el texto de la respuesta. Las buenas prácticas de evaluación de OpenAI recomiendan usar casos representativos y evaluaciones repetibles; su guía para evaluar agentes también pone el foco en llamadas a herramientas, trazas, guardrails y handoffs. Son referencias técnicas del proveedor, no una definición universal ni una garantía de resultado.
Si el agente dice «he reservado tu cita», la prueba correcta es mirar la agenda, no leer la frase.
Nuestro punto de partida, que puedes pedirle a cualquier proveedor, es:
- Un conjunto de preguntas reales, sacadas de tu histórico, con la respuesta correcta escrita al lado.
- Un umbral acordado antes de empezar: qué porcentaje hay que acertar para salir a producción, y qué fallos son inaceptables aunque el porcentaje se cumpla.
- Verificación por estado: se comprueba que la acción ocurrió en el sistema, no que el agente dijo que ocurrió.
- Repetición: la misma pregunta varias veces para detectar variaciones. Si el resultado cambia demasiado, puede ser una señal de inestabilidad que exige investigar.
- Un registro auditable de qué respondió y con qué fuente, para poder reconstruir cualquier conversación después.
Qué revisar antes de exponerlo
Las obligaciones no se resuelven con una etiqueta genérica. Antes de poner el agente delante de una persona, revisa la jurisdicción aplicable, cómo informas de que interviene IA, qué datos procesa, qué acciones puede ejecutar y qué registros conservas.
Si el mismo agente se ofrece en varios países, no des por hecho que una decisión tomada para uno vale para todos. Separa la configuración técnica —aviso, permisos, registros y escalado a una persona— de la decisión jurídica que deba validar un profesional local.
La arquitectura puede preparar esos controles, pero no sustituye la revisión legal del caso concreto.
Quién responde cuando el agente se equivoca
Como criterio operativo, diseña el agente suponiendo que el equipo de la empresa tendrá que explicar de dónde sale cada respuesta y qué ocurrió después. La herramienta no es una excusa para ocultar la fuente ni para borrar el rastro de una acción.
Desde la arquitectura, eso se traduce en citar la fuente de cada respuesta, detenerse cuando no hay una fuente suficiente y conservar un registro útil para reconstruir la conversación.
Qué cuesta mantenerlo vivo
El mantenimiento de un agente no es un adjetivo de propuesta comercial: es un calendario, y las fechas las ponen otros. El plan debe reservar capacidad para revisar contenido, permisos, integraciones, consumo y cambios en proveedores.
Los proveedores pueden cambiar modelos y APIs: OpenAI documenta que había fijado la retirada de la Assistants API para el 26 de agosto de 2026 y Anthropic documenta retiros y recomienda migrar antes de la fecha. Si el modelo o la interfaz de una integración cambia, alguien debe migrarlo y volver a pasar el conjunto de pruebas.
Como escenario de operación, el consumo del modelo puede variar con el volumen, la longitud de las conversaciones y las herramientas que se invocan. La documentación de precios de OpenAI separa tokens, llamadas a herramientas y almacenamiento.
Su documentación de uso expone métricas de solicitudes y tokens, y documenta métricas para algunas herramientas integradas. No extrapolo esas reglas a todos los proveedores.
El alojamiento y los registros también pueden variar según cómo se dimensionen; aquí no se da una tarifa universal. Conviene separarlo del coste de mantenimiento para saber qué parte crece con el uso.
Cuándo no deberías construir uno
Si solo tienes unas pocas conversaciones repetitivas al mes, la aritmética puede no salir: una persona contestándolas puede ser más barata que cualquier cosa que podamos construir. Lo decimos en el Discovery y no cobramos por decirlo.
Si tus preguntas son simples y tu contenido está ordenado, compara primero una herramienta de catálogo bien montada con el alcance de un agente; quizá resuelva el caso con menos superficie.
Cuando el alcance crece, la conversación deja de ser solo sobre el asistente. El coste pasa a estar en la integración, los permisos y la gestión del cambio dentro de tu empresa, y hay que plantearlo como un proyecto de software del que el agente es una parte.
Si quieres evaluar uno, empieza por dibujar el flujo: entrada, sistemas que consulta, acciones que puede ejecutar, punto de aprobación humana, estados que deben comprobarse y registros que deben conservarse. Para profundizar, puedes consultar cómo evaluar un agente de IA. Ese mapa permite decidir si necesitas un chatbot, un agente o una integración más simple; también permite estimar el alcance sin venderte una cifra antes de entenderlo.
¿Puedes señalar qué datos consulta el agente, qué acciones ejecuta y qué ocurre si falla? Si la respuesta no es clara, en Prontavel podemos ayudarte a convertir ese mapa en una arquitectura con permisos acotados, pruebas reproducibles y un plan de mantenimiento. También puedes revisar nuestro enfoque de automatización e integraciones de IA. Esta orientación es general y no constituye asesoramiento legal ni una conclusión de cumplimiento: si el agente opera en varias jurisdicciones, valida las obligaciones aplicables con un profesional local antes de ponerlo en producción. También puedes revisar nuestro servicio de agentes y chatbots para empresas.
Calcula tú mismo el rango
Esto estima cuánto costaría construir y mantener tu proyecto. Cinco preguntas, y cada una enseña lo que suma. Es la misma hoja que usamos en el Discovery, así que puedes comprobar la aritmética en vez de fiarte de un número.
El servicio del que habla este artículo: Chatbots y agentes de IA que sí conocen tu empresa