Seguridad y privacidad en proyectos de IA: datos, RGPD y AI Act

Publicado: 2026-05-25 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Seguridad y privacidad en proyectos de IA: cómo proteger datos y cumplir RGPD y AI Act con proveedores, permisos, registro y evaluación de impacto.

Proteger los datos en un proyecto de IA, y con ello cumplir el RGPD y el Reglamento europeo de IA (AI Act), depende de seis decisiones de seguridad y privacidad que se toman antes de escribir código: qué proveedor procesa los datos y cuánto los guarda, qué datos personales entran, quién puede ver qué (permisos), cómo se contiene la inyección de prompts, qué se registra y si hace falta una evaluación de impacto. Casi todas son decisiones de arquitectura, no de redacción de instrucciones.

La diferencia con el software habitual es que el modelo recibe instrucciones y datos en el mismo texto: un documento puede intentar darle órdenes y una respuesta puede revelar lo que el usuario no debería ver. Por eso los controles eficaces están fuera del modelo. Este artículo es orientación técnica, no asesoramiento jurídico.

Qué cambia en la seguridad de un proyecto de IA

Un sistema de IA hereda los riesgos de cualquier software y añade tres propios:

• Instrucciones y datos mezclados. El modelo no distingue con fiabilidad entre las instrucciones del sistema y el texto de un documento. OWASP sitúa la inyección de prompts (LLM01:2025) en el primer puesto de su Top 10 para aplicaciones con modelos de lenguaje.
• Respuestas que revelan. Una salida puede incluir datos personales o confidenciales del contexto o del índice: es la divulgación de información sensible (LLM02:2025).
• Un tercero en el camino de los datos. Consultas, documentos y ficheros pasan por un proveedor de modelos que los procesa y puede conservarlos.

El principio no cambia: el artículo 25 del RGPD exige aplicar la protección de datos desde el diseño, al decidir los medios del tratamiento y durante este.

Tabla de riesgos y controles en un proyecto de IA

Proveedores de modelos y retención de datos

Si el proveedor trata datos personales por cuenta de tu empresa, actúa como encargado: el artículo 28 del RGPD obliga a elegir encargados con garantías suficientes y a regular la relación con un contrato. Si los datos salen del Espacio Económico Europeo, se aplican además las reglas de transferencias del capítulo V. En la documentación de cada proveedor conviene comprobar tres cosas:

• Uso para entrenar. La API de OpenAI no entrena con los datos salvo aceptación expresa; Azure documenta que los datos no están disponibles para OpenAI ni se usan para mejorar sus modelos, y en Amazon Bedrock los proveedores de los modelos no acceden a consultas ni respuestas.
• Retención y región. OpenAI guarda registros de monitorización de abusos hasta 30 días, salvo exclusión aprobada; Azure permite solicitar una monitorización modificada y procesa en la UE los despliegues de zona de datos creados en un Estado miembro.
• Lo que guarda tu aplicación. En la API de OpenAI, ficheros, almacenes vectoriales y trabajos de fine-tuning se conservan hasta que alguien los borra. Esa retención la decide tu equipo.

Esto resume la documentación pública a fecha de esta revisión; cambia a menudo y debe confirmarse en el contrato. La comparación con un proveedor europeo o un modelo autoalojado está en cómo construir una IA interna y privada.

Datos personales: qué entra en el sistema y qué no

El artículo 5 del RGPD pide datos adecuados, pertinentes y limitados a lo necesario, conservados solo el tiempo necesario. En la ingesta eso significa:

1. Clasificar las fuentes: documentación general, información interna, datos personales y categorías especiales, como la salud.
2. Excluir lo que el caso no necesita: un asistente sobre vacaciones no necesita las nóminas.
3. Seudonimizar cuando haya que relacionar registros sin conocer la identidad; el artículo 32 cita la seudonimización y el cifrado entre las medidas de seguridad.
4. Fijar plazos para documentos indexados, conversaciones y registros: si un documento se borra en el origen, debe salir también del índice.

Ajustar un modelo con datos personales es más delicado, porque lo aprendido queda en los pesos. El Comité Europeo de Protección de Datos, en su dictamen 28/2024, solo considera anónimo un modelo así si resulta muy improbable identificar a las personas o extraer sus datos mediante consultas. Es un buen motivo para preferir RAG; la comparación está en fine-tuning o RAG.

Permisos: que nadie obtenga con una pregunta lo que no podía abrir

El fallo de privacidad más común en un asistente interno no es un ataque sofisticado, sino un índice que mezcla documentos de todos los departamentos. OWASP lo describe en debilidades de vectores y embeddings (LLM08:2025): con controles débiles se recuperan datos confidenciales, y en índices compartidos la información de un grupo aparece en las consultas de otro.

