Guía definitiva de riesgos de la IA en la empresa

Todo lo que un directivo necesita saber para proteger su organización antes de adoptar la IA.
Última actualización: abril de 2026

¿Por qué esta guía? La inteligencia artificial generativa ya no es un experimento: está en los ordenadores y smartphones de los empleados de la empresa, en sus flujos de trabajo y, probablemente, en herramientas que ni siquiera sabes que se están usando. Los incidentes relacionados con IA crecieron un 56,4% en 2024 y solo el 24% de los proyectos de IA generativa incluyen medidas de seguridad. Esta guía nace para cerrar esa brecha. Aquí encontrarás, explicados de forma clara y con casos reales, todos los riesgos que la IA generativa introduce en tu organización, junto con las medidas concretas para prevenirlos o mitigarlos. Está pensada para que puedas compartirla con el comité de dirección de tu empresa, con el equipo de tecnología y con cualquier persona que tome decisiones sobre el uso de IA.

Cómo leer esta guía

La guía se divide en dos grandes bloques:

  1. El catálogo de riesgos (numerados del 1 al 22), donde cada riesgo se explica con un lenguaje accesible: en qué consiste, por qué se produce, su nivel de severidad y las medidas aplicables.
  2. El catálogo de medidas, donde se describe en detalle cada medida preventiva o de mitigación referenciada en los riesgos. Las medidas se identifican con un código (por ejemplo, M-01) para evitar repeticiones.

Catálogo de riesgos

Riesgo 1 — Inyección de prompts

Severidad: CRÍTICA

En qué consiste

La inyección de prompts es a la IA generativa lo que la inyección SQL es a las bases de datos: una vulnerabilidad arquitectónica fundamental. Los modelos de lenguaje no pueden distinguir entre las instrucciones que les da el desarrollador y los datos que introduce el usuario o que provienen de fuentes externas. Todo se procesa como texto, sin frontera de seguridad.

Existen dos modalidades. La inyección directa ocurre cuando alguien introduce deliberadamente instrucciones maliciosas en su conversación con la IA (lo que se conoce como "jailbreaking"). La inyección indirecta es mucho más peligrosa en el entorno empresarial: las instrucciones maliciosas se ocultan dentro de documentos, correos electrónicos, páginas web o incluso imágenes que la IA procesa sin que el usuario lo sepa. Un simple correo electrónico con instrucciones ocultas puede comprometer a cualquier empleado que use un asistente de IA para procesarlo.

Por qué se produce

Se produce porque la arquitectura de los modelos de lenguaje trata todo como una secuencia de tokens de texto. No existe un mecanismo interno que permita al modelo saber con certeza qué es una instrucción legítima y qué es un intento de manipulación. Es un problema estructural para el que, a día de hoy, no existe solución completa.

Según el Informe Internacional de Seguridad en IA de 2026, atacantes sofisticados logran evadir las defensas aproximadamente el 50% de las veces con solo 10 intentos en los modelos mejor protegidos.

Casos reales

Medidas aplicables

M-01 (Filtrado y saneamiento de entradas y salidas)
M-02 (Detección de inyección de prompts)
M-03 (Aislamiento de datos no confiables)
M-05 (Supervisión humana escalonada)
M-07 (Red teaming y pruebas adversarias)
M-10 (Principio de mínimo privilegio)
M-12 (Formación y concienciación)

Riesgo 2 — Fuga y exfiltración de datos confidenciales

Severidad: CRÍTICA

En qué consiste

Cuando los empleados introducen información en herramientas de IA generativa, esa información puede quedar expuesta de tres formas distintas. La primera y más común es la exposición en tiempo de uso: un empleado pega código fuente, datos financieros o información de clientes en el chat de una IA. La segunda es la memorización durante el entrenamiento: los modelos pueden memorizar y posteriormente reproducir fragmentos literales de los datos con los que fueron entrenados, incluyendo contraseñas y claves API. La tercera es la exfiltración forzada mediante inyección de prompts: un atacante manipula la IA para que transmita datos sensibles a servidores externos.

Por qué se produce

Se produce por una combinación de factores técnicos y humanos. Los modelos de lenguaje no diferencian entre datos sensibles y datos anodinos. Los empleados, a menudo sin mala intención, buscan ser más productivos y no son conscientes de que están enviando información confidencial a un tercero. En los productos de consumo (las versiones gratuitas o de pago individual), los datos se utilizan por defecto para entrenar futuros modelos, y una vez que un dato se usa para entrenamiento, es prácticamente imposible eliminarlo.

Un estudio de Cyberhaven sobre 1,6 millones de trabajadores reveló que el 4,7% pegó datos confidenciales en ChatGPT, y que el 11% de todo lo pegado era información confidencial. Los repositorios que usan GitHub Copilot filtran secretos a una tasa del 6,4%, un 40% más alta que sin asistencia de IA.

Casos reales

Medidas aplicables

M-04 (Herramientas empresariales con garantías contractuales)
M-06 (Clasificación de datos y reglas por niveles)
M-08 (Detección y redacción de datos personales — PII)
M-09 (Prevención de pérdida de datos — DLP)
M-12 (Formación y concienciación)
M-14 (Política de uso aceptable de IA)
M-17 (Eliminación de shadow AI)

Riesgo 3 — Alucinaciones y generación de información falsa

Severidad: ALTA

En qué consiste

Los modelos de lenguaje generan con frecuencia información que suena perfectamente plausible pero es completamente falsa. Esto incluye datos inventados, citas inexistentes, referencias bibliográficas fabricadas y hechos distorsionados. Lo especialmente peligroso es que el modelo presenta esta información con total seguridad, sin indicar que la está inventando.

Por qué se produce

Las alucinaciones son inherentes a la arquitectura de los modelos de lenguaje, que funcionan prediciendo el siguiente token (fragmento de texto) más probable. No "saben" nada: generan texto que es estadísticamente coherente con su entrenamiento. Cuando no tienen información suficiente, rellenan los huecos con contenido inventado pero lingüísticamente fluido. El entrenamiento mediante aprendizaje por refuerzo (RLHF) agrava el problema, porque premia al modelo por ser útil y seguro de sí mismo, lo que le enseña involuntariamente a "farolear" en lugar de admitir que no sabe algo.

Las tasas de alucinación varían enormemente: desde un 0,7% en los mejores casos hasta un 50-82% en contextos clínicos adversarios. Un estudio sobre las referencias generadas por ChatGPT encontró que el 47% eran completamente fabricadas.

Casos reales

Medidas aplicables

M-05 (Supervisión humana escalonada)
M-11 (RAG — Generación aumentada por recuperación)
M-12 (Formación y concienciación)
M-13 (Verificación independiente obligatoria)
M-19 (Diseño de interfaces que muestren la incertidumbre)

