Seguridad y RGPD en IA: qué exigir a tu proveedor antes de firmar

Contratar un sistema de IA sin auditar antes las medidas de seguridad y el cumplimiento del RGPD es como firmar un contrato de alquiler sin ver el piso. Cuando el sistema empiece a procesar datos de clientes, empleados o proveedores, la responsabilidad legal recae sobre ti, aunque la tecnología la haya montado un tercero. Un fallo de seguridad, una filtración o un uso indebido de datos personales puede costarte sanciones de hasta 20 millones de euros o el 4% de la facturación global anual, según el RGPD. La multa no distingue si la culpa fue tuya o del proveedor: la Agencia Española de Protección de Datos te expedientará a ti primero.

Este artículo te da un checklist técnico y legal para evaluar a un proveedor de IA antes de firmar el contrato. Cubrimos las cláusulas RGPD obligatorias, las medidas de seguridad que debes exigir, cómo verificar el cumplimiento real y qué señales de alarma justifican descartar al proveedor. Está pensado para responsables de pyme, autónomos y founders que van a contratar automatización con IA, chatbots de WhatsApp o agentes telefónicos y necesitan saber qué preguntar antes de que sea demasiado tarde.

Esta página es informativa, no es asesoramiento vinculante. Cada caso se ajusta tras diagnóstico.

TL;DR

• El RGPD te hace responsable del tratamiento aunque subcontrates la IA; el contrato de encargo de tratamiento es obligatorio y debe incluir cláusulas específicas de seguridad, auditoría y notificación de brechas.
• Exige al proveedor documentación verificable de sus medidas técnicas: cifrado en reposo y tránsito, logs auditables, control de acceso basado en roles, backups cifrados y plan de recuperación ante desastres.
• Si el sistema procesa categorías especiales de datos, toma decisiones automatizadas o monitoriza a gran escala, necesitas una Evaluación de Impacto en Protección de Datos (EIPD) antes de arrancar.
• Servidores fuera de la UE exigen garantías adicionales (cláusulas contractuales tipo, certificaciones) y análisis de transferencias internacionales tras Schrems II.
• Señales de alarma: el proveedor se niega a mostrarte el contrato de encargo antes de firmar, no documenta sus medidas de seguridad, almacena contraseñas en claro o usa modelos de IA sin informar de su ubicación y subcontratistas.
• Antes de firmar, valida certificaciones (ISO 27001, ENS, SOC 2), pide referencias de clientes en sectores regulados y comprueba que el proveedor tiene seguro de responsabilidad civil profesional.

Por qué la seguridad y el RGPD no son opcionales en IA

La normativa europea no distingue entre "IA" y "software tradicional" a efectos de protección de datos. Si tu sistema de IA procesa datos personales (nombres, teléfonos, emails, direcciones IP, cookies, transcripciones de voz, historial de compra), estás obligado a cumplir el RGPD desde el primer día. Un chatbot de atención al cliente, un agente telefónico que cualifica leads o una automatización que sincroniza CRM con WhatsApp procesan datos personales en cada interacción.

La diferencia con un software tradicional es que los sistemas de IA suelen implicar más actores: el proveedor de la plataforma, el proveedor del modelo de lenguaje (OpenAI, Anthropic, Google), el proveedor de infraestructura (AWS, Google Cloud, Hetzner), subcontratistas de telefonía o mensajería. Cada eslabón de esa cadena puede ser un punto de fuga. Si un subcontratista filtra una conversación de WhatsApp o un log con datos de clientes, la sanción inicial recae sobre ti como responsable del tratamiento, aunque luego puedas reclamar al proveedor.

Además, el Reglamento de IA europeo (AI Act), que entró en vigor en 2024 y se aplica por fases hasta 2026, introduce obligaciones adicionales para sistemas de IA de alto riesgo (gestión de personal, evaluación crediticia, servicios esenciales). Aunque tu chatbot de atención no sea de alto riesgo, el proveedor debe documentar la trazabilidad del modelo, los datos de entrenamiento y las medidas contra sesgos discriminatorios. Exigir esa documentación antes de firmar te protege de sanciones futuras.

