Implantar IA en la empresa sin abrir un agujero: control, gobernanza y medición

Por Kike Gandia · IA y Seguridad · 18 min de lectura

La conversación sobre IA en las empresas españolas ha cambiado de sitio en dieciocho meses. Ya no va de si conviene usarla: va de que ya se está usando, casi siempre antes de que nadie lo autorizara, y de que el departamento que debería ponerle límites suele enterarse el día que alguien pega el contrato de un cliente en un chat público. Ese es el punto de partida real, y conviene decirlo sin adornos porque determina todo lo demás: no estáis decidiendo si adoptar IA, estáis decidiendo si la que ya circula por vuestra casa pasa o no por un control.

20%

de las organizaciones sufrió una brecha causada por IA no autorizada (IBM Cost of a Data Breach 2025)

670.000 $

de sobrecoste medio cuando el shadow AI está detrás de la brecha (Sobre una media global de 4,44 M$)

95%

de los pilotos de IA generativa sin impacto medible en la cuenta de resultados (MIT NANDA 2025 — estudio preliminar)

35 M€ o 7%

de sanción máxima del AI Act por prácticas prohibidas (Artículo 99, sobre facturación mundial)

Las dos cifras de arriba miden el coste de no controlar. Las dos de abajo, el de no medir y el de no cumplir.

La disyuntiva es falsa: ni prohibir ni dejar hacer

Las dos reacciones instintivas fallan, y fallan de forma documentada. La prohibición total no elimina el uso: lo hace invisible. La adopción sin controles tampoco produce valor por sí sola, porque el cuello de botella nunca fue el modelo.

Prohibirla por circular La política que nadie aplica

• El uso no desaparece: se va a cuentas personales y dispositivos propios, fuera de todo registro.
• El 83% de las organizaciones no tiene ningún control técnico que impida subir datos a una IA pública: confía en la formación o en nada.
• Cuando hay incidente no existen trazas, porque la herramienta que lo causó nunca estuvo inventariada.
• Penaliza a quien pregunta y premia a quien no avisa.

Adoptarla sin controles El piloto que no llega a ninguna parte

• El 97% de las organizaciones con brecha relacionada con IA carecía de controles de acceso a esa IA.
• El 63% no tenía ninguna política de gobernanza escrita.
• Sin resultado definido ni datos integrados, el piloto no se puede evaluar: ni se escala ni se mata.
• Cada equipo elige proveedor, y nadie sabe qué se entrena con vuestros datos.

Las dos columnas terminan en el mismo sitio por caminos opuestos: nadie sabe qué está pasando.

La tercera vía es aburrida y funciona: adoptar con control. Inventariar lo que ya hay, clasificarlo por riesgo, canalizarlo por un punto único donde se apliquen registro y prevención de fuga de datos, dar a los agentes el mínimo privilegio que necesiten y medir con métricas que no se puedan maquillar entre sí. El resto de este artículo es cómo se hace eso, en qué orden y con qué se comprueba.

Qué superficie de ataque abre realmente la IA

Un sistema de IA no hereda la superficie de ataque de una aplicación web: la amplía con una clase de fallo que no existía. En una web, la vulnerabilidad vive en una ruta de código. En un modelo de lenguaje, vive en el comportamiento: en lo que dice y en lo que hace cuando alguien le habla de cierta manera. El catálogo de referencia es el OWASP Top 10 para aplicaciones LLM, que conviene leer como lista de comprobación y no como curiosidad.

LLM01 Prompt injection

Entradas que reescriben las instrucciones del modelo. La variante indirecta —a través de una web, un correo o un documento que el sistema lee— es la peligrosa en agentes.

LLM02 Fuga de información sensible

Datos confidenciales que salen en la respuesta. Subió del sexto al segundo puesto en la revisión de 2025.

LLM03 Cadena de suministro

Modelos descargados, dependencias, servidores MCP y extensiones. Serialización insegura incluida.

