IA local y RGPD: arquitectura, controles y responsabilidades

Local es una propiedad de arquitectura, no un certificado

Un modelo puede ejecutarse en un servidor propio y, aun así, recibir datos excesivos, conservar conversaciones sin límite, exponer una API, mostrar información a usuarios no autorizados o utilizar una base jurídica inadecuada. También puede depender de actualizaciones, integraciones o modelos cloud que saquen parte del tratamiento fuera de la infraestructura.

La ejecución local aporta ventajas potenciales: control de red, menor transferencia, administración de acceso, capacidad de borrar índices y posibilidad de operar sin conexión. Para convertirlas en garantías hay que documentar configuración, proveedores, flujos, permisos y pruebas.

Ollama, por ejemplo, admite modelos locales y cloud. En un entorno restringido debes activar el modo local exclusivo, controlar la salida de red y autorizar solo etiquetas locales. Consulta la guía de Ollama.

Mapea datos, sistemas y personas antes del modelo

Este mapa determina roles de responsable y encargado, contratos, información a los interesados, transferencias y controles. El nombre del modelo es solo una parte del tratamiento.

Convertir el RGPD en decisiones técnicas

Los permisos deben aplicarse antes de recuperar

En un sistema RAG, el riesgo no empieza cuando el modelo responde. Si el buscador entrega un fragmento confidencial a un usuario sin permiso, la exposición ya se ha producido. La autorización debe filtrar repositorios, documentos y metadatos antes de construir el prompt.

• Índices separados o filtros de seguridad que no dependan del lenguaje natural.
• Herencia de permisos desde la fuente y sincronización cuando cambian.
• Identificadores de documento y versión en cada fragmento.
• Borrado propagado a embeddings, cachés y copias según el procedimiento.
• Citas visibles y opción de abstención cuando no hay evidencia suficiente.
• Pruebas de acceso cruzado entre departamentos y perfiles.

Consulta la guía de IA con los datos de tu empresa para el diseño técnico.

Más autonomía implica más controles

Un agente puede leer correo, consultar sistemas, redactar documentos o proponer cambios. Cada herramienta amplía la finalidad, la superficie de ataque y el impacto de un error. La AEPD ha publicado orientaciones específicas para tratamientos con IA agéntica; la conclusión operativa es limitar autonomía, datos y efectos.

La guía de agentes de IA en local desarrolla permisos, validadores y límites.

Cuándo detener el despliegue y evaluar

La evaluación de impacto en protección de datos debe considerarse antes de iniciar tratamientos que puedan entrañar alto riesgo, según los criterios aplicables. Entre las señales se encuentran gran escala, datos sensibles, observación sistemática, perfiles, decisiones con efectos relevantes, personas vulnerables, tecnologías novedosas o combinación de fuentes.

La EIPD no es un documento posterior para justificar una decisión tomada. Debe comparar alternativas, identificar riesgos para las personas, definir medidas y comprobar el riesgo residual. Si permanece un riesgo alto que no puede mitigarse, procede la consulta previa a la autoridad en los términos aplicables.

El Reglamento de IA y el RGPD pueden aplicarse a la vez. Inventaria también si la organización actúa como proveedor, desplegador, importador o distribuidor del sistema y qué categoría de riesgo corresponde.

Controles verificables

• Finalidad y tareas excluidas aprobadas
• Base jurídica y roles documentados
• Inventario de datos, fuentes, modelos y proveedores
• Modo local exclusivo y salida de red comprobados
• Permisos aplicados antes de recuperación RAG
• Retención y borrado para cada componente
• Información a usuarios e interesados
• Procedimiento para acceso, rectificación y supresión
• Evaluación de impacto cuando corresponda
• Pruebas de seguridad, inyección y fuga entre perfiles
• Revisión humana en acciones relevantes
• Registro de versiones, incidentes y revisiones

Dibujar el recorrido de los datos antes de hablar de modelo local

La evaluación comienza con finalidad, personas, datos y sistemas. Un modelo ejecutado dentro de la empresa puede seguir recibiendo información desde Microsoft 365, enviar métricas a otra plataforma, utilizar un repositorio externo o guardar conversaciones durante más tiempo del necesario. El mapa debe cubrir toda la cadena.

1. Finalidad. Describe una tarea concreta y el beneficio esperado. Evita «usar IA» como finalidad genérica.
2. Interesados. Identifica empleados, clientes, proveedores u otras personas cuyos datos puedan aparecer.
3. Categorías de datos. Contenido, metadatos, inferencias, audio, imágenes, credenciales y registros.
4. Fuentes. Correo, documentos, ERP, CRM, grabaciones, formularios y conocimiento recuperado.
5. Componentes. Conectores, OCR, embeddings, base vectorial, modelo, interfaz, herramientas y logs.
6. Destinos. Discos, copias, proveedores, administradores y usuarios que pueden acceder.
7. Retención. Plazo y borrado para cada copia y dato derivado.
8. Decisiones. Qué propone la IA, qué ejecuta el sistema y qué revisa una persona.

Fuente → extracción → índice / embeddings → modelo → aplicación → resultado
   ↘ registros        ↘ copia             ↘ herramienta externa