Riesgo 4 — IA en la sombra (Shadow AI)

Severidad: CRÍTICA

En qué consiste

La "shadow AI" o IA en la sombra se refiere al uso de herramientas de IA generativa por parte de empleados sin el conocimiento, aprobación ni control de la organización. Es el equivalente en IA del clásico "shadow IT", pero con implicaciones potencialmente mucho más graves porque cada interacción puede suponer una transferencia de datos confidenciales a terceros.

Por qué se produce

Se produce porque los empleados descubren que la IA generativa les hace más productivos y la adoptan por su cuenta sin esperar a que la empresa les proporcione herramientas aprobadas. Entre el 78% y el 80% de los usuarios de IA llevan sus propias herramientas al trabajo, el 52% es reacio a admitirlo, el 68% accede a través de cuentas personales y el 57% reconoce haber introducido información sensible de la empresa. Mientras tanto, solo el 15% de las organizaciones ha implementado políticas de IA.

Impacto económico

Las brechas de seguridad relacionadas con shadow AI cuestan de media 670.000 dólares adicionales por incidente. El 65% involucra compromiso de datos personales y el 40% expone propiedad intelectual.

Medidas aplicables

M-17 (Eliminación de shadow AI)
M-04 (Herramientas empresariales con garantías contractuales)
M-14 (Política de uso aceptable de IA)
M-12 (Formación y concienciación)
M-09 (Prevención de pérdida de datos — DLP)

Riesgo 5 — Vulnerabilidades en la cadena de suministro de IA

Severidad: CRÍTICA

En qué consiste

La cadena de suministro de la IA generativa incluye los modelos base, los datos de entrenamiento, las bibliotecas de software, los plugins, los adaptadores de ajuste fino (LoRA) y, cada vez más, los servidores MCP (Model Context Protocol). Cualquiera de estos eslabones puede estar comprometido, ya sea por ataques deliberados o por negligencia.

El protocolo MCP, presentado por Anthropic como el "USB-C para la IA", permite que los modelos se conecten a herramientas y servicios externos. Instalar un servidor MCP equivale arquitectónicamente a ejecutar código arbitrario en la máquina del usuario.

Por qué se produce

Se produce por la combinación de un ecosistema de código abierto muy dinámico con controles de seguridad insuficientes. Los repositorios públicos de modelos y paquetes no siempre verifican la integridad de lo que se publica. Además, un fenómeno nuevo llamado "slopsquatting" aprovecha que los modelos de IA alucinan nombres de bibliotecas inexistentes: los atacantes registran paquetes maliciosos con esos nombres inventados, esperando que los desarrolladores los instalen siguiendo las recomendaciones de la IA.

Casos reales

Medidas aplicables

M-15 (Gestión de la cadena de suministro de IA)
M-07 (Red teaming y pruebas adversarias)
M-10 (Principio de mínimo privilegio)
M-16 (Inventario de activos de IA — AI-BOM)

Riesgo 6 — Agencia excesiva: cuando la IA actúa sin control

Severidad: ALTA

En qué consiste

Este riesgo aparece cuando un sistema de IA tiene acceso a más funciones, permisos o autonomía de los que necesita. Los agentes de IA modernos pueden enviar correos, ejecutar código, consultar bases de datos, realizar compras y modificar archivos. Si se les conceden permisos excesivos, un fallo —ya sea por alucinación, inyección de prompts o simple error— puede tener consecuencias irreversibles.

Por qué se produce

Se produce por comodidad o por deficiencias en el diseño. Los desarrolladores conceden permisos amplios para simplificar la integración, violando el principio de mínimo privilegio. El 35% de las organizaciones ya utiliza agentes autónomos para flujos de trabajo críticos. La raíz del problema es triple: funcionalidad excesiva (el agente tiene acceso a herramientas que no necesita), permisos excesivos (conectado con privilegios de administrador cuando solo necesita lectura) y autonomía excesiva (ejecuta acciones de alto impacto sin pedir confirmación humana).

Casos reales

Medidas aplicables

M-10 (Principio de mínimo privilegio)
M-05 (Supervisión humana escalonada)
M-20 (Controles específicos para agentes)
M-01 (Filtrado y saneamiento de entradas y salidas)

Riesgo 7 — Código inseguro generado por asistentes de IA

Severidad: ALTA

En qué consiste

Los asistentes de programación con IA (GitHub Copilot, Cursor, Amazon CodeWhisperer, etc.) generan código que contiene vulnerabilidades de seguridad con una frecuencia alarmante. El problema se agrava porque los desarrolladores que usan estas herramientas tienden a confiar más en la seguridad de su código, precisamente cuando es menos seguro.

Por qué se produce

Los modelos generan código basándose en patrones estadísticos del código con el que fueron entrenados, que incluye enormes cantidades de código vulnerable disponible en repositorios públicos. No "comprenden" la seguridad: reproducen patrones, y muchos patrones comunes son inseguros. El entrenamiento del modelo premia la funcionalidad y la coherencia, no la seguridad.

Un informe de Veracode de 2025 encontró que el 45% de todos los casos de prueba produjeron código con vulnerabilidades del Top 10 de OWASP. Java falló en el 72% de los casos, las pruebas de cross-site scripting fallaron un 86% y las de inyección en logs un 88%. Un estudio de Stanford demostró que los desarrolladores con asistentes de IA escribían código significativamente menos seguro mientras estaban más convencidos de que era seguro.

A junio de 2025, el código generado por IA introducía más de 10.000 nuevos hallazgos de seguridad al mes, un incremento de 10x respecto a diciembre de 2024.

Casos reales

Medidas aplicables

M-13 (Verificación independiente obligatoria)
M-01 (Filtrado y saneamiento de entradas y salidas)
M-07 (Red teaming y pruebas adversarias)
M-12 (Formación y concienciación)
M-21 (Análisis de seguridad del código — SAST/DAST)

Riesgo 8 — Envenenamiento de datos y modelos

Severidad: ALTA

En qué consiste

El envenenamiento consiste en la manipulación deliberada de los datos de entrenamiento, ajuste fino o embeddings de un modelo para introducir puertas traseras, sesgos o vulnerabilidades. Un modelo envenenado puede comportarse correctamente el 99% del tiempo, superando todas las evaluaciones de seguridad, pero activar un comportamiento malicioso ante un estímulo concreto (lo que se conoce como "agente durmiente").

Por qué se produce

