NIST quiere enterrar el "cumplimiento puntual" en IA: su nueva prueba matemática apunta a vigilancia continua, no a auditorías de escaparate

La idea de que un sistema de IA puede evaluarse una vez, recibir un sello de conformidad y quedarse tranquilo en producción acaba de recibir un golpe incómodo desde Gaithersburg. NIST ha publicado una noticia sobre un trabajo que extiende a la IA una lógica inspirada en Kurt Gödel para defender algo que, en ciberseguridad, muchos ya intuían y no pocos preferían no escuchar: no existe una forma finita y definitiva de demostrar que un sistema de IA seguirá siendo seguro en todos los contextos futuros. Traducido al lenguaje que entienden los equipos de riesgo, compliance y producto: revisar, desplegar y olvidarse ya no cuela. Si alguna vez coló.

La novedad no está solo en el mensaje, sino en quién lo formula. NIST no es un think tank buscando titulares; es el organismo técnico estadounidense que lleva años marcando el paso en marcos que luego se convierten, de facto, en referencia global. El AI Risk Management Framework 1.0 se publicó en enero de 2023. En julio de 2024 lanzó la primera versión del AI RMF Generative AI Profile, ya orientada a riesgos específicos de IA generativa. Y ahora da un paso más incómodo: sugiere que la propia naturaleza matemática del problema hace inviable el viejo modelo de certificación puntual. No es una recomendación estética. Es un cambio de modelo.

Para Europa, esto importa más de lo que parece. El AI Act ya parte de una lógica de ciclo de vida: gestión de riesgos continua, vigilancia post-comercialización, registro de incidentes, control de cambios y supervisión humana. Lo dice el artículo 9 sobre sistema de gestión de riesgos, el artículo 15 sobre precisión, solidez y ciberseguridad, el artículo 72 sobre vigilancia post-market y el artículo 73 sobre notificación de incidentes graves. La prueba de NIST no cambia el texto legal europeo, pero sí refuerza la interpretación más exigente del mismo: el cumplimiento en IA no es una foto; es una película. Y bastante cara de producir, por cierto.

Lo que NIST está diciendo de verdad, sin envoltorio académico

La noticia de NIST, publicada en junio de 2026, resume un trabajo que aplica a la seguridad de sistemas de IA una lógica emparentada con los teoremas de incompletitud de Gödel. El titular puede sonar grandilocuente, pero el núcleo es bastante práctico. Si un sistema es lo bastante complejo y su comportamiento depende de entradas cambiantes, de actualizaciones, de interacción con otros sistemas y de un entorno que también cambia, no puedes construir una prueba cerrada que garantice de una vez por todas que nunca exhibirá un comportamiento peligroso, inseguro o no previsto.

Eso no significa que toda verificación sea inútil. Significa otra cosa, más molesta: la verificación está condenada a ser parcial, contextual y temporal. Sirve para reducir riesgo, no para abolirlo. Y obliga a sustituir el modelo de "evaluación ex ante y certificado" por otro de "medición continua, telemetría, actualización y reevaluación".

Si te suena a cómo funciona ya la ciberseguridad clásica, exacto. Nadie sensato cree hoy que un pentest anual agote el problema de seguridad de una entidad financiera. Nadie serio confunde una auditoría de junio con resiliencia en noviembre. NIST viene a decir que con IA ocurre lo mismo, solo que con un nivel extra de opacidad y variabilidad. Un modelo puede degradarse, ser manipulado mediante nuevas técnicas de prompt injection, combinarse con agentes externos, conectarse a herramientas, heredar datos distintos a los evaluados inicialmente o mostrar fallos emergentes tras una actualización aparentemente menor. La seguridad deja de ser una propiedad estática del artefacto. Pasa a ser una disciplina operativa.

Aquí está el quid. Durante años, parte del mercado ha vendido “IA fiable” como si fuese un electrodoméstico con etiqueta energética: se revisa, se sella y a otra cosa. NIST está diciendo que esa comodidad intelectual no resiste el análisis matemático. Y cuando una comodidad regulatoria se cae, lo siguiente suele ser una factura para los equipos de control.

La colisión con la realidad regulatoria europea: el AI Act ya iba por ahí

