Seguridad de los datos al implantar IA

La seguridad de los datos con IA se decide en la fase de arquitectura, no después de implantarla. Hay que responder ocho preguntas: qué datos llegan al modelo, dónde se tratan, quién accede, qué permanece en los registros y durante cuánto tiempo, qué roles se derivan del RGPD, qué ocurre ante un incidente y si la persona usuaria sabe que habla con IA.

Situación jurídica de esta sección: agosto de 2026. Es una lista de comprobación de proyecto, no asesoramiento jurídico individual.

Decir que «el proveedor del modelo tiene una buena política de privacidad» no responde a ninguna de ellas.

1. ¿Qué datos deben llegar realmente al modelo?

Una protección básica es minimizar: no envíes lo que no hace falta para realizar la tarea. En la práctica se aplica de tres maneras:

• Reducir el contexto. Un modelo que clasifica una solicitud puede no necesitar todo el historial del cliente. Un buen RAG recupera solo el conjunto de fuentes pertinente y lo más pequeño posible para responder; reduce exposición y coste de tratamiento.
• Enmascarar identificadores. Un número PESEL, de contrato o un apellido puede sustituirse por un marcador si la tarea no requiere su significado. El mapa que permite restaurar el dato sigue requiriendo protección; la seudonimización no es anonimato.
• Dividir la tarea. La parte que exige datos sensibles puede quedarse en el código y enviar al modelo únicamente el fragmento que necesita interpretar texto. La posibilidad y conveniencia dependen del proceso y del coste de un error.

2. ¿Dónde se procesan los datos?

Opción	Control	Coste	Cuándo la elegimos
Modelo comercial mediante la interfaz del proveedor	contractual	a menudo bajo al inicio	cuando condiciones, ubicación y sensibilidad cumplen los requisitos del proceso
Modelo comercial con tratamiento en una región elegida	contractual más requisito de ubicación	medio	cuando se exige conformidad sobre el lugar de tratamiento
Modelo abierto en infraestructura propia	mayor, técnico	alto	requisitos estrictos de datos y equipo capaz de asegurar el conjunto

Es una decisión empresarial, jurídica y tecnológica que debe tomarse antes de poner datos de producción en marcha. Cambiar proveedor o modelo después puede exigir nuevas pruebas de calidad, integración y seguridad. Desglosamos los criterios en qué es un LLM y cómo elegir un modelo.

3. ¿Se usarán los datos para entrenar el modelo?

No hay una respuesta única para «la IA». Hay que comprobar condiciones de la interfaz, plan y ajustes concretos: finalidad de uso, retención, acceso del personal del proveedor, ubicación y posibilidad de desactivar el almacenamiento. Estas cláusulas pueden variar entre un producto de consumo y uno empresarial del mismo proveedor.

Regla práctica: deja constancia en el contrato con el proveedor y en la documentación de implantación, no en un correo. Si quien implementa no puede señalar dónde está regulado, no está resuelto.

4. ¿Quién puede acceder a qué?

Un riesgo de gran impacto en RAG y asistentes internos es un acceso demasiado amplio: el sistema recupera material que quien pregunta no debería ver. Entonces el modelo puede revelar términos de un contrato u otro fragmento fuera de las autorizaciones de la persona usuaria.

Los permisos deben funcionar en la capa de búsqueda, no en la respuesta. Es decir, el sistema ni siquiera recupera fragmentos a los que quien pregunta no tiene acceso; no los recupera para «omitarlos amablemente». Filtrar después es una ilusión de seguridad porque el modelo ya tuvo esos datos en el contexto.

De ello se sigue algo menos obvio: un sistema de IA no puede otorgar un acceso más amplio que sus fuentes y, a veces, debe restringirlo aún más. Si nadie en la empresa sabe quién tiene derecho a cada carpeta, hay que resolverlo antes de abrir el asistente a usuarios.

5. ¿Qué queda en los registros?

Los registros son necesarios: sin ellos no diagnosticarás una respuesta errónea ni detectarás abuso. Pero son también una copia de los datos en otro lugar. Al inicio decidimos explícitamente:

• qué registrar: contenido completo de consultas y respuestas o solo metadatos e identificadores de fuentes;
• cuánto tiempo guardar los registros;
• quién puede acceder a ellos;
• si se rigen por las mismas normas de retención que los datos fuente.

Un registro guardado sin fecha límite es una obligación, no un recurso.

