Eso es el shadow AI. La inteligencia artificial que tu gente ya usa sin pedirte permiso, sin pasar por una evaluación de proveedor, sin aparecer en ningún inventario. No es un riesgo futuro. Está ocurriendo ahora, en tu organización.

¿Qué es el shadow AI?

El shadow AI es el uso de herramientas de inteligencia artificial sin la aprobación ni el conocimiento del equipo de seguridad. Un comercial que pega la propuesta de un cliente en ChatGPT. Un desarrollador que sube código a un asistente. Ninguno tiene mala intención. Todos crean una fuga. Es un animal más peligroso que el shadow IT porque estos servicios procesan y a veces retienen los datos que el empleado les entrega.

¿Por qué tu empresa ya tiene shadow AI?

Porque la adopción ha ido más rápido que cualquier control. El DBIR 2026 de Verizon cuantifica que el uso regular de IA en dispositivos corporativos pasó del 15% al 45% en un año, y el 67% entra por cuentas personales. De 858.440 eventos de fuga analizados, lo que más se sube es código fuente. Y la empresa media tiene más de un 15% de usuarios con extensiones de IA no autorizadas que leen el contenido de cada página.

¿Cómo detectar el shadow AI en la empresa?

El primer mapa se levanta con el stack que ya tienes: 1) compara lo aprobado con lo real; 2) revisa el tráfico DNS y de proxy hacia dominios de IA; 3) audita las extensiones de navegador; 4) revisa los OAuth grants de tu tenant; 5) mira los logs de DLP y CASB; 6) pregunta con una encuesta anónima, sin castigar.

¿En qué se diferencian shadow AI y shadow IT?

El shadow IT es un problema de control de acceso. El shadow AI es, además, un problema de fuga de información: los datos que el empleado entrega se procesan y a veces se retienen para entrenar el modelo. Por eso las tácticas clásicas de bloqueo funcionan solo a medias.

Cómo gobernar el shadow AI sin frenar la productividad

Gobernar no es prohibir, es canalizar: levanta el inventario, clasifica por riesgo, ofrece una alternativa aprobada, publica una política clara, forma al equipo y vigila los vectores nuevos. Ofrecer una opción oficial buena es lo que más reduce el uso no autorizado. Es la columna vertebral de la ISO 42001.

Lee el artículo completo, con la tabla comparativa y las fuentes, en enriquemaza.com.

Para un CISO, la pregunta no es institucional, es operativa: qué puede pedirme esta agencia, cuándo, y qué tengo que tener preparado.

Competencias

Como autoridad de vigilancia del mercado, la AESIA supervisa el cumplimiento del reglamento europeo de IA: prohibiciones, transparencia y requisitos de los sistemas de alto riesgo. El marco español desarrolla un régimen de infracciones muy graves, graves y leves, con el techo que fija el reglamento: hasta 35 millones de euros o el 7% de la facturación global. Opera además el sandbox regulatorio, el espacio controlado de pruebas para sistemas innovadores.

Cómo prepararte

Cinco pasos: inventario de sistemas de IA al día, clasificación de riesgo documentada, evidencia de las obligaciones vivas (Artículo 5, transparencia, GPAI), un interlocutor designado para responder requerimientos y, si desarrollas IA de alto riesgo, valorar el sandbox. Al regulador no le importa lo que haces: le importa lo que puedes demostrar que haces.

Leer el artículo completo en enriquemaza.com

El test del Artículo 6

Hay dos vías de entrada al alto riesgo: ser componente de seguridad de un producto regulado (Anexo I) o encajar en una de las ocho áreas del Anexo III: biometría, infraestructura crítica, educación, empleo, servicios esenciales, aplicación de la ley, migración y justicia. Para una empresa privada típica, las categorías calientes son empleo (el ATS que puntúa candidatos), servicios esenciales (scoring crediticio, seguros) y biometría.

La excepción del Artículo 6(3)

Encajar en el Anexo III no es el final del análisis: si el sistema no supone un riesgo significativo y su papel es estrecho, preparatorio o de apoyo a una decisión humana ya tomada, puede quedar fuera del alto riesgo. Con una línea roja: si hace profiling de personas físicas, es siempre de alto riesgo, sin excepción posible. Y si invocas la excepción, documenta la evaluación antes de poner el sistema en servicio: la autoridad puede pedírtela.

El artículo completo incluye la tabla de las 8 categorías traducidas a sistemas reales, las cuatro condiciones de la excepción con ejemplos y el árbol de decisión de cuatro pasos para clasificar tu inventario.

Leer el artículo completo en enriquemaza.com

La IA generativa entró en las empresas más rápido que cualquier tecnología anterior, normalmente sin pasar por seguridad. El problema es que el repertorio mental de amenazas de la mayoría de los equipos sigue siendo el de las aplicaciones web. Los LLM rompen ese repertorio: aceptan lenguaje natural como instrucción, mezclan datos y órdenes en el mismo canal y, cada vez más, ejecutan acciones por su cuenta.

