Seguridad de datos e IA en empresa: guía RGPD

Cuando una empresa plantea un proyecto de IA, los equipos de compliance y seguridad suelen reaccionar de dos formas: paralizando el proyecto con listas de requisitos interminables, o ignorando los riesgos reales hasta que hay un problema. Ninguna de las dos es la respuesta correcta. Esta guía intenta dar un mapa de los riesgos que importan de verdad y los controles proporcionales a esos riesgos.

¿Qué exige el RGPD en proyectos de IA?

• Base legal para el tratamiento: usar datos de clientes o empleados para entrenar un modelo requiere una base legal válida (consentimiento, interés legítimo, obligación contractual). Si usas datos de CRM para entrenar un modelo de churn, necesitas verificar que la base legal del tratamiento lo permite.
• Minimización de datos: los modelos de IA no necesitan todos los campos de la base de datos. Usar solo los datos necesarios para el objetivo del modelo reduce el riesgo.
• Evaluación de Impacto (EIPD): para tratamientos de alto riesgo (perfilado, toma de decisiones automatizada con impacto significativo en personas), el RGPD exige una evaluación de impacto previa.
• Transferencias internacionales: si usas APIs de IA de proveedores no europeos (OpenAI, Anthropic, Google), verifica que cuentan con las garantías adecuadas (Standard Contractual Clauses, BCRs o equivalentes).

Riesgos de seguridad específicos de los LLMs en empresa

AI Act: qué obligaciones afectan a los proyectos de empresa mediana

El AI Act clasifica los sistemas de IA según nivel de riesgo. Para la mayoría de proyectos de empresa mediana, los sistemas caen en 'riesgo limitado' (obligaciones de transparencia) o 'riesgo mínimo' (sin obligaciones específicas). Los sistemas de 'riesgo alto' — que incluyen IA para selección de personal, evaluación crediticia, acceso a servicios esenciales y gestión de infraestructuras críticas — tienen obligaciones más exigentes: documentación técnica, gestión de riesgos, registro de actividad y supervisión humana. Antes de lanzar cualquier sistema de IA, clasificar su nivel de riesgo según el AI Act es el primer paso de compliance.

Controles minimos de seguridad para proyectos de IA

Antes de conectar cualquier modelo de IA a datos reales, conviene tener resueltos al menos cinco controles basicos. El primero es el inventario de datos sensibles: saber exactamente que campos contienen datos personales, financieros o confidenciales, y donde estan almacenados. Sin este inventario, cualquier medida de seguridad es parcial.

El segundo es el control de acceso por roles. No todos los usuarios necesitan acceder a todos los datos. Un modelo de scoring comercial no necesita ver datos de nominas. Un copilot de soporte tecnico no necesita acceder a contratos con proveedores. La regla es minimo privilegio: cada sistema accede solo a lo que necesita para funcionar.

• Inventario de datos sensibles: campos, ubicacion, clasificacion por nivel de riesgo.
• Control de acceso por roles: quien accede a que, con que permisos, y con que justificacion.
• Cifrado en transito y en reposo: los datos viajan y se almacenan protegidos.
• Registro de actividad: quien consulto que dato, cuando y desde donde.
• Plan de respuesta ante incidentes: que hacer si se detecta una brecha o un acceso no autorizado.

El tercer control es el cifrado. Los datos que alimentan modelos de IA deben estar cifrados tanto cuando se almacenan como cuando se transmiten entre sistemas. Esto aplica especialmente cuando se usan APIs de terceros para procesamiento de lenguaje natural o vision artificial. Si los datos salen de tu infraestructura, el cifrado no es opcional.

Errores frecuentes en seguridad de datos con IA

El error mas comun es asumir que la seguridad del proveedor cloud es suficiente. AWS, Azure y Google Cloud ofrecen una base solida, pero la configuracion es responsabilidad del cliente. Un bucket de S3 mal configurado o un endpoint de API sin autenticacion puede exponer datos sensibles independientemente de lo seguro que sea el proveedor.

Otro error frecuente es no auditar los datos de entrenamiento. Si un modelo se entrena con datos que incluyen informacion personal sin anonimizar, el modelo puede memorizar y reproducir esa informacion en sus respuestas. Esto es especialmente critico en modelos de lenguaje y copilots internos que procesan documentos con datos de empleados o clientes.

El tercer error es tratar la seguridad como un paso final del proyecto. La seguridad debe diseñarse desde el inicio: en la seleccion de datos, en la arquitectura del sistema, y en el diseño de los flujos de acceso. Añadirla al final suele significar rehacer partes importantes del proyecto.

Si te interesa profundizar, en ai act y datos: calidad y trazabilidad exigidas exploramos este tema en detalle.

Para mas contexto, puedes consultar la informe de Gartner sobre datos listos para IA.

Preguntas frecuentes sobre seguridad en IA empresarial

¿Puedo usar los datos de mis clientes para entrenar un modelo de IA?

Depende de la base legal del tratamiento y del tipo de datos. Si los datos están anonimizados o seudonimizados de forma adecuada, el riesgo RGPD se reduce significativamente. Si son datos personales identificables, necesitas una base legal explícita para el nuevo tratamiento (el entrenamiento del modelo), que puede ser distinta de la base legal original para la que se recogieron.

¿Azure OpenAI es más seguro que la API de OpenAI?

Para datos empresariales sensibles, Azure OpenAI es generalmente la opción más segura porque los datos se procesan en el tenant de Azure de tu organización, bajo tu control. Microsoft ha publicado compromisos específicos de no usar datos de Azure OpenAI para entrenar modelos. La API de OpenAI directa también tiene compromisos de no entrenamiento con datos de API, pero los datos salen de tu entorno.

¿Es obligatorio hacer una EIPD antes de cualquier proyecto de IA?

Solo cuando el tratamiento es de 'alto riesgo' según el RGPD: evaluación sistemática de personas, datos a gran escala de categorías especiales, o monitorización sistemática de zonas accesibles al público. Para la mayoría de proyectos de datos e IA en empresa mediana (forecasting, reporting, automatización de procesos), no es obligatoria, aunque sí recomendable documentar el análisis.