Por dónde empezar: no por donde empieza todo el mundo
Aquí es donde mejores datos hay, y van justo en contra de la intuición.
Un estudio realizado en el primer semestre de 2025 —52 organizaciones con entrevistas estructuradas, 153 directivos en cuatro congresos del sector y la revisión de más de 300 iniciativas anunciadas públicamente— encontró que, mientras la atención y el dinero van en su mayor parte a ventas y marketing, automatizar los procesos de back office puede dar un retorno más contundente y más sostenible.
Ahorros concretos y medidos de la misma fuente:
| Área | Ahorro |
|---|---|
| Sustituir atención al cliente y procesamiento documental externalizados | de 2 a 10 millones de dólares al año |
| Gasto externo en creatividad y contenidos | una caída del 30 % |
| Gestión de riesgos externalizada en una financiera | 1 millón de dólares al año |
En el lado del front office también hubo resultados —cualificación de leads un 40 % más rápida, una mejora del 10 % en retención de clientes—, pero allí el plazo de retorno fue más largo y el ahorro de costes menos nítido.
(Ese mismo informe contiene la afirmación tan citada de que el 95 % de las organizaciones obtiene cero retorno. Esa cifra está discutida en el sector y hay que leerla junto con la metodología anterior: entrevistas y cuestionarios recogidos en congresos, no datos oficiales de las empresas.)
El primer consejo respaldado por datos es, por tanto: no empieces por la comunicación con el cliente, sino por un proceso interno y repetitivo de back office. Ahí el ahorro es medible, y ahí el cliente no es el conejillo de indias.
Cómprala, no la construyas
El segundo consejo sale del mismo informe y viene con número.
Los pilotos arrancados con un socio externo o con una plataforma ya hecha llegaron al despliegue completo el doble de veces que los desarrollos propios: un 66 % frente a un 33 %.
Así que para una primera automatización conviene elegir una plataforma ya hecha en vez de código propio. No porque el código propio sea malo, sino porque el proyecto tiene el doble de posibilidades de terminarse.
¿Cuánto cuesta en realidad?
Aquí llega la cifra que recoloca la planificación de la mayoría de los principiantes.
Supuesto: una ejecución al día (30 al mes), una llamada al modelo por ejecución, 1.500 tokens de entrada y 400 de salida.
| Modelo | Coste mensual del modelo |
|---|---|
| Un modelo pequeño y barato | 0,02 $ |
| Un modelo intermedio y rápido | 0,11 $ |
| Un modelo potente de precio medio | 0,21 $ |
| Un modelo de gama alta | 0,53 $ |
Y la cuota de la plataforma para esa misma carga: entre 12 y 20 dólares o euros al mes, según el plan.
La cuota de la plataforma está, pues, entre veintitrés y mil veces el coste del modelo. En concreto: con un modelo intermedio y rápido, el modelo cuesta 11 céntimos al mes y el plan de entrada de la plataforma 12 dólares; la plataforma es más de cien veces más cara que la IA misma.
(Cálculo propio con precios de lista de hoy. No incluye reintentos, ejecuciones fallidas ni pruebas, y esto último suele ser la partida mayor durante la puesta en marcha. Y da por hecho que una ejecución es una llamada al modelo: en un agent pueden ser de 3 a 10 llamadas, y entonces hay que multiplicar.)
Cuatro consecuencias:
- A esta escala, la elección del modelo es financieramente irrelevante. Elige el mejor, no el más barato.
- La decisión de verdad es la plataforma. Si solo tienes una automatización, una opción autoalojada con licencia gratuita sale más barata, pero las horas de trabajo de administrarla tú cuestan normalmente más que los veinte dólares ahorrados.
- La cuenta se da la vuelta cuando hay muchas ejecuciones. Con 3.000 ejecuciones al mes en vez de 30, el coste del modelo se multiplica por cien, y a partir de ahí sí importa qué modelo eliges.
- Así que en la primera automatización no te ocupes del precio del modelo.
Las cuatro cosas que lo estropean
La primera: el sistema no aprende. Según el informe citado, el obstáculo principal no es la infraestructura ni el conocimiento técnico, sino que la mayoría de los sistemas no conserva la realimentación, no se adapta al contexto y no mejora con el tiempo. Las causas, en palabras del informe: flujos de trabajo frágiles, ausencia de aprendizaje contextual y desajuste con la operativa diaria.
La segunda: lo que funcionó una vez no funciona siempre. Hay una medición que no mira si la tarea sale bien, sino si sale bien ocho veces de ocho. Los mejores sistemas del momento quedaron por debajo del 25 %. La demostración en la que todo salió bonito una vez no dice nada de la octava ejecución.
La tercera: el volcado de datos «por si acaso». Según un estudio sobre 18 modelos, la salida es cada vez menos fiable a medida que crece la entrada, y un solo elemento que no pinta nada ya empeora el resultado. El error típico del principiante es meterlo todo en el prompt. Eso no es neutral: perjudica.
La cuarta: los límites de plataforma con los que te vas a topar. Son números documentados, no sorpresas:
- En el plan de entrada de una gran plataforma, un flujo de trabajo recibe 320 MiB de memoria, y el propio software gasta de media 180 de ellos. Según la documentación, con un flujo complejo que procesa mucho dato la instancia puede caerse y quedar inaccesible.
- En ese mismo plan, la retención de registros es de 7 días o 2.500 ejecuciones, lo que se llene antes. Un mes después el registro ya no está.
- Y la documentación añade con franqueza que con el disco muy lleno también borran a mano, y que «por los pasos humanos implicados, el sistema de avisos no es perfecto».
¿Qué registrar?
Para esto hay un estándar formal, así que no hay que inventar nada. Deducidas de las convenciones de observabilidad, ocho cosas sin las cuales dentro de un mes no podrás reconstruir qué pasó:
1. QUÉ VERSIÓN DEL PROMPT se ejecutó
El estándar le dedica un campo propio. Es lo que más
se echa de menos cuando falta.
2. QUÉ MODELO RESPONDIÓ
No el que pediste: el que respondió.
3. CUÁNTAS LLAMADAS AL MODELO Y CUÁNTAS A HERRAMIENTAS
Con esto ves si la ejecución se desbocó.
4. CUÁNTOS TOKENS se gastaron
Entrada, salida y caché por separado.
5. POR QUÉ SE DETUVO
¿Terminó, chocó con un límite o falló?
6. EN CASO DE FALLO, LA CLASE DEL ERROR
No su texto. Su clase, para poder contarlo.
7. EL IDENTIFICADOR DE LA CONVERSACIÓN
Sin él los pasos no se pueden encadenar.
8. SI HUBO COMPACTACIÓN DEL CONTEXTO
Si el sistema recortó el historial por detrás,
eso explica el comportamiento raro.
Y una cosa que hay que decidir a conciencia, no por casualidad. El estándar pone los argumentos y el resultado de la llamada a herramienta en una categoría aparte: por defecto no se registran, solo si lo activas expresamente, y añade que pueden contener datos sensibles.
En román paladino: si tratas datos personales, el registro mismo es tratamiento de datos. Eso no es una decisión técnica, sino jurídica.
La receta
1. ELIGE UNA TAREA INTERNA Y REPETITIVA
Que salga al menos cinco veces por semana y que no la
vea ningún cliente. Ahí el retorno es el más rápido.
2. ESCRÍBELA A MANO ANTES DE AUTOMATIZARLA
Si no la sabes escribir, la máquina tampoco sabrá hacerla.
3. PLATAFORMA YA HECHA, NO CÓDIGO PROPIO
El doble de posibilidades de que lo termines.
4. UNA SEMANA QUE SOLO PROPONGA, QUE NO ACTÚE
Mira a diario qué habría hecho. Es la única manera
de saber si la octava ejecución también sale bien.
5. REGISTRA SEGÚN LOS OCHO PUNTOS
Y mira cuánto tiempo lo guarda tu plataforma.
Siete días es poco.
6. QUE HAYA UN BOTÓN DE PARADA
Un interruptor que lo detenga. Que no haya que
buscarlo cuando hace falta.
El cuarto punto es el más importante y es el que más gente se salta. Una semana en modo «solo propone» mide exactamente lo que la demostración no mide: la fiabilidad en la repetición.
Malentendidos habituales
- «Empecemos por la comunicación con el cliente, ahí se ve antes.» Las mediciones dicen que en los procesos de back office el retorno es más rápido y el ahorro más limpio, y aun así el dinero va al otro lado.
- «Construyámoslo nosotros, lo entenderemos mejor.» Los pilotos de desarrollo propio llegaron al despliegue completo la mitad de veces que los montados sobre una plataforma ya hecha.
- «El modelo va a salir caro.» Con una ejecución diaria, el modelo cuesta unos céntimos al mes. La cuota de la plataforma es la partida varios órdenes de magnitud mayor.
- «En la demostración funcionaba.» El éxito aislado y el éxito ocho de ocho veces son dos métricas distintas, y en la segunda los sistemas son mucho más flojos.
- «Démosle cuantos más datos mejor.» Un solo elemento que no pinta nada ya empeora el resultado de forma medible.
- «Luego lo miramos en el registro.» Si tu plan lo guarda siete días, dentro de un mes no habrá nada que mirar.
Lo que conviene llevarse
En una primera automatización cuentan tres decisiones, y la elección del modelo no está entre ellas.
La tarea: interna, repetitiva y sin contacto con el cliente: ahí el beneficio es medible. La plataforma: una solución ya hecha, porque así tienes el doble de posibilidades de terminar. La prueba: una semana en modo «solo propone», porque un éxito aislado no es prueba.
Y una cuarta, que hay que resolver sobre la marcha y no después: qué registras y cuánto tiempo lo guardas. Eso decide si dentro de un mes podrás decir qué pasó y, en ámbito del RGPD, incluso si te está permitido hacerlo.
Qué plataforma conviene elegir y por qué la unidad de facturación es el núcleo de la decisión lo cuenta con precios el post las plataformas no-code , una por una; de la fiabilidad de las ejecuciones largas y de varios pasos se ocupa el post la matemática de la fiabilidad , con números. Y si el sistema que quieres automatizar no ofrece API alguna, el artículo browser y computer use agents te dice cuándo merece la pena aun así.