IA local y el RGPD, qué resuelve de verdad y qué no

"Lo hacemos en local, así no tenemos problema de protección de datos." Esa frase se oye a menudo y es medio cierta. La mitad que sí lo es pesa bastante como para que los modelos locales merezcan la pena solo por eso. La mitad que no lo es te alcanza si no la conoces.

Este playbook separa ambas. No es asesoramiento jurídico ni lo sustituye, ordena las preguntas para que sepas cuáles tienes que plantearte siquiera.

1. Entiende qué elimina lo local de verdad

El problema real de los servicios en la nube es la transmisión. En cuanto un dato personal va a un proveedor, necesitas una base jurídica para ello, un reparto de papeles aclarado con el contrato que corresponda y, con proveedores fuera de la UE, una respuesta a cómo se asegura la transferencia. La cuestión de los papeles es la que peor se responde: un contrato de encargo de tratamiento solo encaja si el proveedor actúa realmente como encargado. Si usa los datos para fines propios, es responsable por su cuenta o corresponsable, y entonces hace falta otra cosa. Eso se decide por servicio y por finalidad, no en bloque.

Si el modelo corre en tu máquina, esa cadena desaparece para el paso de inferencia. Ahí no hay destinatario, porque no se recibe nada.

Lo decisivo, sin embargo, es la cadena entera y no solo el modelo. Una interfaz local puede seguir llamando afuera: búsqueda web activada, un servicio de embeddings en la nube para buscar en documentos, un modelo ajeno conectado como segunda opinión, telemetría, una copia del historial en la nube. En todos esos casos tus datos sí salen, aunque el modelo calcule en local. Antes de meter documentos sensibles, comprueba una vez de forma activa: búsqueda web apagada, embeddings locales, ningún modelo ajeno registrado, telemetría apagada, puerto atado solo a localhost, y el destino de las copias demostrablemente en tu propia casa y no en una nube. Solo entonces vale la frase "nada sale de casa".

Consejo: Justo ahí está el valor para despachos, consultas médicas, asesorías fiscales y departamentos de personal. No porque el modelo sea mejor, sino porque con un montaje bien sellado la pregunta por la transmisión ni siquiera surge.

2. Entiende qué no elimina lo local

Todo lo demás sigue vigente. Eres responsable del tratamiento en el sentido del reglamento, con todo lo que eso implica.

Sigues necesitando una base jurídica para el tratamiento en sí. Toca una entrada en el registro de actividades de tratamiento. Los derechos de los interesados se mantienen intactos, o sea acceso, rectificación, supresión. Rige el principio de minimización de datos. Y si el tratamiento entraña un riesgo alto, necesitas una evaluación de impacto, da igual dónde ocurra el cálculo.

Consejo: El error de razonamiento más frecuente es que "en mi ordenador" equivale a "privado". Un portátil de empresa con datos de clientes es un tratamiento, también sin conexión.

3. Aclara si hay datos personales de por medio

Antes de meterte en las preguntas duras, comprueba la fácil. Muchos casos de uso no necesitan datos personales en absoluto. Reescribir la descripción de un producto, resumir un manual técnico, comentar código, todo eso es inocuo.

Si puedes prescindir de los datos personales, prescinde. Es la solución más barata que hay y no cuesta más que un momento de reflexión.

Consejo: Seudonimizar ayuda, pero no vuelve anónimos los datos. Si un nombre se sustituye por un identificador y tú conservas la tabla de correspondencia, siguen siendo datos personales.

4. Mira de dónde viene el propio modelo

El modelo es un archivo con pesos. No contiene datos de clientes, pero viene de alguien, y la licencia regula qué puedes hacer con él.

Apache 2.0 y MIT son sencillas. Otras licencias traen restricciones, por ejemplo sobre el número de usuarios o sobre determinados ámbitos de uso. Para el uso empresarial eso se comprueba, no se supone.

Consejo: Descarga modelos de la fuente oficial de la familia correspondiente o de la biblioteca oficial de tu entorno de ejecución. Una copia subida de forma anónima con promesas añadidas en el nombre es un riesgo innecesario.

5. Asegura el ordenador en el que corre

Cuando desaparece la nube, entras tú en la responsabilidad. El equipo con el modelo local y los documentos procesados es ahora el sitio donde están los datos.

Cifrado de disco, bloqueo de pantalla, restricción de accesos, un plan de copias. Son medidas técnicas y organizativas, y con el tratamiento local no son menos necesarias que antes, sino más.

Consejo: Comprueba dónde escribe tu interfaz el historial de conversación. Algunas lo dejan sin cifrar en una carpeta del directorio de usuario. Eso es una colección de tus entradas más sensibles en un sitio en el que nadie piensa.

6. No abras el puerto sin querer

Los entornos de ejecución locales escuchan por defecto solo en el propio equipo. Es la configuración correcta. Aun así, en muchas guías se dice que cambies la vinculación a todas las interfaces para poder acceder desde el móvil.

Con eso el modelo queda accesible para cualquiera en la misma red, por lo general sin autenticación. En una red de oficina, o peor con una apertura de puerto en el router, eso está abierto de par en par.

