NIST activa las sesiones de primavera de 2026 para su Cyber AI Profile: esta vez no va solo de IA, va de gobernanza técnica usable

NIST ha abierto las Spring 2026 CSF 2.0 Cyber AI Profile Virtual Working Sessions y el detalle merece más atención de la que suena a primera vista. No es un gran titular de esos que disparan la adrenalina regulatoria, pero sí una señal bastante más útil: el instituto que redactó el lenguaje operativo de referencia para media industria está intentando convertir el caos de la IA aplicada a ciberseguridad en algo que un CISO, un responsable de riesgo y un auditor puedan discutir sin hablar cada uno un dialecto distinto.

La noticia, en bruto, es sencilla: el National Institute of Standards and Technology, a través del NCCoE, ha convocado sesiones virtuales de trabajo en primavera de 2026 para desarrollar y contrastar el Cyber AI Profile alineado con NIST Cybersecurity Framework 2.0. La lectura menos obvia es la que importa: NIST está intentando bajar la conversación sobre IA desde el pedestal estratégico al terreno incómodo donde siempre acaba todo, que es el de los controles, las dependencias, la validación y la rendición de cuentas.

Eso tiene implicaciones reales. Sobre todo para organizaciones que ya usan IA en operaciones de seguridad, detección de fraude, priorización de alertas, clasificación de vulnerabilidades, gestión de identidades o automatización de respuesta. Si tu empresa sigue diciendo que “está explorando casos de uso”, probablemente llega tarde. Muchas ya no están explorando nada: están desplegando copilotos de SOC, motores de triage, análisis de telemetría con LLM y sistemas de scoring automatizado. El problema es que la gobernanza sigue yendo por detrás. Como casi siempre.

Conviene situar esto bien. El CSF 2.0, publicado por NIST el 26 de febrero de 2024, amplió el marco clásico y formalizó seis funciones: Govern, Identify, Protect, Detect, Respond y Recover. La novedad relevante no fue estética. Fue política y operativa. La función Govern metió de lleno la responsabilidad corporativa, la estrategia, la tolerancia al riesgo, la supervisión de terceros y la integración con el ciclo de negocio. Dicho sin diplomacia: ya no basta con que seguridad haga cosas técnicas en una esquina. El consejo y la dirección tienen que poder explicar qué riesgos aceptan, qué automatizan y por qué.

Ese cambio encaja casi de forma quirúrgica con el debate sobre IA en ciberseguridad. Porque aquí el problema no es solo usar IA para defenderse. El problema es usarla sin poder demostrar qué dato alimenta al sistema, qué dependencia externa introduce, qué sesgos genera en la clasificación de eventos, cómo se valida antes de ponerla en producción y qué pasa cuando alucina con la seguridad de alguien. Y sí, un modelo puede alucinar igual de alegremente que un PowerPoint de proveedor.

Por qué estas sesiones de trabajo importan más de lo que parece

Una convocatoria de sesiones virtuales suena burocrática. A menudo lo es. Pero cuando NIST organiza grupos de trabajo de este tipo, está haciendo algo bastante específico: reunir a industria, técnicos, académicos y sector público para aterrizar un lenguaje común que luego acaba influyendo en procurement, auditoría, controles internos, guías sectoriales e incluso en cómo otros reguladores redactan sus propias expectativas.

El Cyber AI Profile apunta precisamente ahí. Un perfil de NIST no es una ley ni una certificación. Es una forma estructurada de aplicar el CSF a un contexto concreto. En este caso, a la intersección entre IA y ciberseguridad. Eso significa traducir principios amplios a resultados esperables: inventario de sistemas de IA con impacto en funciones de seguridad, control de acceso a modelos y datos, validación de rendimiento, gestión de proveedores, protección frente a manipulación, monitorización de deriva, respuesta ante comportamiento anómalo y retirada segura del sistema cuando deja de ser fiable.

La diferencia entre eso y el ruido habitual del mercado es abismal. El mercado te vende “AI-powered security”. NIST quiere saber si el sistema se puede gobernar, si su uso es proporcional al riesgo, si produce evidencia y si la organización sabría qué hacer cuando ese sistema falla justo en el peor momento. Son preguntas mucho menos sexys. También mucho más útiles.

Hay además un punto institucional que no conviene perder de vista. El NCCoE lleva años trabajando con colaboraciones público-privadas para construir implementaciones de referencia. Cuando abre sesiones de trabajo de primavera de 2026 sobre un perfil de este tipo, no está improvisando una moda. Está reconociendo que la adopción de IA en funciones de seguridad ya ha alcanzado masa crítica suficiente como para requerir taxonomía, criterios y patrones compartidos.

