La IA no se gobierna con una política: por qué la visibilidad y el control son el nuevo perímetro

La adopción de inteligencia artificial no está creando un único sistema que el departamento de seguridad pueda revisar y aprobar. Está sembrando cientos de puntos de acceso: copilotos integrados en suites ofimáticas, modelos consumidos como API, agentes capaces de ejecutar tareas, cuentas de servicio con permisos persistentes y empleados que pegan información corporativa en una aplicación SaaS que nadie ha registrado.

Ese es el problema real detrás de la visibilidad y el control. No basta con saber qué modelo utiliza la organización. Hay que saber qué datos recibe, con qué identidad se conecta, qué proveedor los procesa, dónde se almacenan, qué decisiones puede activar y qué queda registrado cuando algo sale mal.

La noticia de CyberSecurity News ES apunta precisamente a esa dispersión entre plataformas SaaS, nubes públicas, sistemas locales e identidades humanas, técnicas y no humanas. La observación es correcta, pero se queda corta si se interpreta como una recomendación genérica para comprar otra herramienta. El asunto es más incómodo: muchas empresas no tienen todavía un inventario fiable de sus flujos de datos ni de las identidades que los ejecutan. Pretenden gobernar la IA con políticas mientras sus propios sistemas no pueden responder a preguntas elementales.

En 2026, esa carencia ya no es solo un problema de madurez tecnológica. Puede convertirse en un incumplimiento de obligaciones concretas del Reglamento de Inteligencia Artificial de la Unión Europea, del RGPD, de DORA o de NIS2, según el sector y el uso. La soberanía digital tampoco significa tener un botón mágico que diga “los datos permanecen bajo control europeo”. Significa poder demostrar quién controla los datos, las claves, los registros, los proveedores, las transferencias y la capacidad de apagar o sustituir un servicio.

El perímetro de seguridad se ha convertido en un mapa de relaciones

El modelo clásico suponía que la organización conocía sus activos principales: servidores, aplicaciones, redes, dispositivos y usuarios. La IA rompe esa simplificación porque introduce cadenas de dependencia difíciles de ver desde un único inventario.

Un asistente puede ejecutarse dentro de una aplicación de productividad, llamar a un modelo externo, recuperar documentos de un repositorio corporativo, consultar una base de datos y crear una orden en otro sistema. Cada paso añade una relación distinta: una transferencia de información, una autorización, una interfaz técnica, un proveedor y un registro que debe conservarse.

El riesgo no está únicamente en el modelo. Está en la combinación de modelo, datos, identidad y permisos. Un modelo razonablemente protegido puede producir un incidente si una cuenta de servicio tiene acceso de escritura a un sistema financiero. Una aplicación aprobada puede filtrar información si su configuración permite utilizar las entradas de los clientes para mejorar el servicio del proveedor. Un agente puede comportarse de forma técnicamente correcta y, aun así, ejecutar una instrucción maliciosa introducida en un documento que trató como contexto de confianza.

Por eso el inventario útil no es una lista de proveedores de IA. Es un grafo de dependencias. Debería conectar, como mínimo:

• la aplicación o agente que inicia la operación;
• el modelo propio o de terceros que interviene;
• los conjuntos de datos consultados o enviados;
• la identidad humana, técnica o de máquina que actúa;
• los permisos concedidos y la posibilidad de elevarlos;
• el proveedor, la región de tratamiento y los subencargados;
• los registros generados, su retención y quién puede revisarlos;
• la acción que el sistema puede ejecutar sin aprobación humana.

Si una empresa no puede reconstruir esa cadena, tampoco puede investigar con solvencia una fuga de datos, demostrar la base jurídica de un tratamiento o determinar si un fallo del proveedor afecta a una función crítica. La invisibilidad no es neutral: convierte cada incidente en una discusión improvisada entre seguridad, compras, privacidad y negocio.