• Cada fragmento conserva los permisos de su documento en el sistema de origen.
• El filtro se aplica antes de recuperar, con la identidad del inicio de sesión corporativo, no con una instrucción en el prompt.
• Las herramientas usan credenciales de mínimo privilegio, y la autorización se comprueba en el sistema de destino, como recomienda OWASP en agencia excesiva (LLM06:2025).
• Se prueban los accesos denegados con preguntas que cada perfil no debería poder responder.

El diseño de la recuperación con permisos está en copilotos internos con RAG.

Inyección de prompts y fugas de información

Según OWASP, la inyección es directa cuando el usuario escribe instrucciones para alterar el sistema, e indirecta cuando llegan escondidas en contenido externo —una web, un PDF, un correo—. OWASP reconoce que no está claro que existan métodos infalibles para prevenirla, así que el objetivo es que, si funciona, el daño sea pequeño:

• Marcar el contenido externo como no fiable y tratarlo como dato, nunca como orden.
• Validar con código determinista el formato de las salidas antes de usarlas.
• Guardar credenciales y claves de API fuera del alcance del modelo.
• Exigir aprobación humana para las acciones de alto impacto y hacer pruebas adversarias.

Tampoco el prompt de sistema es una barrera: en filtración del prompt de sistema (LLM07:2025), OWASP advierte de que no es un secreto ni un control de seguridad y no debe contener credenciales. Si el sistema puede actuar en otras aplicaciones, el riesgo cambia de escala; lo tratamos en seguridad en agentes de IA en producción.

Registro y auditoría: poder reconstruir qué pasó

Sin registro no se puede investigar una queja, detectar un abuso ni demostrar cumplimiento. Por cada interacción conviene guardar quién preguntó y cuándo, qué fuentes se recuperaron, qué se respondió y, si hubo una acción, con qué parámetros y quién la aprobó. El consumo también: en consumo sin límites (LLM10:2025), OWASP recomienda cuotas por usuario y monitorización.

El registro contiene datos personales, así que necesita acceso restringido y plazo de conservación. Si el sistema es de alto riesgo, el artículo 26 del Reglamento de IA obliga a quien lo despliega a conservar los registros automáticos bajo su control al menos seis meses, salvo que otra norma disponga otra cosa. Y ante una violación de seguridad de datos personales, el artículo 33 del RGPD exige notificarla a la autoridad en un máximo de 72 horas, salvo que sea improbable que suponga un riesgo: sin trazas, es difícil saber a tiempo qué se expuso.

Evaluación de impacto: RGPD y Reglamento europeo de IA

Evaluación de impacto de protección de datos (EIPD)

El artículo 35 del RGPD exige una EIPD cuando un tratamiento, sobre todo con nuevas tecnologías, entrañe probablemente un alto riesgo para las personas; por ejemplo, la evaluación sistemática de aspectos personales mediante perfiles con efectos jurídicos o similares. La AEPD la considera obligatoria, en general, cuando concurren dos o más factores de riesgo, y recomienda hacerla si hay dudas. La LOPDGDD, en su artículo 28, añade supuestos de mayor riesgo que deben tenerse en cuenta, como los perfiles, las categorías especiales, los menores y otros colectivos vulnerables o el tratamiento masivo.

Qué pide el Reglamento europeo de IA y desde cuándo

El reglamento clasifica los sistemas por su uso y escalona su aplicación. Fechas del artículo 113 en la versión consolidada, que ya incluye el Ómnibus Digital sobre IA:

• 2 de febrero de 2025: prácticas prohibidas del artículo 5, como inferir emociones en el trabajo o en centros educativos salvo por motivos médicos o de seguridad, y medidas de alfabetización en IA del artículo 4.
• 2 de agosto de 2026: aplicación general, incluida la transparencia del artículo 50: las personas deben saber que interactúan con una IA, salvo que resulte evidente.
• 2 de diciembre de 2027: obligaciones de los sistemas de alto riesgo del anexo III, como los usados para seleccionar candidatos, decidir promociones, supervisar el rendimiento o evaluar la solvencia.

Quien despliega un sistema de alto riesgo debe asignar supervisión humana competente, informar a los trabajadores afectados antes de usarlo, conservar registros y apoyarse en la información del proveedor para la EIPD. Los organismos públicos y algunas entidades privadas, como las que prestan servicios públicos o evalúan la solvencia, deben hacer además una evaluación de impacto en derechos fundamentales. La mayoría de asistentes internos y automatizaciones de backoffice no son de alto riesgo, pero la clasificación depende del uso: el modelo que resume manuales cambia de categoría si puntúa candidatos.