Europa no necesita esperar a NIST para llegar a esta conclusión. El Reglamento de IA de la UE, formalmente aprobado en 2024 y aplicable por fases, ya está construido sobre una lógica de ciclo de vida. Las prohibiciones empezaron a aplicarse seis meses después de su entrada en vigor; las obligaciones para modelos GPAI llegaron en fases posteriores; y el grueso de las obligaciones para sistemas de alto riesgo se consolida a los 24 meses desde la entrada en vigor, con otros hitos adicionales para determinados casos. El calendario importa porque desmonta otra ficción muy extendida: que el AI Act se resolverá con un proyecto documental de última hora.

El artículo 9 exige un sistema de gestión de riesgos que sea continuous iterative process a lo largo de todo el ciclo de vida del sistema de IA de alto riesgo. No es una metáfora. Es texto legal. Exige identificar y analizar riesgos previsibles, adoptar medidas de mitigación apropiadas y volver a evaluar el sistema a la luz de los datos procedentes del uso real y de la vigilancia post-market. Dicho en lenguaje menos ceremonial: si tu modelo cambia, si el contexto cambia, o si tus usuarios hacen cosas creativas con él, tu evaluación inicial caduca.

El artículo 15 añade otra capa: los sistemas de alto riesgo deben alcanzar un nivel apropiado de precisión, robustez y ciberseguridad, y deben seguir funcionando con resiliencia frente a errores, inconsistencias, fallos o intentos de manipulación. Esa última parte es especialmente interesante porque acerca el AI Act al terreno de la ciberseguridad ofensiva. Ya no hablamos solo de sesgo o explicabilidad. Hablamos de ataques, manipulación de entradas, envenenamiento de datos, explotación de integraciones y abuso del comportamiento del modelo.

Luego llega el artículo 72, que exige a los proveedores de sistemas de alto riesgo establecer un sistema de vigilancia post-comercialización proporcional a la naturaleza del sistema y recopilar, documentar y analizar datos sobre el rendimiento a lo largo de su vida útil. Si alguien todavía piensa que el AI Act es una ley de papeles y anexos, aquí tiene el desmentido. Es una ley de operación continua. Más cerca de un security operations center que de un archivador.

Y el artículo 73 remata la jugada con la obligación de notificar incidentes graves y acciones correctivas a las autoridades competentes. Ese esquema se parece mucho más a la lógica de DORA o NIS2 que a la vieja idea de homologación tecnológica puntual. Una IA que falla no es solo un incumplimiento teórico; puede ser un incidente operativo, de seguridad, de protección de datos o de derechos fundamentales, y a veces las cuatro cosas a la vez.

Por eso la aportación de NIST importa en Bruselas, Fráncfort y Madrid. No porque Europa vaya a copiarla artículo por artículo, sino porque ofrece una base técnica para la interpretación más severa del AI Act: la conformidad inicial no sustituye la vigilancia continua. Como mucho la inaugura.

Por qué esto afecta de lleno a bancos, aseguradoras y fintechs sujetas a DORA

El sector financiero europeo no puede permitirse tratar esto como un debate académico. Si una entidad usa IA en concesión de crédito, detección de fraude, prevención de blanqueo, robo-advice, autenticación biométrica, scoring, atención al cliente o priorización de alertas, el problema ya no es solo si el modelo funciona bien hoy. El problema es si la organización tiene capacidad de observarlo, contenerlo, actualizarlo y demostrar que lo hace.

DORA empuja exactamente en esa dirección. El Reglamento (UE) 2022/2554 es aplicable desde el 17 de enero de 2025, y obliga a las entidades financieras a mantener un marco de gestión del riesgo TIC que cubra identificación, protección, detección, respuesta, recuperación y aprendizaje. El artículo 6 define los elementos del marco de gestión del riesgo TIC. El artículo 10 exige capacidades de detección. El artículo 11 regula respuesta y recuperación. El artículo 13 se centra en aprendizaje y evolución. Si metes IA dentro de procesos críticos o importantes, DORA no te deja esconderla en el laboratorio de innovación. La arrastra, con bastante mala leche, al perímetro de control operativo.

Hay otra pieza clave: los terceros. El artículo 28 de DORA exige gestionar el riesgo derivado de terceros proveedores de servicios TIC. En IA, ese perímetro puede incluir proveedores de modelos fundacionales, plataformas de inferencia, herramientas MLOps, proveedores de anotación de datos, servicios cloud y conectores con herramientas externas. Buena parte del mercado aún gestiona esos componentes como compras de software más o menos sofisticadas. Error. Si un modelo externo alimenta una función crítica, la dependencia operativa y de seguridad ya es material aunque el contrato siga llamándolo “servicio inteligente”.