Qué cambió en 2025

La versión 2025 reordena los riesgos según lo que se ha visto fallar de verdad e incorpora amenazas nuevas como categoría propia: la filtración del prompt de sistema y las debilidades de vectores y embeddings. El motivo es la arquitectura: hemos pasado del chatbot simple a sistemas RAG y a agentes que deciden y actúan.

Los diez riesgos

LLM01 Prompt Injection: instrucciones diseñadas para que el modelo ignore sus reglas, directas o escondidas en documentos que lee. LLM02 Divulgación de información sensible: el modelo revela datos internos o de otro usuario. LLM03 Cadena de suministro: modelos o dependencias comprometidos. LLM04 Envenenamiento de datos y del modelo: datos de entrenamiento manipulados. LLM05 Manejo inadecuado de salidas: la salida se ejecuta sin validar. LLM06 Agencia excesiva: un agente con más permisos de los que necesita. LLM07 Filtración del prompt de sistema: exposición de instrucciones y secretos embebidos. LLM08 Debilidades de vectores y embeddings: los riesgos del RAG. LLM09 Desinformación: alucinaciones tomadas por ciertas. LLM10 Consumo no acotado: el denial of wallet.

Cada riesgo encaja en un control de gestión de ISO 42001 y se conecta con la clasificación de riesgo del EU AI Act. El artículo completo explica cada uno con su ejemplo, su mitigación práctica y los cinco pasos para auditar tus aplicaciones de IA contra la lista.

Leer el artículo completo en enriquemaza.com

Sin esa lista no hay programa de seguridad de IA que se sostenga. Puedes comprar la mejor herramienta de monitorización, redactar la política más elegante y contratar al consultor más caro. Si no sabes qué sistemas de IA tienes, todo lo demás es decoración.

El inventario de sistemas de IA es el paso cero. El control que va antes de todos los controles. Y es justo el que casi todo el mundo se salta porque parece aburrido y no luce en una diapositiva de comité.

No puedes proteger lo que no sabes que existe

Es una frase vieja en seguridad, y tiene la mala costumbre de ser cierta. La gestión de activos lleva décadas siendo el primer dominio de cualquier marco serio, desde los CIS Controls hasta la familia ISO 27000. La IA no cambia el principio. Lo agrava.

Lo agrava porque la IA entra en la organización por puertas que no controla el departamento de compras. Un empleado se crea una cuenta gratuita de un modelo. Un SaaS que ya pagas activa una función de IA por defecto en su última actualización. Un equipo conecta una API a un modelo externo para un piloto que nunca se cerró. Ninguna de esas tres cosas aparece en una factura nueva, y ninguna pasa por tu proceso de evaluación de proveedores.

El inventario es la fuente única de verdad que reúne todo eso en un mismo sitio: lo corporativo y lo que se cuela. Es lo primero que pide cualquier auditoría seria, ya sea bajo ISO/IEC 42001, el NIST AI Risk Management Framework o el Reglamento Europeo de IA. Y es lo primero que falta cuando llega el auditor.

Por qué el inventario es el primer paso de ISO 42001

ISO/IEC 42001 es el estándar internacional del sistema de gestión de IA, lo que la jerga llama AIMS. Su Anexo A define 38 controles organizados en nueve objetivos de control, y uno de los primeros documentos imprescindibles de cualquier implantación es precisamente el inventario de sistemas de IA. No es un detalle administrativo: es el cimiento del que cuelga el resto del sistema.

Piénsalo en orden lógico. La evaluación de riesgos de IA necesita saber qué sistemas evaluar. La declaración de aplicabilidad necesita saber sobre qué se aplica cada control. Los objetivos del AIMS necesitan un universo de sistemas que medir. Las tres cosas dependen de una lista previa. Si esa lista no existe o está incompleta, todo lo que construyas encima hereda el agujero.

Por eso, cuando alguien me pregunta por dónde empezar con ISO 42001, la respuesta nunca es la política ni el comité. Es el inventario. Aburrido, sí. Imprescindible, también.

El inventario y la clasificación de riesgo del EU AI Act

El Reglamento Europeo de IA clasifica cada sistema en uno de cuatro niveles de riesgo: inaceptable, alto, limitado o mínimo. De esa clasificación dependen las obligaciones que te aplican: un chatbot de atención al cliente y un sistema de cribado de currículos no juegan en la misma liga regulatoria.

Aquí aparece el mismo problema de siempre. No puedes clasificar lo que no tienes registrado. La clasificación de riesgo es un paso posterior al inventario, no anterior. Primero sabes qué sistemas existen y qué hacen. Después decides en qué casilla de riesgo cae cada uno. El inventario es el formulario en blanco; la clasificación es lo que escribes en la columna correspondiente.