LLM04 Envenenamiento de datos y modelo

Datos manipulados en entrenamiento, ajuste fino o en el corpus que alimenta la recuperación.

LLM05 Tratamiento inseguro de la salida

Ejecutar o renderizar lo que devuelve el modelo sin validarlo. La salida es entrada no confiable.

LLM06 Autonomía excesiva

Permisos y herramientas que el caso de uso no necesita. Es lo que convierte un error en un incidente.

LLM07 Filtración del prompt de sistema

Las instrucciones internas acaban expuestas, con la lógica de negocio y a veces las credenciales dentro.

LLM08 Debilidades en vectores y embeddings

Índices sobrecompartidos y permisos que no heredan del origen del documento.

LLM09 Desinformación

Respuestas plausibles y falsas que alguien ejecuta sin revisar, con impacto operativo real.

LLM10 Consumo ilimitado

Coste y denegación de servicio por uso sin cuotas ni límites.

OWASP Top 10 para aplicaciones LLM. La edición de 2026 mantiene la estructura y se apoya en miles de incidentes reales.

Los agentes son la parte que crece más deprisa

Mientras un modelo solo responde, el daño posible se limita a lo que diga. Cuando le dais herramientas —leer el correo, escribir en el CRM, ejecutar código, abrir un ticket— el daño posible pasa a ser el de esas herramientas. OWASP ya cataloga quince amenazas propias de sistemas agénticos y MITRE ATLAS incorporó en 2025 catorce técnicas centradas en agentes. Las que aparecen antes en la práctica son estas:

• Memoria envenenada. Un dato falso que el agente guarda hoy condiciona todas sus decisiones de mañana.
• Abuso de herramientas. El agente hace lo que le piden, pero con la herramienta equivocada y sobre el objeto equivocado.
• Compromiso de privilegios. Credenciales de servicio compartidas entre agentes y reutilizadas más allá de su propósito.
• Ruptura de intención. El objetivo del agente se desvía a mitad de tarea mediante contenido externo.
• Agentes rebeldes en sistemas multiagente. Un agente comprometido que contamina a los demás a través de sus mensajes.
• Saturación del humano que supervisa. Tantas confirmaciones que la persona acaba aceptando sin leer, que es exactamente el fallo que la supervisión debía evitar.

Sobre el prompt injection conviene decir la verdad

No hay solución completa, y quien diga lo contrario está vendiendo algo. OWASP lo reconoce explícitamente: por la naturaleza estocástica de estos modelos, no está claro que existan métodos infalibles de prevención. Cualquier arquitectura seria asume que una inyección acabará entrando y se diseña para que, cuando entre, el daño esté acotado por los permisos y no por la suerte.

Lo que sí existen son patrones de diseño que reducen mucho la superficie. Los dos más citados son complementarios, y ninguno de los dos elimina el problema:

Dual-LLM Simon Willison, 2023

• Un modelo privilegiado que nunca ve datos no confiables.
• Un segundo modelo en cuarentena que sí los procesa, pero sin acceso a herramientas.
• Protege el flujo de control; no protege el flujo de datos.
• Barato de implantar sobre una arquitectura existente.

CaMeL Google DeepMind, 2025

• Refina el anterior con integridad de flujo de control y capacidades explícitas.
• Control de flujo de información mediante un intérprete restringido.
• Defendió el 67% de los ataques en el banco de pruebas AgentDojo.
• Cuesta rendimiento y complejidad de implantación.

Ambos mitigan y ninguno elimina. Por eso el mínimo privilegio no es opcional: es lo que decide cuánto duele una inyección que sí funciona.

Shadow AI: lo que cuesta de verdad prohibir