La colisión entre DORA y el AI Act es bastante clara. El AI Act te pide controlar el comportamiento del sistema a lo largo de su ciclo de vida. DORA te pide capacidad operativa para detectar anomalías, responder a incidentes y gobernar terceros ICT. La combinación deja poco margen al compliance de PowerPoint. Una entidad financiera que despliegue IA sin telemetría útil, sin inventario de dependencias, sin criterios de cambios materiales y sin procedimientos de escalado está construyendo una futura explicación para su supervisor, no una capacidad de control.

Y aquí conviene añadir NIS2, aunque el encaje dependa del tipo de organización. La Directiva (UE) 2022/2555 exige en su artículo 21 medidas técnicas, operativas y organizativas apropiadas y proporcionadas, incluyendo gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, evaluación de la eficacia de las medidas y prácticas de higiene cibernética. Una IA integrada en operaciones esenciales no vive al margen de este régimen. Si altera la superficie de riesgo, entra en la conversación. Si provoca un incidente significativo, también.

La parte incómoda: un modelo no se queda quieto aunque tu comité sí

La razón por la que la tesis de NIST resulta tan pertinente es que la IA no falla igual que el software tradicional. Un sistema convencional puede tener un CVE, un bug lógico o una mala configuración. Un sistema de IA añade al menos cinco capas extra de inestabilidad operativa.

La primera es la dependencia del contexto de entrada. Cambias el patrón de consultas, la longitud de los prompts, el idioma, el tipo de usuario o el entorno de uso, y cambia el perfil de riesgo. Esto no es teoría: los sistemas de IA generativa se comportan de forma muy distinta cuando pasan de una demo interna con usuarios entrenados a un canal abierto con clientes reales.

La segunda es la dependencia de datos y de pipelines. Un modelo puede seguir siendo el mismo sobre el papel, pero si cambia la fuente de datos, el filtrado, la recuperación documental o el sistema que inyecta contexto, el comportamiento final se altera. El riesgo está en el conjunto, no solo en el peso del modelo.

La tercera es la integración con herramientas. Cuando un modelo tiene acceso a correo, CRM, base documental, sistemas de ticketing o APIs de ejecución, una alucinación deja de ser un chiste y se convierte en un incidente operativo. Y si además existe capacidad de acción automática, la frontera entre error y evento material se estrecha con bastante rapidez.

La cuarta es la velocidad de actualización. Los proveedores cambian versiones, parámetros, filtros de seguridad, librerías y dependencias con una frecuencia muy superior a la de los ciclos de revisión internos de muchas empresas reguladas. En algunos casos, el modelo subyacente cambia sin que el cliente pueda auditar en detalle qué ha cambiado ni evaluar completamente el impacto. Esto complica tanto el cumplimiento del AI Act como la gestión de terceros exigida por DORA.

La quinta es la aparición constante de nuevos vectores de ataque. Prompt injection, extracción de datos, fuga de secretos, evasión de salvaguardas, envenenamiento de recuperación aumentada, manipulación de agentes, explotación de plugins o herramientas externas. La lista no deja de crecer. Pretender que una evaluación de seguridad ex ante agota ese universo es como pensar que una vacuna de 2019 sirve para todas las variantes de 2026. Ojalá.

Por eso la expresión “continuous monitor and update” no es un eslogan. Es una descripción mínima de lo que ya exige la realidad técnica. NIST le añade ahora una base más ambiciosa: no es solo una buena práctica, sino la respuesta racional a un límite demostrable de verificación completa.

El espejismo de la certificación única: útil para vender, insuficiente para gobernar

El mercado adora los sellos. También los comités de dirección, porque permiten convertir una incertidumbre compleja en una diapositiva ordenada. Certificado obtenido. Evaluación completada. Vendor aprobado. Riesgo mitigado. Todo muy limpio hasta que el sistema cambia, el proveedor actualiza, el uso se amplía o aparece una técnica de abuso no contemplada.

No se trata de despreciar la evaluación previa. Sería absurdo. La documentación técnica, las pruebas de robustez, la evaluación de conformidad, la revisión de sesgos, la validación del caso de uso y la due diligence del proveedor siguen siendo necesarias. El problema aparece cuando se presentan como punto final en lugar de punto de partida.