Ejemplos: tres proyectos y sus decisiones de seguridad

Los escenarios siguientes son hipotéticos e ilustrativos, no casos de clientes.

• Asistente sobre manuales técnicos. Sin datos personales en las fuentes, el trabajo se centra en el proveedor —API empresarial con región europea y sin uso para entrenar—, en marcar como no fiables los PDF de terceros y en registrar fuentes y respuestas. Las conversaciones, que pueden incluir nombres, tienen su propio plazo de conservación.
• Clasificador de correos de clientes. Se extraen solo los campos necesarios para el CRM, se seudonimiza lo que llega al registro y los correos procesados se borran en un plazo fijado. Como un correo puede traer instrucciones ocultas, el modelo devuelve campos con formato validado y no tiene herramientas de escritura.
• Preselección de candidatos. Es un uso del anexo III, perfila a personas y es probable que exija EIPD. Antes de diseñar conviene revisar con la asesoría legal si compensa, qué supervisión humana habrá y cómo se informará a los candidatos; a menudo lo sensato es limitar la IA a tareas que no deciden.

Lista de comprobación antes de pasar a producción

1. Contrato de encargado, región elegida y uso para entrenamiento descartado.
2. Fuentes clasificadas y sin datos personales innecesarios.
3. Plazos de conservación para índices, conversaciones, registros y ficheros en el proveedor.
4. Filtro de permisos probado con accesos denegados.
5. Contenido externo como no fiable y aprobación humana en las acciones de impacto.
6. Prompt de sistema sin secretos y reglas críticas aplicadas en código.
7. Registro con acceso restringido y alertas de consumo.
8. Decisión documentada sobre la EIPD y la clasificación según el Reglamento de IA, y formación básica para la plantilla.

Si el proyecto ya está en marcha, qué revisar en una auditoría técnica de IA recorre datos, permisos, integraciones y evaluación.

Cuánto cuesta incorporar la seguridad

La seguridad no es una partida que se compra al final: forma parte del alcance. Los rangos de nuestro informe de precios 2026 describen sistemas que ya incluyen controles básicos, como fuentes citadas, permisos por rol o revisión humana:

• Automatización acotada con revisión humana: 10.000-20.000 €, en 4-6 semanas.
• Chatbot o asistente con RAG, con fuentes y panel de gestión: 10.000-25.000 €, en 4-8 semanas.
• Copiloto interno con RAG y permisos por rol: 20.000-50.000 €, en 6-12 semanas.
• Agente acotado a una tarea, con revisión humana: 20.000-35.000 €, en 6-8 semanas.

Dentro de cada rango, lo que más pesa son los permisos de origen, el volumen de datos personales y si el sistema actúa sobre otras aplicaciones. Se suman la API de modelos, desde unos 100 € al mes con poco volumen; la infraestructura cloud, entre 50 y 500 € al mes, y el mantenimiento, del 15 al 25 % del coste de desarrollo al año. La asesoría jurídica va aparte.

Preguntas frecuentes

¿Qué riesgos de seguridad son propios de la IA?

La inyección de prompts, directa o escondida en documentos; la fuga de información a través de las respuestas; el acceso indebido a documentos en sistemas RAG; el consumo sin límites y, si el sistema actúa en otras aplicaciones, las acciones no autorizadas. Se suman a los riesgos habituales del software.

¿Se puede usar un modelo de OpenAI, Azure o AWS cumpliendo el RGPD?

Puede hacerse, pero no es automático: hace falta un contrato de encargado, revisar región y transferencias, comprobar que los datos no se usan para entrenar, fijar la retención de ficheros y registros y aplicar permisos en tu aplicación. Conviene confirmarlo con tu asesoría legal.

¿Cuándo necesito una evaluación de impacto?

Cuando el tratamiento entrañe probablemente un alto riesgo para las personas, por ejemplo si las perfila con efectos significativos o trata categorías especiales a gran escala. La AEPD considera que, en general, es obligatoria cuando concurren dos o más factores de riesgo, y recomienda hacerla en caso de duda.

¿Un asistente interno es un sistema de alto riesgo según el AI Act?

Normalmente no, si responde sobre documentación. Pasa a serlo si se usa para fines del anexo III, como seleccionar candidatos o evaluar la solvencia de personas; esas obligaciones se aplican desde el 2 de diciembre de 2027. La transparencia del artículo 50 rige desde el 2 de agosto de 2026.

Lecturas relacionadas

• Cómo construir una IA interna y privada
• Seguridad en agentes de IA en producción
• Fine-tuning o RAG: cuándo usar cada uno
• Sistemas RAG para empresas