¿Cuánto cuesta implementar un agente de IA en un SaaS?

La inversión de añadir un agente a un SaaS no es el precio del modelo. Es un TCO (coste total de propiedad): lo que cuesta desplegarlo y operarlo, partido en cinco líneas y medido por acción exitosa.

No hay un precio cerrado para un agente de IA en un SaaS. Hay un TCO, y ese número se parte en cinco líneas y se mide por acción exitosa: si el coste de una acción supera el valor que genera, el caso no entra.

El error más caro no es elegir mal el modelo, sino presupuestar solo tokens. Tres meses después, el 70% del gasto suele estar en ingeniería, operaciones y el tiempo de gente que ya tenía roadmap.

El precio del modelo no es el TCO

Cuando alguien pregunta cuánto cuesta integrar IA en un SaaS, casi siempre enseña una hoja con tarifas de API. Esa hoja sirve, pero no responde a la pregunta: el modelo es la partida más visible y, en muchos casos, también la más pequeña.

Una demo de un fin de semana cuesta poco. Llevar ese mismo flujo a un producto multi-tenant (varias cuentas de cliente, con permisos, trazas, límite de coste y alguien de guardia) cambia el orden de magnitud, no porque el modelo se encarezca de golpe, sino porque aparece el sistema alrededor. Lo contamos en el checklist de demo versus producción. Aquí nos quedamos con la factura. Por qué el precio por token no es el coste del agente lo desglosamos aparte.

Esos costes se leen en tres números, cada uno con un dueño distinto.

Coste de modelo. Tokens de entrada, salida, caché y tool calls (cada vez que el agente llama a una API o a una herramienta). Lo ve Finanzas en la factura del proveedor. Cambia cada trimestre. Se puede recortar con un modelo más pequeño, caché y menos contexto.

Coste de sistema. Identidad, permisos por tenant, observabilidad, evaluación, colas, reintentos, rollback. Lo ve Ingeniería. No aparece en la tarifa de la API, y es lo que decide si el agente escala o se queda en piloto.

Coste de decisión. Horas de CEO, CTO, legal y producto para aprobar el caso, definir el riesgo aceptable y decidir si se construye o se compra. Cada mes de limbo es un mes sin aprender.

Si el business case solo tiene la primera línea, no es un business case: es un presupuesto de tokens.

Las cinco partidas que tienes que poner en la hoja

Antes de pedir un número a un vendor o a tu equipo, escribe estas cinco líneas. Si alguna queda en blanco, el TCO está incompleto.

1. Modelo y ejecución. Precio por millón de tokens, caché, embeddings si hay RAG (recuperar documentos para dárselos al modelo como contexto), y sobre todo tool calls. Cada vez que el agente toca tu API, un MCP (un protocolo para conectar el agente con herramientas) o un sandbox, pagas inferencia más infra. Revisa las tarifas públicas de los proveedores como suelo, no como tope. El precio real sube con reintentos, contexto largo y modelos de razonamiento.

2. Ingeniería de producto. Convertir tu API en herramientas, inyectar contexto por tenant, definir permisos y montar el harness (la capa que ejecuta, limita y observa al agente). No es un intern y un fin de semana: es el trabajo que hace que el agente hable con tu SaaS y no con un PDF genérico.

3. Operación y calidad. Trazas, evaluación, datasets de regresión, alertas, guardia. Un agente sin medición es un coste variable sin freno. Aquí decides si puedes bajar de modelo o si estás operando a ciegas.

4. Riesgo y soporte. Errores que llegan a cliente, tickets, cumplimiento (RGPD y AI Act), revisión humana en los flujos que escriben. El coste no es solo una indemnización hipotética: es el tiempo de Customer Success y el desgaste de marca.

5. Coste de oportunidad. Lo que deja de hacer el equipo mientras construye el agente. Si el roadmap de producto ya va justo, hacerlo in-house no es gratis: es posponer lo que hoy paga las nóminas.

La investigación de entrega de software de DORA lleva años diciendo lo mismo: el rendimiento no lo marca la herramienta que compras, sino las capacidades de entrega del equipo. Con agentes, esa frase se traduce a euros por mes.

Inversión inicial: lo que pagas antes de que el agente toque un cliente

El coste de implementar un agente de IA no empieza cuando el usuario abre el chat. Empieza cuando alguien decide qué caso merece producción.

En un SaaS B2B típico, la inversión inicial se parece a esto. Son rangos, no presupuestos cerrados. El extremo bajo asume un caso estrecho y un equipo que ya tiene APIs limpias.