La regulación europea no exige “soberanía total”, pero sí capacidad de demostrar control

El lenguaje de la soberanía digital suele prometer más de lo que la ley exige. Ni el RGPD ni el Reglamento de IA obligan, como regla general, a que todos los datos y modelos residan dentro de la Unión Europea. Lo que sí exigen es control jurídico y técnico sobre el tratamiento, la seguridad, la transparencia y la responsabilidad.

El RGPD ofrece varias piezas directamente aplicables. El artículo 5 exige, entre otros principios, limitación de la finalidad, minimización, exactitud, limitación del plazo de conservación, integridad y confidencialidad. El artículo 25 obliga a aplicar protección de datos desde el diseño y por defecto. El artículo 32 exige medidas técnicas y organizativas adecuadas al riesgo, incluida la capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia de los sistemas.

En un proyecto de IA, esos artículos obligan a formular preguntas operativas. ¿Se envían al modelo todos los campos de un expediente o solo los estrictamente necesarios? ¿Se conservan los prompts y las respuestas durante días, meses o indefinidamente? ¿Puede el proveedor reutilizar el contenido? ¿Qué ocurre con los datos incluidos en los registros de depuración? ¿Está separada la información de entrenamiento de la información utilizada para responder a una consulta?

El artículo 35 del RGPD puede exigir una evaluación de impacto cuando el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas, especialmente en casos de evaluación sistemática, perfiles, datos sensibles o decisiones con efectos significativos. La evaluación no debería limitarse a describir el modelo. Tiene que mapear las fuentes de datos, los destinatarios, los accesos, los sesgos previsibles, la intervención humana y las medidas de salida o suspensión.

El artículo 33 añade un reloj que ningún equipo de comunicación debería descubrir después del incidente: la notificación de una violación de datos a la autoridad de control debe realizarse, cuando proceda, sin dilación indebida y, como máximo, en las 72 horas siguientes a que la organización tenga constancia. Sin registros de acceso, trazabilidad de prompts y visibilidad de proveedores, calcular ese plazo se vuelve innecesariamente difícil.

El Reglamento de IA, Reglamento (UE) 2024/1689, eleva la exigencia en función del uso. Su artículo 4 impone obligaciones de alfabetización en materia de IA a proveedores y responsables del despliegue. El artículo 6 determina qué sistemas entran en las categorías de alto riesgo y los artículos 9 a 15 cubren, entre otros aspectos, gestión de riesgos, datos, documentación, registros, transparencia, supervisión humana, precisión, robustez y ciberseguridad.

La fecha importa: la aplicación general del Reglamento de IA está prevista para el 2 de agosto de 2026, con excepciones y calendarios específicos. Las obligaciones para proveedores de modelos de propósito general comenzaron a aplicarse el 2 de agosto de 2025, mientras que determinados sistemas de alto riesgo integrados en productos regulados tienen un calendario distinto. Las empresas que siguen tratando la norma como un asunto futuro están trabajando con un calendario equivocado.

Para un responsable del despliegue, el artículo 26 exige medidas concretas, entre ellas utilizar el sistema conforme a las instrucciones del proveedor, asignar supervisión humana competente, conservar los registros bajo su control cuando proceda y vigilar su funcionamiento. El artículo 12, dirigido a los sistemas de alto riesgo, exige capacidades de registro que permitan reconstruir el funcionamiento durante un periodo adecuado. Sin logs de calidad, la supervisión humana acaba reducida a una firma en un procedimiento.

El artículo 50 introduce obligaciones de transparencia para determinados sistemas, incluidos algunos que interactúan con personas o generan contenido sintético. La pregunta empresarial no es únicamente si el modelo funciona, sino cómo se identifica ante el usuario, cómo se etiqueta el contenido generado y cómo se explica la intervención de la IA en el proceso.

La identidad es el nuevo punto ciego