Responsabilidades legales: quién responde si algo falla

El RGPD distingue dos roles: responsable del tratamiento y encargado del tratamiento. El responsable decide qué datos se recogen, para qué y durante cuánto tiempo. El encargado procesa los datos por cuenta del responsable, bajo sus instrucciones documentadas. En la mayoría de proyectos de IA para pymes, tú eres el responsable y el proveedor es el encargado.

Eso significa que si el sistema filtra datos, tú respondes ante los afectados y ante la AEPD, aunque la brecha la haya causado el proveedor. Luego puedes reclamarle daños y perjuicios si incumplió el contrato de encargo, pero la multa administrativa te llega a ti primero. Por eso es crítico:

• Firmar un contrato de encargo de tratamiento antes de que el sistema procese el primer dato.
• Incluir cláusulas de notificación inmediata de brechas (el encargado debe avisarte en menos de 24 horas).
• Definir medidas técnicas mínimas exigibles (cifrado, logs, control de acceso) y auditorías periódicas.
• Pactar un régimen de responsabilidad que reparta el coste de sanciones según la causa de la brecha.

Si el proveedor actúa como responsable conjunto (decide junto contigo qué datos recoger o cómo usarlos), ambos respondéis solidariamente ante la AEPD. Si es responsable autónomo (usa los datos para sus propios fines, como mejorar el modelo de IA), responde por separado. Clarificar estos roles en el contrato evita sorpresas.

Qué debe incluir el contrato (cláusulas RGPD y técnicas)

El artículo 28 del RGPD obliga a que el contrato de encargo incluya, como mínimo:

• Identificación de responsable y encargado, con datos de contacto del DPO de cada parte (si existe).
• Objeto, duración, naturaleza y finalidad del tratamiento.
• Tipos de datos personales (nombres, emails, teléfonos, transcripciones de voz, direcciones IP) y categorías de interesados (clientes, leads, empleados).
• Obligaciones del encargado: tratar los datos solo según instrucciones documentadas, garantizar la confidencialidad del personal, aplicar medidas técnicas y organizativas (cifrado, logs, control de acceso), notificar brechas en menos de 24 horas, colaborar en auditorías, devolver o destruir los datos al finalizar.
• Régimen de subcontratación: el encargado no puede subcontratar sin tu autorización previa por escrito. Si lo hace, debe imponer al subencargado las mismas obligaciones y responder ante ti de su cumplimiento.
• Auditorías: derecho a inspeccionar las instalaciones, sistemas y documentación del encargado, con preaviso razonable y bajo acuerdo de confidencialidad.
• Devolución o destrucción de datos: al finalizar el contrato, el encargado devuelve todos los datos y copias, o los destruye de forma certificable, salvo que una norma legal obligue a conservarlos.
• Limitación de responsabilidad: si el contrato incluye una cláusula de limitación de responsabilidad (típica en SaaS), asegúrate de que no cubra incumplimientos del RGPD, negligencia grave o brechas de seguridad intencionadas.

Además de lo obligatorio, conviene añadir:

• Medidas técnicas específicas: cifrado AES-256 en reposo y TLS 1.3 en tránsito, logs auditables durante 12 meses, autenticación multifactor para accesos administrativos, backups cifrados diarios con retención de 30 días, plan de recuperación ante desastres (RTO < 4 horas, RPO < 1 hora).
• SLA de disponibilidad y rendimiento: si el sistema cae, cuánto tarda el proveedor en restaurarlo y qué compensación recibes.
• Cláusula de cambio normativo: si el RGPD o el AI Act cambian, ambas partes renegocian el contrato en plazo razonable.
• Seguro de responsabilidad civil profesional: el proveedor debe tener una póliza que cubra al menos 1 millón de euros en reclamaciones derivadas de brechas de datos o incumplimientos del RGPD.

Si el proveedor te envía un contrato genérico de SaaS sin estas cláusulas, pide un anexo específico de encargo de tratamiento. Si se niega, descártalo.

