Benchmarks de IA: lo que miden, lo que ocultan y por qué el 80% no significa nada en producción

El Cuñado tiene una tabla de clasificación y no le va a hacer caso a nadie

El Cuñado dice: "Mira, GPT-5.5 saca un 80% en el benchmark de ciberseguridad del gobierno británico. Si el modelo del Reino Unido lo certifica, es que funciona de puta madre para proteger mi empresa."

La realidad es: Ese 80% mide la tarea más larga, en horas de trabajo humano equivalente, que el modelo completa de forma autónoma con éxito. No mide si detecta una brecha en tu infraestructura, no mide si responde bien cuando hay datos del paciente de por medio, y desde luego no mide si el output es defendible ante un auditor. Según el AI Security Institute (AISI) del gobierno del Reino Unido, esa dificultad se duplica cada 4,7 meses a fecha de febrero de 2026, en noviembre de 2025 era cada 8 meses. La aceleración es real. El problema es que nadie en ventas te explica qué mide exactamente esa cifra.

Por qué importa saberlo: Porque las organizaciones toman decisiones de compra, de despliegue y de auditoría basándose en esas tablas. Y si la tabla mide algo parecido a lo relevante, pero no lo relevante, el riesgo que aceptas no es el que crees que aceptas.

---

Qué mide realmente un benchmark (y qué no puede medir por diseño)

Antes de tirar todo a la basura, hay que ser precisos: los benchmarks no son inútiles. Son una herramienta de medición con un alcance concreto. El problema es que ese alcance se vende como si fuera más amplio de lo que es.

El AISI usa el concepto de horizonte temporal: toma desafíos de ciberseguridad, estima cuánto tardaría un experto humano en resolverlos y luego mide la tarea más larga que un modelo de IA resuelve con un 80% de éxito de forma autónoma. Para que funcione, el modelo tiene que mantener rendimiento en múltiples pasos, gestionar contexto y recuperarse de fallos intermedios. Eso sí es una señal de capacidad ofensiva real, como señala Kat Traxler de Vectra AI: no mide si el modelo detecta una vulnerabilidad aislada, sino si puede encadenar múltiples fallos en un ataque funcional.

Eso tiene valor. El problema es lo que queda fuera.

Las pruebas del AISI limitan los modelos a 2,5 millones de tokens, los bloques de texto que el modelo procesa de golpe. Los ataques reales encadenan múltiples etapas que necesitan más contexto del que ese límite permite. No está confirmado si esa limitación infravalora o sobreestima la capacidad ofensiva real en entornos empresariales, pero sí sesga el resultado de forma sistemática. El benchmark mide algo parecido a lo real, no lo real. Y esa diferencia importa cuando la usas para tomar decisiones de seguridad.

"Un ranking en una tabla de clasificación no es una decisión de confianza. Las puntuaciones de confianza miden cuán seguro está el modelo, no cuán correcto es.", Rob Clark, Seekr

---

El problema de la agregación: cuando el número medio oculta el fallo crítico

Pearl Enterprise evaluó los modelos líderes comparando sus respuestas con las de expertos en cinco dominios: negocios, salud, derecho, mascotas y tecnología. GPT-5.5 alcanzó un 72,7% de alineación experta en agregado. Suena aceptable hasta que abres el desglose:

• Negocios: 80,9%
• Salud: 68,8%
• Mascotas: 62,1%

La variabilidad entre dominios es de casi 19 puntos porcentuales. Y el número agregado la oculta como un truco de mago.

¿Qué significa eso en la práctica? Que si despliegas ese modelo para uso general en tu empresa y el 30% de las consultas son sobre salud, el rendimiento real de esas consultas no es 72,7%. Es 68,8%, y podría ser peor en subdominios específicos que el benchmark de Pearl tampoco desglosa (Pearl no detalla el número de preguntas por dominio ni el perfil exacto de los expertos que generaron las respuestas de referencia).