Las empresas han aprendido a controlar usuarios humanos mediante gestión de identidades y accesos. La IA añade identidades que no descansan en una persona sentada delante de un teclado: cuentas de servicio, claves de API, identidades de cargas de trabajo, agentes autónomos y conectores con privilegios delegados.

La diferencia no es menor. Un empleado suele tener una jornada, un responsable y un proceso de baja. Una cuenta técnica puede sobrevivir a su creador, utilizar la misma clave durante meses y mantener acceso a varios entornos. Un agente puede reutilizar credenciales para leer documentos, invocar herramientas o modificar registros. Si el inventario de identidades solo recoge usuarios humanos, la organización desconoce una parte sustancial de su superficie de ataque.

El control operativo debe empezar por asignar a cada identidad no humana un propietario, una finalidad, un ámbito de permisos, una fecha de revisión y una fecha de expiración. Las claves deben rotarse y, cuando sea posible, sustituirse por autenticación federada, credenciales de corta duración y autorización basada en tokens con alcance limitado. La pregunta “¿quién autorizó este acceso?” tiene que poder responderse también cuando el actor es un agente.

El principio de mínimo privilegio necesita una traducción específica para la IA. No basta con limitar lo que el modelo puede leer. También hay que limitar lo que puede hacer. Un agente que resume contratos necesita acceso de lectura; no necesita necesariamente capacidad para modificar el sistema de gestión contractual. Un asistente que consulta inventario no debería poder emitir una orden de compra. Una separación clara entre lectura, recomendación y ejecución reduce el impacto de las alucinaciones, de la inyección de instrucciones y de una credencial comprometida.

Los controles más eficaces suelen ser poco glamurosos: gestión centralizada de secretos, rotación automática, listas de herramientas permitidas, autorización por acción, límites de volumen, aprobación humana para operaciones irreversibles y registros inmutables. La industria puede llamarlo “orquestación de agentes”. En muchos casos, sigue siendo control de acceso bien hecho, solo que con más marketing.

Los datos sensibles no desaparecen porque pasen por una API

La externalización del modelo no externaliza la responsabilidad. Cuando una aplicación envía información a un proveedor de IA, la organización debe saber si actúa como responsable, encargado o parte de una cadena de subencargados, qué finalidad tiene el tratamiento y qué garantías existen para las transferencias internacionales.

El contrato debe especificar, entre otras cuestiones, si el proveedor utiliza prompts y respuestas para entrenar modelos, qué regiones intervienen, cuánto tiempo conserva los datos, cómo atiende solicitudes de derechos, cómo notifica incidentes y qué ocurre al terminar el servicio. Las declaraciones comerciales del tipo “no entrenamos con tus datos” son insuficientes si no se traducen en una configuración verificable, una obligación contractual y una evidencia de auditoría.

La clasificación de la información debe preceder al uso de la herramienta, no llegar después de la primera fuga. Una política útil distingue entre información pública, interna, confidencial, datos personales, categorías especiales, secretos comerciales, credenciales y material sujeto a secreto profesional. Después debe aplicar controles técnicos: bloqueo de determinados patrones, prevención de pérdida de datos, tokenización, enmascaramiento y validación de destino.

La tokenización puede permitir que un modelo procese una referencia sin recibir el identificador real. El enmascaramiento puede evitar que un asistente vea números completos de cuenta o historiales clínicos. Pero ninguna de las dos técnicas es una coartada automática: si la reidentificación sigue siendo razonablemente posible o el proveedor recibe suficientes atributos para reconstruir el contexto, el riesgo permanece.

La soberanía también incluye las claves criptográficas. Mantener los datos en una región europea no garantiza por sí mismo el control si el proveedor administra las claves, opera desde otras jurisdicciones o puede acceder al contenido bajo sus propios procedimientos. La estrategia de claves gestionadas por el cliente, módulos de seguridad hardware y separación de funciones puede ser relevante para cargas de mayor sensibilidad, aunque eleva costes y complejidad. El criterio debe ser el riesgo, no la estética geográfica del centro de datos.