El AI Act ya distingue entre la evaluación de conformidad y las obligaciones permanentes del proveedor. DORA distingue entre controles definidos y su efectividad operativa. GDPR hace algo parecido desde hace años: el artículo 25 exige protección de datos desde el diseño y por defecto, pero el artículo 32 obliga a mantener medidas técnicas y organizativas apropiadas, y el artículo 33 obliga a notificar violaciones de seguridad de los datos personales en 72 horas. Es decir, ni siquiera en privacidad basta con diseñar bien. Hay que seguir vigilando y responder cuando algo falla. Con IA, ese patrón se vuelve más exigente porque el comportamiento es menos predecible y el ecosistema más dependiente de terceros.

La ironía aquí es bastante evidente. Durante años, muchas organizaciones criticaron la ciberseguridad continua por costosa y compleja, mientras destinaban presupuestos razonables a auditorías periódicas que producían paz burocrática. Ahora la IA amenaza con trasladar esa tensión a una escala mayor. Las revisiones estáticas dan tranquilidad. La monitorización continua da trabajo. Y la regulación, poco a poco, está dejando claro cuál de las dos le parece seria.

Qué cambia en la práctica para CISOs, responsables de IA, compliance y auditoría interna

La consecuencia operativa principal es que la seguridad de IA deja de ser un proyecto de validación y pasa a ser una función sostenida. Eso tiene impacto en gobierno, arquitectura, contratos, métricas y evidencias.

Para el CISO, el primer cambio es de perímetro. Los sistemas de IA no pueden seguir fuera del inventario serio de activos críticos por el hecho de estar etiquetados como “experimental”, “piloto” o “copilot interno”. Si acceden a datos sensibles, si influyen en decisiones o si automatizan acciones, ya son parte del riesgo operacional y de ciberseguridad. Deben entrar en gestión de vulnerabilidades, registro de eventos, detección de abuso, pruebas de seguridad y respuesta a incidentes.

Para el responsable de cumplimiento, el cambio es de evidencia. La pregunta ya no será solo “¿dónde está la evaluación inicial?” sino “¿qué métricas revisas?”, “¿qué cambios consideras materiales?”, “¿cada cuánto reevalúas?”, “¿cómo documentas incidentes y cuasi-incidentes?”, “¿qué umbrales disparan revisión humana?” y “¿qué puedes demostrar sobre proveedores y subprocesadores?”. Si no hay respuesta, no hay gobernanza; hay esperanza, que para auditar sirve regular.

Para auditoría interna, el reto es abandonar el enfoque exclusivamente documental. Habrá que revisar evidencia operativa: logs de prompts y respuestas con controles de privacidad, tasas de rechazo, desvíos de rendimiento, escalados a humano, cambios de versión, pruebas de regresión, incidentes clasificados, decisiones de desactivación y pruebas de resiliencia frente a inputs maliciosos. Esto se parece bastante más a auditar un proceso vivo que a revisar una política firmada.

Para legal y compras, el punto delicado está en los terceros. Contratar IA sin visibilidad sobre cambios de versión, prácticas de seguridad, residencia de datos, subencargados, retención, entrenamiento con datos del cliente, soporte forense o notificación temprana de incidentes es comprar un problema con branding atractivo. DORA, en su artículo 30, ya detalla elementos contractuales clave para servicios TIC que apoyan funciones críticas o importantes. Aunque no todo proveedor de IA encaje automáticamente ahí, el estándar de diligencia se está desplazando con rapidez hacia ese nivel de rigor.

Y para el negocio, la conclusión es bastante simple: no puede pedir velocidad ilimitada y garantías absolutas al mismo tiempo. Si quiere desplegar IA en procesos relevantes, tendrá que aceptar fricción de control. No por capricho del regulador, sino porque la alternativa es peor: sistemas opacos, con comportamiento mutable y responsabilidades difusas. Ese cóctel siempre acaba reclamando a alguien en la sala. Suele ser al que firmó.

Cuatro capacidades que pasan de recomendables a inevitables

No hace falta inventar una nueva religión del control. Pero sí aceptar que algunas capacidades dejan de ser opcionales.

La primera es observabilidad real del sistema de IA. No solo uptime y latencia. También eventos de seguridad, tipos de prompts, patrones anómalos de uso, errores de herramientas, respuestas bloqueadas, acciones ejecutadas, desviaciones frente a pruebas de referencia y resultados de controles de salida. Si no ves lo que hace tu sistema, no estás gestionando IA; estás apostando.