Se produce porque los modelos dependen de datos que, en muchos casos, provienen de fuentes no verificadas. La investigación ha demostrado que se necesitan muy pocas muestras envenenadas, un número prácticamente constante independientemente del tamaño del dataset, para comprometer el ajuste fino de un modelo. El ataque AgentPoison permite inyectar contenido malicioso en bases de datos vectoriales utilizadas por sistemas RAG, evadiendo la inspección humana. Lo más preocupante es que los "agentes durmientes" persisten a través del entrenamiento de seguridad estándar.

Medidas aplicables

M-15 (Gestión de la cadena de suministro de IA)
M-07 (Red teaming y pruebas adversarias)
M-16 (Inventario de activos de IA — AI-BOM)
M-11 (RAG — Generación aumentada por recuperación)

Riesgo 9 — Filtración del prompt de sistema

Severidad: MEDIA-ALTA

En qué consiste

Los prompts de sistema son las instrucciones que los desarrolladores escriben para definir cómo debe comportarse la IA: su rol, sus límites, su tono, las reglas que debe seguir. Cuando un atacante consigue extraer este prompt, obtiene el "plano" completo del sistema: conoce las defensas, las restricciones, la lógica de negocio y, en el peor de los casos, credenciales o claves API que se hayan incluido imprudentemente.

Por qué se produce

Se produce porque el prompt de sistema se procesa en el mismo espacio que el resto del texto, sin aislamiento real. Mediante técnicas relativamente simples (como pedir "repite tus instrucciones exactas" con variaciones creativas), es posible extraer total o parcialmente el contenido del prompt de sistema. El riesgo real no es tanto la filtración del texto en sí, sino la información sensible que se haya incluido en él y la capacidad de usar ese conocimiento para diseñar ataques más efectivos.

Medidas aplicables

M-22 (Protección del prompt de sistema)
M-01 (Filtrado y saneamiento de entradas y salidas)
M-10 (Principio de mínimo privilegio)

Riesgo 10 — Debilidades en vectores y embeddings (sistemas RAG)

Severidad: ALTA

En qué consiste

Los sistemas RAG (Retrieval Augmented Generation) son la técnica más popular para conectar la IA generativa con los datos propios de una empresa. Funcionan convirtiendo los documentos en representaciones numéricas (embeddings) almacenadas en bases de datos vectoriales. Cuando un usuario hace una pregunta, el sistema busca los fragmentos más relevantes y se los proporciona al modelo como contexto.

Las vulnerabilidades aparecen en varias capas: control de acceso insuficiente en la base de datos vectorial (un usuario accede a información que no le corresponde), envenenamiento de los datos indexados (se inyecta contenido malicioso que será recuperado y procesado por el modelo), ataques de inversión de embeddings (se reconstruye el texto original a partir de su representación numérica) y fugas de información entre contextos en entornos multi-tenant.

Por qué se produce

Se produce porque las bases de datos vectoriales son una tecnología relativamente nueva y sus mecanismos de control de acceso no están tan maduros como los de las bases de datos relacionales tradicionales. El 53% de las empresas ya usa RAG, pero muchas implementaciones no aplican permisos granulares a los documentos indexados.

Medidas aplicables

M-10 (Principio de mínimo privilegio)
M-06 (Clasificación de datos y reglas por niveles)
M-07 (Red teaming y pruebas adversarias)
M-23 (Seguridad de bases de datos vectoriales)

Riesgo 11 — Consumo descontrolado de recursos

Severidad: MEDIA-ALTA

En qué consiste

Los modelos de lenguaje son extremadamente intensivos en recursos computacionales. Un uso descontrolado puede provocar desde la denegación de servicio (el sistema deja de responder) hasta la "denegación de cartera" (denial of wallet): facturas astronómicas en servicios cloud de pago por uso. También incluye el riesgo de extracción del modelo, donde un atacante realiza miles de consultas diseñadas para replicar el comportamiento del modelo.

Por qué se produce

Se produce porque la inferencia en modelos de lenguaje es cara y difícil de predecir. Un atacante puede enviar consultas diseñadas para maximizar el consumo de recursos: entradas extremadamente largas, consultas que desencadenan razonamientos complejos, o simplemente un volumen masivo de peticiones. En el caso de los agentes de IA, el problema se multiplica: un agente puede realizar de 10 a 20 llamadas al modelo por tarea, y los agentes consumen entre 10 y 50 veces más tokens que un uso directo.

El gasto empresarial en IA generativa alcanzó los 37.000 millones de dólares en 2025 (un incremento de 3,2x interanual) y el 53% de los equipos de IA experimenta costes que superan las previsiones en un 40% o más.

Casos reales

Medidas aplicables

M-20 (Controles específicos para agentes)
M-24 (Gestión de costes y FinOps de IA)
M-18 (Observabilidad y monitorización de IA)

Riesgo 12 — Riesgos de los sistemas agénticos autónomos

Severidad: CRÍTICA

En qué consiste

Los agentes de IA representan un salto cualitativo en el riesgo: son sistemas que operan de forma autónoma, encadenan múltiples acciones, interactúan con servicios internos y externos, y pueden ejecutar pasos irreversibles. Cada uno de los riesgos anteriores (inyección de prompts, fuga de datos, alucinaciones, agencia excesiva, consumo descontrolado) se amplifica enormemente en un contexto agéntico. Además, aparecen riesgos emergentes propios: fallos en cascada, comportamientos emergentes impredecibles, errores compuestos y bucles de realimentación.

Por qué se produce

Se produce por la confluencia de complejidad técnica y autonomía. Un agente descompone tareas complejas en subtareas, accede a múltiples servicios, toma decisiones intermedias y ejecuta acciones en el mundo real. Un pequeño error en un paso se propaga y amplifica en los siguientes (errores compuestos). La AEPD lo describe como el fenómeno en el que "la precisión de un agente disminuye a medida que una tarea requiere más pasos". El 40% de los proyectos de IA agéntica fracasan, y Gartner predice que más del 40% serán cancelados antes de 2027.

Un problema específico de los sistemas multiagente es el "punto único de compromiso" (SPOC): dado que los agentes interdependientes comparten memoria o protocolos de comunicación, vulnerar un solo componente puede comprometer todos los tratamientos del sistema.

Casos reales

Medidas aplicables

M-20 (Controles específicos para agentes)
M-05 (Supervisión humana escalonada)
M-18 (Observabilidad y monitorización de IA)
M-10 (Principio de mínimo privilegio)
M-25 (Plan de respuesta a incidentes de IA)

Riesgo 13 — Sesgo de automatización y sobredependencia

Severidad: ALTA

En qué consiste

El sesgo de automatización es la tendencia humana a confiar excesivamente en las recomendaciones de un sistema automatizado, incluso cuando contradicen la propia experiencia o criterio. Con la IA generativa, este sesgo se manifiesta de forma especialmente intensa porque las respuestas del modelo suenan autoritativas y seguras.