Descubrimiento y recorte de alcance (1-3 semanas). Elegir un flujo con valor medible, definir qué cuenta como éxito y decidir qué no hará el agente. Sale barato en dinero y caro si lo saltas, porque un alcance abierto multiplica el resto.

Integración con tu producto (2-8 semanas). Exponer endpoints como tools, autenticación por tenant, contexto real, límites. Si tu API ya es coherente, vas al extremo bajo. Si el agente tiene que "entender la empresa" a base de prompts, vas al alto.

Capa de producción (2-6 semanas, en paralelo o después). Logs, costes por ejecución, evaluación mínima, límite de gasto, rollback. Es el trabajo que la demo no enseña, y el que evita la sorpresa en la factura.

Personas. Un perfil de platform o AI engineering a tiempo parcial o completo, más horas de producto y de alguien que conozca el dominio. El salario no entra en la slide del vendor: entra en la tuya.

Horquilla útil para un comité: montar el primer agente usable en producto suele estar entre unas pocas semanas de un perfil senior y un trimestre de un equipo pequeño, más el gasto de modelo de las pruebas. El POC (prueba de concepto) de 5.000 € y dos sábados existe, y casi nunca es el sistema que quieres poner delante de un cliente.

Si el caso es un asistente de lectura sobre documentación interna, el inicial se comprime. Si el agente escribe en el tenant del cliente (crea objetos, cambia estados, lanza workflows), el inicial se estira, y debe estirarse.

Coste recurrente: tokens, tool calls y gente de guardia

El gasto mensual no es una licencia plana. Es volumen por complejidad por calidad exigida.

Modelo. Un turno de conversación simple, con poco contexto y un modelo ligero, puede costar céntimos de dólar o menos. El mismo turno con historial largo, RAG, un modelo de razonamiento y cinco tool calls se va a decenas de céntimos o a más de un dólar. Multiplica por conversaciones al mes. Deja de ser "el coste de la IA" y pasa a ser una línea de COGS (coste de lo vendido: lo que te come el margen por cada cliente).

Tool calls. En producto, el agente no solo habla: llama. Cada llamada a tu API consume tokens de orquestación. Si hay sandbox o conectores, también infra. Por eso medimos por tool call y no solo por token: es la unidad que se parece a una acción de producto.

Observabilidad y evaluación. Retener trazas, correr evals, mantener un dataset de regresiones. Sale barato al principio y crece cuando quieres detectar fallos antes que el cliente. Recortar aquí ahorra hoy y paga incidentes mañana.

Personas de operación. Alguien mira fallos, ajusta prompts, decide cuándo cambiar de modelo y atiende el caso que se salió del carril. Aunque sea un 20% de un perfil, es recurrente. Si nadie lo tiene en el organigrama, el coste aparece igual: en el Slack de madrugada del CTO.

Regla práctica: si no puedes decir cuánto te cuesta una acción exitosa esta semana, no tienes TCO, tienes una factura que aún no has leído.

Unit economics: cuánto puedes permitirte por conversación

El business case no se aprueba con un total anual. Se aprueba con una desigualdad.

Coste por acción exitosa < valor capturado por esa acción × tasa de éxito.

Ejemplo, sin inventar un cliente. Un agente que resuelve un ticket de soporte de 12 € de coste interno. Si acierta el 70% de las veces y el 30% restante lo escala a humano (con el coste del humano más el del intento fallido), el coste combinado tiene que seguir por debajo de esos 12 €. Si el modelo solo ya se come 2 € por conversación y encima hay reintentos, el problema no es que "la IA es cara": es que ese flujo aún no debería ser autónomo.

Tres palancas que sí controlas.

Recortar el alcance. Menos tools, menos contexto, menos libertad para divagar. El agente más barato es el que hace una cosa.

Bajar de modelo cuando la evaluación lo permite. El modelo grande es para el 10% de turnos difíciles, no para saludar. Sin evaluación no te atreves a bajar, y entonces pagas el premium para siempre.

Poner un límite. Tope por tenant, por hilo y por día. Un bucle de reintentos sin tope convierte un céntimo en una factura. Lo hemos visto más veces de las que nos gusta admitir.

Si vendes un SaaS con margen bruto del 70-80%, un agente que añade 15 puntos de COGS en el segmento donde lo enciendes no es innovación: es una decisión de precio. O subes precio, o eliges un flujo donde el valor por acción es más alto, o no lo enciendes en todos los planes.

Un business case que un CEO puede firmar

