Toda empresa de software que mete IA en su producto llega, tarde o temprano, a la misma pregunta incómoda: ¿esto funciona de verdad, o solo lo parece? Y a una segunda, aún más incómoda cuando llega la factura: ¿nos sale a cuenta? La mayoría de equipos no puede responder ninguna de las dos con datos, porque midieron la IA como se mide una feature normal —"pasa los tests, sale"— cuando la IA generativa exige medir distinto. Esta es la guía práctica de qué medir, cómo instrumentarlo y qué decisión tomar con el resultado. No es teoría: es lo que separa una feature de IA que aguanta en producción de una que corre rápido hacia el muro.
Por qué "funciona" no es una métrica
El software tradicional es determinista: la misma entrada da la misma salida, y un test que pasa hoy pasa mañana. La IA generativa no funciona así. La misma pregunta puede dar respuestas distintas; una respuesta puede sonar impecable y ser falsa; y el modelo puede degradarse cuando el proveedor lo actualiza sin avisar. Por eso el "parece que funciona" de la demo es traicionero: la demo la haces tú, con el caso feliz y el prompt afinado, y producción la usan miles de clientes con datos que no anticipaste.
El síntoma clásico: una feature de IA que impresionó en la review interna y, tres semanas después de salir, acumula quejas de soporte por respuestas inventadas, mientras la factura de tokens se ha triplicado y nadie sabe explicar por qué. No es que la IA no sirva. Es que se lanzó sin instrumentar, y "funciona" era una sensación, no un número. Medir bien no es un lujo de madurez: es el requisito para que la IA de tu producto sea operable, gobernable y rentable.
Las dos únicas métricas que importan
Se puede instrumentar una feature de IA con cincuenta paneles y no entender nada. La disciplina consiste en reducir a lo esencial. Hay dos métricas que gobiernan la decisión; el resto son diagnósticas.
| Métrica | Qué responde | Sin ella… |
|---|---|---|
| Calidad verificada | ¿La salida es correcta según un criterio explícito, no según "suena bien"? | Cada release es una apuesta; los fallos se descubren en producción. |
| Coste por tarea útil | ¿Cuánto cuesta cada resultado que pasa la calidad y se usa de verdad? | La factura crece sin saber si el valor la justifica; imposible decidir build vs. buy. |
Fíjate en que las dos están acopladas por la palabra "útil": no cuenta un output barato que está mal, ni uno correcto que nadie usó. La intersección —correcto y usado— es donde vive el valor. Todo lo demás (latencia, tokens, tasa de error por tipo) es diagnóstico: te ayuda a mejorar, pero no es el criterio de decisión.
Cómo montar evals que sí sirven
Una eval es una forma automática y reproducible de responder "¿esta salida es correcta?". Sin evals, la calidad la juzga quien mira la demo ese día, con su criterio y su estado de ánimo. Con evals, el criterio es explícito, versionado y ejecutable en cada cambio. No todas las evals son iguales; se montan por niveles, de lo barato a lo caro:
| Nivel | Cómo | Cuándo |
|---|---|---|
| 1 · Determinista | Reglas y aserciones: ¿cita fuentes reales? ¿respeta el formato/JSON? ¿está dentro del dominio permitido? | Siempre. Es barato y caza el 40% de los fallos. |
| 2 · Dataset dorado | Un conjunto de casos reales con la respuesta correcta validada por un humano; se ejecuta en cada cambio de prompt/modelo. | Antes de cada release y en CI. El ancla contra regresiones. |
| 3 · LLM-as-judge | Otro modelo puntúa la salida contra una rúbrica; útil para calidad "blanda" (tono, relevancia). Se calibra contra el juicio humano. | Para escala, con muestreo humano de control periódico. |
| 4 · Humano en producción | Señal real: pulgar arriba/abajo, edición del usuario, abandono. Cierra el bucle con el mundo. | Siempre que el producto lo permita. Es la verdad de terreno. |
La regla que evita el auto-engaño: la eval se escribe antes que la feature. Si no sabes cómo vas a decidir que una salida es correcta, no estás listo para construirla — estás listo para hacer otra demo. Y una métrica honesta por encima del acierto medio: pass@k (¿en cuántos intentos el sistema produce al menos una salida correcta?) frente a la tasa de acierto a la primera; te dice si el problema es de capacidad o de consistencia, que se arreglan distinto.
Cómo medir el coste por tarea útil (con números)
El error más común de coste es medir coste por llamada o coste por usuario. Ninguno te dice si la feature es rentable. La métrica correcta es el coste por tarea útil: lo que cuesta producir un resultado que pasó la eval y se usó. La fórmula:
Coste por tarea útil = (créditos/tokens consumidos por el workflow) ÷ (nº de outputs que pasaron la eval y se usaron en producción)
Un ejemplo concreto para verlo:
- Una feature de asistente en tu SaaS consume 500 € al mes en tokens.
- Genera 20.000 respuestas al mes. Pero el 70% pasa la eval (14.000 correctas) y, de esas, el usuario usa el 60% (8.400 útiles).
- Coste por tarea útil = 500 € ÷ 8.400 = 0,06 € por resultado útil.
Ahora la decisión es posible: si cada resultado útil te ahorra al cliente 2 € de trabajo manual o mejora la retención, 0,06 € es una ganga. Si la feature es cosmética, quizá no. Y fíjate en el apalancamiento: subir la tasa de acierto del 70% al 85% baja el coste por tarea útil un 18% sin tocar el modelo — es método (mejor contexto, mejor eval), no un modelo más caro. Ese es exactamente el trabajo de la ingeniería de contexto.
El tablero mínimo: qué mirar cada semana
No necesitas un centro de mando. Necesitas cinco líneas que un Head of Product y un CTO puedan leer en un minuto y sobre las que se pueda decidir:
- % de salidas que pasan la eval (calidad verificada). Tendencia: ¿sube, baja, se mantiene?
- Coste por tarea útil, con su tendencia. Es la métrica de rentabilidad.
- % de outputs útiles usados (adopción real de la feature). Si es bajo, quizá el problema no es la IA: es que la feature no importa.
- Deriva de calidad tras cambios del proveedor: una caída del pass rate sin que tú tocaras nada = el modelo cambió. Sin este panel, te enteras por soporte.
- Cola de fallos etiquetados: los casos que fallaron, agrupados por tipo. Es el backlog de mejora — y alimenta el dataset dorado.
Cuándo una feature de IA merece seguir viva
Medir sirve para decidir. Con las dos métricas y el tablero, cada feature de IA cae en uno de cuatro cuadrantes, y cada uno tiene una acción clara:
| Calidad | Coste por tarea útil | Decisión |
|---|---|---|
| Alta | Bajo | Escalar. Funciona y es rentable — invierte y expande. |
| Alta | Alto | Optimizar. El valor está; baja el coste con método (contexto, caché, modelo menor donde baste) antes de escalar. |
| Baja | Bajo | Arreglar la calidad — es barato, así que merece la inversión de método antes de rendirse. |
| Baja | Alto | Matar o rediseñar. No funciona y es caro; mantenerla por orgullo de demo es la decisión más cara. |
Aquí también se resuelve el build vs. buy: para las piezas del cuadrante "alta calidad, coste alto" que no logras optimizar dentro de tu producto, la alternativa honesta es delegar la ejecución a un proveedor que asuma el riesgo de modelo y de pricing en el contrato, no en tu factura. Construyes lo que te diferencia; sacas de tu coste variable lo que no.
Los errores que revientan la medición
- Medir el acierto medio en vez de por caso. Un 90% de acierto con el 10% de fallos concentrados en tu caso de uso más importante es un producto roto que parece sano.
- Evals que se auto-aprueban. Un LLM-as-judge sin calibración humana termina premiando el estilo del modelo que juzga. Muestrea siempre con humanos.
- Medir coste por llamada, no por tarea útil. Optimizas para hacer llamadas baratas que no sirven en vez de resultados que sí.
- No vigilar la deriva del proveedor. El modelo cambia bajo tus pies; sin el panel de deriva, tu calidad baja y lo achacas a los usuarios.
- Instrumentar al final. El coste y las evals se montan con el primer prototipo, no cuando llega la primera factura sorpresa.
Preguntas frecuentes
¿Cómo sé si la IA de mi producto SaaS funciona de verdad?
Con evals reproducibles que midan si la salida es correcta según un criterio explícito (no "suena bien"), combinadas con la señal real del usuario en producción. "Parece que funciona" es una impresión; el % de salidas que pasan la eval, con su tendencia, es un dato. Sin evals, cada release es una apuesta y los fallos se descubren tarde, en producción.
¿Qué es el coste por tarea útil y por qué es la métrica que importa?
Es lo que cuesta producir un resultado que pasó la eval y se usó de verdad: créditos consumidos ÷ outputs correctos y usados. A diferencia del coste por llamada o por usuario, te dice si la feature es rentable y permite decidir build vs. buy. Subir la calidad baja el coste por tarea útil sin tocar el modelo: es método, no un modelo más caro.
¿Necesito montar evals aunque mi feature de IA sea sencilla?
Sí, aunque sean del nivel más barato (reglas deterministas + un pequeño dataset dorado). Sin una forma automática de saber si una salida es correcta, no puedes poner la feature en producción con garantías ni detectar cuándo el modelo se degrada. La eval se escribe antes que la feature: si no sabes cómo decidir que funciona, aún no estás listo para construirla.
¿Cada cuánto reviso estas métricas?
Semanalmente para el tablero de decisión (pass rate, coste por tarea útil, adopción, deriva del proveedor, cola de fallos) y en cada release/cambio de modelo para el dataset dorado en CI. La deriva del proveedor obliga a vigilancia continua: un modelo puede cambiar sin avisar y tu calidad caer sin que tú tocaras nada.
Conclusión
La IA de tu producto no se gobierna con impresiones: se gobierna con dos números. Calidad verificada te dice si funciona; coste por tarea útil te dice si sale a cuenta. Con esos dos y un tablero de cinco líneas, la decisión de escalar, optimizar, arreglar o matar una feature de IA deja de ser una opinión de sala y pasa a ser una lectura de datos. Y casi siempre, la palanca para mejorar los dos números no es un modelo más caro: es método —contexto de tu producto y verificación en cada paso—, que es exactamente lo que hace que la IA pase de la demo a producción y se quede rentable.
Si tienes features de IA en producción sin instrumentar —o quieres montarlas bien desde el principio— empieza por un diagnóstico: en unas semanas tienes las evals, el coste por tarea útil y el tablero de decisión funcionando, y sabes qué features escalar y cuáles rediseñar. Y si eres una empresa de software o SaaS, aquí tienes nuestro enfoque completo: IA para empresas de software y SaaS.