Andy Kurtzig, CEO de Pearl, lo resume sin anestesia: un modelo que responde con total confianza pero se equivoca es como un estudiante de C- que se cree de A+. Y eso es exactamente el perfil más peligroso: confianza alta, precisión baja. El modelo no te avisa de que no sabe. Contesta igual de seguro cuando acierta que cuando mete la pata.

Los benchmarks públicos miden capacidad. No miden calibración, no miden seguridad, no miden si la respuesta es defendible ante un auditor. Como señala Varun Badhwar, CEO de Endor Labs, su empresa ejecuta el Agent Security League precisamente para rastrear la brecha entre código que pasa tests funcionales y código que es realmente seguro. Esa brecha no aparece en ninguna tabla de clasificación pública.

---

El caso de la contabilidad: cuando el benchmark prueba algo que no existe en producción

El desmontaje más limpio de cómo un benchmark puede ser técnicamente correcto y prácticamente irrelevante viene del sector contable.

Hay dos benchmarks relevantes aquí. TaxCalcBench evalúa modelos de lenguaje en condiciones de aislamiento total: sin andamiaje, sin motor de impuestos, pidiéndoles calcular un Form 1040 de una sola pasada. El mejor modelo obtiene alrededor del 35% de acierto estricto. Los propios autores reconocen que están probando cálculo puro, no sistemas de producción.

DualEntry evalúa modelos en tareas de flujo de trabajo contable, clasificación de transacciones, asientos, conciliación, informes financieros, también en aislamiento. El mejor modelo puntúa alrededor del 79%.

Ambos números son reales. Ambos son casi irrelevantes para entender qué pasa en producción.

¿Por qué? Porque en Tax Season 2026, los sistemas de IA en producción para impuestos no son modelos aislados. Son flujos de trabajo con agentes especializados, clasificación de documentos, planificación, población de hojas de trabajo, revisión, acoplados a un motor de impuestos determinista que maneja cálculos, validación e interfaces de revisión. El trabajo del modelo no es generar una declaración desde cero. Es revisar un borrador que ya tiene gran parte del trabajo hecho por el sistema determinista que lo rodea.

Los benchmarks prueban al modelo solo en el campo. Los sistemas de producción juegan en equipo.

Hay más problemas que los tests ignoran por completo:

El contexto incompleto. Aproximadamente una cuarta parte de los archivos necesarios para una declaración no son documentos fiscales, sino correos, notas del cliente y papeles de trabajo de años anteriores. Sin ese contexto, la precisión cae, no por falta de razonamiento del modelo, sino porque trabaja con una imagen incompleta. El benchmark no simula eso.

La naturaleza iterativa del trabajo. Los benchmarks realizan tareas de una sola pasada. En la vida real los documentos llegan en oleadas, la salida del agente es revisada por un agente secundario que señala inconsistencias, y el ciclo preparador-revisor-cliente se repite varias veces. Un benchmark de una sola pasada prueba un sprint cuando el trabajo real es un maratón.

La jerarquía de revisión. La contabilidad tiene una estructura: pasantes y preparadores junior producen borradores, seniors y gerentes revisan, socios firman. La IA está reemplazando el primer nivel de preparación. La revisión humana sigue operando encima. La pregunta relevante no es si el agente produce una declaración perfecta, nunca lo hará en producción sin revisión, sino si produce un primer borrador más rápido y con menos errores que un junior. Ningún benchmark mide eso.

Y hay un comportamiento que los benchmarks directamente no capturan: cuando el agente no está seguro, los sistemas bien diseñados plantean una incidencia al revisor en lugar de adivinar. Ese comportamiento dirige la atención humana a los puntos donde el juicio importa. Es más valioso que una puntuación de acierto/fallo en un test de una sola pasada. Pero no aparece en ninguna tabla.

---

Sanidad: cuando ignorar la calibración mata