La pregunta de fondo no es si la IA cambia la ciberseguridad. Eso ya ocurrió. La pregunta es quién define primero el vocabulario operativo con el que luego se van a pedir explicaciones. Y ahí NIST tiene una ventaja incómoda para el resto: cuando NIST nombra un problema, media cadena de suministro estadounidense y buena parte de la internacional empieza a copiar el diccionario.

Lo que probablemente busca cubrir el Cyber AI Profile

A falta de un texto final cerrado, sí se puede anticipar con bastante prudencia qué ámbitos va a querer ordenar un perfil de este tipo, precisamente porque el CSF 2.0 ya marca la arquitectura y porque NIST ha trabajado en paralelo marcos como el AI Risk Management Framework 1.0, publicado en enero de 2023. El valor no estará en inventar conceptos nuevos, sino en coserlos bien.

Primero, inventario y propósito. Suena elemental, pero sigue fallando. Muchas organizaciones tienen herramientas de seguridad con componentes de IA o aprendizaje automático integrados por terceros sin un inventario real de qué módulo hace qué, con qué datos, en qué entorno y con qué nivel de autonomía. Si un motor prioriza alertas del SOC, eso altera la superficie de riesgo operacional. Si un sistema decide qué señales descarta como ruido, afecta a la capacidad de detección. Y si nadie ha documentado esa lógica de negocio, luego nadie sabrá por qué el incidente pasó por debajo del radar.

Segundo, procedencia y control de datos. Aquí está uno de los puntos más delicados. Los sistemas de IA para ciberseguridad dependen de datos de red, registros de eventos, telemetría de endpoints, indicadores de compromiso, inteligencia de amenazas y, a veces, datos de usuarios o administradores. Eso abre preguntas muy concretas: quién puede acceder a esos datos, cómo se minimizan, qué retención se aplica, si hay transferencias internacionales, qué señales contienen datos personales y cómo se evita que un modelo aprenda cosas que no debería retener.

Para una organización sujeta a GDPR, la tensión es evidente. El artículo 5 exige minimización y limitación de finalidad; el artículo 25 introduce protección de datos desde el diseño y por defecto; el artículo 32 obliga a medidas técnicas y organizativas adecuadas. Si además hay una violación de seguridad con datos personales, el artículo 33 fija la notificación a la autoridad en 72 horas. Un sistema de IA de seguridad que consuma más datos de los necesarios o cuya lógica nadie pueda explicar no es solo un problema técnico. Es una mala defensa regulatoria esperando su turno.

Tercero, validación, robustez y pruebas. Un motor de detección basado en IA no debería entrar en producción con un estándar más laxo que el de un control tradicional. Y sin embargo ocurre. Se prueba una demo, se observa que reduce falsos positivos y se despliega como si fuera magia estadística bendecida por ventas. Un perfil serio tendrá que empujar controles de validación previos al despliegue, métricas de rendimiento continuas, testing con escenarios adversariales y umbrales de degradación aceptables. Si no los tiene, hablamos de fe tecnológica, no de seguridad.

Cuarto, gestión de terceros. Esto no es un detalle menor. Gran parte de la IA aplicada a ciberseguridad llega como función embebida en herramientas de EDR, SIEM, XDR, IAM, correo seguro o inteligencia de amenazas. En otras palabras: el riesgo de IA entra a menudo por el contrato de software, no por un laboratorio interno. Quien opere en Europa verá aquí un eco claro de DORA. Los artículos 28 a 30 del Reglamento (UE) 2022/2554 ponen el foco en la gestión del riesgo de terceros TIC, el contenido contractual y la supervisión de dependencias críticas. Aunque el perfil de NIST no sea vinculante en la UE, la lógica operativa coincide: no puedes externalizar una capacidad crítica y fingir que con ello externalizas la responsabilidad.

Quinto, supervisión humana y capacidad de intervención. La fantasía del SOC autónomo sigue siendo eso, una fantasía útil para demos. En la práctica, cualquier organización madura quiere saber cuándo un sistema automatiza, cuándo recomienda y cuándo ejecuta. Y, sobre todo, quién puede parar la máquina. El AI Act europeo, ya en vigor pero todavía entrando por fases, ha convertido este punto en algo menos abstracto. Su enfoque de gobernanza, transparencia y supervisión humana no se limita a productos “de IA” de cara al público; contamina la conversación corporativa entera. Aunque un caso de uso de ciberseguridad no encaje siempre como sistema de alto riesgo, la exigencia cultural ya está aquí: si no puedes explicar el rol humano, no tienes gobernanza, tienes delegación ciega.

