El 6 de julio de 2026, apareció un artículo en ITmedia.
"El cuello de botella para la utilización de la IA está pasando del rendimiento del modelo a la 'evaluación', la 'gobernanza' y la 'eficiencia de costos'", dice Jonathan Frankle, científico jefe de IA en Databricks y cofundador de MosaicML.
Su argumento es simple:
- La IA ya es lo suficientemente inteligente. Solo pensar en cómo usar los modelos existentes deja "décadas de trabajo".
- Lo que se necesita para una mejor implementación de la IA no es desarrollar modelos más inteligentes, sino invertir en evaluación y gobernanza.
- La IA "no es suficiente con un 70% o 90% de precisión"; necesita una evaluación órdenes de magnitud más rigurosa.
- Y el mayor desafío es traducir el estándar humano de "qué es un buen trabajo" en una lista de verificación. Esto "es mucho más difícil que desarrollar el próximo modelo gigante y podría llevar más de 10 años".
Al leer esto, sentí una punzada aguda de comprensión.
Recientemente, he estado experimentando con la medición del "volumen de uso" de la IA. Tengo un panel que extrae la telemetría de uso de "Databricks" x "Claude Code/Codex/Cowork" a través de OpenTelemetry en Databricks, actualizándose cada mañana con "quién usó qué herramienta, cuánto y a qué costo".
Pero el punto del artículo no era ese. "¿Ese trabajo fue bueno?" — La evaluación de la calidad del Agente era un agujero enorme.
Le di el artículo a Fable y le pregunté: "Piensa en lo que deberíamos evaluar"
Entonces, le di la URL del artículo a Claude (Fable 5), que uso regularmente, y le pregunté:
Lee este artículo y piensa en lo que deberíamos estar evaluando.
Después de examinar nuestra infraestructura de registros interna y la configuración del panel, Fable ideó un diseño que consta de "tres capas de cosas a evaluar".
La respuesta de Fable: Tres capas de "Qué evaluar"
Consejo a continuación """""""""""""""""""""""""""""""""
Capa 1: Señales de fricción (Diarias, para todos, juicio mecánico)
Hay "signos de mala calidad" que se pueden detectar mecánicamente a partir de los registros sin siquiera preguntarle a un LLM.
- Bucles sospechosos: Usar la misma herramienta más de 5 veces seguidas.
- Valores atípicos de costo: Gastar más de $5 en una sola sesión.
- Frecuencia de bloqueo: Detenerse muchas veces esperando la confirmación humana.
- Eficiencia de caché: Mala reutilización del contexto (es decir, releer cada vez).
- Fallos de conexión de herramientas: Fracaso continuo al conectarse a servidores MCP.
Capa 2: Calidad del trabajo (Semanal, juez LLM)
Crear un sistema que pase los registros de trabajo del agente de IA (trazas) a un juez LLM para que los puntúe en 8 ejes.
- Logro de objetivos / Precisión / Selección de herramientas / Fidelidad a la evidencia / Validez de los pasos / Recuperación de fallos / Seguridad / Eficiencia
- Aprobado si el promedio es 3.5 o superior. Sin embargo, si "Logro de objetivos" o "Seguridad" es 2 o inferior, es un fracaso inmediato (fallo duro) incluso si todo lo demás es perfecto.
Puntuar automáticamente las sesiones más recientes cada domingo por la noche para que la "tasa de aprobación de la semana" aparezca en la revisión regular del lunes. Solo los fallos duros de seguridad activan una alerta por correo electrónico a la mañana siguiente.
Capa 3: Convertir la evaluación en un producto
El trabajo del que el artículo dice que "lleva 10 años" — "traducir los criterios para un buen trabajo en una lista de verificación" — es exactamente lo que deberíamos estar proporcionando a los clientes como consultores de IA y formadores corporativos. El panel que se ejecuta internamente se convierte en una demostración de ventas tal cual.
"""""""""""""""""""""""""""""""""
Y se implementó ese mismo día
Esta es la parte asombrosa de la era de los agentes: las tres capas comenzaron a ejecutarse ese mismo día.
- Se añadió una vista SQL para la Capa 1 como una pestaña de "Calidad" al panel organizacional y se publicó.
- Se programó la ejecución semanal para la Capa 2 y se integraron las alertas de seguridad en el sistema de monitoreo.
- Se documentó un documento de diseño de oferta para la Capa 3.
Todo lo que hice fue elegir la política, hacer clic en algunos botones de aprobación y ejecutar el comando de registro del programador una vez.
"Descubrimientos" desde el primer día
Y en el primer día de operación, hubo dos descubrimientos inmediatos.
Primero: Estábamos perdiendo mal cuando se medía.
Cuando puntuamos 8 sesiones internas recientes de agentes usando el juez de 8 ejes, el resultado fue — 1 aprobado, 7 fallos. Había una distancia entre "hacer que la IA haga mucho trabajo" y "que la IA haga un buen trabajo" que solo se hizo visible una vez que se midió.
Segundo: Se encontró "fricción que se puede solucionar si se enseña".
En el Cowork (espacio de trabajo del agente de Claude) de un miembro, el panel detectó que los fallos de conexión del servidor MCP habían empeorado de 4 el día anterior a 12 ese día. La autenticación del plugin había estado rota durante dos días, y él seguía usándolo.
La persona probablemente solo pensó: "Está actuando un poco raro", y siguió trabajando. Se puede arreglar en 5 minutos hablando y corrigiendo la autenticación. La "fricción que se puede solucionar si se enseña" se acumula sin que nadie la reporte — esto era exactamente lo que nunca era visible en el panel de uso.
Tres cosas que aprendí al probarlo
1. La evaluación es una operación, no una herramienta
Si solo construyes el mecanismo de puntuación y te detienes, es como si no lo tuvieras. Solo cuando lo conectas a la ejecución regular semanal y las alertas, y los números aparecen en la reunión del lunes, puedes decir que estás "evaluando". La "inversión en evaluación" que menciona Frankle probablemente se refiere a operaciones, no a herramientas.
2. Coloca una capa de juicio mecánico antes del juez LLM
La evaluación del juez de 8 ejes es poderosa, pero cuesta tiempo y dinero porque ejecuta un LLM. Fue realista ejecutar señales deterministas como bucles, valores atípicos de costo y fallos de conexión diariamente para el volumen completo, y usar el juez para el muestreo semanal.
3. Implementar "el 90% no es suficiente" significa fallos duros
Al observar las puntuaciones promedio, los problemas de seguridad quedan enterrados en otros puntos. Solo al diseñarlo para que "si la seguridad es 2 o inferior, es un fallo incluso si los demás son perfectos" nos acercamos un paso más a la "evaluación órdenes de magnitud más rigurosa" mencionada en el artículo. La tasa de aprobación de 1/8 es dolorosa, pero este dolor es el punto de partida para la mejora.
Conclusión
"La IA ya es lo suficientemente inteligente."
— Por eso la próxima batalla es quién puntúa el trabajo encomendado a la IA inteligente y cómo.
Frankle dijo que esto es un trabajo de 10 años.
Las cosas que llevan 10 años se convierten en un diferenciador cuanto antes empieces. Y empezar en sí fue posible en un día con un agente de IA.
En mi empresa (AI Brain Partners), ayudamos a construir este sistema de "medición y evaluación del uso de la IA" a través de formación corporativa especializada en Claude Code y consultoría de IA. Si te preguntas, "¿Qué está pasando realmente con nuestra utilización de la IA?" , consulta los enlaces a continuación.
- Formación en Agentes de IA para Empresas: https://ai-agent.camp/ja/lab/corporate-training
- Informe gratuito "Cómo introducir la IA en las empresas": https://ai-agent.camp/ja/lab/whitepaper-ai-enterprise
(Artículo original: ITmedia AI+ "El cuello de botella para la utilización de la IA se está desplazando hacia la evaluación y la gobernanza" 6 de julio de 2026)