Para el comité caben una página y cuatro números. Sobran las slides de "potencial de la IA".

1. Caso y métrica. Qué flujo, qué acción cuenta como éxito, quién es el usuario. Si no cabe en una frase, no está listo para presupuestar.

2. Inversión inicial. Semanas de ingeniería más coste de pruebas. Incluye el trabajo de producción, no solo el prototipo.

3. Coste recurrente a volumen. Tres escenarios: 1.000, 10.000 y 100.000 acciones al mes. En cada uno, modelo + operación + soporte. El escenario del medio suele ser el más honesto.

4. Payback. En qué mes el valor (horas ahorradas, conversión, retención, tickets evitados) cubre inicial + recurrente. Si el payback depende de un volumen que no tienes, el caso es una apuesta, no un plan.

Añade una línea de "qué pasa si el modelo cambia de precio", porque va a cambiar. Si el TCO no aguanta una subida del 30% en inferencia, el número aún no está cerrado.

Añade otra de riesgo: qué porcentaje de acciones requiere humano, y qué coste tiene ese humano. El agente que "casi" resuelve y luego escala todo es más caro que no tener agente.

Señales de que el número no cuadra

No hace falta un modelo financiero sofisticado: estas señales bastan para parar. El equipo estima tokens y dice que el resto se verá, cuando el resto es el proyecto. Nadie sabe el coste por hilo esta semana, así que nadie puede decidir si bajar de modelo. El caso de uso escribe en datos de cliente y aún no hay límite de gasto ni dueño, y el coste oculto es el incidente. El ROI (retorno de la inversión) se calcula con un 95% de acierto que nadie ha medido: mide primero en un 5% del tráfico. Y la alternativa "lo construimos nosotros" no incluye plataforma, evaluación ni guardia, así que estás comparando un prototipo con un producto.

Si varias de estas se cumplen, no necesitas un vendor más barato: necesitas un alcance más estrecho o más semanas de sistema. El precio de crear un agente de IA in-house no es el salario de quien escribe el primer prompt. Es el coste de operarlo el mes 6, cuando el modelo ha cambiado dos veces y quien lo montó ya no está.

Cómo bajar el TCO sin recortar el caso de negocio

Hay formas de gastar menos que no consisten en elegir el modelo más débil y esperar que funcione.

Empieza en un plan o un segmento. El unit economics se aprende con volumen real, no con una extrapolación de 40 demos. Un plan free o un piloto instrumentado sirve para eso: ver tool calls, tokens y fallos antes de comprometer el margen de toda la base.

Mide por agente, no por cuenta. Un agente de soporte y uno de onboarding no tienen el mismo coste ni el mismo valor. Si los mezclas, el que destruye margen se esconde detrás del que lo crea.

Caché, contexto mínimo, tools justas. Cada documento que metes "por si acaso" se paga en cada turno. Cada tool extra es una oportunidad de equivocarse y reintentar.

No construyas dos veces la capa de plataforma. Observabilidad, permisos, límite de coste y MCP sobre tu API son trabajo de plataforma. Si tu equipo lo monta para un solo agente, el TCO del segundo agente sigue siendo alto. Si esa capa ya existe (propia o comprada), el coste marginal cae. El debate de construir o comprar esa capa va después de tener el número, no antes.

En Devic esa capa es el producto: harness con observabilidad y control de coste, tool calls como unidad, y planes con volumen incluido para medir antes de escalar. El plan free cubre 5.000 tool calls al mes sin tarjeta. No es el TCO de producción: es la forma de medir antes de adivinar. Si el caso pide on-premise, retención larga o acompañamiento, el número ya no es self-serve. Se habla con los requisitos encima de la mesa.

Checklist: ¿tienes un TCO o solo una factura de tokens?

Antes de aprobar el business case, el equipo debería poder responder sí a esto: si está escrito el flujo y la métrica de éxito; si la inversión inicial incluye producción, no solo la demo; si hay coste por acción exitosa, no solo un total mensual; si existen tres escenarios de volumen, no uno "conservador" sacado de una presentación; si hay límite de gasto por tenant y un dueño con nombre; si el payback aguanta una subida del 30% en el modelo; y si sabéis qué parte construiréis y qué parte no queréis volver a construir.

Si no puedes responder a varias de estas preguntas, el siguiente paso no es negociar precio: es cerrar el alcance e instrumentar.

Cuando tengas esas líneas, el resto es aritmética. Si quieres contrastarlas con un caso real (tu API, tu margen, tu volumen), lo miramos con los números delante.