Las fechas concretas del EU AI Act se movieron con el Digital Omnibus, y conviene tenerlas claras para no preparar el calendario equivocado. Las repasé en detalle en las fechas reales del EU AI Act tras el Omnibus. Lo importante para este artículo es lo que no cambia: hagan lo que hagan con los plazos, el primer trabajo siempre es el mismo, tener el inventario.

El shadow AI: por qué tu inventario corporativo no basta

El shadow AI es toda la IA que se usa en tu organización sin que tú la hayas aprobado. Cuentas personales de modelos, extensiones de navegador, plugins, funciones activadas por defecto en herramientas que ya tenías. No aparece en el CASB, no aparece en las compras, no aparece en el inventario corporativo. Pero está dentro, procesando datos.

Es el mismo patrón que vimos con las aplicaciones OAuth conectadas a los tenants corporativos, que analicé en Shadow AI 2.0 y los scopes de OAuth: cosas que entran con un clic de un empleado y se quedan años sin que seguridad lo sepa. Un inventario que solo recoge lo contratado oficialmente nace incompleto. La parte que importa, la que no controlas, es justo la que no está en ninguna factura.

Por eso un buen inventario de IA distingue de forma explícita lo corporativo de lo detectado, y trata el shadow AI como una categoría más que hay que registrar, no como una anomalía que se ignora. Lo que no se registra, no se gobierna.

Qué registrar: las 13 columnas de un inventario usable

Un inventario sirve cuando es suficiente para gobernar el riesgo y no tan pesado que nadie lo mantenga. El punto medio que funciona en la práctica son trece columnas. Ni una ficha de cien campos que se abandona al mes, ni una lista de nombres que no dice nada.

La columna que más gente se salta es la 12. Un sistema sin propietario es un riesgo sin responsable, y cuando algo falla, lo primero que ocurre es la búsqueda de a quién preguntar. Si ya está escrito en el inventario, te ahorras la peor reunión de la semana.

Dos sistemas inventariados: cómo queda en la práctica

La teoría se entiende mejor con dos filas reales. La primera es un sistema corporativo de manual. La segunda es el tipo de hallazgo que aparece cuando de verdad cazas el shadow AI.

AI-007, Copilot M365 (corporativo)

Categoría: API más modelo. Función: productividad ofimática. Proveedor: externo, Microsoft. Datos: confidencial. Usuarios: oficina, unos 250. Clasificación EU AI Act: limitado. EIPD: no. Guardrails: por defecto del proveedor. Owners: responsable de IT y dirección de operaciones. Estado: alta en marzo, revisado en junio, activo. Es el caso ordenado: comprado, conocido, con dueño.

AI-013, ChatGPT en cuentas personales (shadow AI)

Categoría: API o modelo. Función: varias, desde marketing hasta desarrollo. Proveedor: externo, OpenAI en cuentas gratuitas. Datos: PII y confidencial, sin control. Clasificación EU AI Act: no clasificado. EIPD: no. Guardrails: no. Owners: sin asignar. Estado: detectado, a regularizar. Es el caso que duele: nadie lo aprobó, procesa datos sensibles y, hasta que lo registras, no existe para tu organización aunque exista para OpenAI.

La diferencia entre las dos filas no es la tecnología. Es la visibilidad. Una está gobernada y la otra solo está ocurriendo.

Mi opinión como CISO

Voy a ser honesto: la primera vez que me senté a hacer un inventario de IA en serio, el mío tampoco estaba completo. Sabía de los sistemas grandes, los que pasan por presupuesto. El shadow AI fue otra historia, y la lista creció cada vez que preguntaba a un equipo distinto.

Trabajo en el sector nuclear, un entorno determinista, auditado y procedimentado. Exactamente lo opuesto a la IA. Esa tensión entre dos mundos es la que me da la perspectiva para decir esto: la IA llega a la organización mucho más rápido de lo que la gobiernas, y el inventario es el único punto desde el que puedes empezar a recuperar el control. No porque la lista en sí proteja nada, sino porque sin ella no sabes ni qué estás dejando sin proteger.

Lo incómodo del inventario es que su valor no se ve hasta que falta. Nadie felicita al CISO por tener la lista al día. Pero el día que el regulador, un cliente o un incidente te pide qué sistemas de IA usas, esa lista es la diferencia entre responder en una tarde y empezar de cero bajo presión.

Cómo arrancar tu inventario de IA en un día

No necesitas una herramienta cara ni un proyecto de seis meses. Necesitas una hoja de cálculo, las trece columnas y una tarde bien aprovechada. Estos son los cuatro pasos.

Paso 1: vuelca lo que ya conoces