Sexto, seguridad del propio sistema de IA. Esto parece obvio, pero merece decirse. La IA usada en ciberseguridad también se puede atacar. Hay riesgos de prompt injection en asistentes, manipulación de entradas, envenenamiento de datos, exfiltración de contexto, abuso de APIs, escalado lateral a través de conectores y filtrado involuntario de secretos. El perfil tendrá sentido si obliga a tratar esos sistemas no solo como defensa, sino también como activos expuestos. Porque lo son.

La intersección regulatoria: NIST no legisla, pero condiciona cómo se cumple

En Europa existe la tentación de mirar a NIST como si fuera útil pero ajeno, una especie de primo americano muy técnico y poco normativo. Es un error. NIST no dicta obligaciones para una entidad española o europea, claro. Lo que hace es algo más sutil y a menudo más influyente: proporciona el lenguaje de control con el que proveedores, auditores, integradores y multinacionales estructuran programas globales. Y ese lenguaje termina afectando a cómo se demuestra el cumplimiento frente a normas vinculantes.

Piensa en DORA. Desde el 17 de enero de 2025, las entidades financieras de la UE están sujetas a exigencias plenas en materia de gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia y terceros críticos. El artículo 5 exige un marco interno sólido de gestión del riesgo TIC. El artículo 6 obliga a contar con estrategias, políticas, procedimientos, protocolos y herramientas. El artículo 15 trata la detección de actividades anómalas. El artículo 17 entra en clasificación y gestión de incidentes. El artículo 28, ya citado, se centra en terceros TIC. Si una entidad usa herramientas de IA en monitorización o respuesta, esas herramientas quedan absorbidas por ese perímetro de control, aunque DORA no pronuncie la palabra “LLM” cada tres líneas. No hace falta.

En NIS2 ocurre algo parecido. La Directiva (UE) 2022/2555, en su artículo 21, exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de ciberseguridad. Ahí entran políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro, evaluación de la eficacia de las medidas y prácticas básicas de ciberhigiene. Si una organización crítica apoya parte de su detección o priorización en IA, el debate ya no es “si la norma cubre la IA”, sino si la organización puede demostrar que esa dependencia es segura, evaluada y supervisada.

La lógica con GDPR es incluso más incómoda, porque une seguridad, tratamiento de datos y accountability. Un sistema de seguridad que procesa masivamente logs con identificadores personales, correlaciona comportamientos y toma decisiones automatizadas de bloqueo puede rozar artículos sensibles si se diseña mal. El artículo 35 sobre evaluaciones de impacto relativas a la protección de datos puede entrar en juego si el tratamiento implica alto riesgo. No siempre, pero a menudo merece análisis. Y cuando la IA se integra en funciones de seguridad, ese análisis deja de ser solo de privacidad y pasa a ser de arquitectura operativa.

Por eso estas sesiones de NIST importan incluso para quien no reporte jamás a un regulador estadounidense. El perfil puede convertirse en el puente informal entre obligaciones duras y ejecución técnica. En cumplimiento moderno, ese puente vale oro. O al menos vale menos discusiones estériles entre compliance y seguridad.

La gran pregunta: ¿estamos hablando de IA para defenderse o de asegurar la propia IA?

La respuesta correcta es “ambas”, y justo ahí está la dificultad. Durante 2024 y 2025 el mercado mezcló dos conversaciones distintas hasta volverlas casi indistinguibles: usar IA para mejorar la ciberseguridad y proteger sistemas de IA frente a amenazas. No es lo mismo. Un Cyber AI Profile serio necesita separar ambas capas o acabará generando controles vagos que sirven para cualquier cosa y para nada.

La primera capa es IA como herramienta defensiva. Aquí hablamos de copilotos para analistas, clasificación de alertas, enriquecimiento de inteligencia, automatización de consultas, detección de anomalías, correlación de eventos y ayuda en respuesta. El riesgo principal no es solo que falle, sino cómo falla: sesgo, sobreconfianza del analista, ceguera ante señales nuevas, dependencia excesiva del proveedor, exposición de datos a servicios externos o decisiones automatizadas sin revisión suficiente.