La segunda es gestión de cambios con criterio técnico y legal. Cada actualización de modelo, fine-tuning, cambio de proveedor, ajuste de umbrales, modificación del contexto recuperado o integración con nuevas herramientas debe tener reglas claras de clasificación: cambio menor, cambio significativo, reevaluación requerida, nueva validación, necesidad de intervención humana reforzada, actualización contractual o revisión de base jurídica de tratamiento. Esto no es burocracia añadida; es la única forma de evitar que la evolución del sistema destruya tu trazabilidad.

La tercera es capacidad de reversión o contención. Si el sistema empieza a comportarse mal, necesitas degradarlo, aislarlo, limitar funciones, activar revisión humana o desactivar determinadas herramientas sin hundir la operación entera. En entornos financieros, esta capacidad debería conectarse con los procesos de continuidad y respuesta a incidentes ya exigidos por DORA.

La cuarta es disciplina de pruebas continuas. No basta con probar antes del lanzamiento. Hay que repetir pruebas funcionales, de seguridad y de robustez con datasets de regresión, ataques conocidos y escenarios reales de uso. Igual que un equipo de AppSec no deja de escanear una aplicación tras ponerla en producción, un programa serio de IA no puede dejar de probar porque ya “pasó la validación”.

La diferencia entre las entidades que lo entiendan y las que no será brutal. Las primeras construirán un sistema imperfecto pero gobernable. Las segundas acumularán riesgos invisibles hasta que un incidente les obligue a aprender de golpe y a un precio bastante menos elegante.

La conexión con GDPR: cuando la monitorización continua choca con la minimización de datos

Aquí aparece una tensión real, y conviene no despacharla con tópicos. Si la tesis de NIST empuja a monitorizar continuamente sistemas de IA, esa monitorización puede exigir recopilar más telemetría, más logs, más ejemplos de prompts, respuestas, metadatos de interacción y eventos de uso. Desde la óptica de seguridad y control, tiene sentido. Desde la óptica de protección de datos, abre una pregunta incómoda: ¿cuánta visibilidad puedes acumular sin violar principios de minimización y limitación de la finalidad?

GDPR no prohíbe monitorizar; prohíbe hacerlo sin base, sin límites y sin proporcionalidad. El artículo 5 obliga a que los datos sean adecuados, pertinentes y limitados a lo necesario. El artículo 6 exige base jurídica. El artículo 25 exige protección de datos desde el diseño y por defecto. El artículo 32 exige seguridad del tratamiento. Así que la salida no es renunciar a la observabilidad, sino diseñarla bien: pseudonimización cuando sea posible, separación de entornos, retención limitada, controles de acceso estrictos, redacción automática de datos sensibles en logs, muestreo cuando baste y evaluación de impacto cuando el riesgo lo requiera.

En sistemas de IA que procesan datos personales o contenido sensible, esta tensión será uno de los puntos más mal gestionados de los próximos dos años. Muchas empresas pasarán de no registrar nada a registrarlo todo. Las dos cosas son malas. La primera impide gobernar. La segunda crea un nuevo problema regulatorio. La solución buena, como casi siempre, es menos vistosa: registrar lo necesario para seguridad, calidad y rendición de cuentas, con arquitectura de privacidad desde el diseño. Más ingeniería y menos fe.

Lo que NIST no ha dicho, pero conviene no olvidar

La prueba matemática no convierte cualquier preocupación sobre IA en una verdad absoluta. Tampoco justifica un maximalismo regulatorio sin criterio. Que no exista una garantía total no significa que todos los sistemas sean igual de arriesgados ni que todas las aplicaciones requieran el mismo nivel de control. Un modelo interno para resumir actas de reuniones no merece el mismo tratamiento que un sistema que influye en decisiones de crédito o en filtrado de reclamaciones médicas.

También hay que resistirse a otro reflejo bastante europeo: convertir una constatación técnica sensata en una catarata de obligaciones formales mal calibradas. Si la respuesta a la imposibilidad de verificación completa es pedir más plantillas, más comités y más anexos, el resultado será previsible: cumplimiento teatral y poca capacidad real. NIST apunta hacia monitorización y actualización continuas. La palabra relevante es operativa, no ornamental.