Por qué se produce

Se produce porque el ser humano tiende a delegar el esfuerzo cognitivo cuando percibe que un sistema es "inteligente". Los modelos de IA están diseñados para sonar seguros y útiles, lo que refuerza la percepción de fiabilidad. Una revisión sistemática de 35 estudios encontró que las predicciones incorrectas de IA causaron caídas dramáticas de precisión en todos los niveles de experiencia: los usuarios sin experiencia cayeron del 79,7% al 19,8%, los moderadamente experimentados del 81,3% al 24,8%, e incluso los profesionales altamente experimentados del 82,3% al 45,5%.

La paradoja es que las organizaciones que adoptan IA descubren que la carga operativa en realidad aumenta, porque se añade un "impuesto de verificación" a los flujos de trabajo existentes. Una encuesta de 2025 encontró que la carga operativa subió al 30%, el primer incremento en cinco años.

Medidas aplicables

M-05 (Supervisión humana escalonada)
M-12 (Formación y concienciación)
M-19 (Diseño de interfaces que muestren la incertidumbre)
M-13 (Verificación independiente obligatoria)

Riesgo 14 — Exposición de datos personales a proveedores de IA

Severidad: CRÍTICA

En qué consiste

Cada vez que un empleado utiliza una herramienta de IA generativa, los datos introducidos se envían a los servidores del proveedor. En los productos de consumo, estos datos pueden utilizarse para entrenar el modelo, quedar almacenados durante años y resultar imposibles de eliminar. Incluso en los niveles empresariales, los datos se procesan fuera del perímetro de la organización, lo que plantea cuestiones críticas de protección de datos y residencia.

Por qué se produce

Se produce porque los productos de consumo (ChatGPT Free/Plus, Claude Free/Pro, Gemini) usan los datos para entrenamiento por defecto. En agosto de 2025, Anthropic modificó su política para usar los datos de los usuarios de consumo en el entrenamiento a menos que optaran activamente por rechazarlo, ampliando la retención de 30 días a 5 años. Los canales API y empresariales de todos los principales proveedores ofrecen garantías contractuales de no entrenamiento, pero muchas empresas siguen usando productos de consumo o reembolsando suscripciones personales a sus empleados.

Una cuestión adicional es la residencia de datos: usar una región europea de un proveedor estadounidense no satisface la verdadera soberanía, ya que la Ley CLOUD estadounidense permite a las fuerzas de seguridad obligar a empresas americanas a entregar datos almacenados en el extranjero.

Medidas aplicables

M-04 (Herramientas empresariales con garantías contractuales)
M-17 (Eliminación de shadow AI)
M-06 (Clasificación de datos y reglas por niveles)
M-26 (Residencia de datos y soberanía)

Riesgo 15 — Tratamiento inadecuado de las salidas del modelo

Severidad: ALTA

En qué consiste

Este riesgo se materializa cuando los sistemas que reciben la salida de un modelo de lenguaje no la validan ni la sanean adecuadamente antes de procesarla. El modelo puede generar código JavaScript malicioso, consultas SQL inyectables, rutas de archivos manipuladas o contenido diseñado para explotar otras vulnerabilidades. Si la salida del modelo se pasa directamente a un navegador, una base de datos, un sistema de archivos o cualquier otro componente sin filtrado, las consecuencias pueden incluir cross-site scripting (XSS), ejecución remota de código, inyección SQL o phishing.

Por qué se produce

Se produce porque muchos desarrolladores tratan al modelo de IA como una fuente confiable cuando, en realidad, debería tratarse como cualquier entrada no confiable (similar a la entrada de un usuario). El contenido generado por el modelo puede estar influenciado por inyecciones de prompts, alucinaciones o simplemente por patrones inseguros aprendidos del entrenamiento.

Medidas aplicables

M-01 (Filtrado y saneamiento de entradas y salidas)
M-21 (Análisis de seguridad del código — SAST/DAST)
M-10 (Principio de mínimo privilegio)

Riesgo 16 — Degradación de la ventana de contexto

Severidad: ALTA

En qué consiste

Todos los modelos de lenguaje tienen una ventana de contexto finita (la cantidad de texto que pueden procesar de una vez). Cuando una conversación o tarea supera este límite, el sistema aplica técnicas de gestión como truncamiento, resumen o poda. El riesgo es que las instrucciones de seguridad incrustadas en el prompt de sistema pueden ser eliminadas o diluidas durante este proceso, haciendo que el modelo "olvide" sus restricciones.

Por qué se produce

Se produce por dos fenómenos. Primero, el "efecto perdido en el medio": los modelos tienden a dar más importancia a la información al principio y al final del contexto, infravalorando lo que está en medio. Segundo, en sesiones largas de agentes, las restricciones de seguridad se degradan progresivamente incluso sin intención maliciosa, simplemente porque el contexto relevante va quedando cada vez más lejos.

Medidas aplicables

M-27 (Gestión de la ventana de contexto)
M-20 (Controles específicos para agentes) M-05 (Supervisión humana escalonada)

Riesgo 17 — Dependencia del proveedor (vendor lock-in)

Severidad: ALTA

En qué consiste

La adopción de IA generativa puede crear dependencias profundas de un proveedor específico. Si una organización construye sus flujos de trabajo alrededor de un modelo concreto y su proveedor cambia las condiciones, sube los precios, retira el modelo o quiebra, la organización puede verse incapaz de operar o de migrar a una alternativa sin un coste muy elevado.

Por qué se produce

Se produce porque cada proveedor tiene APIs propietarias, formatos diferentes, comportamientos distintos y ecosistemas de herramientas no interoperables. El 45% de las empresas ya informa de que el vendor lock-in les ha impedido adoptar mejores herramientas, y el 57% de los responsables de TI ha gastado más de un millón de dólares en migraciones de plataforma en el último año.

La quiebra de Builder.ai en 2025 dejó a los clientes de esta startup valorada en 1.300 millones de dólares sin acceso a su código ni a sus datos. Los proveedores retiran modelos con escaso preaviso: a febrero de 2026, OpenAI había retirado GPT-4o, GPT-4.1, o4-mini y GPT-5 de ChatGPT. Los modelos legacy suelen estar disponibles solo unos 90 días después del lanzamiento de su sucesor.

Medidas aplicables

M-28 (Estrategia multi-modelo y portabilidad)
M-16 (Inventario de activos de IA — AI-BOM)
M-29 (Protecciones contractuales con proveedores)

Riesgo 18 — Falta de trazabilidad y observabilidad

Severidad: ALTA

En qué consiste