Empieza por lo fácil. Lista las herramientas de IA contratadas oficialmente: licencias, suscripciones corporativas y, sobre todo, los módulos de IA embebidos en SaaS que ya pagas. Muchos productos han activado funciones de IA en sus últimas versiones sin que nadie lo decidiera de forma consciente. Eso ya cuenta como sistema de IA en uso.

Paso 2: caza el shadow AI

Esta es la parte que separa un inventario de verdad de una lista de compras. Combina dos fuentes: una encuesta anónima al personal sobre qué herramientas de IA usan en su día a día, y el análisis del tráfico de proxy y DNS buscando dominios de los grandes proveedores de modelos. Apunta categorías de uso, no personas concretas. El objetivo es visibilidad, no caza de brujas, y si la gente cree que es lo segundo, dejará de contártelo.

Paso 3: asigna un owner a cada sistema

Recorre la lista y pon dos nombres en cada fila: quién lo opera y quién responde de los resultados. Sin dueño, no hay control ni hay a quién preguntar cuando algo se tuerce. Es la columna más incómoda de rellenar porque obliga a tener conversaciones, y es exactamente por eso la más valiosa.

Paso 4: clasifica el riesgo

Con la lista poblada, marca para cada sistema su nivel de riesgo del EU AI Act y el tipo de datos que procesa. Esa combinación te dice de un vistazo qué sistemas necesitan una evaluación de impacto, cuáles piden guardrails reforzados y cuáles puedes dejar en vigilancia ligera. Ahí es donde el inventario deja de ser una lista y se convierte en una herramienta de decisión.

Para cerrar

El inventario no es el trabajo glamuroso de la seguridad de IA. No sale en titulares y no impresiona en una sala de juntas. Pero es el cimiento sobre el que se construye todo lo demás: ISO 42001 lo pide, el EU AI Act lo presupone y cualquier auditor lo busca el primer día.

La pregunta para tu próximo comité es sencilla: ¿cuántos sistemas de IA tenemos en uso ahora mismo, y cuántos están en una lista con propietario y nivel de riesgo asignado? Si las dos cifras no coinciden, y no van a coincidir, ya tienes tu primera tarea. Y no necesitas esperar a nada para empezarla.

Fuentes

• ISO/IEC 42001:2023: estándar internacional del sistema de gestión de inteligencia artificial (AIMS) y su Anexo A de 38 controles.
• EU Artificial Intelligence Act, resumen de alto nivel: niveles de riesgo (inaceptable, alto, limitado, mínimo) y obligaciones asociadas.
• NIST AI Risk Management Framework: marco de gestión de riesgos de IA con el inventario como práctica base.
• CIS Critical Security Controls: la gestión de activos como primer dominio de cualquier programa de seguridad.
• EU AI Act high risk: las fechas reales tras el Omnibus: el calendario de cumplimiento actualizado.
• Shadow AI 2.0 y los scopes de OAuth: cómo entra en la organización lo que nadie aprobó.

Es un error de lectura.

El 2 de agosto de 2026 sigue activando cosas. Solo que no las que la mayoría pensaba. Y una de ellas es una multa nueva que casi nadie está mirando.

¿Qué activa de verdad el EU AI Act el 2 de agosto de 2026?

El acuerdo provisional del Digital Omnibus se cerró el 7 de mayo de 2026 entre Consejo y Parlamento. Es el primer paquete de enmiendas a la Ley de IA desde su adopción en junio de 2024. Aplazó plazos. No los borró.

Lo que entra en vigor el 2 de agosto de 2026 es el poder de enforcement de la Oficina de IA europea sobre los modelos de propósito general (GPAI): investigaciones, órdenes de cumplimiento y multas. A partir de esa fecha, quien firmó el GPAI Code of Practice se beneficia de una presunción de conformidad. Quien no lo firmó tiene que demostrar cumplimiento equivalente por otros medios, y la carga de la prueba recae sobre él.

Para el proveedor de un modelo fundacional, eso es urgente. Para el CISO de una empresa usuaria, el efecto es indirecto pero real: si integras un GPAI vía API en un flujo crítico, dependes de que tu proveedor upstream tenga su casa en orden. Y ahí aparece la segunda pieza del 2 de agosto, la que no sale en los titulares.

¿Qué es la multa del Artículo 25 que casi nadie está mirando?

El Omnibus enmendó el régimen sancionador del Artículo 99 para añadir un supuesto nuevo. El incumplimiento del Artículo 25 (apartados 2 y 4) pasa a estar sancionado con hasta el 3% de la facturación mundial anual o 15 millones de euros, lo que sea mayor. Queda equiparado en gravedad a las infracciones de los Artículos 16, 26 y 50.

¿Qué es el Artículo 25? Las obligaciones de compartir información en la cadena de proveedores. En concreto:

• Artículo 25(2): si un proveedor cede un sistema a un actor que, por modificación sustancial o por reorientación del propósito, se convierte en nuevo proveedor, el original debe entregar documentación técnica suficiente para evaluar la conformidad, informar de las limitaciones y modos de fallo conocidos, y dar acceso técnico para pruebas y validación.
• Artículo 25(4): el Omnibus añade explícitamente el "modelo de IA" a la lista de elementos que, cuando los suministra un tercero para integrarlos en un sistema de alto riesgo, deben quedar cubiertos por un acuerdo escrito que especifique información, capacidades y acceso técnico.

Traducido a la vida de un CISO: si tu organización compra un modelo o un componente IA y lo integra en algo que acaba siendo de alto riesgo, o si lo modificas hasta el punto de convertirte en proveedor a ojos del reglamento, hay un contrato de documentación compartida que tiene que existir. Y la sanción por no tenerlo ya no es simbólica.

Lo interesante del orden de las cosas: esta multa muerde antes que las multas clásicas de alto riesgo, porque el alto riesgo se aplazó a 2027 y 2028, pero el régimen del Artículo 25 entra con el resto del Omnibus. La cadena de proveedores es la primera superficie de exposición real.

¿Cuáles son las fechas reales del EU AI Act tras el Omnibus?

Si vas a llevar una sola diapositiva al comité, que sea esta. La fecha popular ("agosto, ya da igual") sustituida por las fechas que de verdad marcan trabajo:

La trampa está en la primera fila. Mientras la conversación se va a la última (diciembre de 2027), la exposición real empieza arriba. Si ya hiciste los deberes de inventario y clasificación, esto lo cubres. Si los aparcaste porque "se aplazó", llegas tarde a una fecha que creías que no existía. El proceso para no llegar tarde es el mismo de siempre: la auditoría EU AI Act paso a paso que ya describí, ahora con el calendario corregido.

El borrador de directrices del 19 de mayo: tu ventana de input

Hay una pieza más, y tiene fecha de caducidad para actuar. El 19 de mayo de 2026 la Comisión Europea publicó el borrador de directrices para clasificar sistemas de alto riesgo bajo el Artículo 6. Es la primera vez que existe un documento con ejemplos concretos de qué cuenta como alto riesgo y qué no, en las áreas del Annex III: biometría, educación, empleo, servicios esenciales y aplicación de la ley.

Dos cosas importan para un CISO:

Primera: las directrices dicen que el proveedor decide la clasificación, no el deployer, y que esa decisión se evalúa mirando el propósito previsto: instrucciones técnicas, documentación, materiales de marketing y comunicaciones promocionales. Un posicionamiento amplio "para cualquier caso de uso" puede activar la clasificación de alto riesgo a menos que excluyas de forma clara y consistente los usos sensibles. Lo que tu equipo de producto escribe en una landing tiene consecuencias regulatorias.

Segunda: el borrador está en consulta pública y la consulta cierra el 23 de junio de 2026. No es vinculante todavía, pero refleja la interpretación que va a guiar el enforcement. Si tienes sistemas en una zona gris o tu sector está mal cubierto en los ejemplos, este es el momento de mandar comentario. Después, la versión final será mucho menos negociable.

Mi opinión como CISO

El aplazamiento no es un regalo. Es un test. La UE ha repartido los dieciséis meses extra para que las organizaciones hagan lo que no hicieron en los dos años anteriores, no para que cierren el proyecto.

Trabajo en el sector nuclear, un entorno determinista y procedimentado donde el cumplimiento es parte del ADN operativo. Esa cultura es la excepción. En la mayoría de organizaciones donde se despliega IA, el sistema de gestión de riesgos comparable no existe todavía, y el inventario de sistemas IA crece más rápido que la capacidad de gobernarlo.

Lo que más me preocupa del Omnibus no es ninguna de sus cláusulas. Es el efecto psicológico. La palabra "aplazamiento" desvía la atención de Dirección, suelta el presupuesto que tanto costó defender y relaja a los proveedores justo cuando deberían estar entregándote fichas técnicas. El daño no lo hace el texto legal. Lo hace la lectura perezosa del titular.

Qué hacer con el calendario corregido

Seis acciones concretas que salen de leer el Omnibus con la letra pequeña, no el titular:

1. Inventario IA exprés. Revisa los logs de DNS y proxy buscando dominios de OpenAI, Anthropic, Mistral, Google AI o HuggingFace. Cruza con las compras SaaS de los últimos 24 meses para detectar IA embebida que nadie inventarió. Sin esto, lo demás es teoría.

2. Pre-clasifica contra el Annex III usando el borrador del 19 de mayo. Marca cada sistema como probable alto riesgo, riesgo limitado o mínimo. No esperes al texto final: los ejemplos del borrador ya son la interpretación oficial que vas a tener enfrente.

3. Audita la cadena de proveedores bajo el Artículo 25. Si modificas sustancialmente un sistema de un tercero o integras un modelo upstream, revisa que existan los acuerdos de documentación compartida. Aquí vive la multa que entra en agosto.

