Bajada. El Centre for AI Measurement, liderado por el National Physical Laboratory (NPL), propone una capa práctica entre los marcos de gobernanza y los estándares: protocolos repetibles para demostrar cómo se comporta un sistema de IA, bajo qué condiciones y con qué incertidumbre. Para las empresas, la confianza empieza a parecerse menos a una promesa y más a una evidencia que otro equipo puede revisar.
La noticia más importante sobre IA de esta semana no trae un modelo nuevo ni una demo espectacular. Trae una pregunta incómoda: ¿cómo puede una empresa demostrar que su sistema funciona como dice que funciona?
El 10 de noviembre de 2026, el National Physical Laboratory del Reino Unido celebró el lanzamiento oficial de su Centre for AI Measurement, una iniciativa dedicada a construir la base científica para probar, evaluar, verificar, validar y monitorizar sistemas de IA. El centro trabajará con investigadores, empresas, gobierno, organismos de estándares y proveedores de aseguramiento.
La propuesta llega en un momento preciso. Las organizaciones ya cuentan con marcos de riesgo, políticas internas y principios de IA responsable. Lo que suele faltar es el procedimiento técnico que convierta esos principios en una afirmación comprobable: qué se midió, con qué datos, en qué versión del sistema, bajo qué configuración y con qué límites.
El hueco entre la política y la prueba
El NPL describe el Centre for AI Measurement como una iniciativa nacional para desarrollar la ciencia de medición necesaria para evaluar la calidad y la confiabilidad de la IA. Su programa se organiza en tres frentes:
- avanzar en los fundamentos de medición para las pruebas y evaluaciones de IA;
- trabajar con la industria y el sector público en métodos de aseguramiento aplicables a casos reales;
- mejorar la coordinación, el intercambio de conocimiento y las capacidades del ecosistema de aseguramiento.
En el lanzamiento oficial del 10 de noviembre, NPL planteó que las evaluaciones necesitan ser más robustas, repetibles y comparables. No basta con afirmar que un modelo es seguro, preciso o fiable. Hay que poder explicar qué significa esa afirmación para un sistema concreto y cómo se obtuvo la evidencia.
La diferencia parece técnica, pero cambia decisiones de negocio. Un marco puede decir que una empresa debe gestionar el riesgo de un sistema. Un protocolo puede especificar cómo probar una propiedad, registrar la variabilidad, documentar los resultados y dejar claro cuándo la conclusión ya no es válida.
Qué es un protocolo de medición para IA
El documento de NPL, From Frameworks to Protocols: A Measurement Science Foundation for Technical AI Assurance, propone usar protocolos como una capa intermedia entre los marcos de gobernanza y los estándares formales.
Un protocolo no es una lista genérica de buenas intenciones. Es un procedimiento completo, repetible y declarado antes de la prueba para generar evidencia técnica sobre una propiedad concreta de un sistema de IA, en condiciones definidas. Entre otras cosas, debería dejar establecido:
- qué propiedad o pregunta se está evaluando;
- cuál es el sistema bajo prueba, su versión y configuración;
- qué entradas, datos y referencias se utilizarán;
- qué pasos, decisiones y opciones están permitidos;
- qué métricas se aplicarán y cómo se tratarán la variabilidad y la incertidumbre;
- qué comprobaciones de validez y límites tiene el resultado;
- qué registro de evidencia y afirmación técnica se entregarán al final.
La propuesta también contempla una biblioteca modular. Habría protocolos para la evaluación técnica antes del despliegue, la monitorización operativa, los incidentes, la verificación de integraciones, la validación en el entorno de uso y la publicación de evidencia. En sistemas generativos, con recuperación de información o capaces de usar herramientas, ese enfoque es especialmente relevante: el comportamiento no depende solo del modelo, sino también de los datos, permisos, interfaces, instrucciones y contexto.
Hay un límite importante. NPL aclara que un protocolo no es por sí mismo una certificación ni una decisión de conformidad. Puede generar evidencia y aplicar un umbral previamente definido, pero la decisión de si un sistema es aceptable, seguro o adecuado depende del uso previsto, del marco correspondiente y de quien tenga la responsabilidad de decidir.
La lectura Olbrite: la confianza se está convirtiendo en un activo operativo
Durante años, muchas conversaciones sobre IA empresarial se quedaron atrapadas entre dos extremos: la promesa comercial y la prohibición preventiva. El enfoque de NPL abre una tercera vía: medir de forma disciplinada para poder decidir.
La tesis es sencilla: a medida que la IA entra en procesos importantes, la capacidad de demostrar su comportamiento será tan valiosa como la capacidad de producir una respuesta.
Eso modifica el expediente que acompaña a un sistema. Ya no debería contener solo una política aprobada o una captura de una demo. También necesita la versión exacta que se evaluó, el conjunto de pruebas, las condiciones de ejecución, los resultados, la incertidumbre, las excepciones y las señales que obligan a repetir la evaluación.
Para el proveedor, ese expediente facilita explicar qué puede prometer y dónde no. Para el comprador, permite comparar afirmaciones que de otro modo parecen equivalentes. Para operaciones, crea una base para detectar cuándo la evidencia dejó de representar el entorno real.
La medición no elimina la incertidumbre. La hace visible y gestionable. Esa diferencia es decisiva cuando un sistema puede recomendar una acción, afectar a un cliente, activar una herramienta o tomar decisiones a una escala que una revisión manual no puede cubrir.
Qué cambia para las empresas
1. Operaciones: probar el sistema completo, no solo el modelo
Una evaluación aislada del modelo puede perder los riesgos que aparecen cuando se conecta a documentos, APIs, bases de datos, usuarios y reglas internas. El objeto de prueba debe incluir la configuración real o una representación suficientemente fiel del flujo de trabajo.
Esto exige registrar más que la salida final: entradas, permisos, llamadas a herramientas, cambios de contexto, intervención humana, errores y acciones posteriores. La trazabilidad deja de ser un requisito de auditoría que se revisa al final y pasa a formar parte del diseño operativo.
2. Compras: comparar evidencia, no únicamente benchmarks
Dos proveedores pueden presentar resultados altos en una misma prueba y comportarse de manera distinta en el caso de uso de una empresa. Los protocolos ayudan a preguntar qué se midió, bajo qué condiciones, con qué configuración y si el resultado se puede reproducir.
En una compra de IA, conviene exigir una declaración técnica con alcance y límites explícitos. Un número sin contexto puede ser una señal de marketing; una prueba documentada permite tomar una decisión.
3. Producto y riesgo: convertir la incertidumbre en umbrales de acción
No todas las desviaciones tienen la misma gravedad. Un sistema que tarda más en una tarea rutinaria no se gestiona igual que uno que accede a información fuera de sus permisos. La empresa necesita definir qué variaciones son aceptables, cuáles activan una revisión y cuáles obligan a detener el sistema.
La lógica de protocolos permite conectar métricas con decisiones: repetir una evaluación, reducir permisos, pedir revisión humana, cambiar de versión o retirar una integración.
4. Personas: la responsabilidad no desaparece al automatizar
Un resultado medido no sustituye el criterio profesional. Al contrario, permite que las personas sepan qué están revisando y qué no está demostrado. Equipos de producto, seguridad, operaciones y legal necesitan compartir un lenguaje sobre validez, incertidumbre, evidencia y límites.
La pregunta útil no es si existe un humano “en el circuito”. Es quién tiene autoridad para intervenir, qué información recibe y cuánto tarda en actuar cuando la evidencia muestra una desviación.
5. Costes: medir antes puede reducir retrabajo después
Diseñar pruebas repetibles requiere tiempo, almacenamiento y disciplina. Pero reconstruir un incidente sin registros, repetir una evaluación con métodos distintos o comparar versiones sin condiciones equivalentes también tiene un coste, normalmente más alto y más urgente.
La oportunidad está en reutilizar protocolos y evidencias. Una prueba bien descrita puede servir para compras, controles internos, revisión de proveedores y seguimiento de una nueva versión, sin empezar desde cero cada vez.
6. Estrategia: la confianza verificable puede acelerar la adopción
El aseguramiento no tiene por qué ser el freno de la innovación. Una organización que estandariza las pruebas de casos de bajo riesgo puede reservar el análisis más profundo para los usos con mayor impacto. El propio objetivo del Centre for AI Measurement es que los resultados sean comparables y que la evidencia pueda viajar entre organizaciones y sectores.
Eso crea una ventaja práctica: quien puede mostrar límites, condiciones y resultados con claridad tiene más posibilidades de superar una revisión de seguridad, una compra empresarial o una ampliación de alcance.
Qué hacer esta semana
- Inventariar las afirmaciones críticas. Para cada sistema de IA en producción o piloto, escribir qué se afirma sobre precisión, seguridad, velocidad, ahorro o cumplimiento y qué evidencia respalda cada afirmación.
- Definir el sistema bajo prueba. Registrar modelo, versión, instrucciones, datos, herramientas, permisos, configuración y entorno. Si solo se prueba el modelo, declarar esa limitación.
- Predeclarar una prueba repetible. Fijar la pregunta, las entradas, las métricas, los umbrales y los criterios de exclusión antes de mirar los resultados.
- Añadir incertidumbre y límites. Documentar la variabilidad esperada, los casos no cubiertos y las condiciones que invalidan la conclusión. Un resultado sin límites invita a sobreinterpretarlo.
- Conectar la evidencia con una decisión. Definir qué ocurre si el sistema supera, iguala o no alcanza el umbral: aprobar, escalar a revisión, restringir permisos, repetir la prueba o detener el despliegue.
Qué observar ahora
El lanzamiento del centro no convierte todavía sus propuestas en una certificación obligatoria ni en una norma universal. El trabajo está construyendo métodos, casos de uso y una infraestructura de aseguramiento que todavía deberá probar su utilidad en contextos reales.
Las señales siguientes serán concretas: qué protocolos se pilotan con empresas, cómo se comparan resultados entre evaluadores, qué tratamiento reciben los sistemas que cambian con el tiempo y qué formatos de evidencia aceptan compradores, reguladores y aseguradores. También será importante ver si la flexibilidad de los protocolos se mantiene sin perder reproducibilidad.
La conversación conecta con dos debates que ya hemos tratado en Olbrite. En Australia cambia la regla para la IA de frontera: reportar el fallo será parte del producto, la obligación central era poder detectar y notificar incidentes. En La reproducibilidad de una IA puede romperse antes de que empiece a aprender, el problema aparecía antes, en la posibilidad de repetir y comparar un resultado. Los protocolos de medición unen ambos extremos: sin evidencia reproducible, el reporte se vuelve una narración; sin seguimiento operativo, la prueba envejece.
La IA empresarial no será confiable porque prometa menos errores. Será confiable cuando una organización pueda mostrar, con método y límites, qué midió, qué encontró y qué hace cuando la realidad se aparta de la promesa.