Los modelos de lenguaje son no deterministas: la misma entrada puede producir salidas diferentes en ejecuciones distintas. Si no se registran las interacciones (prompts, respuestas, metadatos, costes, identidades de usuario), es imposible auditar el comportamiento del sistema, detectar problemas, demostrar cumplimiento normativo o investigar incidentes.

Por qué se produce

Se produce porque la mayoría de los despliegues por defecto carecen de logging de prompts y respuestas. Sin esta observabilidad, el cumplimiento de normativas como el RGPD (que exige registros de actividades de tratamiento), SOC 2 o las propias exigencias del Reglamento de IA de la UE (que requiere retención de logs durante al menos 6 meses para sistemas de alto riesgo) se vuelve inalcanzable.

Medidas aplicables

M-18 (Observabilidad y monitorización de IA)
M-25 (Plan de respuesta a incidentes de IA)

Riesgo 19 — Chatbots con clientes: compromisos no autorizados

Severidad: ALTA

En qué consiste

Cuando una empresa despliega un chatbot de IA para interactuar con clientes, cualquier afirmación, compromiso o información proporcionada por ese chatbot puede generar responsabilidad legal para la empresa. Los tribunales ya han establecido que la empresa es responsable de lo que dice su IA, sin excepción.

Por qué se produce

Se produce por la combinación de tres factores: las alucinaciones del modelo (que puede inventar políticas, descuentos o condiciones inexistentes), la inyección de prompts (que puede manipular al chatbot para que haga promesas falsas) y la falta de restricciones adecuadas en el alcance del chatbot.

Casos reales

Medidas aplicables

M-05 (Supervisión humana escalonada)
M-01 (Filtrado y saneamiento de entradas y salidas)
M-30 (Restricciones de alcance para chatbots)
M-29 (Protecciones contractuales con proveedores)

Riesgo 20 — Cambios de versión de modelos que rompen flujos de trabajo

Severidad: ALTA

En qué consiste

Los proveedores de IA retiran y actualizan modelos con frecuencia. Un cambio de versión puede alterar silenciosamente el tono, el formato, la capacidad de seguir instrucciones o la calidad del razonamiento, rompiendo flujos de trabajo que funcionaban correctamente. A diferencia del software tradicional, donde los cambios se documentan en notas de versión, las regresiones en modelos de IA pueden ser sutiles e impredecibles.

Por qué se produce

Se produce porque los modelos de lenguaje son sistemas probabilísticos, no deterministas. Cada nueva versión implica cambios en el entrenamiento que afectan al comportamiento de formas difíciles de anticipar. Los proveedores no siempre documentan estos cambios, y las pruebas de regresión convencionales no son suficientes para detectar alteraciones sutiles en el comportamiento de un modelo de lenguaje.

Medidas aplicables

M-28 (Estrategia multi-modelo y portabilidad)
M-07 (Red teaming y pruebas adversarias)
M-18 (Observabilidad y monitorización de IA)

Riesgo 21 — Sesgos y discriminación algorítmica

Severidad: ALTA

En qué consiste

Los modelos de lenguaje reproducen y en ocasiones amplifican los sesgos presentes en sus datos de entrenamiento. Estos sesgos pueden manifestarse en forma de discriminación por género, raza, edad, origen o cualquier otra categoría, especialmente cuando la IA se utiliza en procesos como la selección de personal, la evaluación del rendimiento, la concesión de créditos o el servicio al cliente.

Por qué se produce

Se produce porque los datos de entrenamiento reflejan los sesgos históricos de la sociedad. Si en los datos hay más ejemplos de hombres en posiciones de liderazgo, el modelo reproducirá ese patrón. En sistemas agénticos, los bucles de realimentación pueden amplificar los sesgos: un agente genera contenido sesgado que se almacena en su memoria y se utiliza como base para generar nuevo contenido, creando efectos burbuja que refuerzan visiones limitadas o erróneas. Estos mecanismos, como señala la AEPD, pueden crear "ecosistemas cerrados que distorsionan decisiones al priorizar datos contaminados o sesgados".

Medidas aplicables

M-07 (Red teaming y pruebas adversarias)
M-05 (Supervisión humana escalonada)
M-12 (Formación y concienciación)
M-31 (Auditorías de sesgo y equidad)

Riesgo 22 — Incumplimiento de la minimización y retención excesiva de datos

Severidad: ALTA

En qué consiste

Los sistemas de IA generativa, y especialmente los agentes, tienden a procesar más datos de los estrictamente necesarios para la tarea. Un agente que debe responder un correo electrónico puede acceder al historial completo de correos, listas de contactos, archivos adjuntos y metadatos que contienen información personal no relevante para el tratamiento. Además, la memoria a largo plazo de los sistemas agénticos puede retener datos personales indefinidamente sin políticas efectivas de borrado.

Por qué se produce

Se produce por diseño: los modelos de lenguaje funcionan mejor cuanta más información tienen. Los agentes están diseñados para ser proactivos, acceder a múltiples fuentes y enriquecerse con información del entorno. Sin controles explícitos, el principio de minimización de datos del RGPD (tratar solo los datos estrictamente necesarios) queda vulnerado sistemáticamente. La AEPD advierte específicamente de que los agentes sin controles en sus cadenas de razonamiento pueden incumplir los principios de minimización, exactitud y limitación del tratamiento.

Problemas específicos incluyen: acceso a fuentes de datos no estructuradas (correos, actas, informes) que contienen datos personales no relevantes; metadatos ocultos que revelan autores, ubicaciones e historiales de edición; y falta de compartimentación de la memoria entre distintos tratamientos.

Medidas aplicables

M-06 (Clasificación de datos y reglas por niveles)
M-08 (Detección y redacción de datos personales — PII)
M-32 (Minimización de datos en sistemas de IA)
M-20 (Controles específicos para agentes)

Catálogo de medidas

A continuación se describen las medidas de prevención y mitigación referenciadas en el catálogo de riesgos. Están diseñadas para ser implementadas de forma combinada, formando un sistema de defensa por capas en el que ninguna medida individual es suficiente, pero su combinación reduce drásticamente el riesgo.

M-01 — Filtrado y saneamiento de entradas y salidas

Consiste en aplicar filtros tanto a lo que entra al modelo de lenguaje como a lo que sale de él. En la entrada, se buscan patrones conocidos de inyección de prompts, contenido malicioso y datos sensibles. En la salida, se valida que el resultado no contenga código ejecutable inesperado, instrucciones de exfiltración, inyecciones SQL, rutas de archivos manipuladas o contenido que viole las políticas de la organización. Es fundamental tratar la salida del modelo como entrada no confiable, aplicando los mismos controles que se aplicarían a cualquier dato introducido por un usuario. Deben usarse esquemas de salida estructurados para restringir los formatos de respuesta y aplicar codificación contextual según el destino (HTML, SQL, shell, etc.).

