Agentes de IA y RGPD: qué puede hacer tu empresa y qué no

La pregunta que llega a una reunión de dirección suele ser «¿podemos usar un agente de IA sin incumplir el RGPD?». Es la pregunta equivocada, porque el RGPD no regula la IA: regula el tratamiento de datos personales. El límite legal no está en la tecnología, sino en qué datos toca el agente, con qué finalidad y quién responde de cada decisión que produce. Cambia esas tres preguntas y la mayoría de bloqueos que hoy paralizan proyectos se disuelven —o se convierten en un no razonado, que también vale.

Dos normas distintas que la gente mezcla

En Europa hay dos planos que conviene no confundir. El Reglamento General de Protección de Datos (Reglamento UE 2016/679) se activa cuando hay datos personales de por medio, sea con IA o con una hoja de cálculo. El Reglamento de Inteligencia Artificial (Reglamento UE 2024/1689, el llamado AI Act) regula el sistema de IA en sí: qué usos están prohibidos, cuáles son de alto riesgo y qué obligaciones tiene quien lo despliega, aunque no trate ni un solo dato personal.

La consecuencia práctica: un agente que resume documentación técnica interna sin datos de personas queda fuera del RGPD, pero puede seguir teniendo obligaciones bajo el Reglamento de IA. Y al revés, un agente que clasifica correos de clientes está plenamente dentro del RGPD aunque su uso sea trivial. Para el detalle de cada caso, las fuentes a consultar son el texto de ambos reglamentos en el Diario Oficial de la Unión Europea y las guías de la Agencia Española de Protección de Datos (AEPD); esto es criterio operativo, no asesoramiento jurídico.

Los artículos que de verdad te van a tocar

No necesitas leerte el reglamento entero. En un proyecto de agente, casi todo lo que se discute cae en estos puntos del RGPD:

• Principios (art. 5): limitación de la finalidad y minimización. Si el agente ve más datos de los que necesita para su tarea, ahí tienes un problema antes que ningún otro.
• Base jurídica (art. 6): consentimiento, ejecución de un contrato, obligación legal o interés legítimo. Toda finalidad necesita una, y «lo hacemos porque es útil» no es ninguna.
• Decisiones automatizadas (art. 22): límites cuando una decisión sin intervención humana produce efectos jurídicos o afecta significativamente a una persona.
• Encargado del tratamiento (art. 28): el proveedor del modelo o de la plataforma suele ser encargado, y eso exige contrato con instrucciones, garantías y subencargados identificados.
• Registro de actividades (art. 30): el nuevo tratamiento debe aparecer documentado, no vivir como un experimento paralelo.
• Seguridad (art. 32): control de accesos, cifrado, registro de qué hizo el agente y con qué información.
• Evaluación de impacto (art. 35): obligatoria cuando el tratamiento entraña un alto riesgo para los derechos de las personas.
• Transferencias internacionales (cap. V): dónde se procesan realmente los datos y bajo qué garantías.

El error de mercado: tratar el RGPD como un interruptor

Se ve en dos versiones opuestas y ambas salen caras. La primera es la parálisis: «no podemos usar IA por el RGPD», dicho sin haber mirado un solo flujo de datos. Bloquea proyectos que serían perfectamente viables con datos anonimizados o con un tratamiento acotado. La segunda es la temeridad: «es solo una herramienta, como el buscador», mientras alguien pega el histórico de clientes en un servicio contratado con tarjeta personal y sin contrato de encargo.

Las dos posturas comparten la misma carencia: nadie ha inventariado qué dato entra, qué dato sale y dónde se queda. Sin ese inventario no hay ni permiso ni prohibición; hay opinión. Y las opiniones no se defienden ante una inspección ni ante un cliente que pregunta.

El marco: tres preguntas antes de elegir herramienta

1. ¿Qué dato entra y qué dato sale?

Recorre el flujo de trabajo paso a paso y anota la categoría de dato en cada punto: identificativos, contacto, económicos, contractuales, de salud, laborales. Marca cuáles son categorías especiales, porque el listón sube mucho. Después pregunta lo incómodo: ¿el agente necesita todos esos campos para hacer su trabajo, o los ve simplemente porque están en la misma tabla? En la mayoría de proyectos que revisamos, buena parte del riesgo se elimina recortando el acceso, no comprando nada.

2. ¿Con qué finalidad y con qué base jurídica?

