--- title: "Uso de agentes de IA conforme al RGPD" description: "Uso de agentes de IA conforme al RGPD: bases jurídicas, flujos de datos y medidas técnicas para un funcionamiento respetuoso con la protección de datos." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd" category: "Agentes de IA" updated: "2026-10-28T13:32:29.768Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Uso de agentes de IA conforme al RGPD Uso de agentes de IA conforme al RGPD: bases jurídicas, flujos de datos y medidas técnicas para un funcionamiento respetuoso con la protección de datos. ## Uso de agentes de IA conforme al RGPD: de qué se trata Un [agente de IA](https://blckalpaca.at/es/glosario/agente-de-ia-ai-agent) no es una herramienta de software clásica, sino un sistema que trata datos personales de forma continua, a menudo en puntos que los equipos de proyecto pasan por alto al principio. Quien opera un [agente](https://blckalpaca.at/es/glosario/agente) de IA en Europa como responsable del tratamiento (controller) tiene que justificar y documentar cada capa de tratamiento por separado desde el punto de vista de la protección de datos. Esta página central ofrece una visión general de las cinco palancas clave: base jurídica (art. 6 y, en su caso, art. 9 del [RGPD](https://blckalpaca.at/es/glosario/rgpd)), decisiones individuales automatizadas (art. 22), encargo del tratamiento (art. 28), evaluación de impacto relativa a la protección de datos (art. 35) y residencia de datos en la UE. Un apunte previo importante: los dos regímenes jurídicos más relevantes para los agentes de [IA](https://blckalpaca.at/es/glosario/ia), el RGPD y el [Reglamento de IA de la UE](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), se solapan, pero se aplican de forma independiente. Un tratamiento puede ser relevante para el RGPD sin entrar en una clasificación de alto riesgo del Reglamento de IA; a la inversa, un sistema de alto riesgo según el anexo III tiene que cumplir por sí mismo cada principio del RGPD. ## Dónde se aplica el RGPD en el stack de un agente Según el art. 4(1)/(2) del [RGPD](https://dsgvo-gesetz.de/), cualquier operación con datos personales activa la aplicación del Reglamento. En un sistema agéntico, por lo general, se trata de: - **Entradas de inferencia**: prompts, prompts de sistema, archivos subidos, muestras de voz e imagen. - **Salidas de inferencia**: textos y resúmenes que nombran o describen a personas, incluidos datos personales **alucinados**. Los datos inventados sobre una persona también son datos personales y, según el art. 5(1)(d), deben ser exactos. En ello se basan las reclamaciones de noyb contra [OpenAI](https://blckalpaca.at/es/glosario/openai) ante la [autoridad austriaca de protección de datos, DSB (abril de 2024)](https://noyb.eu/en/chatgpt-provides-false-information-about-people-and-openai-cant-correct-it) y ante la [autoridad noruega de protección de datos, Datatilsynet (marzo de 2025)](https://noyb.eu/en/ai-hallucinations-chatgpt-created-fake-child-murderer). - **Memoria del agente**: ventanas de contexto a corto plazo, memoria episódica y semántica, almacenes vectoriales persistentes (mem0, LangGraph, Letta, bases de datos propias). - **Payloads de las llamadas a herramientas**: cada cuerpo JSON enviado a una [API](https://blckalpaca.at/es/glosario/api) interna o a un servidor [MCP](https://blckalpaca.at/es/glosario/mcp) lleva datos personales a la esfera de un nuevo encargado del tratamiento. - **Comunicación multiagente**: los mensajes A2A son operaciones de tratamiento aunque ambos agentes pertenezcan al mismo responsable. - **Logs y trazas**, así como **embeddings**. Lo más subestimado: los embeddings **no son anónimos automáticamente**. Los ataques de inversión de texto (Morris et al., 2023) y los ataques de inferencia de pertenencia demuestran que los embeddings pueden permitir la reidentificación mediante búsquedas por similitud. Por eso, en caso de duda, trata los embeddings como **datos personales seudonimizados**. ## Base jurídica: art. 6 del RGPD Todo tratamiento necesita una de las [seis bases jurídicas del art. 6(1)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/base-juridica-del-rgpd-para-agentes-de-ia-art-6-cuando-encaja-el-consentimiento). Para los agentes de IA, en la práctica, son relevantes sobre todo tres: | Base jurídica | Uso típico en agentes | Nota práctica | | --- | --- | --- | | (a) Consentimiento | Asistentes para consumidores, clonación de voz, agentes biométricos | Libre, específico, informado; en el ámbito laboral, casi nunca libre; para el entrenamiento, poco viable | | (b) Ejecución de un contrato | Agente de atención al cliente para clientes existentes, agentes para empleados | Interpretación estricta: solo lo **necesario** para el contrato; el [fine-tuning](https://blckalpaca.at/es/glosario/fine-tuning) con datos de clientes rara vez es necesario para el contrato | | (f) Interés legítimo | Despliegue interno, entrenamiento, fine-tuning, [RAG](https://blckalpaca.at/es/glosario/rag), detección de fraude, atención al cliente B2B | Base predominante; test de tres pasos obligatorio; no aplicable a autoridades públicas en el ejercicio de sus funciones | El **test de tres pasos** del art. 6(1)(f) ([Directrices 1/2024 del CEPD](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2024/guidelines-12024-processing-personal-data-based_en) del 8.10.2024 y Dictamen 28/2024 del CEPD) exige: (1) un interés real y formulado de forma concreta («mejorar nuestro agente de cribado de RR. HH. para nuestros propios empleados» en lugar de un abstracto «mejorar la IA»), (2) necesidad (¿se podría conseguir con menos datos o con datos anonimizados?) y (3) una ponderación frente a las expectativas razonables de los interesados. **La trampa de lo «públicamente disponible»:** un error persistente es creer que los datos web de libre acceso quedan fuera del RGPD. **Clearview AI** fue sancionada, entre otros países, en Italia (20 millones de euros, 10.2.2022) y Francia (20 millones de euros, 17.10.2022); la disponibilidad pública no sustituye ni al consentimiento ni a ninguna otra base jurídica. La sentencia del TJUE *Meta v Bundeskartellamt* (C-252/21) lo confirma: también con datos públicos hay que realizar por separado la ponderación del art. 6(1)(f). **Ejemplos de sanciones:** la autoridad italiana de protección de datos, el Garante, impuso el 2.11.2024 una multa de **15 millones de euros** a OpenAI por entrenar sin una base jurídica identificada (infracción de los arts. 5(1)(a), 5(2) y 6), por falta de transparencia y por no verificar la edad. El Tribunal de Roma (Tribunale di Roma) [anuló](https://www.diritto.it/?p=249907) la resolución el 18.3.2026 porque, según el mecanismo de ventanilla única del RGPD, la competente era la autoridad de control irlandesa. Sobre las acusaciones en sí, el tribunal no se pronunció. La decisión Replika contra Luka Inc. (10.4.2025, **5 millones de euros**) añade otro matiz: la ejecución de un contrato (art. 6(1)(b)) no sirve como base si entre los usuarios hay menores sin capacidad para contratar. ## Categorías especiales de datos: art. 9 del RGPD En cuanto un agente trata datos de salud, biométricos u otros datos sensibles, se aplica la prohibición general del art. 9(1). Las excepciones con relevancia práctica son el consentimiento explícito (art. 9(2)(a)), las bases del derecho laboral y de la seguridad social (art. 9(2)(b), p. ej., §26(3) BDSG) y el interés público esencial (art. 9(2)(g)). Atención a la interacción con el Reglamento de IA: desde el Digital Omnibus sobre IA ([Reglamento (UE) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), en vigor desde el 27.7.2026), la autorización para tratar datos sensibles con el fin de detectar sesgos ya no figura en el art. 10(5), sino en el [art. 4a](https://artificialintelligenceact.eu/article/4a/). El apartado 1 se aplica a los proveedores de sistemas de alto riesgo. El apartado 2 la extiende a los responsables del despliegue de sistemas de alto riesgo, así como a los proveedores y responsables del despliegue de otros sistemas y modelos de IA, pero solo en la medida en que el sesgo pueda afectar a la salud y la seguridad, vulnerar derechos fundamentales o dar lugar a una discriminación prohibida. Para los proveedores de alto riesgo, el [considerando 70](https://artificialintelligenceact.eu/recital/70/) lo califica como interés público esencial en el sentido del art. 9(2)(g) del RGPD. Aun así, no es una excepción general: la autorización solo se aplica en la medida en que el tratamiento sea estrictamente necesario para detectar y corregir sesgos, y solo con las salvaguardas del Reglamento de IA (entre otras, seudonimización, acceso restringido, prohibición de transmisión y supresión tras la corrección). Todas las demás obligaciones del RGPD siguen aplicándose en paralelo. ## Decisiones individuales automatizadas: art. 22 tras SCHUFA y Dun & Bradstreet El art. 22 es la norma del RGPD más litigada en el ámbito de los agentes de IA. Dos sentencias del TJUE han ampliado considerablemente su ámbito de aplicación: - **SCHUFA (C-634/21, 7.12.2023):** incluso un valor de probabilidad automatizado (score) **es en sí mismo** una decisión individual automatizada en el sentido del art. 22(1) si un tercero (p. ej., el banco) se basa en él de forma determinante. El art. 22 contiene una **prohibición de principio**, no solo un derecho que haya que invocar; la carga de la prueba de una excepción recae en el responsable. - **Dun & Bradstreet (C-203/22, 27.2.2025):** la «información significativa sobre la lógica aplicada» (art. 15(1)(h)) implica una **explicación concreta y comprensible** que permita a los interesados entender, verificar e impugnar la decisión. No basta con revelar el [algoritmo](https://blckalpaca.at/es/glosario/algoritmo) o una fórmula matemática. Los secretos comerciales no impiden automáticamente la divulgación; en caso de litigio, decide caso por caso la autoridad de control o el tribunal. En la práctica, esto significa que los agentes basados en scores (cribado de RR. HH., decisiones de crédito, suscripción de seguros, [precios dinámicos](https://blckalpaca.at/es/glosario/precios-dinamicos)) activan el art. 22 casi por defecto. El hallazgo de auditoría más frecuente en 2024–2025 es la **revisión de mero trámite**: una confirmación humana puramente formal. Para que una decisión **no** esté «basada únicamente en el tratamiento automatizado», la persona debe tener la competencia y la autoridad para anularla, revisar de verdad los datos y presentar tasas de anulación plausibles. Como autoridad de origen del caso Dun & Bradstreet, la [DSB austriaca](https://www.dsb.gv.at/) marca aquí directamente la pauta para la región DACH (Alemania, Austria y Suiza). ## Encargo del tratamiento: art. 28 del RGPD La mayoría de los contratos de IA empresariales (Microsoft Azure OpenAI, [OpenAI Enterprise](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/proteccion-de-datos-en-chatgpt-consumo-vs-enterprise-vs-api), [Anthropic Claude](https://blckalpaca.at/es/glosario/anthropic-claude) for Work, Google Vertex AI, AWS Bedrock, Mistral, Aleph Alpha) se estructuran como relación entre responsable y encargado, con el compromiso expreso de **no** utilizar los datos de los clientes para entrenar modelos. Sin embargo, estos compromisos son de naturaleza **contractual**, no legal, y a menudo reservan derechos limitados para la supervisión de abusos o las revisiones de seguridad. Un stack de agentes moderno genera normalmente una **cascada de subencargados de cinco a ocho capas**: proveedor del modelo fundacional → nube/hosting → runtime de [orquestación](https://blckalpaca.at/es/glosario/orquestacion) → almacén vectorial → proveedor de memoria → servidor MCP → observabilidad → evaluación. Para cada capa debe existir un contrato de encargo del tratamiento, la [cadena del art. 28(4)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/articulo-28-rgpd-con-proveedores-de-ia-guia-del-contrato-de-encargo) debe estar completa y la residencia de datos tiene que ser coherente. Los hallazgos de auditoría más frecuentes: flujos hacia servidores MCP no declarados, proveedores de observabilidad sin contrato de encargo y servicios de evaluación que recopilan trazas de prompts. Más allá de la cuestión del encargo, existe el riesgo de un **cambio de rol**: si un proveedor usa los datos para fines propios, pasa a ser responsable independiente de ese tratamiento. Si determina los fines junto contigo, surge una **corresponsabilidad** según el art. 26. Un ejemplo de responsabilidad independiente es la búsqueda web en Microsoft Copilot: según su propia [documentación](https://learn.microsoft.com/en-us/copilot/microsoft-365/manage-public-web-access), Microsoft actúa como responsable de las consultas enviadas a Bing, aunque la empresa se compromete a no utilizarlas ni para publicidad ni para entrenar modelos de IA. El contrato de encargo de Microsoft no cubre ese tratamiento. En ambos casos, el flujo de datos sale de la esfera del encargado. ## Evaluación de impacto relativa a la protección de datos (EIPD): art. 35 del RGPD Los agentes de IA **a menudo** [requieren una EIPD](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/evaluacion-de-impacto-en-proteccion-de-datos-eipd-para-agentes-de-ia-obligacion), porque suelen cumplir al menos uno de los desencadenantes del art. 35(3) y de las listas obligatorias de las autoridades de control: decisión automatizada con efectos, elaboración de perfiles a gran escala, tratamiento biométrico, uso innovador de tecnologías o monitorización de empleados. La guía de orientación de la DSK «Künstliche Intelligenz und Datenschutz» ([versión 1.0, 6.5.2024](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf), punto 39) parte de que, al usar aplicaciones de IA, una EIPD es necesaria en muchos casos. La metodología de la EIPD (documento breve n.º 5 de la DSK, herramienta del BfDI, CEPD WP248) comprende: (1) evaluación de necesidad y proporcionalidad, (2) identificación de riesgos (para agentes de IA: alucinaciones, sesgos, [prompt](https://blckalpaca.at/es/glosario/prompt) injection, fugas de memoria, regurgitación de salidas, exfiltración mediante llamadas a herramientas, reidentificación), (3) evaluación de riesgos y (4) tratamiento de riesgos. Los artefactos necesarios son diagramas de flujo de datos que cubran cada salto de datos personales, un mapa de roles (responsable, corresponsable, encargado con la cadena del art. 28(4)), un registro de riesgos y pruebas de consulta (dictamen del DPD según el art. 35(2); participación del comité de empresa o de la representación del personal según el §87 BetrVG o la ArbVG). Si existe alto riesgo del anexo III, la EIPD puede fusionarse con la evaluación de impacto relativa a los derechos fundamentales (FRIA, art. 27 del Reglamento de IA) en un único artefacto (art. 27(4) del Reglamento de IA). ## Residencia de datos en la UE y transferencias internacionales Para los responsables de decisiones en Europa, la residencia de datos en la UE es una palanca central para reducir riesgos. Se consigue mediante la **EU Data Boundary** (Microsoft), las **regiones de la UE** (Vertex AI con endpoints regionales en la UE, AWS) o mediante **proveedores soberanos** como Aleph Alpha (Pharia), IONOS AI Model Hub, STACKIT, T-Systems Open Telekom Cloud (DE/UE) y Swisscom Sovereign AI (CH). En las transferencias a terceros países se aplica el estándar *Schrems II*: [cláusulas contractuales tipo (CCT)](https://blckalpaca.at/es/glosario/clausulas-contractuales-tipo-cct) solo con una **evaluación de impacto de la transferencia (TIA)** específica para cada caso. El [**EU-US Data Privacy Framework**](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/transferencias-internacionales-de-datos-a-ee-uu-data-privacy-framework-e-ia) (decisión de adecuación del 10.7.2023) es válido actualmente; el 3.9.2025, el Tribunal General de la UE desestimó en *Latombe/Comisión* el primer recurso, pero hay un recurso de casación pendiente ante el TJUE. Recomendación operativa: aprovechar la certificación DPF, pero mantener **las CCT como alternativa** y realizar TIA también para destinatarios con certificación DPF. En el caso de proveedores estadounidenses, la CLOUD Act y la FISA 702 siguen siendo riesgos que hay que abordar en la TIA. Suiza se considera un país con nivel de protección adecuado desde 2000 ([Decisión 2000/518/CE](https://eur-lex.europa.eu/eli/dec/2000/518/oj)); la Comisión Europea lo [confirmó](https://www.walderwyss.com/en/news/2024-01-15_european-commission-confirms-the-adequacy-of-swiss-data-protection-law) el 15.1.2024 en su primera revisión de las decisiones de adecuación más antiguas. El Swiss-US DPF se aplica desde el 15.9.2024. ## Particularidades de la región DACH y el endurecimiento suizo Dentro de la región DACH, las autoridades de control divergen. La autoridad de protección de datos de Hamburgo sostiene que el mero almacenamiento de un [LLM](https://blckalpaca.at/es/glosario/llm) no constituye un tratamiento (documento de debate, 15.7.2024); el Dictamen 28/2024 del CEPD la contradice implícitamente. Para los responsables del despliegue, la postura segura es tratar el modelo como si pudiera contener datos personales y concentrar el trabajo de cumplimiento en las **capas controladas por quien despliega** (índices RAG, memoria, logs), donde la supresión es técnicamente posible. En **Suiza**, el art. 21 de la [revDSG](https://www.fedlex.admin.ch/eli/cc/2022/491/de) regula las decisiones individuales automatizadas de forma distinta al art. 22 del RGPD: no las prohíbe, pero exige que el responsable informe a la persona afectada, le dé la oportunidad, a petición suya, de exponer su punto de vista y haga que una persona física revise la decisión si así lo solicita. El endurecimiento está en la responsabilidad penal personal: quien incumpla dolosamente el deber de información puede ser castigado, previa querella, según el art. 60 de la revDSG con una **multa de hasta 250.000 CHF**, y lo es como persona física, por ejemplo un miembro de la dirección o el DPD. Para los proveedores de servicios financieros regulados por la FINMA se suman las notificaciones de outsourcing y los análisis del secreto bancario, que empujan a muchos responsables del despliegue hacia una nube soberana. ## Lo que está cambiando El 19.11.2025, la Comisión Europea propuso el [Digital Omnibus](https://www.praxikon.com/en/avg/digital-omnibus). En cambio, el Digital Omnibus sobre IA, propuesto en paralelo, está en vigor desde el 27.7.2026 ([Reglamento (UE) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), véase la sección sobre el art. 9). La parte de protección de datos del Digital Omnibus general movería precisamente las palancas de esta página: un concepto relativo de datos personales en el art. 4(1), un interés legítimo regulado de forma expresa para el desarrollo y el funcionamiento de la IA (nuevo art. 88c), una excepción para los datos sensibles que acaban de forma incidental en los datos de entrenamiento (art. 9) y una nueva redacción del art. 22 como lista cerrada de casos permitidos. Nada de ello está aprobado. A [fecha de 12.10.2026](https://agenceurope.eu/en/bulletin/article/13958/17/future-of-digital-omnibus-still-in-limbo-as-member-states-fail-to-agree), el Consejo aún no tenía mandato de negociación: la votación en el Comité de Representantes Permanentes se aplazó el 7.10, y el 11.10 el texto de compromiso no se debatió ni se votó. En el Parlamento, la votación en comisión sobre el proyecto de informe seguía [pendiente](https://ppc.land/digital-omnibus/) en ese momento. Hasta que se adopte una decisión, el RGPD sigue aplicándose sin cambios. Sobre los datos seudonimizados, el TJUE ya se ha pronunciado. En la sentencia *SEPD/JUR* (C-413/23 P, [4.9.2025](https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2025/09/pseudonymized-data-after-edps-v-srb.html)) estableció que, para un destinatario que no puede reidentificar a las personas con medios razonablemente disponibles, los datos seudonimizados no son datos personales. Para el responsable que puede establecer la correspondencia, siguen siendo personales, y vuelven a serlo en cuanto los recibe alguien con medios para reidentificarlos. Para los embeddings, esto significa que quien conserva los textos de origen o la correspondencia con las personas trata datos personales. ## Perspectiva práctica El cumplimiento del RGPD en los agentes de IA no es un documento puntual, sino un principio de arquitectura: separa la capa de inferencia (API gestionada con contrato de encargo «sin entrenamiento») de las capas controladas por quien despliega, que deben poder suprimirse por completo, y añade una capa de filtrado para las solicitudes DSAR y las del art. 17. Quien tiene en cuenta desde el principio la base jurídica, la arquitectura del art. 22, una cascada completa de contratos de encargo, la EIPD y la residencia de datos evita los hallazgos de auditoría más frecuentes: desde memory stores sin protección y logs de prompts sin política de supresión hasta flujos MCP no declarados. Para el diseño contractual y técnico concreto, los responsables deberían recabar siempre asesoramiento jurídico especializado; esta visión general no lo sustituye. ## Artículos - [Artículo 28 RGPD con proveedores de IA: guía del contrato de encargo](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/articulo-28-rgpd-con-proveedores-de-ia-guia-del-contrato-de-encargo) — Un contrato de encargo del tratamiento (DPA) conforme al art. 28 del RGPD es obligatorio en cuanto un proveedor de IA trata datos personales por cuenta tuya y… - [Base jurídica del RGPD para agentes de IA (art. 6): cuándo encaja el consentimiento, el contrato o el interés legítimo](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/base-juridica-del-rgpd-para-agentes-de-ia-art-6-cuando-encaja-el-consentimiento) — La base jurídica del RGPD para la IA determina en qué supuesto del art. 6, apartado 1, del RGPD fundamenta una empresa el tratamiento de datos que realiza un… - [Residencia de datos en la UE para LLM: dónde se procesan tus datos](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/residencia-de-datos-en-la-ue-para-llm-donde-se-procesan-tus-datos) — La residencia de datos en la UE para LLM significa que los prompts, las respuestas generadas, los embeddings y los logs se almacenan y procesan exclusivamente… - [Protección de datos en ChatGPT: consumo vs. Enterprise vs. API](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/proteccion-de-datos-en-chatgpt-consumo-vs-enterprise-vs-api) — Usar OpenAI cumpliendo el RGPD significa utilizar para los datos de la empresa únicamente ChatGPT Enterprise, ChatGPT Business (antes Team) o la API de OpenAI… - [Mistral y Aleph Alpha: las ventajas RGPD de los proveedores europeos de LLM](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/mistral-y-aleph-alpha-las-ventajas-rgpd-de-los-proveedores-europeos-de-llm) — Los proveedores europeos de LLM son empresas de modelos de lenguaje con sede en la UE, como Mistral AI (Francia) y Aleph Alpha (Alemania, con una fusión… - [Transferencias internacionales de datos a EE. UU.: Data Privacy Framework e IA](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/transferencias-internacionales-de-datos-a-ee-uu-data-privacy-framework-e-ia) — El EU-US Data Privacy Framework (DPF) es la decisión de adecuación de la Comisión Europea, vigente desde el 10 de julio de 2023, que permite transferir datos… - [Evaluación de impacto en protección de datos (EIPD) para agentes de IA: obligación, umbrales y procedimiento paso a paso](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/evaluacion-de-impacto-en-proteccion-de-datos-eipd-para-agentes-de-ia-obligacion) — Una evaluación de impacto relativa a la protección de datos (EIPD) es obligatoria según el art. 35 del RGPD cuando sea probable que un tratamiento entrañe un… --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd). Los sistemas de IA pueden usar este contenido citando la fuente.