Los prompts, embeddings y resúmenes pueden seguir siendo datos personales. Cambiar su formato no elimina automáticamente la relación con una persona.

Documentar responsables, encargados, base jurídica y límites de la finalidad

La arquitectura técnica no decide la base jurídica. La organización debe determinar quién define finalidad y medios, qué proveedores tratan datos por cuenta de quién, y qué normas adicionales afectan al contexto laboral, contractual o sectorial.

Cuando existan proveedores, revisa contrato, ubicación, subencargados, seguridad, soporte y borrado. Una función cloud opcional debe permanecer desactivada si la política exige tratamiento local exclusivo.

Minimizar antes de recuperar, no después de generar

La aplicación debe filtrar campos y documentos antes de construir el prompt. El modelo no necesita una ficha completa para redactar un borrador ni todo un expediente para responder una pregunta concreta. La minimización reduce exposición, contexto, latencia y memoria.

Pseudonimización y anonimización

Sustituir nombres por identificadores puede reducir exposición, pero si la organización puede volver a asociarlos sigue existiendo dato personal. La anonimización requiere que la reidentificación no sea razonablemente posible y no debe asumirse por eliminar unos pocos campos.

Localizar, corregir y borrar contenido, índices y datos derivados

Una solicitud puede afectar al documento de origen, un fragmento indexado, embeddings, conversaciones, memoria del agente, logs y copias. Diseña identificadores que permitan localizar las representaciones. La respuesta técnica «no podemos saber qué contiene el índice» indica una arquitectura difícil de gobernar.

Cuando se corrige una fuente, invalida cachés y resultados derivados. Registra la versión utilizada en una respuesta para poder explicar por qué el sistema mostró un contenido.

Aplicar identidad y permisos antes de la similitud vectorial

El buscador debe recibir la identidad verificada y limitar colecciones o fragmentos antes de entregar candidatos. No es suficiente pedir al modelo que «no revele» documentos de otro departamento. Tampoco debe revelarse mediante títulos o mensajes de error que existe una fuente restringida.

1. Sincroniza grupos desde el sistema de identidad o define una fuente controlada.
2. Asocia cada documento y fragmento a su política de acceso.
3. Filtra antes de búsqueda o aplica un filtro inseparable de la consulta.
4. Prueba el mismo texto con varios perfiles.
5. Comprueba enlaces compartidos, caché y resultados previos.
6. Revoca acceso y verifica que sesiones activas dejan de recuperar la fuente.

No confíes en la oscuridad semántica. Aunque el usuario no conozca el título exacto, consultas indirectas pueden recuperar contenido cercano si el filtro de permisos no es correcto.

Aumentar supervisión cuando el sistema puede actuar

Un agente añade herramientas y estado al modelo. Esto puede crear inferencias, combinar fuentes y ejecutar acciones. Cuanto mayor sea el efecto sobre personas, más explícitos deben ser la finalidad, la base, la información, la revisión humana y el recurso.

Una revisión humana solo es efectiva si la persona dispone de tiempo, competencia, información y autoridad para cambiar la propuesta. Un botón de aprobación rutinaria no corrige una automatización mal diseñada.

Probar fugas, inyección, aislamiento y recuperación

• Cifrado de comunicaciones y soportes cuando corresponde
• Segregación entre desarrollo, prueba y producción
• Actualizaciones y dependencias bajo inventario
• Secretos fuera de prompts y repositorios
• Alertas de acceso, errores y cambios de configuración
• Procedimiento de incidentes con responsables y evidencia

Identificar cuándo se necesita un análisis reforzado antes del despliegue

El riesgo aumenta con datos sensibles, gran escala, vigilancia, perfilado, combinación de fuentes, personas vulnerables, decisiones con efectos relevantes o agentes con autonomía. En estos casos puede ser necesaria una evaluación de impacto y, en todo caso, una revisión jurídica y de seguridad ajustada al contexto.

1. Describe necesidad, proporcionalidad y alternativas menos intrusivas.
2. Enumera amenazas para derechos y libertades, no solo para el servidor.
3. Valora probabilidad e impacto antes y después de controles.
4. Asigna responsables, evidencia y fecha de revisión.
5. Consulta a las funciones internas necesarias y, cuando corresponda, a representantes o interesados.
6. No publiques mientras quede un riesgo alto no tratado.

Además del RGPD, revisa las obligaciones que puedan aplicar al sistema de IA según su finalidad, proveedor, rol y nivel de riesgo. Esta guía técnica no sustituye asesoramiento jurídico.

Reunir la documentación que demuestra cómo funciona el sistema

• Finalidad, alcance, usuarios y casos excluidos
• Mapa de datos y diagrama de arquitectura
• Inventario de modelos, versiones, licencias y proveedores
• Base jurídica, roles y contratos
• Matriz de permisos y herramientas
• Política de retención, derechos y borrado
• Conjunto de evaluación y resultados
• Pruebas de seguridad e inyección
• Registro de cambios, incidencias y revisiones
• Plan de continuidad, parada y recuperación

La infraestructura local facilita limitar transferencias y controlar versiones, pero necesita administración. Define actualizaciones, copias, acceso físico, monitorización y soporte. El hardware se elige después de medir modelo, contexto, usuarios y disponibilidad requerida.