La segunda capa es seguridad de sistemas de IA como activos empresariales. Aquí entran modelos desplegados internamente, asistentes conectados a bases de conocimiento, agentes con permisos operativos, pipelines de datos de entrenamiento, repositorios de prompts, embeddings, conectores a sistemas críticos y APIs expuestas. Los riesgos cambian: manipulación de entradas, abuso de herramientas conectadas, extracción de información sensible, suplantación de identidad en agentes, degradación silenciosa del modelo o dependencia de componentes de terceros cuya superficie de ataque no está bien inventariada.

El valor del perfil dependerá de si NIST consigue evitar una mezcla perezosa de ambas cosas. Si lo logra, ofrecerá algo poco abundante este año: una forma coherente de mapear riesgos distintos bajo un mismo marco sin fingir que todo problema de IA se resuelve con “principios éticos” pegados a un PDF.

Qué deberían vigilar ya los equipos de seguridad y compliance

La mala noticia es que no conviene esperar a que el perfil final esté maduro para empezar. La buena es que muchas de las medidas más útiles no dependen de ese texto concreto. Dependen de disciplina básica, esa especie en extinción cuando hay presupuesto para innovación.

Lo primero es saber dónde está la IA en tu stack de seguridad. No “dónde crees”. Dónde está. Eso implica inventariar herramientas que incorporan funciones de IA generativa, modelos predictivos o automatizaciones basadas en aprendizaje automático. Hay que registrar qué datos usan, qué decisiones soportan, qué autonomía tienen, quién es el proveedor, dónde se procesa la información y qué controles existen para validación y reversión. Si no puedes responder eso en una semana, ya tienes la primera evidencia de desorden.

Lo segundo es distinguir entre asistencia y decisión. Un copiloto que sugiere una consulta al SIEM no tiene el mismo perfil de riesgo que un sistema que aísla un endpoint o deshabilita credenciales automáticamente. Parece obvio, pero demasiados programas de gobierno tratan todo bajo la misma etiqueta de “IA de seguridad”. Error. La clasificación debería reflejar al menos el impacto operacional, el acceso a datos sensibles, el grado de automatización y la dependencia del tercero.

Lo tercero es revisar contratos. Sí, contratos. La parte menos glamourosa de la ciberseguridad vuelve a ser la más decisiva. Si el proveedor utiliza tus datos para mejorar modelos, si transfiere información fuera del EEE, si subcontrata inferencia, si no ofrece segregación suficiente, si no permite auditoría o si no define métricas de rendimiento y notificación de incidentes, luego no digas que nadie te avisó. La cláusula elegante sobre “innovación continua” suele ser menos interesante que dos líneas claras sobre retención, telemetría y uso secundario de datos.

Lo cuarto es crear pruebas de adversario adaptadas a IA. No basta con pasar un pentest estándar a la plataforma perimetral. Un asistente conectado al repositorio de tickets, al directorio corporativo o a documentación interna necesita pruebas que contemplen prompt injection, fuga de contexto, escalado a herramientas conectadas y recuperación no autorizada de información. Si el sistema genera recomendaciones para respuesta, conviene probar también errores sutiles: instrucciones plausibles pero incorrectas, priorizaciones absurdas con buena redacción y confianza estadística donde no la hay.

Lo quinto es construir evidencia. Esto gusta mucho menos que comprar herramientas nuevas, pero sirve bastante más cuando llega auditoría, incidente o comité de riesgos. Evidencia significa decisiones documentadas sobre finalidad, datasets, validación, criterios de aceptación, supervisión humana, métricas de deriva, revisiones periódicas y planes de retirada. No hace falta una catedral documental. Hace falta trazabilidad.

Un detalle que a menudo se escapa: si tu organización ya usa el CSF 2.0 como estructura, el trabajo puede hacerse sin esperar instrucciones milimétricas. La función Govern permite asignar roles y apetito de riesgo; Identify cubre inventario y dependencias; Protect se alinea con control de acceso y salvaguardas de datos; Detect encaja con monitorización del sistema y de su rendimiento; Respond y Recover sirven para el fallo del propio sistema de IA o para incidentes causados o agravados por él. El mapa ya existe. Lo que NIST está intentando ahora es hacer el terreno menos resbaladizo.

Lo que esta iniciativa dice del mercado en 2026

Dice varias cosas, y ninguna particularmente cómoda para los vendedores de humo.

