Medir para escalar: el problema que bloquea la IA empresarial
Hace dos años, la mayoría de los directivos que conozco discutían sobre qué modelo de lenguaje elegir. Hoy, los que ya tomaron esa decisión —y aun así no pueden justificar una segunda ronda de inversión— empiezan a entender que el problema nunca fue el modelo. Fue la medición.
El sector empresarial lleva varios años adoptando inteligencia artificial a ritmo acelerado. Según McKinsey, el 88% de las organizaciones han incorporado IA en al menos una función de negocio. Pero solo un tercio de ellas ha comenzado a escalarla con consistencia. Esa brecha —entre probar y escalar— no es tecnológica. Es organizacional, y se origina en una conversación que la mayoría de los equipos directivos ha evitado tener con precisión: qué significa, en términos operativos y financieros, que esto funcione.
En Sustainabl llevamos tiempo observando cómo las empresas construyen sus casos de inversión en IA. Lo que vemos con mayor frecuencia no es incompetencia técnica. Es una confusión de capas: se mide lo que el proveedor entrega —puntuaciones en pruebas estandarizadas, precisión en laboratorio, rankings comparativos— y se olvida medir lo único que la junta directiva necesita ver: qué cambió en el negocio.
La trampa del benchmark y lo que revela sobre el liderazgo
Cuando un equipo directivo evalúa modelos de IA comparando puntajes de referencia, está repitiendo un error que el mundo tecnológico ya cometió con los servidores en los años noventa: comprar especificaciones en lugar de resultados. El problema no es que los benchmarks sean inútiles. Es que responden a una pregunta diferente.
Los benchmarks miden qué tan bien un modelo resuelve tareas estandarizadas, en condiciones controladas, con datos que no tienen nada que ver con los flujos reales de tu empresa, tu base de conocimiento propietaria ni tus casos límite específicos. Lo que ocurre en producción —con los datos que tienes, los procesos que ya existen y los usuarios que interactúan diariamente— puede diferir de esas métricas en 15 a 25 puntos porcentuales. Esa brecha no es un detalle técnico. Es la distancia entre una promesa de proveedor y un resultado de negocio.
Lo que me interesa aquí no es la ingeniería del modelo. Me interesa lo que esta confusión revela sobre cómo operan las organizaciones cuando enfrentan tecnología nueva. Hay una pauta recurrente: ante la incertidumbre, el liderazgo tiende a delegar el criterio de éxito al dominio técnico. Se adopta el lenguaje de los ingenieros —precisión, recall, puntuación F1— sin traducirlo al lenguaje del negocio. Y esto no sucede porque el liderazgo sea incompetente. Sucede porque nadie quiso tener la conversación incómoda de definir qué significa fracasar con esta inversión.
Esa conversación tiene un costo. Cuando un proyecto de IA llega a los 90 días sin poder mostrar movimiento en ningún indicador operativo, el debate se vuelve político antes de volverse analítico. Cada área defiende su interpretación, nadie quiere ser el responsable del resultado y el proyecto se sostiene por inercia o se cancela por frustración. Ambos desenlaces son evitables si el equipo directivo establece desde el inicio —antes de elegir modelo, antes de seleccionar proveedor— qué indicadores de negocio se van a mover y cuánto.
Lo que un director financiero necesita escuchar
Hay una prueba que aplico mentalmente cuando reviso propuestas de inversión en IA: imaginar al director financiero leyendo el caso de negocio doce meses después del despliegue. Si el documento solo puede mostrar que el modelo obtuvo un 93% en un benchmark de razonamiento, el proyecto está en riesgo. No porque ese número sea irrelevante, sino porque no responde a ninguna de las preguntas que un director financiero hace cuando autoriza un segundo año de presupuesto.
Las preguntas reales son: cuánto bajó el tiempo de resolución por caso, cuánto mejoró la tasa de resolución en el primer contacto, cuánto costó cada interacción asistida por IA frente a una completamente manual, cuánto tardaron los agentes nuevos en alcanzar un nivel operativo aceptable. Estas métricas no las entrega el modelo. Las entrega la arquitectura completa del sistema: la calidad del dato, el diseño de la recuperación de información, la latencia de integración, los mecanismos de control. El modelo es una variable dentro de ese sistema. Frecuentemente, no es la variable más determinante.
Lo que se mide en producción, contra los datos propios de la empresa y con los casos límite reales del negocio, es lo que define si la solución entrega valor. Un modelo más modesto, mejor calibrado a la base de conocimiento específica y a los patrones lingüísticos del cliente, puede superar consistentemente a uno más sofisticado que nunca fue ajustado para ese contexto. He visto esto ocurrir en centros de contacto del sector de servicios públicos: el modelo "ganador" del benchmark terminó siendo reemplazado por uno más simple que se desempeñaba mejor en las consultas reales de los clientes.
La implicación es directa: el modelo debe tratarse como un componente intercambiable, no como la identidad del proyecto. Las organizaciones que diseñan sus arquitecturas con esa lógica —separando la capa del modelo de la capa de la aplicación— pueden sustituir un modelo sin desmantelar toda la solución. Las que no lo hacen quedan atrapadas en una dependencia técnica que encarece cualquier mejora futura.
Un marco de tres capas que sobrevive los ciclos presupuestarios
Después de observar múltiples despliegues en sectores industriales y de servicios, la estructura de medición que demuestra mayor durabilidad no es la más sofisticada. Es la más legible para toda la cadena de mando, desde el equipo técnico hasta la junta directiva.
La primera capa mide precisión en producción: qué porcentaje de los resultados generados por el sistema son correctos sin corrección humana, medidos contra los datos reales de la empresa y sus casos extremos. No el accuracy que reporta el proveedor. El que emerge de las interacciones reales con usuarios y expertos internos.
La segunda capa mide eficiencia operativa: si el tiempo de gestión bajó, si las tasas de resolución mejoraron, si los escalamientos disminuyeron. Estas son las métricas que justifican continuar. Un despliegue que no puede mostrar movimiento en al menos uno de estos indicadores dentro de los primeros noventa días tiene un problema en algún punto de la pila técnica, y esperar más tiempo para saberlo solo aumenta el costo de corregirlo.
La tercera capa mide impacto financiero: el costo por interacción asistida frente a la interacción completamente manual, el período de recuperación de la inversión, el ahorro atribuible. Esta es la capa que convierte el proyecto en un activo dentro del balance de decisiones directivas. Sin ella, la conversación sobre IA permanece en el dominio de los entusiastas de la tecnología, no en el de quienes asignan capital.
Lo que hace funcionar a este marco no es su complejidad. Es que obliga a la organización a tener la conversación de definición antes de desplegar. Definir tres a cinco indicadores de negocio específicos para cada caso de uso, antes de seleccionar modelo o proveedor, no es un ejercicio metodológico. Es la señal de que el liderazgo entiende a qué se está comprometiendo y con qué criterio evaluará si se cumplió.
Quien mide bien, escala. Quien no, itera sin dirección
El contexto regulatorio añade urgencia a esta conversación. La normativa europea de inteligencia artificial, en vigor desde agosto de 2024 con aplicabilidad amplia desde agosto de 2026, exige que las organizaciones no solo despleguen sistemas de IA, sino que puedan demostrar que esos sistemas operan dentro de parámetros definidos, auditables y no discriminatorios. Eso no es posible sin una infraestructura de medición activa. Las empresas que ya tienen tableros de seguimiento de indicadores operativos están, sin proponérselo, mejor posicionadas para cumplir con las exigencias de gobernanza que vendrán.
Pero la regulación es el argumento mínimo. El argumento de fondo es de madurez organizacional.
Las empresas que logran escalar IA no son necesariamente las que eligieron el mejor modelo. Son las que construyeron la disciplina de medir, ajustar y comunicar resultados con precisión suficiente para sostener el apoyo interno a lo largo del tiempo. Esa disciplina requiere que alguien en el equipo directivo asuma la incomodidad de decir: "Todavía no sabemos si esto funciona porque no definimos a tiempo qué significaría que funcionara."
Hay organizaciones donde esa conversación nunca ocurrió porque ningún ejecutivo quiso ser el que pusiera en duda el entusiasmo del equipo, o porque el piloto llegó con demasiado ruido político como para que alguien se atreviera a proponer criterios de fracaso claros. El resultado es lo que vemos con frecuencia: proyectos que se sostienen en iteraciones sin dirección, con equipos técnicos que optimizan métricas que nadie en el comité directivo puede interpretar, y líderes que aprueban presupuestos adicionales por miedo a reconocer que la primera inversión no entregó lo que prometía.
La IA no resuelve ese problema. Lo amplifica. Un sistema que genera cientos de miles de interacciones por semana amplifica tanto el valor como el error. Si no sabes qué estás midiendo, tampoco sabrás qué estás multiplicando.
El modelo siempre va a mejorar. Los proveedores lanzarán versiones más capaces en ciclos cada vez más cortos. Lo que no cambia por sí solo es la capacidad de una organización para establecer criterios claros antes de actuar, medir con honestidad lo que ocurre y ajustar sin necesidad de reconstruir el proyecto desde cero. Eso no lo entrega ningún modelo. Lo construye el liderazgo, o no lo construye nadie.