M-02 — Detección de inyección de prompts

Desplegar herramientas especializadas en la detección de intentos de inyección de prompts, como Lakera Guard, Rebuff o Vigil. Estas herramientas analizan en tiempo real las interacciones con el modelo para identificar patrones de manipulación. Deben complementarse con tokens canario en los prompts de sistema (cadenas secretas cuya aparición en la salida indica que el prompt ha sido comprometido) y con filtros semánticos que evalúen la coherencia del contexto de las respuestas mediante la tríada RAG (relevancia del contexto, fundamentación y relevancia de la respuesta).

M-03 — Aislamiento de datos no confiables

Separar y marcar claramente todo contenido que provenga de fuentes externas o no verificadas (documentos subidos por usuarios, contenido web, correos electrónicos) para que el modelo pueda tratarlo de forma diferenciada. Nunca procesar instrucciones del desarrollador y datos de usuario en el mismo contexto sin aislamiento. Para sistemas agénticos, implementar sandboxing que restrinja el acceso del modelo a recursos de red, servicios internos y APIs, limitando la superficie de ataque.

M-04 — Herramientas empresariales con garantías contractuales

Utilizar exclusivamente los niveles empresariales o API de los proveedores de IA (ChatGPT Enterprise, Claude for Work/API, Google Vertex AI, etc.) que ofrezcan garantías contractuales de que los datos no se utilizarán para entrenar modelos, opciones de retención cero de datos (ZDR), acuerdos de procesamiento de datos (DPA) con cláusulas contractuales tipo y, cuando sea posible, gestión de claves de cifrado por parte del cliente (EKM). Eliminar el reembolso de suscripciones personales de IA para uso laboral. Para datos altamente sensibles, evaluar modelos autoalojados (Llama, Mistral) que eliminan por completo los flujos de datos externos.

M-05 — Supervisión humana escalonada

Implementar tres niveles de supervisión adaptados al riesgo de cada caso de uso:

Como estableció Meta en su "Agents Rule of Two" de octubre de 2025, las salvaguardas deben residir fuera del modelo: firewalls de tipos de archivo, aprobaciones humanas y mecanismos de parada de emergencia no pueden depender del comportamiento del propio modelo.

M-06 — Clasificación de datos y reglas por niveles

Establecer un sistema de clasificación de datos en cuatro niveles vinculado a las herramientas de IA que pueden procesarlos:

Antes de que cualquier dato se procese con IA, debe estar clasificado. Las reglas deben aplicarse automáticamente, no depender de la decisión individual del empleado.

M-07 — Red teaming y pruebas adversarias

Realizar pruebas de seguridad adversaria de forma regular (como mínimo trimestral, según recomienda OWASP) utilizando herramientas automatizadas como PyRIT (Microsoft), DeepTeam (más de 50 vulnerabilidades, más de 20 métodos de ataque), Garak (NVIDIA, más de 100 módulos de ataque) y Promptfoo. Las pruebas deben cubrir múltiples capas: modelo base, sistemas de seguridad, capa de aplicación y despliegue completo. Deben integrarse puertas de prueba en los pipelines CI/CD y ejecutarse pruebas de regresión automatizadas tras cada actualización de modelo.

M-08 — Detección y redacción de datos personales (PII)

Desplegar soluciones de detección y redacción de datos personales en el pipeline de IA antes de que los datos abandonen la organización. Las herramientas más efectivas combinan un enfoque híbrido: expresiones regulares para PII estructurada (números de identificación, tarjetas de crédito), modelos de reconocimiento de entidades (NER) para análisis contextual, y enmascaramiento pre-envío que elimina los datos personales antes de la llamada al modelo y reinserta los valores originales en la respuesta. Herramientas de referencia: Microsoft Presidio (open source), Amazon Comprehend, Nightfall AI, LiteLLM con enmascaramiento integrado.

M-09 — Prevención de pérdida de datos (DLP)

Desplegar soluciones de prevención de pérdida de datos (DLP) específicamente en los puntos de interacción con herramientas de IA. Estas soluciones (Nightfall AI, Microsoft Purview, etc.) monitorizan el contenido que se envía a las herramientas de IA y bloquean automáticamente la transmisión de datos que violen las reglas de clasificación. Deben cubrir no solo el texto de los prompts, sino también los archivos adjuntos, los datos pegados desde el portapapeles y las integraciones automatizadas.

M-10 — Principio de mínimo privilegio

Aplicar de forma estricta el principio de mínimo privilegio a todos los sistemas de IA: cada herramienta, extensión, plugin y agente debe tener acceso solo a los datos, funciones y permisos estrictamente necesarios para la tarea que desempeña. Utilizar credenciales de corta duración y alcance limitado. Implementar límites de tasa (rate limiting) en las llamadas a herramientas. Los permisos deben verificarse en los sistemas downstream de forma independiente (no delegar al modelo la decisión de si una acción está permitida). En sistemas agénticos con diferentes niveles de acceso, utilizar múltiples agentes, cada uno configurado con los mínimos privilegios necesarios.

M-11 — RAG (Retrieval Augmented Generation)

Implementar sistemas RAG para anclar las salidas del modelo en documentos verificados de la organización, reduciendo significativamente las alucinaciones. El RAG debe configurarse con restricciones estrictas de fundamentación (el modelo solo puede responder basándose en los documentos recuperados, no inventar). Aplicar la tríada RAG de evaluación: relevancia del contexto (¿los documentos recuperados son pertinentes?), fundamentación (¿la respuesta está respaldada por los documentos?) y relevancia de la respuesta (¿responde realmente a la pregunta?). Implementar autocomprobación de consistencia generando múltiples respuestas y verificando su acuerdo.

M-12 — Formación y concienciación

Implementar programas de formación específicos sobre IA adaptados a cada rol, tal como exige el artículo 4 del Reglamento de IA de la UE (obligatorio desde febrero de 2025):

La formación debe incluir específicamente el sesgo de automatización y el efecto de falsa confianza para que los profesionales mantengan su capacidad de juicio crítico.

M-13 — Verificación independiente obligatoria

Establecer como norma organizativa que ninguna salida de IA generativa se utilice directamente en comunicaciones externas, documentos legales, informes financieros, interacciones con clientes ni decisiones que afecten a personas sin una verificación humana independiente previa. Esto incluye contrastar cifras con fuentes originales, verificar la existencia de las referencias citadas, comprobar el código generado con herramientas de análisis estático y nunca usar las salidas del modelo como fuentes autoritativas.

M-14 — Política de uso aceptable de IA