4. Comenta la consulta antes del 23 de junio de 2026. Si tu sector está mal cubierto en el borrador o tienes sistemas en zona gris, manda comentario formal. Es la única ventana de input antes de que la interpretación se cierre.

5. Reescribe el roadmap con las cuatro fechas reales. Saca del documento la fecha popular y mete las operativas: agosto de 2026 (GPAI y Artículo 25), diciembre de 2026 (watermarking y prohibiciones), agosto de 2027 (sandboxes) y diciembre de 2027 (Annex III).

6. Comunica al comité que el trabajo no se aplazó. Sin alarmismo. El mensaje cabe en una frase: no nos han dado tiempo libre, nos han dado tiempo para hacer lo que no hicimos. Lo más caro que puede pasar es perder el sponsor ejecutivo justo ahora.

Antes de auditar nada, conviene que en la organización exista una política de uso aceptable de la IA que defina qué se aprueba y qué no. Sin ese marco, cada sistema que encuentres es una excepción que regularizar a posteriori.

Para cerrar

El aplazamiento no es la noticia. La noticia es lo que sigue vivo y la fecha en la que muerde. El enforcement GPAI en agosto. La multa del Artículo 25 en la cadena de proveedores. El watermarking en diciembre. Y un borrador de clasificación que se cierra a comentarios el 23 de junio.

La pregunta para tu próximo comité: "De nuestros proveedores de IA, ¿cuántos nos han entregado la documentación técnica que el Artículo 25 exige, y cuántos contratos de integración la contemplan por escrito?"

Si las dos cifras no coinciden, y rara vez coinciden, ya tienes el primer trabajo del trimestre.

Fuentes

• Council of the EU - Council and Parliament agree to simplify and streamline rules (7 may 2026) - Comunicado oficial del acuerdo provisional del Omnibus.
• Inside Privacy (Covington & Burling) - EU AI Act Update: Timeline Relief, Targeted Simplification, and New Prohibitions (18 may 2026) - Análisis detallado de plazos, Artículo 25 y nuevas prohibiciones.
• European Commission - Draft Commission guidelines on the classification of high-risk AI systems (19 may 2026) - Borrador oficial en consulta pública hasta el 23 de junio.
• Hunton Andrews Kurth - European Commission Releases Draft Guidelines on High-Risk AI - Estructura y alcance del borrador de directrices.
• Bird & Bird - The Commission's Draft High-Risk AI Guidelines: A First Read - Primer análisis del criterio "el proveedor decide".
• Gibson Dunn - EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes - Vista jurídica del calendario tras el Omnibus.

Una política de uso aceptable de la IA es un documento interno que define qué pueden y qué no pueden hacer los empleados con sistemas de inteligencia artificial: quién decide, con qué datos, sobre qué procesos y bajo qué supervisión. No es una declaración ética. Es el documento operativo que responde a tres preguntas que tu equipo se hace cada día: ¿puedo subir este dato a ChatGPT?, ¿puedo conectar este agente IA al Drive corporativo?, ¿puedo dejar que un sistema automatizado decida si aprueba o rechaza esta solicitud?

El núcleo mínimo: 5 secciones y un sistema semáforo

Después de leer veintitantas políticas reales —desde la de la AEPD hasta las de Iberdrola, Prisa o Técnicas Reunidas— hay cinco secciones que aparecen en todas las que funcionan: objetivo y alcance, clasificación de uso (sistema semáforo), reglas generales, régimen de incumplimiento, marco normativo. El núcleo entra en una sola página. La plantilla que acompaña este artículo trae 17 escenarios concretos clasificados en verde, amarillo y rojo, alineados con NIST AI RMF, ISO/IEC 42001 y EU AI Act.

Tres reglas para construir el sistema semáforo

Primero: cada categoría se define por escenario, no por herramienta. La misma herramienta puede estar en verde, ámbar o rojo según los datos que maneje. Segundo: el ámbar tiene que tener un responsable con nombre y un SLA. "Requiere aprobación" sin decir quién la da en cuánto tiempo es lo mismo que no tener proceso. Tercero: el rojo se nombra explícitamente. "No se puede usar IA para evaluar candidatos sin intervención humana en la decisión final" es concreto, verificable y sancionable. "Usos que vulneren la normativa" no lo es.

Los 6 errores que veo cuando reviso una política IA ajena

De las políticas que he leído este semestre, aparecen estos seis errores con regularidad de manual: confundir principios con reglas, listar herramientas en lugar de criterios, no diferenciar uso individual del corporativo, silencio sobre los agentes IA autónomos, olvidarse del shadow AI que ya está dentro, y aprobación una vez con olvido. Si tu política tiene tres o más, está rota.

Cómo desplegarla en 30 días