Medidas técnicas que debes exigir (cifrado, logs, acceso, backups)

El RGPD obliga a aplicar medidas técnicas y organizativas apropiadas al riesgo. "Apropiadas" no significa lo mismo para una tienda online que para una clínica que procesa datos de salud, pero hay un mínimo exigible a cualquier sistema de IA que maneje datos personales:

• Cifrado: AES-256 para datos en reposo (bases de datos, backups, logs), TLS 1.3 para datos en tránsito (APIs, webhooks, conexiones a modelos de IA). Si el proveedor usa cifrado en tránsito pero no en reposo, cualquier acceso no autorizado al servidor expone todos los datos en claro.
• Control de acceso: autenticación multifactor (MFA) para accesos administrativos, control de acceso basado en roles (RBAC), logs de auditoría de quién accede a qué dato y cuándo. Si el proveedor da a sus desarrolladores acceso directo a producción sin MFA, es una señal de alarma.
• Logs auditables: registro de todas las operaciones críticas (creación, consulta, modificación, borrado de datos personales, accesos administrativos, cambios de configuración) con timestamp, usuario, IP y acción. Retención mínima de 12 meses. Los logs deben ser inmutables (write-once) y estar cifrados.
• Backups: copias diarias cifradas, almacenadas en ubicación geográfica distinta del sistema principal, con retención de al menos 30 días. Pruebas de restauración trimestrales documentadas. Si el proveedor no hace backups o no los prueba, una brecha de ransomware puede destruir tus datos sin posibilidad de recuperación.
• Aislamiento de datos: si el proveedor ofrece un SaaS multi-tenant, cada cliente debe tener su esquema o base de datos aislada, no solo segregación lógica por filtros SQL. Un fallo de configuración en un filtro puede exponer datos de un cliente a otro.
• Plan de recuperación ante desastres: RTO (Recovery Time Objective) y RPO (Recovery Point Objective) documentados, con procedimientos de failover automatizado si el sistema es crítico. Un chatbot de WhatsApp que gestiona pedidos en tiempo real no puede estar caído 48 horas.
• Gestión de secretos: contraseñas, claves API y tokens nunca en código fuente ni en variables de entorno en claro. Uso de gestores de secretos (AWS Secrets Manager, Vault, 1Password) y rotación periódica.

Pide al proveedor un documento técnico que detalle cada una de estas medidas. Si responde con generalidades ("usamos las mejores prácticas del sector"), insiste en datos concretos: algoritmo de cifrado, frecuencia de backups, ubicación de los servidores, política de acceso.

Cómo auditar al proveedor antes de firmar (checklist)

Antes de firmar, verifica:

1. Certificaciones y estándares: ISO 27001 (gestión de seguridad de la información), ENS (Esquema Nacional de Seguridad, si el proveedor trabaja con administraciones públicas), SOC 2 Type II (auditoría de controles de seguridad y disponibilidad). Las certificaciones no garantizan el cumplimiento del RGPD, pero son un indicador de madurez.
2. Política de privacidad actualizada: debe mencionar el RGPD, identificar al responsable y al DPO, explicar base legal de cada tratamiento, informar de transferencias internacionales y derechos de los interesados. Si la política es de 2018 o anterior, puede estar desfasada.
3. Registro de actividades de tratamiento: el proveedor debe tener un registro actualizado (obligatorio si tiene más de 250 empleados o trata categorías especiales de datos). Pide una copia, al menos de las actividades que te afectan.
4. Referencias de clientes en sectores regulados: si el proveedor trabaja con clínicas, despachos de abogados, asesorías o entidades financieras, ha pasado auditorías más estrictas. Pide contactos de referencia y pregúntales por incidentes de seguridad.
5. Evaluación de Impacto en Protección de Datos (EIPD): si tu proyecto implica decisiones automatizadas, categorías especiales de datos o monitorización a gran escala, pide al proveedor que colabore en la EIPD o que aporte la suya si ya hizo una para casos similares.
6. Prueba de concepto con datos sintéticos: antes de conectar el sistema a tu CRM o base de datos real, haz una prueba con datos ficticios y revisa los logs, accesos y trazas. Si ves datos en claro en logs o URLs, es una señal de alarma.
7. Contrato de encargo en borrador: el proveedor debe enviarte el contrato antes de la firma comercial, no después. Si te dice "firmamos primero y luego te envío el anexo de RGPD", rechaza.