Si en ciberseguridad y contabilidad los benchmarks tienen agujeros serios, en sanidad el problema se vuelve directamente peligroso.

Un estudio citado en HIT Consultant encontró que el 95,4% de las evaluaciones de IA en salud se centran en precisión. Equidad y sesgo aparecen en el 15,8% de los estudios. Consideraciones de despliegue, en el 4,6%. Calibración e incertidumbre, en el 1,2%. Solo el 5% de los ensayos usaron datos reales de atención al paciente.

El problema de obsesionarse con la precisión es que oculta la calibración. Las métricas de precisión miden ranking relativo: si el modelo ordena bien los riesgos de mayor a menor. Pero las decisiones clínicas dependen de umbrales absolutos: no de si el paciente A tiene más riesgo que el paciente B, sino de si el riesgo del paciente A justifica una intervención ahora mismo. Un modelo puede clasificar bien riesgos relativos y aun así fallar sistemáticamente al determinar si un riesgo concreto cruza el umbral de acción.

Y luego está la varianza en subgrupos. Un modelo puede funcionar bien en promedio y fallar específicamente en enfermedades raras, minorías étnicas o categorías subrepresentadas en los datos de entrenamiento. El rendimiento promedio oculta esa varianza. Si tu hospital atiende a una población con características demográficas distintas a las del dataset de entrenamiento, el 80% de accuracy del benchmark no se traslada a tu contexto.

La recomendación que sale de todo esto es lo que en HIT Consultant llaman un playbook de evaluación que incluya: validación técnica completa (AUROC, F1, calibración, sensibilidad), rendimiento por subgrupo, validación temporal y en datos locales, pruebas silenciosas, ejecutar el modelo en entornos reales sin afectar la atención para comparar predicciones con resultados observados, y monitoreo continuo post-despliegue para detectar derivas. Nada de eso aparece en un benchmark público.

---

La pregunta que nadie hace en la tabla de clasificación

Hay un patrón que cruza los cuatro dominios analizados, ciberseguridad, benchmarks generales, contabilidad y sanidad, y es el mismo: los benchmarks miden lo que es fácil de medir, no lo que importa en producción.

El AISI mide horizonte temporal con límites de tokens que no existen en ataques reales. Pearl mide alineación experta en agregado que oculta fallos críticos por dominio. TaxCalcBench mide cálculo puro en aislamiento cuando en producción el modelo trabaja integrado en un sistema determinista. Los estudios de salud miden precisión cuando lo que mata es la mala calibración en subgrupos específicos.

Patrick Sullivan, de A-LIGN, formula la pregunta correcta: "¿Puedo producir evidencia de que el sistema funcionó correctamente en mi caso de uso específico?" Esa pregunta no tiene respuesta en ninguna tabla de clasificación pública. Porque requiere validación en tus datos, en tu infraestructura, con tu distribución de casos de uso, y con monitoreo continuo después del despliegue.

Lo que sí puedes extraer de los benchmarks públicos:

• Capacidad relativa entre modelos en tareas controladas. Útil para saber con cuál empezar a probar, no para decidir si desplegar.
• Señales de regresión cuando salen nuevas versiones. Si un modelo puntúa peor en un benchmark que en la versión anterior, algo ha cambiado.
• Áreas de debilidad conocida cuando el benchmark desglosa por dominio o tipo de tarea. El desglose de Pearl por dominio, aunque imperfecto, es más útil que el número agregado.

Lo que no puedes extraer:

• Si el modelo es seguro en tu contexto.
• Si la salida es defendible ante un auditor regulatorio.
• Si el rendimiento se mantiene cuando los datos del mundo real difieren del dataset del benchmark.
• Si el modelo falla de forma silenciosa o avisa cuando no sabe.