La primera es que la fase de fascinación ya pasó. Durante los últimos dieciocho meses abundaron los anuncios de capacidades “autónomas”, “cognitivas” y “contextuales” sin demasiada evidencia de control real. La entrada de NIST con sesiones de trabajo específicas sugiere que el mercado ha madurado lo suficiente como para aceptar una pregunta mucho menos romántica: ¿cómo se gobierna esto sin degradar la seguridad ni multiplicar el riesgo legal?

La segunda es que la IA en ciberseguridad ya se considera infraestructura de decisión, no simple capa de productividad. Ese matiz importa. Cuando una herramienta redacta un resumen del incidente, hablamos de eficiencia. Cuando decide qué alertas ve primero el analista o qué credenciales desactiva el sistema, hablamos de control operativo. Y los controles operativos acaban, tarde o temprano, bajo escrutinio interno, contractual o regulatorio.

La tercera es que la convergencia entre ciberseguridad, riesgo de modelos y gobernanza tecnológica se acelera. El viejo reparto organizativo —seguridad por un lado, datos por otro, cumplimiento en otra planta y compras mirando precios— empieza a romperse. No por visión estratégica, sino por necesidad. Porque la IA atraviesa demasiadas funciones a la vez. Quien no lo organice bien acabará creando un sistema donde nadie tiene una foto completa y todos firman trozos del riesgo. Es el tipo de ingeniería institucional que solo parece buena idea hasta que hay un incidente.

La cuarta es que el liderazgo práctico está en el terreno de los perfiles y los controles, no de los manifiestos. La prueba es sencilla: cada vez que una organización quiere desplegar IA de forma seria, acaba necesitando responder preguntas muy concretas sobre acceso, logging, validación, terceros, datos, intervención humana y continuidad. Da igual cuántos principios éticos tenga colgados en la web corporativa. En la sala donde se aprueban despliegues, mandan los controles y la evidencia.

Lo que puede salir mal si las sesiones se quedan en generalidades

También conviene decirlo: no todo lo que toca NIST se convierte automáticamente en una brújula precisa. Hay un riesgo real de que el perfil termine formulando categorías demasiado amplias o lenguaje tan neutro que nadie se dé por aludido. Si eso ocurre, el mercado hará lo que siempre hace: llenar los huecos con diapositivas comerciales y autoevaluaciones generosas.

El peligro específico en IA es la abstracción excesiva. Si un perfil habla de “gestionar riesgos de datos” pero no aterriza control de entrenamiento, inferencia, retención, transferencia y uso secundario, servirá poco. Si menciona “supervisión humana” pero no distingue entre recomendación y ejecución autónoma, también. Y si no aborda bien el riesgo de terceros, será directamente insuficiente, porque buena parte del problema está encapsulado en productos ajenos que la empresa apenas puede inspeccionar.

Otro punto delicado será la medición. En seguridad clásica ya es difícil acordar qué métricas importan de verdad. En IA aplicada a seguridad, más aún. Reducir falsos positivos está bien, salvo que aumenten falsos negativos invisibles. Ganar velocidad de triage suena magnífico, salvo que el analista acabe fiándose de resúmenes incorrectos. Un perfil útil debería empujar a métricas combinadas: precisión, cobertura, degradación, revisión humana, impacto operacional y comportamiento en escenarios adversariales. Si se limita a celebrar eficiencia, se quedará en marketing con membrete técnico.

Hay además un sesgo institucional a vigilar: que el perfil esté demasiado centrado en grandes organizaciones con recursos amplios. Eso ocurre a menudo en foros de este tipo. Sin embargo, una parte muy significativa del mercado usará estas capacidades a través de plataformas empaquetadas, con poca capacidad de personalización y menos margen contractual. Si NIST no contempla ese uso realista, dejará fuera justo a quienes más necesitan criterios claros para no comprar una caja negra con esteroides.

Qué deberían aportar las organizaciones a estas sesiones

Si tu empresa participa o puede seguir de cerca estas sesiones de primavera de 2026, el objetivo no debería ser “estar en la conversación” para decorar la estrategia de relaciones institucionales. Debería ser mucho más terrenal: llevar casos concretos, fricciones reales y preguntas incómodas. Eso es lo que hace útil un proceso de perfilado.

Las organizaciones maduras harían bien en empujar al menos cinco temas. Uno, cómo clasificar casos de uso según impacto operativo y nivel de autonomía. Dos, qué evidencia mínima debería exigirse a proveedores que integran IA en controles críticos. Tres, cómo validar rendimiento y deriva en producción sin convertir el gobierno en una ceremonia imposible. Cuatro, cómo conectar seguridad de IA con privacidad y gestión de terceros sin duplicar burocracia. Cinco, qué criterios deberían disparar revisión humana obligatoria o límites de automatización.