DORA, NIS2 y el coste de perder un proveedor de IA

Para las entidades financieras, la disponibilidad de una aplicación de IA puede ser menos importante que la función que sostiene. Un modelo utilizado para clasificar documentos internos no tiene el mismo impacto que una herramienta conectada a operaciones de pagos, atención al cliente, prevención del fraude o generación de información para decisiones crediticias.

DORA se aplica desde el 17 de enero de 2025 y obliga a las entidades financieras a reforzar la gestión del riesgo de las tecnologías de la información y las comunicaciones. Sus artículos 28 a 30 se ocupan de la gestión del riesgo de terceros proveedores de servicios TIC. Una API de IA, una plataforma de inferencia o un servicio de almacenamiento de prompts pueden entrar en ese análisis si sostienen una función empresarial.

El artículo 28 exige gestionar el riesgo contractual y operativo asociado a proveedores TIC, mientras que el artículo 30 establece elementos contractuales que deben quedar cubiertos, incluidos los niveles de servicio, la localización del tratamiento, la asistencia durante incidentes, los derechos de auditoría y las condiciones de terminación. La organización que no sabe qué subproveedores utiliza su plataforma de IA tampoco está en posición cómoda para ejercer sus derechos de auditoría o preparar una salida ordenada.

DORA incorpora además requisitos sobre gestión de incidentes y pruebas de resiliencia. Sus artículos 17 y siguientes cubren el proceso de gestión y clasificación de incidentes relacionados con las TIC, y los artículos 24 a 27 tratan las pruebas de resiliencia operativa digital. El uso de IA no crea una excepción para los fallos de terceros: si un proveedor deja de responder, devuelve resultados corruptos o expone información, la entidad debe poder detectar, clasificar, contener y comunicar el impacto.

NIS2 ofrece un enfoque similar para entidades esenciales e importantes dentro de su ámbito. El artículo 21 exige medidas de gestión de riesgos de ciberseguridad, incluida la seguridad de la cadena de suministro, la gestión de incidentes, la continuidad de negocio, la criptografía, el control de accesos y la evaluación de la eficacia de las medidas. El artículo 23 fija obligaciones de notificación de incidentes significativos, con una alerta temprana en un plazo de 24 horas desde que se tiene conocimiento, una notificación del incidente en 72 horas y un informe final, salvo que el Estado miembro aplique condiciones específicas conforme a la directiva y su transposición.

La consecuencia práctica es clara: el proveedor de IA debe formar parte del mapa de dependencias críticas, aunque el contrato lo describa como una simple herramienta de productividad. La etiqueta comercial no decide el impacto operativo.

Qué significa realmente tener visibilidad

La visibilidad no consiste en instalar un panel que muestre cuántos prompts se han enviado. Un programa mínimamente serio debe responder a cinco preguntas sobre cada caso de uso.

1. Qué entra: qué datos, documentos, metadatos y contexto recibe el modelo, y si contienen información personal, confidencial o regulada.
2. Quién lo solicita: qué usuario, aplicación, agente o cuenta de servicio inicia la operación y con qué nivel de autenticación.
3. Qué ocurre dentro: qué modelo, versión, proveedor, región y herramientas intervienen, y qué reglas de filtrado o moderación se aplican.
4. Qué sale: qué respuesta genera el sistema, a qué destinatario llega y si puede activar una decisión o una acción automática.
5. Qué queda registrado: qué evidencias permiten reconstruir la operación, cuánto tiempo se conservan y quién puede alterarlas o eliminarlas.