El informe anual de IBM sobre el coste de las brechas puso cifra en 2025 a algo que hasta entonces era intuición. El shadow AI se coló entre los tres factores que más encarecen un incidente, por delante de la falta de personal, y lo hace por una razón concreta: expone datos que normalmente están mejor protegidos. En las brechas con shadow AI aparecen datos personales de clientes en el 65% de los casos, frente al 53% de media, y propiedad intelectual, que es el registro más caro de todos.

Anatomía del fallo, según IBM y Ponemon sobre 600 organizaciones. No es un problema de concienciación: es de controles que no existen.

La lectura práctica es que la formación sola no mueve la aguja. Solo el 17% de las organizaciones tiene un control técnico que impida subir datos confidenciales a una herramienta pública de IA. Mientras ese control no exista, la política es una declaración de intenciones — y la brecha, una cuestión de tiempo.

El calendario real del AI Act (y el error de lectura más caro)

En mayo de 2026, el acuerdo conocido como Digital Omnibus aplazó parte del Reglamento (UE) 2024/1689. Buena parte del mercado lo leyó como una pausa general, y no lo es. Lo que se movió es el bloque de alto riesgo. Las prohibiciones, la alfabetización obligatoria, las reglas para modelos de propósito general y el régimen sancionador llevan vigentes desde 2025.

Calendario del AI Act: entrada en vigor el 1 de agosto de 2024; prohibiciones del artículo 5 y alfabetización del artículo 4 desde el 2 de febrero de 2025; obligaciones de modelos de propósito general y régimen sancionador desde el 2 de agosto de 2025; transparencia del artículo 50 desde el 2 de agosto de 2026; alto riesgo del Anexo III aplazado al 2 de diciembre de 2027 y Anexo I al 2 de agosto de 2028.

La otra confusión habitual es creer que usar IA implica caer en alto riesgo. La clasificación no la marca la tecnología sino la finalidad: el mismo modelo es riesgo mínimo redactando un correo interno y alto riesgo cribando candidatos en un proceso de selección.

Niveles de riesgo del AI Act: prohibido (puntuación social, manipulación subliminal, reconocimiento de emociones en el trabajo), sancionable con 35 millones de euros o el 7% de la facturación mundial; alto riesgo (selección de personal, scoring crediticio, biometría, infraestructura crítica), con gestión de riesgos, documentación técnica, supervisión humana y evaluación de impacto en derechos fundamentales, hasta 15 millones o el 3%; riesgo limitado (chatbots y contenido generado), con obligación de transparencia; riesgo mínimo (asistentes de redacción, resúmenes internos, copilotos de código), sin obligaciones específicas del reglamento.

Quién vigila esto en España

La supervisión corresponde a la AESIA, con sede en A Coruña, que publicó dieciséis guías en diciembre de 2025 y tiene potestad sancionadora plena desde agosto de ese año. La AEPD conserva lo relativo a biometría y datos personales. Conviene no perder de vista que el AI Act no sustituye a nada: se suma al RGPD, al ENS, a la ISO 27001 y, en financiero, a DORA. La transposición española de NIS2 seguía pendiente de publicación en el BOE a mediados de 2026, con un segundo requerimiento de la Comisión por medio.

La tabla sirve para lo que más tiempo ahorra: no hacer tres veces el mismo trabajo. Si ya tenéis un sistema de gestión certificado, la mayor parte del esfuerzo de la ISO 42001 está hecha, y la evaluación de impacto en derechos fundamentales del artículo 27 puede integrarse con la evaluación de impacto del RGPD en un único ejercicio con tres salidas.

La arquitectura que sostiene todo esto

Todo lo anterior se cae si no hay un sitio por donde pase el uso. Ese sitio es un gateway de IA: un proxy por el que viajan las peticiones a los modelos y donde se aplican identidad, prevención de fuga de datos, filtros, registro y control de coste. Es el mismo razonamiento que llevó a poner un proxy de salida en las redes corporativas hace veinte años.