También merece la pena llevar ejemplos de fallo, aunque sean anonimizados. El valor de estos grupos suele aparecer cuando alguien reconoce que una herramienta generó priorizaciones absurdas, introdujo fuga de información en consultas, fabricó contexto inexistente o produjo decisiones excesivamente agresivas en respuesta automatizada. La industria aprende bastante más de un error bien descrito que de veinte presentaciones triunfales.

Y una advertencia para los proveedores: si acuden a estas sesiones con el repertorio de siempre —“nuestra IA aprende sola”, “reduce ruido”, “acelera al analista”, “opera a escala”— no aportarán gran cosa. Lo que el mercado necesita ya no es entusiasmo. Es explicabilidad operativa: datasets, límites, controles, telemetría, rutas de escalado, seguridad de conectores, retención, segregación y auditoría. Menos fuegos artificiales. Más tornillos.

La lectura europea: utilidad inmediata aunque no haya obligación directa

Desde España y desde Europa, la tentación puede ser pensar que esto queda lejos. No debería. Hay tres razones bastante concretas para seguirlo de cerca este año.

La primera es la cadena de suministro. Buena parte de las herramientas usadas por bancos, aseguradoras, telecoms, industria y sector público europeo incorporan componentes desarrollados o gobernados con estándares estadounidenses. Cuando NIST perfila un lenguaje de control, ese lenguaje suele filtrarse a contratos, cuestionarios de terceros, anexos de seguridad y documentación de producto.

La segunda es la armonización interna. Muchas multinacionales operan con marcos comunes para seguridad a escala global y luego los aterrizan frente a DORA, NIS2, GDPR o requisitos sectoriales locales. El Cyber AI Profile puede convertirse en la pieza que faltaba para dar coherencia a usos de IA de seguridad que ahora viven desperdigados entre políticas de IA, estándares de arquitectura, evaluaciones de privacidad y procesos de compras.

La tercera es el tono regulatorio general de 2026. Este año ya no se discute si la IA debe gobernarse; se discute cómo demostrar que está bajo control cuando forma parte de operaciones críticas. Eso coloca a marcos como CSF 2.0 en una posición muy práctica. No sustituyen la ley. Hacen posible cumplirla sin que cada equipo invente su propia religión metodológica.

Para entidades financieras europeas, la conexión es especialmente clara. Bajo DORA, cualquier dependencia tecnológica con impacto en operaciones críticas pide más trazabilidad, más disciplina contractual y mejor supervisión. Si un banco usa IA en su capacidad de detección o respuesta, no tendrá que justificar la IA en abstracto; tendrá que justificar el control concreto. Ahí un perfil bien diseñado puede ahorrar meses de discusiones internas y algunas sorpresas desagradables con auditoría o supervisión.

La conclusión incómoda: el verdadero reto no es adoptar IA, es poder defender su uso delante de alguien hostil

Ese “alguien hostil” puede ser un regulador, un auditor, un cliente institucional, un comité de riesgos o simplemente el equipo interno que investiga por qué un incidente no se detectó a tiempo. En todos esos escenarios, la pregunta central será parecida: quién aprobó esta capacidad, con qué evidencia, bajo qué límites y con qué supervisión.

Las sesiones virtuales de primavera de 2026 sobre el Cyber AI Profile no resolverán por sí solas ese problema. Pero apuntan en la dirección correcta. Intentan convertir un debate plagado de promesas vagas en un marco de control discutible, verificable y, con un poco de suerte, útil. No es poco.

Lo interesante de verdad no es que NIST hable de IA. A estas alturas hasta la máquina del café quiere parecer impulsada por IA. Lo interesante es que NIST la mete dentro del CSF 2.0, es decir, dentro de una gramática de gobierno y resultados que las organizaciones ya conocen. Esa decisión reduce fricción. Y en cumplimiento, reducir fricción suele ser la diferencia entre un estándar que se adopta y otro que acaba decorando bibliotecas internas.

Así que la pregunta para los equipos de seguridad, riesgo y compliance en 2026 no es si van a observar estas sesiones. La pregunta es más incómoda: cuando el perfil esté más maduro, ¿tu organización tendrá algo sólido que mapear contra él o seguirá confiando en que el proveedor “lo lleva cubierto”? Si la respuesta se parece a lo segundo, quizá ya sabes por dónde empezar.