La adopción de IA suele comenzar con una frase que suena razonable en una reunión de planificación:
“Deberíamos usar IA aquí.”
A veces esa intuición es correcta. Un modelo realmente puede reducir la revisión manual, acelerar la investigación, enrutar tickets de soporte, resumir información desordenada o ayudar a los equipos a entregar mejor software.
Pero la intuición es una base poco sólida para gestionar programas de IA.
Lo difícil no es lanzar el primer piloto. Lo difícil es saber si el sistema realmente está mejorando el negocio, si la mejora justifica el costo y si se están acumulando nuevos modos de falla sin que nadie los note.
Esa es la diferencia entre usar IA y usar IA correctamente.
TL;DR
- La adopción de IA sin medición se convierte en una apariencia de actividad: pilotos, dashboards, políticas y demos que no demuestran valor.
- El primer error de medición suele ser omitir la línea de base previa a la IA. Si no conoces el tiempo de ciclo, la tasa de error, el costo o el nivel de satisfacción anteriores, no puedes demostrar que los nuevos son mejores.
- Las métricas útiles de IA suelen agruparse en tres capas: resultados de negocio, calidad del flujo de trabajo y comportamiento del modelo y del sistema.
- La matriz de Rumsfeld ofrece una perspectiva útil: lo conocido conocido se puede instrumentar, lo desconocido conocido se puede monitorear, lo conocido desconocido se puede sacar a la luz con expertos de dominio y lo desconocido desconocido requiere controlar el alcance del impacto.
- El camino práctico es sencillo, pero no fácil: definir el resultado, establecer líneas de base, ejecutar experimentos controlados, evaluar la calidad continuamente y revisar la métrica cuando la realidad te enseñe algo nuevo.
Qué aprenderás aquí
- Por qué “todos los demás están adoptando IA” no es una estrategia
- Cómo aplicar las categorías de lo conocido y lo desconocido a la medición de IA
- Qué métricas importan antes, durante y después del despliegue
- Cómo conectar el comportamiento de la IA con el valor de negocio sin engañarte
- Cómo diseñar sistemas de IA capaces de resistir sorpresas
- Una hoja de ruta de 8 pasos para pasar de la intuición a un ROI de IA medible
La trampa de la intuición
Nunca ha sido tan fácil justificar emocionalmente la adopción de IA.
Hay mejores modelos, mejores herramientas, mejores flujos de trabajo para desarrolladores y mejores argumentos para los ejecutivos. La presión por hacer algo es real. En la encuesta global de McKinsey de 2024, la adopción de IA llegó al 72% de las organizaciones que usan IA en al menos una función de negocio. Por su parte, BCG informó que muchas empresas todavía tienen dificultades para convertir la actividad relacionada con IA en valor tangible.
Esa brecha es lo que realmente importa.
El problema no es que a los equipos no les interese la IA. El problema es que muchos todavía miden la adopción en lugar del valor.
Entre las señales poco concluyentes más comunes están:
- número de pilotos lanzados
- número de políticas de IA redactadas
- número de modelos desplegados
- número de empleados con acceso a herramientas
- número de prompts o conversaciones creados
Esas métricas no son inútiles. Pueden indicar si existe un programa. No pueden indicar si funciona.
Un chatbot de soporte con mucho uso todavía puede frustrar a los clientes. Un asistente de código puede generar más carga de revisión que ahorro de tiempo. Un resumidor de documentos puede ahorrar tiempo mientras introduce riesgos sutiles de cumplimiento. Un copiloto de ventas puede generar más mensajes sin mejorar la conversión.
Por eso, el primer cambio es filosófico:
El éxito de la IA no es la adopción. El éxito de la IA es una mejora medible en un flujo de trabajo real.
Comienza con la línea de base
La medición comienza antes de que aparezca el modelo.
Si quieres que la IA mejore un proceso, primero registra su estado actual:
| Pregunta sobre el flujo de trabajo | Métrica de línea de base |
|---|---|
| ¿Cuánto tiempo toma esto hoy? | Tiempo de ciclo, tiempo de resolución, tiempo de revisión |
| ¿Con qué frecuencia falla? | Tasa de error, tasa de escalamiento, tasa de retrabajo |
| ¿Cuánto cuesta? | Costo por tarea, costo por caso, horas de trabajo |
| ¿Qué tan bueno es el resultado? | Puntuación según una rúbrica, puntuación de control de calidad, satisfacción del cliente |
| ¿Cuánta supervisión humana se necesita? | Minutos de revisión, tasa de intervención humana, tasa de aprobación |
Sin esta línea de base, los equipos terminan afirmando cosas como “la IA nos hizo más rápidos” sin saber con qué están comparando esa velocidad.
Esto es especialmente riesgoso porque la IA cambia la naturaleza del trabajo. Puede reducir el tiempo de redacción y aumentar el de verificación. Puede disminuir la latencia de la primera respuesta y aumentar el volumen de escalamientos. Puede permitir que un equipo haga más trabajo mientras otro absorbe más excepciones.
La pregunta útil no es:
¿El modelo produjo algo?
Es:
¿Mejoró el flujo de trabajo después de considerar todos los costos, las revisiones, las fallas y los efectos de segundo orden?
La matriz de Rumsfeld para el trabajo con IA
El marco de Donald Rumsfeld de “lo conocido conocido / lo desconocido conocido / lo desconocido desconocido” es útil porque los sistemas de IA no fallan únicamente de formas que puedas enumerar de antemano.
Toda iniciativa de IA abarca cuatro categorías:
What We Know What We Do Not Know
Aware Known Knowns Known Unknowns
Accuracy Drift patterns
Latency Long-term user behavior
Cost Edge-case performance
Throughput Explainability gaps
Unaware Unknown Knowns Unknown Unknowns
Tacit expert rules Emergent behaviors
Hidden data assets Second-order incentives
Overlooked patterns Valid-looking bad outputs
Existing signals Unexpected dependenciesLo conocido conocido
Estas son las métricas que nos resultan familiares.
Puedes instrumentar la exactitud, la latencia, el costo, el throughput, la disponibilidad, la finalización de tareas y la validez del esquema. Tienen su lugar en los dashboards. Se pueden seguir a lo largo del tiempo. Se pueden usar como criterios para aprobar una versión.
Por ejemplo:
- latencia de respuesta p95 inferior a 2 segundos
- tasa de alucinaciones inferior al 2% en un conjunto de datos etiquetado
- costo por ticket resuelto por debajo de un umbral objetivo
- validez del esquema JSON superior al 99.5%
Lo desconocido conocido
Estos son riesgos que puedes identificar, pero no predecir por completo.
Sabes que puede haber desviaciones. Sabes que los usuarios pueden cambiar su comportamiento una vez que la herramienta exista. Sabes que aparecerán casos límite en producción. Sabes que el modelo puede funcionar de manera diferente en un nuevo segmento de clientes.
Lo desconocido conocido exige monitoreo, experimentos y revisiones periódicas.
Por ejemplo:
- monitorear la calidad por segmento de clientes
- comparar los flujos de trabajo asistidos por IA con los realizados solo por humanos
- ejecutar evals de regresión después de cambiar un prompt o un modelo
- seleccionar muestras de resultados de producción para revisión humana
Lo conocido desconocido
Son las cosas que la organización sabe, pero que no ha incorporado al conocimiento del sistema.
Una persona a cargo de soporte puede saber qué casos de reembolso siempre necesitan escalamiento. Un analista de datos puede saber que un campo no es confiable después de una migración. Una persona de cumplimiento puede saber qué expresiones generan riesgos. Un ingeniero sénior puede saber qué fallas de herramientas son inofensivas y cuáles son peligrosas.
Los programas de IA fallan aquí cuando tratan el conjunto de datos como si fuera toda la verdad.
La solución no es solo tener más datos. Es hacer un proceso estructurado de descubrimiento:
- entrevistar a expertos de dominio antes de construir
- realizar pre-mortems con los operadores
- revisar incidentes históricos y casos límite
- convertir las reglas tácitas en rúbricas, pruebas y guardrails
Lo desconocido desconocido
Estas son las sorpresas.
Un agente genera SQL aparentemente válido que daña un flujo de trabajo posterior. Un sistema de recomendación cambia el comportamiento de los usuarios de una forma que invalida la métrica original. Un resumidor reduce el tiempo de lectura, pero hace que los revisores pasen por alto el contexto. Un agente que llama herramientas descubre una ruta que técnicamente funciona, pero omite un punto de revisión humana importante.
No puedes escribir una lista de verificación completa para lo desconocido desconocido.
Sí puedes diseñar para controlar el impacto:
- feature flags
- despliegues canary
- aprobación humana para acciones de alto riesgo
- límites de tasa y permisos de alcance limitado
- mecanismos de rollback
- detección de anomalías
- revisiones de incidentes que cuestionen las suposiciones, no solo los bugs
El objetivo no es predecir cada falla. Es hacer que el sistema pueda resistir las sorpresas.
Las tres capas de métricas que importan
Los equipos de IA suelen mezclar métricas que responden a preguntas diferentes. Un modelo más claro consiste en separarlas en tres capas.
1. Métricas de resultados de negocio
Responden: ¿Mejoró el negocio?
Ejemplos:
- ingresos por cuenta
- tasa de conversión
- retención de clientes
- costo de soporte por caso resuelto
- tiempo de resolución
- horas de trabajo ahorradas después de incluir el tiempo de revisión
- incidentes de riesgo evitados
Esta es la capa que suele importarles a los ejecutivos. También es la más propensa a contaminarse con expectativas infundadas si falta la línea de base del flujo de trabajo.
2. Métricas de calidad del flujo de trabajo
Responden: ¿Mejoró el proceso?
Ejemplos:
- tasa de finalización de tareas
- tasa de aceptación en el primer intento
- tasa de retrabajo
- tasa de intervención humana
- exactitud del escalamiento
- latencia de aprobación
- carga de trabajo de los revisores
- satisfacción del usuario después de interactuar con la IA
Esta es la capa en la que los product managers, los responsables de operaciones y los equipos de ingeniería suelen tener las conversaciones más prácticas.
Para un agente de soporte con IA, la métrica de negocio podría ser “costo de soporte por caso resuelto”. Las métricas del flujo de trabajo podrían ser “tasa de enrutamiento correcto”, “casos resueltos sin escalamiento” y “promedio de minutos de revisión por respuesta”.
3. Métricas del modelo y del sistema
Responden: ¿Se comportó correctamente el sistema de IA?
Ejemplos:
- puntuación de eval
- tasa de alucinaciones
- precisión de recuperación
- exactitud de las llamadas a herramientas
- validez del esquema
- latencia
- costo de inferencia
- corrección de las negativas
- cumplimiento de las políticas de seguridad
Esta es la capa por la que comienzan la mayoría de los equipos de IA porque es la más cercana a la implementación. Importa, pero no es suficiente.
Un modelo puede obtener una buena puntuación en un eval y aun así no crear valor de negocio. Un flujo de trabajo puede crear valor incluso si el modelo es imperfecto, siempre que el sistema que lo rodea detecte las fallas pertinentes.
La tarea consiste en conectar las tres capas.
Model behavior -> workflow quality -> business outcome
Tool-call accuracy -> correct ticket routing -> lower time-to-resolution
Retrieval quality -> fewer bad answers -> higher customer satisfaction
Summary quality -> faster review -> lower cost per caseCadena de impacto: el antídoto contra un ROI impreciso
Una técnica práctica es la cadena de impacto.
En lugar de decir “la IA mejorará el soporte”, traza la cadena causal:
| Capacidad de IA | Cambio en el flujo de trabajo | Resultado de negocio |
|---|---|---|
| Clasificar tickets entrantes | Enrutamiento más rápido a la cola adecuada | Menor tiempo de resolución |
| Redactar respuestas de soporte | Menor tiempo de redacción por caso | Menor costo por caso resuelto |
| Recuperar fragmentos de políticas | Menos respuestas incorrectas | Mayor CSAT, menor riesgo de cumplimiento |
| Resumir el historial de casos | Revisión humana más rápida | Mayor throughput de los agentes |
Cada eslabón necesita una métrica.
Si la IA redacta respuestas, mide el tiempo de redacción. Pero también mide el tiempo de revisión, la distancia de edición, la tasa de aprobación, la tasa de error y la satisfacción del cliente. Si el tiempo de revisión se duplica, la aparente ganancia de productividad puede desaparecer.
Aquí es donde se desmoronan muchas historias sobre el ROI de la IA. Miden el paso que se aceleró e ignoran los pasos que se volvieron más pesados.
Los experimentos controlados superan a la esperanza
La forma más clara de saber si la IA está ayudando es comparar flujos de trabajo.
En un despliegue real, eso podría verse así:
- El equipo A usa el proceso actual; el equipo B usa el proceso asistido por IA.
- Una muestra aleatoria de tickets recibe clasificación inicial con IA; el resto sigue el proceso habitual.
- Una variante de modelo/prompt atiende a una cohorte de prueba; otra atiende a una cohorte de control.
- Los revisores humanos califican los resultados sin saber qué sistema los produjo.
Mide el flujo de trabajo completo:
- tasa de finalización
- tiempo hasta la finalización
- tasa de error
- tasa de retrabajo
- tasa de escalamiento
- costo por tarea completada
- puntuación de calidad asignada por humanos
- satisfacción del usuario
Esto es menos llamativo que una demo, pero también es mucho más difícil que induzca a error.
También hace que la selección del modelo sea más honesta. El mejor modelo no siempre es el que obtiene la puntuación más alta en un benchmark. Es el que mejora el flujo de trabajo objetivo dentro de las restricciones relevantes de costo, latencia, calidad y riesgo.
Los evals son el puente entre producto e ingeniería
Para las aplicaciones de IA, los evals no son solo pruebas técnicas. Son el contrato entre la intención del producto y el comportamiento del sistema.
Una buena suite de evals convierte expectativas vagas en ejemplos que se pueden examinar:
- “El agente de soporte debe solicitar los datos de cuenta faltantes antes de actuar.”
- “El agente de código no debe modificar archivos fuera del alcance solicitado.”
- “El asistente de investigación debe distinguir la evidencia directa de las inferencias.”
- “El asistente de ventas no debe inventar condiciones de precios.”
Esas expectativas se convierten en conjuntos de datos, rúbricas, verificaciones deterministas y prompts para evaluadores.
Para sistemas de agentes, normalmente prefiero una combinación de:
- pruebas deterministas para esquemas, permisos y límites de las herramientas
- evals con conjuntos de datos para ejemplos que se ejecutan repetidamente
- evaluadores LLM basados en rúbricas para la calidad semántica
- evaluación basada en trazas para la elección de herramientas, la recuperación y las decisiones intermedias
- calibración humana con muestras de resultados
Esto importa porque la calidad de la IA en producción rara vez tiene una sola dimensión. Una respuesta puede ser cortés, pero incorrecta. Correcta, pero sin respaldo. Rápida, pero riesgosa. Barata, pero incompleta. Útil para un segmento de clientes y perjudicial para otro.
Los evals le dan al equipo un lenguaje compartido para hablar de esas compensaciones.
Aprendizaje de doble ciclo: corrige la métrica, no solo el modelo
El aprendizaje de ciclo simple pregunta:
¿Estamos alcanzando el objetivo?
El aprendizaje de doble ciclo pregunta:
¿Sigue siendo este el objetivo correcto?
Los equipos de IA necesitan aprendizaje de doble ciclo porque los sistemas de IA cambian el entorno que los rodea. Una vez que existe una herramienta, los usuarios se adaptan. Los equipos canalizan más trabajo a través de ella. Los responsables ajustan sus expectativas. Los casos límite que eran poco frecuentes pueden volverse comunes porque la IA hace posible un nuevo flujo de trabajo.
Eso significa que la métrica original puede quedar obsoleta.
Por ejemplo:
- Optimizaste la velocidad de respuesta y luego descubriste que la confianza disminuyó porque los usuarios querían más explicaciones.
- Optimizaste la tasa de automatización y luego descubriste que los casos más difíciles se estaban automatizando de forma demasiado agresiva.
- Optimizaste para reducir los escalamientos y luego descubriste que el sistema ocultaba la incertidumbre en lugar de hacerla visible.
- Optimizaste el costo de tokens y luego descubriste que los resultados más cortos aumentaban el tiempo de revisión humana.
La respuesta correcta no siempre es “mejorar el modelo”.
A veces es:
- cambiar la métrica
- desglosar la métrica por nivel de riesgo
- agregar un paso de aprobación humana
- reducir la automatización en ciertos casos
- reescribir la rúbrica
- retirar el caso de uso
Esa última opción importa. Un programa de IA maduro debería poder cancelar un caso de uso de IA que no funciona sin considerarlo una falta de ambición.
Una hoja de ruta de 8 pasos para madurar la medición de IA
Esta es la secuencia práctica que usaría con la mayoría de los equipos.
1. Identifica el flujo de trabajo
No comiences con una “estrategia de IA”. Comienza con un flujo de trabajo.
Mal:
- “Usar IA en éxito del cliente.”
Mejor:
- “Reducir el tiempo promedio de resolución de tickets de facturación de nivel 1 sin aumentar los reembolsos incorrectos.”
2. Establece la línea de base
Registra el proceso actual antes de que la IA lo cambie:
- tiempo de ciclo
- costo
- tasa de error
- retrabajo
- escalamiento
- puntuación de calidad
- satisfacción del usuario
3. Define la métrica de resultado
Elige el resultado de negocio que importa.
Ejemplos:
- reducir el costo por caso resuelto en un 20%
- aumentar la resolución en el primer contacto en un 10%
- reducir el tiempo de investigación de los analistas en un 30%
- mejorar la precisión de la calificación de leads en un 15%
4. Define los guardrails del flujo de trabajo
Agrega métricas que eviten que la optimización de una parte cause daños más amplios.
Ejemplos:
- ningún aumento en la tasa de quejas
- ningún aumento en los escalamientos relacionados con cumplimiento
- tasa de intervención humana por debajo de un umbral objetivo
- puntuación de la rúbrica de calidad por encima del umbral de lanzamiento
5. Construye el conjunto de evals
Crea ejemplos que representen la realidad:
- casos comunes
- casos de alto riesgo
- fallas históricas
- casos límite aportados por expertos de dominio
- entradas adversariales o ambiguas
Esto se convierte en la suite de regresión para prompts, modelos, herramientas y políticas.
6. Ejecuta experimentos controlados
Compara los flujos de trabajo asistidos por IA con el proceso actual.
No midas solo el resultado del modelo. Mide todo el recorrido, desde la recepción de la tarea hasta la aceptación del resultado.
7. Monitorea el comportamiento en producción
Después del lanzamiento, sigue:
- desviaciones de calidad
- desviaciones de costo
- desviaciones de latencia
- cambios en el comportamiento de los usuarios
- patrones de intervención humana
- incidentes y cuasiincidentes
Selecciona muestras de resultados de producción para revisión humana. Incorpora las fallas interesantes al conjunto de evals.
8. Revisa la métrica en sí
Cada pocas semanas, pregunta:
- ¿Esta métrica sigue midiendo el objetivo real?
- ¿Los usuarios están manipulando la métrica?
- ¿Cambió el flujo de trabajo?
- ¿Están apareciendo nuevos riesgos?
- ¿Deberían automatizarse menos algunos casos?
Esa última revisión es lo que separa la medición de la decoración de dashboards.
La verdadera prueba
Saber que estás usando la IA correctamente no significa predecir cada resultado.
Significa que tu sistema puede responder tres preguntas con honestidad:
- ¿Cómo era el flujo de trabajo antes de la IA?
- ¿Qué cambió después de la IA, incluidos los costos y la carga de revisión?
- ¿Qué estamos aprendiendo de las fallas que no sabíamos que podían ocurrir?
Las organizaciones que hagan esto bien no serán las que tengan más demos. Serán las que tengan los ciclos de retroalimentación más estrechos entre la intención del producto, el comportamiento del sistema, el criterio humano y el valor de negocio.
Ese es el cambio:
De la intuición a las métricas.
De las demos a la evidencia.
De “estamos usando IA” a “sabemos dónde funciona la IA, dónde no y qué vamos a cambiar a continuación”.
Fuentes
- El estado de la IA a principios de 2024 - McKinsey, May 2024
- Adopción de IA en 2024: el 74% de las empresas tiene dificultades para obtener valor y llevarlo a escala - Boston Consulting Group, October 24, 2024
- Una encuesta de Gartner revela que la IA generativa es ahora la solución de IA más desplegada en las organizaciones - Gartner, May 7, 2024
- ROI de la IA: cómo medir el verdadero valor de la IA - CIO, con Adrian Dunkley de StarApple AI
- Cómo vincular la adopción de IA con la productividad: 5 métricas probadas y un framework de ROI de Worklytics - Worklytics
- Guía del modelo de madurez de IA y la herramienta de evaluación organizacional de MITRE - MITRE