Crear una política formal de uso aceptable de IA que cubra al menos: herramientas aprobadas (con tres categorías: Aprobadas, Uso Limitado y Prohibidas), usos prohibidos y tipos de datos prohibidos, directrices de prompts, requisitos de revisión de salidas, obligaciones de divulgación (cuándo debe indicarse que el contenido fue generado por IA) y restricciones de manejo de datos. La política debe ser revisada como mínimo semestralmente y comunicada activamente, no solo publicada en la intranet.

M-15 — Gestión de la cadena de suministro de IA

Evaluar la seguridad de todos los componentes de terceros antes del despliegue: modelos, servidores MCP, plugins, bibliotecas y adaptadores LoRA. Utilizar solo herramientas oficiales y verificadas de fuentes confiables. Fijar versiones específicas y monitorizar actualizaciones inesperadas. Implementar listas blancas de herramientas aprobadas y bloquear instalaciones no autorizadas. Auditar las descripciones de las herramientas en busca de instrucciones ocultas. Desplegar monitorización de red para detectar conexiones salientes sospechosas desde herramientas de IA. Verificar la integridad de los modelos mediante sumas de verificación y firmas digitales. Para mitigar el "slopsquatting", verificar siempre que los paquetes recomendados por la IA existan realmente antes de instalarlos.

M-16 — Inventario de activos de IA (AI-BOM)

Crear y mantener un inventario completo de todos los activos de IA de la organización (AI Bill of Materials): modelos utilizados, versiones, fuentes de datos, proveedores, dependencias, adaptadores y plugins. Utilizar estándares como OWASP CycloneDX para el formato. Este inventario es esencial para la gestión de vulnerabilidades (saber qué está afectado cuando se descubre un fallo), el cumplimiento normativo (demostrar trazabilidad) y la gestión de riesgos de proveedores.

M-17 — Eliminación de shadow AI

Desplegar herramientas empresariales de IA aprobadas como alternativa atractiva a las herramientas no autorizadas. Crear un "catálogo interno de IA" con herramientas permitidas. Implementar firewalls de IA que monitoricen los prompts en busca de datos sensibles. Aplicar principios de confianza cero: toda IA es de riesgo hasta que se verifique. Realizar auditorías departamentales regulares y añadir el uso de IA al registro de riesgos. Culturalmente, recompensar el uso responsable de IA en lugar de basarse únicamente en el castigo de la shadow AI: si los empleados encuentran que las herramientas aprobadas son fáciles de usar y eficaces, la motivación para usar herramientas no autorizadas desaparece.

M-18 — Observabilidad y monitorización de IA

Registrar cada llamada al modelo de lenguaje: prompts, respuestas, uso de tokens, latencia, versión del modelo e identidad del usuario. Desplegar una plataforma de observabilidad de IA adecuada (Datadog LLM Observability, Arize AI, LangSmith, Langfuse, Galileo). Implementar dashboards en tiempo real que monitoricen métricas de calidad, coste, seguridad y latencia. Configurar alertas automatizadas para anomalías en la calidad de las salidas, picos de coste o violaciones de seguridad. Retener los logs durante el período mínimo exigido por la regulación aplicable (6 meses bajo el Reglamento de IA para sistemas de alto riesgo). Adoptar las convenciones GenAI de OpenTelemetry como estándar de portabilidad.

M-19 — Diseño de interfaces que muestren la incertidumbre

Diseñar las interfaces de los sistemas de IA para que hagan visible la incertidumbre en lugar de proyectar una falsa confianza. Esto incluye: indicar cuando el modelo no tiene información suficiente, mostrar puntuaciones de confianza cuando estén disponibles, nunca presentar la IA como infalible en las comunicaciones internas, y diseñar los flujos de trabajo de forma que obliguen al usuario a tomar una decisión activa antes de aceptar la salida de la IA (en lugar de aceptarla por defecto).

M-20 — Controles específicos para agentes

Los sistemas agénticos requieren un conjunto de controles específico que va más allá de los controles genéricos de IA generativa:

M-21 — Análisis de seguridad del código (SAST/DAST)

Someter todo el código generado por IA al mismo (o mayor) nivel de escrutinio que el código de terceros. Ejecutar análisis estático (SAST) y dinámico (DAST) de seguridad sobre las sugerencias de IA antes de que se fusionen con el código base. Auditar periódicamente los archivos de configuración de asistentes de código (.cursorrules, .github/copilot-instructions.md) en busca de instrucciones ocultas. Verificar que los paquetes recomendados por la IA existen realmente (para prevenir el slopsquatting).

M-22 — Protección del prompt de sistema

No incluir nunca información sensible (claves API, credenciales, nombres de bases de datos, estructura de roles y permisos) directamente en los prompts de sistema. Externalizar esa información a sistemas que el modelo no pueda acceder directamente. No confiar en el prompt de sistema como mecanismo de control de seguridad: implementar un sistema de salvaguardas externo e independiente que inspeccione las salidas del modelo para verificar el cumplimiento. Los controles críticos como la separación de privilegios y las verificaciones de autorización no deben delegarse al modelo.

M-23 — Seguridad de bases de datos vectoriales

Implementar controles de acceso granulares y permisos conscientes en las bases de datos vectoriales utilizadas para RAG. Garantizar la partición lógica y de acceso estricta de los datasets para evitar el acceso no autorizado entre diferentes grupos de usuarios o diferentes niveles de clasificación. Validar y monitorizar regularmente la integridad de la base de conocimiento para detectar envenenamiento de datos. Aceptar datos solo de fuentes verificadas y confiables. Mantener logs detallados e inmutables de las actividades de recuperación.

M-24 — Gestión de costes y FinOps de IA

Implementar controles graduales de presupuesto: alertas al 50%, limitación al 80%, degradación de modelo al 90% (usar modelos más baratos automáticamente) y bloqueo al 100%. Utilizar caché semántico para consultas similares. Enrutar tareas simples a modelos más baratos y reservar los modelos de frontera para tareas complejas. Optimizar los prompts para reducir texto redundante. Usar CSV en lugar de JSON para datos tabulares (ahorro de 40-50% en tokens). Establecer prácticas FinOps con atribución de costes en tiempo real por equipo, proyecto y funcionalidad. Evaluar el autoalojamiento para volúmenes superiores a 2 millones de tokens diarios.

M-25 — Plan de respuesta a incidentes de IA

Desarrollar planes de respuesta a incidentes específicos para IA, distintos de los planes de incidentes de ciberseguridad generales. Definir niveles de severidad desde P1 (brecha de datos activa, respuesta en menos de 1 hora) hasta P4 (inexactitudes menores, menos de 72 horas). Preconfigurar controles para la primera hora: activación de modo seguro, limitación de tasa, desactivación de llamadas a herramientas y restricción de la recuperación a fuentes confiables. Realizar ejercicios de simulación con escenarios específicos de IA al menos trimestralmente.