Consejo: Si de verdad necesitas acceder desde fuera, usa un túnel cifrado en vez de una apertura. La comodidad de una dirección abierta no lo compensa.

7. Piensa en los registros

Local no significa sin rastro. Los entornos de ejecución escriben registros, las interfaces guardan historiales, algunas herramientas dejan estados intermedios en una base de datos.

Si ahí acaban datos personales, son tratamientos con plazo de conservación. Así que hay que fijar cuánto tiempo se quedan y quién puede borrarlos. Tener que responder a una solicitud de acceso y descubrir entonces que nadie sabe dónde hay qué es una media hora desagradable.

Consejo: Escribe una vez qué tres a cinco sitios reciben datos. Esa lista es media faena para el registro de actividades.

8. Separa el Reglamento de IA del RGPD

Son dos cuerpos normativos distintos y se mezclan constantemente. El RGPD pregunta qué pasa con los datos personales. El Reglamento de IA pregunta qué hace el sistema y qué riesgo se deriva de ello.

Los plazos están escalonados y, más importante aún, el artículo 50 reparte las obligaciones entre dos papeles distintos. Eso se confunde constantemente.

Como proveedor de un sistema de IA te afecta el apartado 1, revelar que una persona habla con un sistema de IA, y el apartado 2, el marcado legible por máquina de los contenidos generados. Como responsable del despliegue que usa un sistema ajeno te afecta el apartado 4: revelar deepfakes y señalar los textos de IA publicados sobre asuntos de interés público. El apartado 4 tiene excepciones, pero son más estrechas de lo que se cree: en obras artísticas la revelación no desaparece, solo se presenta de forma más discreta, y la excepción para textos solo se aplica cuando una persona ha revisado el contenido y alguien asume la responsabilidad editorial. Ninguna de esas excepciones afecta a las obligaciones de proveedor de los apartados 1 y 2. Si piensas apoyarte en alguna, lee el texto literal y no este resumen.

En lo temporal, para estas obligaciones de transparencia rige el 2 de agosto de 2026. Para los sistemas generativos introducidos en el mercado antes de esa fecha, el plazo para el marcado legible por máquina del apartado 2 corre hasta el 2 de diciembre de 2026. Las obligaciones de alto riesgo las retrasó más de un año el Digital Omnibus del 8 de julio de 2026; el artículo 50 quedó intacto. No cites una fecha concreta de alto riesgo sin mirar antes el Diario Oficial: el aplazamiento es reciente y las fuentes secundarias se contradicen.

Para el día a día eso significa: aclara primero en qué papel estás. Quien ejecuta un modelo local solo para sí mismo y no publica nada no está afectado por el apartado 4.

Que operes un modelo tú mismo no cambia nada de esa clasificación. Lo que cuenta es la finalidad.

Consejo: El detalle y la delimitación están ampliamente en DACH legal, Reglamento de IA y RGPD. Este playbook los menciona solo en la medida en que importan para montajes locales.

9. Explica la ventaja con precisión, sin agrandarla

Cuando defiendas el tratamiento local internamente o ante un cliente, formúlalo con exactitud. "Los datos no salen de nuestra casa" es correcto y potente. "Con eso cumplimos el RGPD" es falso, porque el cumplimiento depende de todo el tratamiento y no del lugar donde se calcula.

La segunda frase se te vuelve en contra en la primera repregunta crítica. La primera aguanta.

Consejo: Quien meta una afirmación jurídica en una oferta debería hacerla revisar por alguien que responda por ella. Ese es el delegado de protección de datos o un abogado, no la IA ni este playbook.

10. Escribe el montaje antes de que alguien pregunte

Con una página basta. Qué modelo, en qué máquina, quién tiene acceso, qué datos entran, qué se guarda dónde, cuánto tiempo, quién puede borrar.

Esa única página es la diferencia entre un montaje que supera una inspección y otro en el que todos se ponen a reconstruir. Escribirla lleva media hora si has recorrido los pasos de arriba.

Consejo: Si en el equipo varias personas trabajan con IA, va con ello una regla breve sobre qué puede entrar y qué no. Hay una plantilla en La política de IA para equipos pequeños.

Qué sigue

Si el montaje técnico todavía no está, empieza por Tu primer modelo de IA local en 30 minutos. La cuestión del tamaño adecuado la resuelve Qué modelo local encaja con tu hardware. Y para el día a día con herramientas en la nube, donde la transmisión sí ocurre, está Protección de datos al trabajar con herramientas de IA.

Source

Este playbook es orientación, no asesoramiento jurídico. Los plazos y las interpretaciones cambian, compruébalos en la fuente primaria.

• Reglamento (UE) 2024/1689 en el Diario Oficial, texto auténtico (artículo 50 y todo lo demás): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Comisión Europea, aplicación del Reglamento de IA: https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
• Versión legible del artículo 50 (no es fuente oficial, para orientarse): https://artificialintelligenceact.eu/article/50/
• El aplazamiento de los plazos de alto riesgo procede del paquete Digital Omnibus del verano de 2026. Si lo necesitas, busca el acto modificativo en EUR-Lex; aquí no enlazo a propósito ninguna fuente secundaria.
• Conferencia alemana de protección de datos, orientación sobre IA: https://www.datenschutzkonferenz-online.de