Si el proveedor supera estos filtros, pide una reunión técnica con su DPO o responsable de seguridad. Pregunta por el procedimiento de notificación de brechas, el tiempo medio de respuesta ante incidentes, el plan de continuidad de negocio y el historial de sanciones (si ha tenido alguna).

Servidores, subcontratistas y transferencias internacionales

El RGPD permite transferir datos personales fuera del Espacio Económico Europeo (EEE) solo si el país de destino ofrece un nivel de protección adecuado o si se aplican garantías adicionales. Tras la sentencia Schrems II (2020), que invalidó el Privacy Shield entre la UE y EE.UU., las transferencias a EE.UU. exigen cláusulas contractuales tipo aprobadas por la Comisión Europea y un análisis caso por caso de los riesgos.

Si tu proveedor usa servidores en EE.UU. (AWS us-east-1, Google Cloud us-central1, Azure East US) o subcontrata proveedores de modelos de IA estadounidenses (OpenAI, Anthropic, Google Gemini hospedado en EE.UU.), necesitas:

• Cláusulas contractuales tipo (Standard Contractual Clauses, SCC) firmadas entre tú y el proveedor, y entre el proveedor y cada subcontratista fuera del EEE.
• Evaluación de impacto de la transferencia (Transfer Impact Assessment, TIA): análisis de si las leyes del país de destino (por ejemplo, FISA 702 o Executive Order 12333 en EE.UU.) permiten accesos gubernamentales sin garantías equivalentes al RGPD, y qué medidas técnicas adicionales aplica el proveedor para mitigarlos (cifrado extremo a extremo, anonimización, minimización de datos).
• Documentación de subcontratistas: lista de todos los subencargados (proveedor de hosting, proveedor de modelo de IA, proveedor de telefonía si es un agente de voz), con su ubicación geográfica y el tipo de datos que procesan.

Si el proveedor usa servidores en la UE (Hetzner Alemania, OVH Francia, AWS eu-west-1 Irlanda) y modelos de IA hospedados en la UE (Anthropic Claude via AWS eu-west-1, Mistral, modelos propios), la transferencia internacional no aplica, pero sigue obligado a documentar subcontratistas y aplicar las medidas de seguridad.

Algunas alternativas conformes:

• Proveedores que ofrecen residencia de datos en la UE (todos los datos y logs se almacenan y procesan exclusivamente en servidores de la UE).
• Sistemas de IA on-premise o en cloud privado (VPC aislada) donde tú controlas la infraestructura y el proveedor solo entrega el software.
• Modelos de IA de código abierto (Llama, Mistral) desplegados en tu propia infraestructura europea, con el proveedor como integrador.

Si el proveedor no puede documentar dónde están los servidores, qué subcontratistas usa o cómo gestiona las transferencias internacionales, no es una opción viable bajo el RGPD.

Señales de alarma: cuándo NO contratar

Descarta al proveedor si:

• Se niega a firmar un contrato de encargo de tratamiento antes de empezar, o te dice que "el RGPD está cubierto en los términos de servicio".
• No documenta sus medidas de seguridad o responde con generalidades cuando preguntas por cifrado, backups o logs.
• Almacena contraseñas en claro o usa algoritmos de hashing débiles (MD5, SHA-1 sin salt). Si un desarrollador puede ver tu contraseña, puede ver todos los datos.
• No tiene seguro de responsabilidad civil profesional que cubra brechas de datos o sanciones del RGPD.
• Usa modelos de IA sin informar de su ubicación: si no sabes si el modelo está en EE.UU., China o la UE, no puedes evaluar el riesgo de transferencia internacional.
• No hace backups o no los prueba periódicamente. Un ransomware destruye tus datos en minutos.
• Ofrece precios muy por debajo del mercado sin justificación técnica. La seguridad y el cumplimiento tienen un coste; un proveedor que cobra un 70% menos que la competencia probablemente recorta en cifrado, auditorías o infraestructura redundante.
• No tiene referencias verificables de clientes en producción, o se niega a dártelas "por confidencialidad" (puede darte contactos con consentimiento previo).
• Te pide acceso de administrador a tu CRM, base de datos o panel de control sin MFA, auditoría de accesos o limitación temporal.