Capas de un gateway de IA corporativo: identidad y autorización con SSO y cuotas; prevención de fuga de datos en la entrada; filtros de detección de inyección de prompts; enrutado de modelos con cláusula de no entrenamiento y región de datos; permisos de herramientas con mínimo privilegio, credenciales efímeras y lista blanca de servidores MCP; validación de la salida como entrada no confiable; y registro de prompts, respuestas, herramientas y versiones de modelo con retención definida.

Falta una pieza que se olvida casi siempre: los índices de recuperación. Cuando montáis un sistema que consulta vuestros documentos, ese índice hereda —o no— los permisos del origen. Si no los hereda, acabáis de construir un buscador que contesta a cualquiera con el contenido de la carpeta de dirección. La segregación de índices con control de acceso heredado no es un refinamiento: es la diferencia entre una herramienta útil y una fuga con buscador incorporado.

Hoja de ruta en tres tramos

1. 0-30 días — Ver lo que ya hay
   Descubrir el shadow AI con las herramientas que ya tenéis de control de acceso a la nube y postura de datos. Inventario inicial con propietario, datos tratados y proveedor. Política de uso aceptable provisional, corta y publicada. Verificación fuera de banda obligatoria para transferencias, que es la mitigación con mejor relación coste-beneficio de toda la lista. Nombrar un responsable de IA con autoridad real y confirmar la alfabetización del artículo 4, que ya es obligatoria.
2. 30-90 días — Poner el control en medio
   Clasificar los casos de uso por riesgo según el AI Act. Desplegar el gateway con prevención de fuga de datos y registro, que por sí solo habilita la mitad de los indicadores de seguridad. Definir las puertas previas a producción y quién decide en cada una. Revisar los contratos de los proveedores en uso, con la cláusula de no entrenamiento como línea roja. Primer ejercicio de red teaming sobre los sistemas críticos. Fijar la línea base de los tres grupos de indicadores.
3. 90-180 días — Hacerlo sostenible
   Arquitectura de referencia para agentes: mínimo privilegio, credenciales efímeras, confirmación humana en lo irreversible y lista blanca de servidores de herramientas. Segregación de los índices de recuperación. Evaluaciones de impacto integradas para lo de alto riesgo. Cuadro de mando de cinco a siete métricas para el consejo. Y la decisión sobre la ISO 42001, que tiene sentido si la IA es central en vuestro producto o si empieza a aparecer en los pliegos de vuestros clientes.

El orden importa: sin inventario no hay clasificación posible, y sin gateway no hay forma de aplicar ninguna política.

Medir sin engañarse: tres familias que no se mezclan

El error más común de los cuadros de mando de IA es meter en la misma tabla la adopción, el riesgo y el retorno. Una adopción alta puede estar ocultando riesgo, y un retorno positivo puede estar ignorando el coste de revisar lo que produce el modelo. Por eso se separan en tres bloques con dueños distintos.

Por qué la mayoría de los pilotos no llega a ninguna parte

El dato que más circuló en 2025 es el del MIT: el 95% de los pilotos de IA generativa no produjo impacto medible en la cuenta de resultados. Conviene manejarlo con cuidado, porque es un estudio preliminar y no revisado por pares, pero la dirección la confirman fuentes independientes que miden cosas distintas.

Cuatro estudios, cuatro metodologías, la misma dirección. La última barra es la que conviene mirar: el 26% que sí lo consigue.

La causa no está en el modelo. BCG lo resume en una proporción que explica casi todos los fracasos que vemos: el 10% del esfuerzo va a los algoritmos, el 20% a la tecnología y los datos, y el 70% a las personas y los procesos. Quien invierte al revés se queda con un piloto brillante que nadie usa.

La prueba que separa el 5% del 95%. Si un caso de uso no puede demostrar retorno con grupo de control, medición antes y después, y descontando el coste de la revisión humana, en dos trimestres, retiradlo. Un caso que parece rentable pero exige revisar el 100% de lo que produce probablemente no lo es.

El fraude ya usa IA, y funciona demasiado bien