La calidad de la respuesta depende de la calidad del inventario. Las técnicas de descubrimiento pueden identificar llamadas a dominios de proveedores de IA, extensiones de navegador, paquetes de software, claves API y conectores. Pero el descubrimiento técnico no encuentra todos los usos: un empleado puede utilizar un servicio desde un navegador personal o incorporar una función de IA dentro de una plataforma ya aprobada. Por eso hay que combinar telemetría, revisión de contratos, entrevistas con equipos de producto, controles de compras y mecanismos de declaración de usos.

La visibilidad debe abarcar también la cadena de modelos. Una aplicación puede cambiar de modelo sin que el cliente lo perciba, activar una función nueva o incorporar un subprocesador. Ese cambio puede alterar el rendimiento, el tratamiento de datos, la localización, el precio y el riesgo. Los contratos y procedimientos de revisión deben exigir aviso, información suficiente y, cuando el impacto lo justifique, derecho de oposición o terminación.

La seguridad de los agentes exige controles distintos

El debate sobre IA suele concentrarse en la exactitud de las respuestas. En los agentes, el problema principal es la autoridad. Un sistema que solo redacta una respuesta tiene un riesgo distinto de otro que puede enviar un correo, modificar una base de datos, abrir un ticket o efectuar una transferencia.

Los controles deben situarse alrededor de las herramientas que el agente puede invocar. Cada herramienta necesita una definición de finalidad, parámetros permitidos, límites de frecuencia y reglas de aprobación. Las operaciones de alto impacto deben requerir confirmación humana independiente del agente. No es una buena idea que el mismo modelo proponga una transacción y se autorice a sí mismo a ejecutarla.

La inyección indirecta de instrucciones merece atención especial. Un agente que consulta páginas web, correos o documentos puede encontrar texto diseñado para manipular su comportamiento. El contenido recuperado debe tratarse como datos no confiables, no como una orden con la misma autoridad que la política del sistema. La separación entre instrucciones del sistema, contexto recuperado y contenido de usuario debe estar acompañada de validaciones, filtros y límites técnicos.

La observabilidad debe capturar las decisiones relevantes sin almacenar indiscriminadamente información sensible. Un registro útil puede incluir identificador de sesión, identidad que inició la tarea, herramientas invocadas, parámetros relevantes, modelo utilizado, resultado de las autorizaciones y acción final. Si se guardan prompts completos, la empresa debe justificar la retención y proteger esos registros como información potencialmente confidencial.

El marco NIST AI RMF 1.0, aunque voluntario, ofrece una estructura práctica con sus funciones Govern, Map, Measure y Manage. No sustituye al Reglamento de IA ni al RGPD, pero ayuda a ordenar responsabilidades, riesgos y mediciones. Su valor aumenta cuando se utiliza para producir evidencias concretas: inventario, evaluación, pruebas, incidentes, decisiones de aceptación del riesgo y revisiones periódicas.

Qué debería cambiar en la agenda del CISO, privacidad y compliance

La respuesta no es prohibir la IA hasta que exista un inventario perfecto. Ese día no llegará. La respuesta es gobernar el uso por niveles de riesgo y exigir un mínimo técnico común.

Primero, la organización debería registrar los casos de uso y clasificarlos por datos, impacto y autonomía. Un chatbot que responde preguntas sobre información pública no requiere el mismo proceso que un sistema que recomienda operaciones sobre clientes o un agente que accede a sistemas críticos. La clasificación debe incorporar el Reglamento de IA cuando sea aplicable, pero también criterios propios de seguridad, privacidad, continuidad y reputación.

Segundo, compras y seguridad deben revisar juntos al proveedor. Una evaluación que solo pregunta por certificaciones no revela si el modelo conserva entradas, cambia de subprocesador o permite exportar los registros. Las certificaciones pueden aportar evidencia, pero no sustituyen las preguntas sobre arquitectura, datos y salida.

Tercero, hay que probar el sistema con escenarios adversos antes de conectarlo a procesos sensibles. Las pruebas deben incluir extracción de información, prompt injection, abuso de privilegios, respuestas fabricadas, indisponibilidad del proveedor, cambio de modelo y pérdida de conectividad. El objetivo no es demostrar que el sistema es perfecto; es descubrir qué ocurre cuando deja de comportarse como espera el folleto comercial.