Ahí Europa tiene un riesgo y una oportunidad. El riesgo es burocratizar la idea. La oportunidad es aterrizarla en supervisión técnica verificable. Por ejemplo: exigir criterios de cambios materiales, trazabilidad de versiones, métricas de rendimiento en producción, pruebas periódicas de robustez, inventario de dependencias externas y procedimientos de respuesta a incidentes específicos de IA. Eso sí sería coherente con el AI Act, DORA y NIS2. Lo otro, apilar PDFs, solo engorda archivos.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, EAF, gestoras, entidades de pago y fintech en España, la señal es bastante directa. Si el uso de IA toca procesos críticos, atención al cliente, modelos de fraude, autenticación, análisis de operaciones sospechosas o decisiones con efecto jurídico o equivalente, la gobernanza ya no puede descansar en una combinación de proveedor reputado, cláusula contractual estándar y revisión anual del comité de riesgos tecnológicos.

El Banco de España, la CNMV y la DGSFP no han necesitado esperar a una prueba matemática para interesarse por la resiliencia operativa y la gobernanza de modelos. Pero el mensaje de NIST refuerza la expectativa supervisora de que las entidades podrán explicar cómo vigilan el comportamiento real de sus sistemas. No solo cómo los aprobaron en origen.

Eso afecta especialmente a tres frentes. Uno: externalización y concentración tecnológica. Muchas entidades están consumiendo IA a través de un puñado de hyperscalers y proveedores de modelos. DORA ya obliga a tomarse muy en serio esa concentración. Dos: trazabilidad de cambios. Los proveedores de IA cambian rápido; los procesos internos bancarios, no tanto. Esa asimetría es una fuente de riesgo en sí misma. Tres: integración con procesos regulados. Cuando un modelo pasa de apoyar tareas internas a influir en decisiones de cliente, el umbral de exigencia cambia radicalmente.

Si tu entidad todavía no ha definido qué considera “cambio material” en un sistema de IA, quién autoriza pasar a producción una nueva versión, qué métricas se revisan semanalmente y qué eventos escalan a incidente operativo o de seguridad, no estás tarde para un seminario. Estás tarde para el control.

Mi lectura: NIST acaba de dar munición técnica a la supervisión basada en ciclo de vida

La noticia de NIST no inaugura el problema, pero sí puede cambiar el tono de la conversación. Hasta ahora, muchas discusiones sobre seguridad de IA oscilaban entre dos extremos igual de poco útiles: el entusiasmo ingenuo del “ya lo resolverá el proveedor” y el alarmismo abstracto del “la IA nunca será segura”. NIST introduce una tercera posición, bastante más seria: la seguridad completa y definitiva no es demostrable en sistemas complejos de IA; por tanto, la respuesta racional es un modelo continuo de observación, prueba, actualización y corrección.

Eso encaja con la evolución de la regulación europea y con la dirección de viaje de la supervisión financiera. También encaja con la experiencia básica de cualquier equipo de ciberseguridad que haya visto cómo un entorno aparentemente estable cambia en silencio por actualizaciones, integraciones, configuraciones y usos creativos de los usuarios. La IA solo acelera y amplifica esa dinámica.

El verdadero cambio aquí no es filosófico. Es presupuestario y organizativo. Aceptar la tesis de NIST implica admitir que la IA segura no se compra como licencia; se opera como capacidad. Requiere telemetría, pruebas, ingeniería de control, revisión de terceros, gobierno de cambios, respuesta a incidentes y coordinación entre seguridad, legal, riesgo y negocio. Exactamente el tipo de trabajo que nadie presume en un keynote pero que luego decide quién sobrevive a una inspección, a una incidencia seria o a una demanda.

Durante años, el sector ha vivido bastante bien con la ficción del examen final: llega auditoría, se ordenan papeles, se presenta el modelo, se enseña el proveedor, se enseña la política, y todos vuelven a casa. La IA, si NIST tiene razón —y cuesta ver que no la tenga en lo esencial—, se parece mucho menos a un examen final que a una monitorización cardiaca. Puedes quitarla, claro. Pero entonces lo que pierdes no es comodidad. Es visibilidad justo cuando más la necesitas.

La conclusión para Europa es sencilla y algo incómoda. El AI Act no debería aplicarse como una ley de homologación estática. Debería supervisarse como un régimen de control continuo, especialmente cuando los sistemas son de alto riesgo, están conectados a terceros, procesan datos personales o inciden en funciones críticas. DORA y NIS2 ya han preparado el terreno. NIST solo ha puesto una frase más elegante —y esta vez con matemáticas de fondo— a una verdad muy poco glamurosa: en IA, la seguridad no se obtiene. Se mantiene.