Si detectas dos o más de estas señales, busca otro proveedor. El ahorro inicial no compensa el riesgo de una sanción de la AEPD o una demanda colectiva de clientes afectados por una filtración.

Preguntas frecuentes

¿Quién es responsable si un chatbot de IA filtra datos de clientes?

Depende del contrato. Si eres responsable del tratamiento y el proveedor actúa como encargado, tú respondes ante los afectados y la AEPD, pero puedes reclamar al proveedor si incumplió el contrato de encargo. Si el proveedor es responsable conjunto o autónomo, comparte la responsabilidad. Por eso es crítico definir roles y obligaciones por escrito antes de firmar.

¿Qué cláusulas RGPD debe tener el contrato con un proveedor de IA?

Como mínimo: identificación de responsable y encargado, finalidad y duración del tratamiento, tipos de datos y categorías de interesados, obligaciones del encargado (cifrado, logs, notificación de brechas), régimen de subcontratación, auditorías, devolución o destrucción de datos al finalizar, y limitación de responsabilidad ajustada al RGPD. Todo por escrito, antes de que el sistema procese el primer dato.

¿Puedo usar un sistema de IA sin hacer una evaluación de impacto (EIPD)?

Depende del riesgo. Si el sistema toma decisiones automatizadas sobre personas, procesa categorías especiales de datos (salud, origen étnico) o monitoriza a gran escala, la EIPD es obligatoria. En la práctica, cualquier chatbot o agente de voz que maneje datos de clientes justifica al menos una evaluación ligera. Consulta con un DPO o asesor legal antes de arrancar.

¿Cómo verifico que el proveedor cumple con el RGPD antes de firmar?

Pide certificaciones (ISO 27001, ENS, SOC 2), documentación de sus medidas técnicas (cifrado, backups, logs), política de privacidad actualizada, registro de actividades de tratamiento, y referencias de clientes en sectores regulados. Si se niega a mostrarte el contrato de encargo antes de la firma o no documenta sus medidas, descártalo.

¿Qué pasa si el proveedor usa servidores fuera de la UE?

Necesitas garantías adicionales: cláusulas contractuales tipo aprobadas por la Comisión Europea, certificación bajo un marco de adecuación (si existe), o medidas técnicas complementarias (cifrado extremo a extremo, anonimización). Tras Schrems II, las transferencias a EE.UU. y otros terceros países exigen análisis caso por caso. Exige al proveedor documentación de las salvaguardas aplicadas.

¿Es obligatorio tener un DPO si uso un sistema de IA en mi empresa?

No siempre. El DPO es obligatorio si eres autoridad pública, si tu actividad principal implica seguimiento habitual y sistemático a gran escala, o si tratas categorías especiales de datos a gran escala. Una pyme que usa un chatbot para atención básica no suele estar obligada, pero nombrar un DPO (interno o externo) facilita el cumplimiento y reduce riesgos. Consulta con asesor legal para tu caso concreto.

Siguiente paso

Si necesitas auditar a un proveedor de IA antes de firmar, revisa el checklist de este artículo y descarga la plantilla de cláusulas RGPD desde la sección legal. Si ya tienes un sistema de IA en producción y quieres verificar que cumple, solicita un diagnóstico técnico y legal gratuito que incluye revisión de contrato, evaluación de medidas de seguridad y plan de acción priorizado. Si buscas un proveedor que cumpla desde el diseño, consulta nuestros servicios de automatización con IA, agentes de voz y chatbots de WhatsApp, todos con infraestructura europea, contrato de encargo incluido y auditoría de seguridad pre-despliegue.