Cuarto, el consejo y la alta dirección necesitan métricas que no sean solo número de usuarios o ahorro de tiempo. Algunas métricas útiles son el porcentaje de casos de uso inventariados, la proporción de identidades no humanas con propietario y caducidad, el número de aplicaciones que envían datos sensibles a proveedores externos, el tiempo necesario para revocar una integración y el porcentaje de operaciones de alto impacto con aprobación humana verificable.

Quinto, debe existir una ruta de salida. La empresa necesita saber cómo exportar sus datos, reconstruir sus registros, sustituir el modelo, revocar credenciales y operar manualmente si el proveedor falla. El Reglamento de Datos de la Unión Europea, aplicable desde el 12 de septiembre de 2025, refuerza determinadas obligaciones relacionadas con el acceso y la portabilidad de datos y aborda aspectos de cambio de proveedor de servicios de procesamiento de datos. No convierte la migración en un trámite instantáneo, pero sí hace más difícil aceptar la dependencia técnica como una fatalidad.

La trampa de confundir visibilidad con vigilancia total

Más telemetría no equivale automáticamente a mejor gobierno. Registrar cada prompt puede generar una nueva base de datos sensible, ampliar el riesgo interno y crear obligaciones de conservación difíciles de justificar. La vigilancia desproporcionada también puede erosionar la confianza de los empleados y provocar que el uso de herramientas se desplace fuera de los canales visibles.

El diseño debe aplicar minimización y separación de funciones. Seguridad necesita detectar abusos; privacidad necesita limitar la recogida; auditoría necesita evidencia fiable; el negocio necesita comprender el rendimiento. No todos deben acceder al contenido completo de las interacciones. En muchos casos bastará con metadatos, tokens irreversibles, muestreo controlado o acceso excepcional aprobado.

La gobernanza también debe explicar qué puede hacer el empleado sin pedir permiso y qué requiere revisión. Una prohibición absoluta de herramientas públicas suele fracasar porque no elimina la necesidad de trabajar. Solo empuja el uso hacia cuentas personales y elimina la visibilidad que precisamente se pretendía conseguir.

La política sensata combina canales aprobados, controles de datos, formación específica y consecuencias claras. El artículo 4 del Reglamento de IA exige alfabetización, pero una sesión genérica sobre “riesgos de la inteligencia artificial” no prepara a un empleado para distinguir un entorno sin entrenamiento de datos de otro que sí los reutiliza, ni para reconocer una instrucción maliciosa dentro de un documento.

La decisión que no puede esperar

La visibilidad y el control no son proyectos accesorios para cuando termine la adopción de IA. Son la condición que permite que la adopción sea defendible. Sin ellos, la organización no puede demostrar qué tratamiento realiza, qué proveedor utiliza, quién tiene acceso, qué ocurrió durante un incidente ni cómo volver a operar si un servicio desaparece.

La pieza de CyberSecurity News ES acierta al situar los datos dispersos y las identidades múltiples en el centro del problema. La conclusión que debe extraerse en 2026 es más exigente: el perímetro ya no se define por la red corporativa ni por la lista de aplicaciones aprobadas. Se define por cada relación entre una identidad, un dato, un modelo, una herramienta y una acción.

La pregunta decisiva para un CISO, un delegado de protección de datos o un responsable de compliance no es “¿hemos aprobado la IA?”. Es esta: si mañana un regulador o un auditor nos pide reconstruir la última decisión tomada por un agente, ¿podemos mostrar quién le dio permiso, qué datos consultó, qué modelo utilizó y qué control detuvo —o permitió— la acción?

Si la respuesta es no, la organización no tiene un problema de comunicación sobre soberanía digital. Tiene un problema de control.