Una finalidad concreta y escrita: «clasificar incidencias entrantes para asignarlas al equipo correcto». No «mejorar la atención al cliente». Con la finalidad escrita, la base jurídica casi se elige sola y se ve enseguida si estás usando datos recogidos para otra cosa —el fallo más común y el más difícil de justificar después.

3. ¿Quién responde de cada decisión?

Aquí está el corazón del asunto. Un agente propone, ejecuta o decide, y cada verbo tiene un régimen distinto. Si propone y una persona valida, tienes intervención humana real. Si ejecuta dentro de reglas cerradas, necesitas trazabilidad y capacidad de revertir. Si decide sobre una persona con efectos relevantes, entras en el terreno del artículo 22 y la respuesta por defecto es no, salvo excepciones tasadas y con garantías. La autonomía no es una característica técnica: es una asignación de responsabilidad.

Un agente no diluye la responsabilidad: la concentra. Si nadie es dueño del proceso, tampoco hay nadie que responda de su salida.

Qué suele poder hacer tu empresa y qué no

Normalmente sí, con las garantías correctas

• Clasificar y enrutar correos o incidencias entrantes, con revisión de los casos dudosos.
• Extraer datos de facturas, albaranes o contratos para volcarlos a un sistema, con validación antes de contabilizar.
• Redactar borradores de respuesta que una persona revisa y envía.
• Buscar y resumir documentación interna, limitando el acceso del agente a lo que esa persona ya podría ver.
• Detectar anomalías o desviaciones y avisar a un responsable, sin actuar por su cuenta.

No, o no sin condiciones muy exigentes

• Decidir automáticamente sobre una persona con efecto jurídico o similar: denegar un crédito, descartar una candidatura, resolver una reclamación en contra. Territorio del art. 22.
• Reutilizar datos de clientes recogidos para gestionar pedidos con una finalidad nueva —entrenar, perfilar, segmentar— sin base jurídica ni información previa.
• Volcar datos personales en servicios contratados sin contrato de encargo del tratamiento, sin saber dónde se procesan y sin control de subencargados.
• Usos que el Reglamento de IA prohíbe expresamente, como el reconocimiento de emociones en el ámbito laboral o la categorización biométrica en los supuestos vetados.
• Dar acceso al agente a repositorios completos «porque es más fácil» y confiar en que no usará lo que no debe.

Siete pasos para dejarlo defendible

1. Dibuja el flujo de trabajo end-to-end y marca en qué pasos aparecen datos personales.
2. Clasifica esos datos por categoría y elimina del alcance del agente todo lo que no necesite.
3. Escribe la finalidad en una frase y asigna base jurídica; si no sale, el proyecto no está listo.
4. Cierra el contrato de encargo con el proveedor y localiza dónde se procesa y con qué garantías.
5. Define el nivel de autonomía por tipo de caso: proponer, ejecutar o decidir, y quién valida cada uno.
6. Registra el tratamiento, activa el rastro de auditoría y evalúa si necesitas evaluación de impacto.
7. Mide: porcentaje de casos que requieren intervención humana, errores detectados en revisión y tiempo de respuesta ante una solicitud de derechos.

Ese último punto es el que casi nadie prepara. Si mañana un cliente ejerce su derecho de supresión, ¿sabes qué se le pasó al agente, qué queda registrado y en cuánto tiempo puedes responder? Si la respuesta es «habría que mirarlo», el problema no es de IA: es de gobierno del dato, y se arregla antes y más barato que después.

Cuándo compensa avanzar y cuándo parar

Compensa avanzar cuando el proceso está mapeado, el dato personal es acotado o prescindible, hay una persona que valida las salidas sensibles y existe una métrica que demostrará la mejora. Ahí el cumplimiento es un diseño, no un freno.

Conviene parar cuando la finalidad todavía es difusa, cuando el agente necesitaría ver todo el sistema para funcionar, cuando nadie quiere firmar como responsable de sus decisiones o cuando el proveedor no puede decirte dónde se procesan los datos. Parar ahí no es renunciar: es evitar un proyecto que se caerá en el primer control interno, y suele significar que primero toca ordenar el dato. Es el mismo trabajo previo que describimos en los datos que necesitas antes de un proyecto de IA.

Nada de esto sustituye a un análisis jurídico de tu caso concreto. Lo que sí hace es llegar a esa conversación con el flujo dibujado, el dato inventariado y la responsabilidad asignada —que es exactamente lo que un asesor necesita para darte una respuesta útil en vez de un «depende».