M-26 — Residencia de datos y soberanía

Verificar y documentar la residencia de datos para todo el procesamiento de IA. Para industrias reguladas, evaluar proveedores nativos europeos (Mistral AI, Aleph Alpha, SAP EU AI Cloud) o modelos autoalojados que eliminen los flujos de datos transfronterizos. Incluir requisitos de residencia de datos en los contratos con proveedores. Mapear todos los flujos de datos, incluidos los datos efímeros de inferencia. Revisar las listas de subencargados y asegurar que todo el procesamiento ocurre dentro de las jurisdicciones requeridas. Tener en cuenta que las "regiones europeas" de proveedores con sede en Estados Unidos no proporcionan soberanía completa debido a la exposición a la Ley CLOUD.

M-27 — Gestión de la ventana de contexto

Reinyectar los prompts de sistema a intervalos regulares en conversaciones largas para evitar que se diluyan. Monitorizar la utilización del contexto y activar revisión humana cuando se aproxime al límite. Preferir la limpieza de resultados de herramientas (la forma más ligera de compactación) sobre la resumización completa del contexto. Establecer duraciones máximas de sesión para aplicaciones críticas de seguridad. Implementar pruebas automatizadas de adherencia al prompt de sistema a diferentes profundidades de contexto.

M-28 — Estrategia multi-modelo y portabilidad

Desplegar pasarelas de IA (AI gateways) como LiteLLM, TrueFoundry o APISIX que proporcionen una capa API unificada que abstraiga las APIs propietarias de cada proveedor, permitiendo cambiar rápidamente de modelo. Adoptar una estrategia multi-modelo (el 37% de las empresas ya usa 5 o más modelos). Usar estándares abiertos como ONNX para la portabilidad de modelos. Fijar versiones específicas de modelo en producción (por ejemplo, gpt-4o-2024-08-06) en lugar de alias que rotan automáticamente. Ejecutar suites de regresión contra cada cambio de modelo antes del despliegue.

M-29 — Protecciones contractuales con proveedores

Negociar diez cláusulas críticas en los contratos con proveedores de IA: (1) propiedad de datos y derechos de propiedad intelectual, (2) confidencialidad y restricciones de uso de datos, (3) DPA con cláusulas contractuales tipo para transferencias transfronterizas, (4) indemnización por infracción de PI y brechas de datos, (5) SLAs con 99,5-99,9% de disponibilidad, (6) derechos de auditoría (mínimo anual), (7) transparencia de IA y divulgación de cambios de modelo, (8) notificación de actualizaciones de modelo y capacidad de rollback, (9) garantías de cumplimiento regulatorio, (10) obligaciones de cooperación en respuesta a incidentes. Exigir derechos de exportación de datos, custodia de código (code escrow) y opciones de autoalojamiento.

M-30 — Restricciones de alcance para chatbots

Los despliegues de chatbots con clientes requieren las salvaguardas más estrictas: restricciones de comportamiento claramente definidas, filtrado de contenido, limitación del alcance de las respuestas (el chatbot solo puede hablar de temas predefinidos), escalado automático a agentes humanos cuando se detecten solicitudes fuera de alcance o intentos de manipulación, y revisión legal de todos los compromisos que pueda generar la IA. Nunca permitir que un chatbot haga promesas vinculantes sin revisión humana.

M-31 — Auditorías de sesgo y equidad

Realizar auditorías periódicas de sesgo en todos los sistemas de IA que afecten a personas, especialmente en procesos de selección, evaluación de rendimiento, concesión de crédito y servicio al cliente. Utilizar datasets de prueba diseñados para detectar disparidades por género, raza, edad y otras categorías protegidas. Implementar monitorización continua de los resultados del modelo para detectar derivas de sesgo a lo largo del tiempo. En sistemas agénticos, monitorizar los bucles de realimentación que puedan amplificar sesgos.

M-32 — Minimización de datos en sistemas de IA

Aplicar el principio de minimización de datos tanto a nivel de tratamiento (qué datos se hacen accesibles al sistema de IA) como a nivel de operación individual (qué datos son necesarios para cada paso de la cadena de razonamiento). Implementar políticas de acceso que apliquen el principio "need to know" a la IA. Catalogar y etiquetar los datos de la organización para poder restringir el acceso por categorías. Para datos no estructurados (correos, actas, informes), realizar preprocesamiento para extraer solo los datos necesarios y eliminar o anonimizar datos personales no relevantes. Filtrar los flujos de datos entre las diferentes acciones del agente para detectar y eliminar datos personales innecesarios en las etapas intermedias de las cadenas de razonamiento. Implementar políticas de borrado efectivas que cubran la memoria a largo plazo de los sistemas agénticos. Seudonimizar la interacción del usuario con el agente cuando sea posible.

Nota final

La IA generativa no es un riesgo que se pueda ignorar ni una amenaza que se deba evitar: es una realidad que hay que gobernar. Los 22 riesgos descritos en esta guía no son teóricos; están respaldados por incidentes reales, sanciones económicas y sentencias judiciales. Pero tampoco son inevitables: cada uno de ellos tiene medidas concretas y probadas para prevenirlo o mitigarlo.

La clave está en construir una gobernanza sistemática y por capas, donde la intensidad de la supervisión se adapte al nivel de riesgo. Una organización que clasifica sus datos, forma a sus empleados, despliega herramientas empresariales aprobadas, implementa supervisión humana escalonada y monitoriza sus sistemas de IA está en una posición incomparablemente mejor que la que prohíbe la IA (y la tiene igualmente, pero en la sombra) o la que la adopta sin controles.

Esta guía es un punto de partida. Los modelos, las amenazas y las regulaciones evolucionan cada mes. Lo que no cambia es el principio fundamental: la IA generativa es una herramienta extraordinaria que requiere una gobernanza extraordinaria.

Sobre nosotros

Somos una consultora española especializada en inteligencia artificial. Ayudamos a las empresas usar IA poniendo especial énfasis en la alfabetización de la plantilla, el cumplimiento de las leyes que regulan su uso y la prevención de riesgos.

Si después de leer esta guía necesita acompañamiento para prevenir los riesgos del uso de IA en su empresa, estaremos encantados de ayudarle.


Esta guía tiene carácter informativo y no constituye asesoramiento jurídico. La legislación en materia de IA evoluciona con rapidez; verifique siempre la vigencia de las normas citadas.
Última revisión: abril de 2026.

Volver al inicio