Semana 1: mapa del uso real (logs + encuesta anónima). Semana 2: borrador con input de los cuatro perfiles. Semana 3: validación cruzada uno a uno, no en comité. Semana 4: aprobación, comunicación y formación de 15 minutos por equipo. Si el día treinta no tienes la política publicada y el 70% del personal formado, el problema no es la política. Es la organización.

La pregunta para tu próximo comité: ¿cuántas herramientas de IA tienes ahora mismo en uso real, y cuántas pasaron por tu proceso de evaluación de proveedor? Si las dos cifras no coinciden —y no van a coincidir— ya sabes cuál es la primera línea de tu inventario.

Leer el artículo completo en enriquemaza.com

El equipo de Halcyon hizo la ingeniería inversa y publicó el hallazgo: el binario regenera localmente un nuevo par de claves RSA en cada ejecución, cifra los archivos con esa clave y descarta inmediatamente la privada. No hay clave maestra, no hay servidor C2 que la custodie, no hay forma de recuperar nada. Halcyon atribuye con confianza moderada el desarrollo del malware a tooling asistido por IA: un error de criptografía elemental que solo se comete cuando nadie sabía lo que estaba pidiendo, y nadie revisó lo que el modelo entregó.

Y ahí está el punto. El vibe coding —construir software describiéndolo a un agente IA, sin escribir prácticamente código— no es peligroso porque genere código malo. El código humano también lo es. Es peligroso porque rompe a la vez las tres capas que históricamente contenían el riesgo: la velocidad supera la revisión, la ignorancia elimina el juicio y la autonomía cierra el ciclo sin humano en el loop. El triángulo mortal.

Por qué el modelo AppSec clásico ya no aplica

Durante quince años el modelo era predecible: el desarrollador escribía, otro revisaba, los tests pasaban y el pipeline desplegaba. Tres filtros en serie. El vibe coding no respeta ninguno. Plataformas como Lovable, Base44, Replit, Netlify o Cursor en modo agente permiten que alguien sin formación técnica describa una aplicación y la tenga desplegada en minutos. RedAccess escaneó internet a principios de mayo de 2026 y encontró aproximadamente 380.000 aplicaciones vibe-coded públicamente accesibles. Alrededor de 5.000 filtraban datos sensibles: historiales médicos, estrategias comerciales, conversaciones internas con clientes.

Vértice 1: velocidad

Los desarrolladores que usan asistentes IA producen commits a 3-4 veces la tasa de sus pares sin IA, pero introducen hallazgos de seguridad a 10 veces esa tasa (Apiiro). La Cloud Security Alliance cuenta los CVEs atribuidos a herramientas IA: 6 en enero, 15 en febrero, 35 en marzo. Solo marzo superó la suma de todo 2025. Mientras tanto, el 62% de los profesionales senior de seguridad declara no poder mantener el ritmo, y el 66% pasa más del 50% de su tiempo en validación manual.

Vértice 2: ignorancia

Una parte importante de quien usa vibe coding no detectaría una vulnerabilidad si la tuviera delante. Moltbook lo ilustró en febrero: 1,5M tokens API, 35K emails, 4.060 mensajes privados expuestos por una clave pública Supabase en el bundle del cliente. El fundador declaró no haber escrito una sola línea de código. Lovable / Khan: 16 vulnerabilidades, 18.697 registros expuestos en una sola app, UC Berkeley, UC Davis y K-12 incluidos. El 78% de los CISOs señala la exposición de secretos como riesgo número uno del coding IA.

Vértice 3: autonomía

Microsoft publicó el 7 de mayo de 2026 dos CVEs en su propio framework Semantic Kernel (CVE-2026-26030 e CVE-2026-25592) que permiten que un prompt malicioso escale a ejecución de código. La cita textual del informe es de las que tienen la mala costumbre de ser ciertas: "Your LLM is not a security boundary. The tools you expose define your attacker's affected scope." DryRun Security testó los tres agentes principales: 87% de pull requests con al menos una vulnerabilidad. Meta vivió en directo cómo un agente IA interno otorgó acceso no autorizado a sistemas durante dos horas.

El cierre del triángulo

Los tres ejes no son independientes: se refuerzan. La velocidad fuerza al pipeline a saltar revisiones. La ignorancia llena el código de cosas que la revisión habría cazado. La autonomía permite que ese código ejecute decisiones sin humano en el loop. El resultado es Sicarii: código IA defectuoso aplicado a un dominio crítico —criptografía— que produce daño irreversible, incluso al propio atacante.

Plan de acción CISO: 6 pasos para esta semana

1. Inventario de stack vibe-coding interno (logs DNS, proxy, SaaS).
2. Política explícita de qué puede y qué no puede generar la IA.
3. SAST/DAST + secrets scanning obligatorios en pipeline post-IA.
4. Agentes IA en least-privilege con auditoría de las tools expuestas.
5. Trazas completas: prompt, output, revisor humano, decisión final.
6. Cultura: el vibe coding NO exime de revisión.

