El coste real de operar una feature de IA: tokens, latencia y confianza
El precio por token es la parte pequeña de la factura. Las cinco partidas que aparecen después del lanzamiento y cómo estimarlas antes de comprometerte.
Casi todas las estimaciones de coste de una funcionalidad de IA que veo tienen una sola línea: el precio por millón de tokens multiplicado por el volumen esperado. Esa línea suele ser correcta y suele ser la partida más pequeña de todas.
Estas son las cinco que aparecen después, en orden de cuánto sorprenden.
1. El consumo real, que no es el que calculaste
El cálculo de servilleta usa el caso medio. La factura la marca la cola.
Tres cosas la inflan de forma sistemática. Los reintentos, porque cuando la respuesta no convence, alguien vuelve a pulsar. Los casos largos, porque el documento de 80 páginas existe aunque la media sean cuatro. Y el contexto acumulado, porque si la funcionalidad conversa, cada turno arrastra todo lo anterior.
Cómo estimarlo bien: coge veinte casos reales de tu producto, pásalos por el flujo completo y mide. Multiplica por el volumen esperado y por tres. Ese tres no es pesimismo, es lo que se come el uso interno mientras el equipo prueba.
2. La revisión humana
Si la funcionalidad puede equivocarse y el error importa, alguien tiene que mirar los casos dudosos. Eso es una persona, o parte de una, de forma indefinida.
Es la partida que más se olvida y la más cara, porque no baja con el volumen: crece con él. Un sistema que necesita revisión en el 5 % de los casos necesita cinco veces más revisión cuando multiplicas el uso por cinco.
La única manera de bajarla es que el sistema sepa cuándo no está seguro y solo levante la mano en esos casos. Diseñar eso desde el principio cuesta poco. Añadirlo después, cuando ya hay una persona quemada revisando todo, cuesta rehacer el flujo.
3. La latencia, que se paga en uso
No aparece en ninguna factura y decide si la funcionalidad se usa.
Por debajo de dos segundos, la gente espera. Entre dos y cinco, espera si le has enseñado que algo está pasando. Por encima de ocho, en un flujo interactivo, la funcionalidad está muerta aunque funcione perfectamente.
Las salidas son conocidas: enseñar la respuesta según se genera, mover la tarea a segundo plano y avisar al terminar, o usar un modelo más pequeño para la parte que tiene que ser inmediata. Todas cuestan trabajo de producto, y ninguna aparece en la estimación inicial.
4. El mantenimiento cuando cambia el contexto
Una funcionalidad de IA se afina contra un producto, unos datos y un criterio de negocio. Los tres cambian.
Cambias el precio y el clasificador de leads se desalinea. Añades un tipo de documento y el extractor empieza a fallar en silencio. Cambias el segmento y lo que era un caso raro pasa a ser el 30 %.
Lo peor es que el fallo no es ruidoso. El software roto da error; una funcionalidad de IA desalineada sigue devolviendo respuestas con la misma seguridad de siempre. Sin una revisión periódica contra casos conocidos, te enteras por un cliente.
Presupuesta una revisión trimestral con un conjunto de casos de prueba que sepas cómo deberían salir. Es la póliza más barata que vas a contratar.
5. El coste de la desconfianza
El más difícil de contabilizar y el que decide el retorno.
Si la funcionalidad se equivoca de forma visible dos veces, la gente deja de usarla. No la desactiva, simplemente la ignora, y tú sigues pagando el desarrollo, el mantenimiento y los tokens de una funcionalidad que nadie mira. Es el peor escenario económico posible: todos los costes y ninguno de los beneficios.
Y recuperar la confianza cuesta más que ganarla la primera vez. Lo desarrollo en diseñar para la desconfianza: UX de funciones con IA.
La cuenta completa
Para una funcionalidad de tamaño medio en un SaaS B2B, el reparto típico se parece a esto:
| Partida | Peso relativo |
|---|---|
| Modelo (tokens) | 10 a 20 % |
| Revisión humana | 30 a 50 % |
| Mantenimiento y reajuste | 20 a 30 % |
| Soporte generado por errores | 10 a 20 % |
El número exacto depende de tu caso. Lo que se repite es la forma: la partida que estimaste es la más pequeña de la tabla.
Qué hacer con esto
No es un argumento para no aplicar IA. Es un argumento para elegir mejor cuáles.
Los casos que salen rentables comparten cuatro cosas: hay volumen, el criterio es repetible, el resultado se puede verificar contra algo que pasó de verdad, y el error es barato. El marco completo está en dónde aplicar IA en tu producto SaaS sin quemar presupuesto, y el método para ordenarlos, en cómo priorizar features de IA por impacto y esfuerzo.
Un caso concreto que cumple las cuatro, con su cuenta hecha, está en cualificar leads inbound con IA.
¿Cuánto cuesta operar una funcionalidad de IA al mes?
El gasto en modelo suele ser la partida menor, y en muchos productos B2B se queda en decenas o pocos cientos de euros al mes. Lo que pesa es lo demás: revisión humana de los casos dudosos, mantenimiento cuando cambia el contexto, y el soporte que genera cuando se equivoca. Presupuestar solo los tokens es cómo se llega a una sorpresa en el mes tres.
¿Cómo se estima el consumo antes de lanzar?
Coge veinte casos reales, pásalos por el flujo completo y mide lo que consume cada uno de verdad. Multiplica por el volumen esperado y por tres, porque los reintentos, los casos largos y las pruebas internas se comen el margen. Estimar sobre casos inventados da números que no se parecen a la factura.
¿La latencia es un coste?
Sí, y de los que no aparecen en ninguna factura. Si la respuesta tarda ocho segundos, la gente deja de usar la función y has pagado el desarrollo entero para nada. En flujos interactivos, por encima de dos o tres segundos hace falta enseñar progreso o mover la tarea a segundo plano.