6. RGPD en la práctica: qué hay que resolver

Sin una clase de derecho, cerramos esta lista práctica en nuestros proyectos:

• Finalidad y base jurídica para cada tipo de dato y uso.
• Roles de las partes. El responsable determina fines y medios esenciales; el encargado actúa en su nombre. No se deben deducir roles solo del nombre de un contrato. Ayudan las directrices EDPB 07/2020.
• Documentación y evaluación de riesgos. Registro de actividades, evaluación de impacto o contrato de encargo se exigen según rol, escala y riesgo del proceso concreto, no de forma automática en cada proyecto.
• Transferencias fuera del EEE: si existen y bajo qué mecanismo jurídico.
• Derechos de la persona. Hay que poder localizar, rectificar o suprimir registros adecuados también en el índice, los logs y las copias, con los periodos de retención aplicables.
• Minimización y retención. El sistema recibe solo datos necesarios para la finalidad y no los guarda indefinidamente.

No somos un despacho y no fingimos serlo. Respondemos de que la arquitectura permita cumplir esos requisitos; la valoración jurídica corresponde a tu abogado o responsable de protección de datos.

7. ¿Qué ocurre cuando algo sale mal?

Hay tres situaciones para las que necesitas respuesta antes de implantar:

• El modelo respondió mal y alguien decidió basándose en ello. ¿Quién lo detectará y cómo? Para asuntos con riesgo dejamos el modo «el sistema sugiere, la persona aprueba».
• Alguien intentó extraer datos sin autorización. ¿Hay log? ¿Hay alerta?
• El proveedor tuvo una caída o cambió las condiciones. ¿Se puede cambiar de modelo sin reescribir el sistema? Esto devuelve a una arquitectura intercambiable.

8. ¿La persona usuaria sabe que habla con IA?

Desde el 2 de agosto de 2026 se aplica la parte principal del Reglamento europeo de IA. Su artículo 50 exige que un sistema destinado a interacción directa informe a la persona de que habla con IA, salvo que resulte evidente en las circunstancias. La información debe ser clara y darse como máximo en la primera interacción; el alcance completo de excepciones y responsabilidades figura en el Reglamento (UE) 2024/1689.

En la práctica: nombra al automatismo en la interfaz, ofrece una vía fácil hacia una persona y no diseñes la conversación para que se confunda al sistema con un empleado. Otros deberes pueden derivarse del sector y el tipo de uso, por lo que un abogado o responsable de protección de datos debe aprobar la evaluación antes de publicar la solución.

Lo que la tecnología no puede resolver

• No se puede sellar completamente un modelo con un prompt. «No reveles información confidencial» es una instrucción, no una protección. La protección es que el modelo no recibió esa información.
• No se puede garantizar que el modelo jamás se equivoque. Se pueden limitar frecuencia y consecuencias con grounding, pruebas, control de permisos y puertas de aprobación.
• No se puede decidir la responsabilidad con una frase en los términos. Los roles de responsable y encargado derivan de la influencia real sobre fines y medios; deben establecerse para el flujo concreto.

Preguntas frecuentes

¿Es más seguro alojar el modelo internamente?

Respecto al control de datos, sí. Respecto a la seguridad real, no necesariamente: hay que mantener servidores, actualizaciones e infraestructura, trabajo que debes hacer por tu cuenta. Un modelo propio desplaza el riesgo; no lo hace desaparecer.

¿Un asistente público puede extraer nuestros datos internos?

Sí, si el recorrido público obtiene acceso a una fuente interna o el filtro de permisos es defectuoso. Por eso los asistentes público e interno deben tener fuentes, identidades técnicas, permisos y pruebas de intentos de extracción separados.

¿Quién debe participar por nuestra parte?

Hace falta una persona que conozca el proceso y, según datos y riesgo, una responsable de protección de datos, seguridad o cumplimiento. Dirigimos el trabajo técnico, mientras quien posee el proceso en la empresa cliente aprueba finalidad y alcance del uso de datos considerando recomendaciones jurídicas y técnicas. Los roles y responsabilidades formales se establecen según la influencia real, no solo el nombre del contrato.

---

La seguridad se resuelve antes de la primera línea de código, durante diseño y planificación, no después de implantar. Si tienes requisitos de cumplimiento y no sabes cómo conciliarlos con IA, escríbenos o consulta integraciones LLM.