La pregunta para tu próximo comité: ¿cuántas aplicaciones internas construidas con herramientas tipo Lovable, Base44 o Cursor agent corren ahora mismo en producción tocando datos sensibles, y cuántas pasaron por code review? Si las dos cifras no coinciden —y no van a coincidir— ya tienes el primer trabajo del lunes.

Artículo completo con fuentes verificadas y FAQ extendido en enriquemaza.com.

Por primera vez documentada, un actor de crimen cibernético desarrolló un exploit zero-day con ayuda de inteligencia artificial y lo metió en producción. La vulnerabilidad: un bypass de autenticación de dos factores en una popular herramienta de administración web open source. El plan: usarlo en un evento de explotación masiva. Google lo cortó antes de que ocurriera y coordinó la divulgación responsable con el vendor afectado.

El zero-day no era un fallo de memoria ni una inyección clásica. Era un fallo semántico de lógica: el desarrollador hardcodeó una suposición de confianza que volvía la verificación 2FA bypasseable bajo condiciones específicas. Justo el tipo de fallo que ningún SAST tradicional encuentra y que un LLM identifica leyendo intención.

Esto cambia el escalón de amenazas — y lo hace esta semana

John Hultquist, jefe de análisis de GTIG: "Está aquí. La era de la explotación de vulnerabilidades con IA ya está aquí." El informe enmarca el hito así: el LLM ya no es un asesor pasivo, sino un participante activo en la cadena ofensiva, capaz de orquestar conjuntos de herramientas complejos y tomar decisiones tácticas a velocidad máquina.

Anatomía del exploit: cómo se sabe que lo escribió una IA

Los marcadores forenses son los típicos de salida de modelo de lenguaje contaminada con datos de entrenamiento: docstrings demasiado bien escritos, CVSS score alucinado, formato Pythónico de manual, una clase ANSI color llamada _C. Ninguno concluyente por sí solo; en conjunto producen una huella reconocible.

Por qué tu SAST no va a ver esto

El fallo es un "dormant logic error": parece funcionalmente correcto a cualquier scanner pero está estratégicamente roto desde el punto de vista de seguridad. El modelo lee la intención del desarrollador, no busca patrones de memoria. Los LLMs van a encontrar fallos que ya están en tu código esperando.

El zoo completo: APTs, malware con IA y supply chain

GTIG documenta cinco grupos estado-nación con TTPs distintos (UNC2814, APT45, APT27, UNC5673, UNC6201), cinco familias de malware con LLM embebido (PROMPTFLUX, HONESTCUE, CANFAIL, LONGSTREAM, PROMPTSPY), y una campaña de supply chain de TeamPCP que comprometió Trivy, Checkmarx, LiteLLM y BerriAI en marzo 2026.

PROMPTSPY es el caso más sofisticado: backdoor Android que serializa la UI del dispositivo en XML, la envía a Gemini, recibe coordenadas y simula gestos físicos en pantalla. Captura PINs biométricos. Si intentas desinstalarlo, renderiza un overlay invisible sobre el botón "Uninstall".

Big Sleep y CodeMender: Google jugando en el mismo campo

Google también está en el otro lado del tablero. Big Sleep ya encontró su primera vulnerabilidad real en producción. CodeMender parchea automáticamente vulnerabilidades críticas usando Gemini sin intervención humana inmediata. Si los atacantes usan LLMs a velocidad máquina, los defensores tienen que jugar al mismo juego.

Mi opinión como CISO — lo que cambia desde hoy

Tres cosas incómodas. Primera: el repositorio público wooyun-legacy con 85.000 casos de vulnerabilidades chinas se está integrando como plugin de Claude Code por actores ofensivos. Segunda: el tráfico API de Gemini, hoy por hoy, no se diferencia del developer de marketing usando ChatGPT. Tercera: yo tampoco tengo resuelto cómo distinguir el developer cumplidor del comprometido sin abrir un problema GDPR de proporciones bíblicas.

Plan de acción — 7 cosas para hacer esta semana en tu SOC

1. Inventario forzado de uso interno de IA por developers.
2. Auditar dependencias open source con énfasis en gateways IA.
3. Detección de prompt injection y RCE en frameworks agénticos.
4. Caza de patrones código generado por LLM en pull requests nuevos.
5. Hardening de cuentas premium LLM corporativas.
6. Bloqueo de aggregators y gateways LLM sospechosos en proxy.
7. Revisar OAuth grants a SaaS de IA en tu tenant.

La pregunta para tu próximo comité: ¿cuántas integraciones IA tienes ahora mismo en producción de las que no sabes quién las usa, qué dependencias tienen y qué clave API gobierna su acceso? Si la respuesta es "no lo sé", ya tienes la primera tarea del lunes.

Leer el artículo completo en enriquemaza.com