Nosotros hemos pasado por este ejercicio en el laboratorio de Domina IA. Probamos qué arquitectura de bot aguanta el lenguaje natural real de los clientes (con todas las abreviaciones, faltas y cambios de tema que conlleva) y documentamos qué modelos resistían sin romperse: qué arquitectura de bot aguanta el lenguaje natural del cliente. Y cuando quisimos saber qué LLMs funcionan mejor como backend para generación de leads, montamos un benchmark propio con criterios de producción y comparamos los modelos que realmente se usan en ese contexto: los 6 mejores LLMs backend para leads, con benchmark propio. Los números en papel y los números en tu flujo de trabajo son dos cosas distintas.

---

La aceleración que sí debería preocuparte

Volviendo al dato del AISI que abre este artículo: la dificultad de las tareas de ciberseguridad que los modelos pueden completar se duplicaba cada 8 meses en noviembre de 2025. Para febrero de 2026, esa cifra había bajado a 4,7 meses. Modelos como Claude Mythos Preview y GPT-5.5 muestran capacidades mayores aún.

Eso no significa que la IA esté hackeando empresas de Fortune 500 de forma autónoma esta semana. Significa que la velocidad de mejora es superior a la velocidad a la que los benchmarks se actualizan para medir esas capacidades. Los tests que hoy parecen difíciles pueden quedarse obsoletos en menos de un año.

Y ahí está el problema real: no que los benchmarks sean malos, sino que el ritmo al que el mundo real supera a las métricas se está acortando. El Ministerio de IA del Reino Unido ya advirtió en abril de 2026, en una carta abierta a empresas, que las capacidades cibernéticas avanzan más rápido de lo esperado y generan riesgos reales para organizaciones con defensas débiles. No como predicción futura. Como descripción del presente.

El benchmark te dice que el modelo aprueba el examen. Tu infraestructura tendrá que aprobarlo también, en condiciones que ningún benchmark diseñó para medir. Y ese examen no avisa de cuándo empieza.

---

Preguntas frecuentes

¿Los benchmarks de IA son completamente inútiles?

No, pero su utilidad es más estrecha de lo que se vende. Sirven para comparar capacidad relativa entre modelos en tareas controladas y detectar regresiones entre versiones. Lo que no miden es rendimiento en producción, calibración, seguridad en contextos específicos ni si la salida es defendible ante un auditor. Para eso necesitas validación en tus propios datos y tu propio contexto.

¿Qué significa que la dificultad de ciberseguridad se duplica cada 4,7 meses según el AISI?

El AISI del Reino Unido mide el horizonte temporal: la tarea más larga, en horas de trabajo humano equivalente, que un modelo completa con 80% de éxito de forma autónoma. Que esa dificultad se duplique cada 4,7 meses (dato de febrero de 2026, con modelos limitados a 2,5 millones de tokens) indica aceleración en capacidad autónoma ofensiva, no velocidad de ataque. Es una señal de tendencia, no una medida de riesgo operativo directo.

¿Por qué el 72,7% de alineación experta de GPT-5.5 no es suficiente para confiar en él en salud?

Porque ese porcentaje es un agregado que oculta varianza crítica. En el benchmark de Pearl Enterprise, GPT-5.5 alcanzó 68,8% en salud y 62,1% en mascotas frente al 80,9% en negocios. Además, la alineación experta mide concordancia con respuestas de referencia, no calibración ni comportamiento en subgrupos clínicos específicos. Un 68,8% con alta confianza en respuestas incorrectas es más peligroso que un 60% que admite incertidumbre.

¿Cómo debería evaluar un sistema de IA antes de desplegarlo en mi empresa?

Valida en tus propios datos, no en el dataset del benchmark. Mide rendimiento por subgrupo relevante para tu caso de uso. Comprueba calibración: si el modelo dice que está 90% seguro, ¿acierta el 90% de las veces? Ejecuta pruebas silenciosas en producción antes de dejar que afecte decisiones reales. Y establece monitoreo continuo post-despliegue para detectar derivas. Ninguno de estos pasos aparece en una tabla de clasificación pública.