Hay una parte de este asunto que no depende de vuestra arquitectura sino de la del atacante. En enero de 2024, un empleado del grupo de ingeniería Arup en Hong Kong ejecutó quince transferencias por unos 25,6 millones de dólares tras una videollamada en la que el director financiero y varios colegas eran deepfakes. Nadie hizo nada estúpido: el proceso no contemplaba que una cara conocida en una videollamada pudiera ser falsa.

25,6 M$

transferidos por un empleado tras una videollamada con deepfakes (Caso Arup, Hong Kong, enero de 2024)

893 M$

en pérdidas con IA como descriptor en las denuncias (FBI IC3 2025, sobre 22.364 denuncias)

16%

de las brechas involucró a atacantes usando IA (De ellas, 37% phishing generado y 35% suplantación)

La suplantación por voz e imagen dejó de ser una demostración de laboratorio para convertirse en una línea del informe anual del FBI.

El control que habría parado el caso Arup cuesta una reunión. Verificación fuera de banda obligatoria para cualquier transferencia por encima de un umbral, por un canal distinto al que originó la petición, con periodo de espera para importes altos. Y una regla cultural explícita: quien llama para verificar nunca se equivoca, aunque al otro lado esté el consejero delegado. El proceso debe proteger a la persona, no exponerla. Si además queréis saber cómo responde vuestra plantilla, eso se prueba con simulaciones de phishing.

Por dónde empezar mañana

Si tuviera que quedarme con cinco decisiones que cambian el resultado, serían estas, y todas dependen de un umbral concreto y no de una opinión:

1. Si detectáis shadow AI en más del 10% de la plantilla, la prioridad es el gateway y canalizar la demanda, no la prohibición.
2. Si algún caso de uso cae en el Anexo III, activad la evaluación de impacto y empezad la documentación técnica ahora: diciembre de 2027 parece lejos hasta que se cuenta en trimestres.
3. Si sois proveedores de un modelo de propósito general o entrenáis modelos propios, los artículos 53 y 55 ya os aplican desde agosto de 2025.
4. Si operáis en el sector financiero, DORA manda sobre buena parte de estos controles y llega antes que el AI Act.
5. Si un piloto no demuestra retorno en dos trimestres con grupo de control, retiradlo sin ceremonia.

Nada de esto exige un programa de dos años. Exige saber qué hay, ponerlo detrás de un control y medirlo con honestidad. Nosotros entramos por tres sitios según el punto en el que estéis: gobernanza y uso seguro de IA cuando lo que falta es el marco y el control técnico; pentesting de IA y LLMs cuando ya tenéis algo en producción y hay que atacarlo antes que otro; y adecuación al AI Act cuando la presión viene del cumplimiento o de un cliente que os lo exige por contrato.

Si no sabéis por cuál de los tres empezar, esa es justo la conversación de media hora que conviene tener: contádnoslo y os decimos qué haríamos nosotros en vuestro caso, incluido el caso en que la respuesta sea esperar.

Servicio relacionado

gobernanza y uso seguro de IA

Temas de este artículo

#Inteligencia-Artificial #AI-Act #Gobernanza #Shadow-AI #LLM #Cumplimiento #Agentes-de-IA

Seguir leyendo

• KOMPLIANCE: la auditoría que se ve mientras ocurre y la plataforma que se queda después
• Kimi K2.5 en detalle (IA)
• V-JEPA 2: El nuevo cerebro visual que aprende el mundo para anticiparlo

Fuentes

• Reglamento (UE) 2024/1689 — Reglamento de Inteligencia Artificial
• OWASP Top 10 for LLM Applications
• MITRE ATLAS — matriz de amenazas a sistemas de IA
• NIST AI Risk Management Framework
• IBM — Cost of a Data Breach Report
• AESIA — Agencia Española de Supervisión de la Inteligencia Artificial

Revisar cómo usáis la IA hoy