IA conforme al RGPD que tu delegado de protección de datos puede revisar

Cumplir el RGPD tiene una mitad jurídica que no es nuestra, la base de legitimación, la información al interesado y el ejercicio de derechos. La ingeniería puede aportar tres respuestas respaldadas por pruebas, no solo por declaraciones del proveedor. Sin ellas, la mitad jurídica se defiende mal.

El reglamento no menciona la inteligencia artificial por su nombre en ningún sitio. Regula datos personales. Un asistente que lee facturas, reserva citas o responde preguntas sobre tu operación está lleno de datos personales desde el primer día. Así que se le aplican los principios de siempre. Cada principio tiene que traducirse en una decisión concreta de ingeniería.

La minimización se convierte en una decisión sobre qué datos recibe cada petición. Un modelo de lenguaje solo puede filtrar lo que le dieron, así que el control real es qué entra en la petición.

La limitación de finalidad, que corresponde a tu empresa y no al agente, puede apoyarse en controles técnicos verificables. Un agente que solo puede llamar a tres funciones aprobadas no tiene camino técnico para desviarse de su finalidad, así que la arquitectura no garantiza la limitación pero sí permite demostrarla.

Y la responsabilidad proactiva exige que el sistema deje registros que permitan comprobar qué ocurrió. Si el sistema no puede enseñar por qué hizo lo que hizo, ningún documento de política lo va a enseñar tampoco.

Por eso la documentación de cumplimiento debe describir controles que ya existen en el sistema. Un sistema bien construido permite documentar mejor el contrato de encargo, la evaluación de impacto y el registro de actividades de tratamiento, porque cada afirmación de esos documentos señala algo que existe de verdad en el código.

¿Y al revés, primero los papeles y luego el sistema? Ningún documento puede sustituir a los controles y registros que hacen auditable al sistema.

Una empresa que despliega IA en Europa responde hoy ante dos reglamentos a la vez. El RGPD gobierna qué puede pasarle a un dato personal, lo trate quien lo trate. En España lo acompaña la ley orgánica de protección de datos, la 3/2018, con la AEPD como autoridad de control.

El reglamento europeo de IA ordena los sistemas por el riesgo de su uso, desde las prácticas prohibidas hasta el riesgo mínimo. Pone deberes concretos a las empresas que usan los de más riesgo, entre ellos supervisión, vigilancia y registros. Su calendario cambió en julio de 2026.

El Ómnibus Digital, el Reglamento (UE) 2026/1744, aplazó las obligaciones de alto riesgo de los sistemas del anexo III al 2 de diciembre de 2027 y las de la IA integrada en productos del anexo I al 2 de agosto de 2028.

Lo que sí se aplica ya es lo demás, las prácticas prohibidas y la alfabetización en IA desde febrero de 2025, las reglas de los modelos de propósito general desde agosto de 2025 y la transparencia del artículo 50 desde el 2 de agosto de 2026. Las multas del tramo más alto llegan a 35 millones de euros o al 7 % de la facturación.

Explicamos el Reglamento Europeo de IA por separado, con sus funciones y obligaciones concretas. Una pieza sí pertenece aquí, porque va de datos y no de sistemas. En diciembre de 2024 el Comité Europeo de Protección de Datos publicó su Dictamen 28/2024, su primer dictamen formal sobre los modelos en sí. Tres conclusiones son especialmente relevantes al elegir un proveedor.

Que un modelo entrenado sea anónimo se valora caso por caso. El interés legítimo solo puede sostener un tratamiento con IA tras una evaluación documentada en tres pasos. Y la tercera es la que más te toca. Un modelo desarrollado con un tratamiento ilícito puede contaminar el despliegue, así que quien lo despliega tiene que valorarlo. Ninguna de las tres es un sello automático.

Las tres hacen especialmente importante que el proveedor pueda demostrar cómo ha cumplido esas obligaciones. Por eso, sobre todo por la tercera, el proveedor del modelo debe evaluarse y aprobarse de forma expresa, en lugar de asumir que sus condiciones son adecuadas.

La infraestructura corre en una cuenta en la nube que es tuya, no nuestra. El repositorio está a tu nombre desde el primer día. No alojamos tu asistente en nuestra infraestructura para después darte acceso a él. Lo hacemos así para que tu empresa controle directamente la infraestructura y pueda responder con claridad a las preguntas sobre acceso y ubicación de los datos.

No mantenemos una base de datos propia con una copia de tus registros ni tienes que migrarlos de nuestra infraestructura si dejamos de trabajar juntos. El sistema se queda donde siempre estuvo, con su documentación y su historia.

Y hay algo que casi ningún proveedor dice de sí mismo. Nosotros también somos encargados del tratamiento. Operamos el sistema, así que accedemos a datos personales, lo que significa que hace falta un contrato de encargo con nosotros igual que con cualquier otro proveedor de la cadena.

Desde esa infraestructura hay dos flujos de datos que deben estar identificados. El primero es la llamada al proveedor del modelo, la empresa que ejecuta el modelo de lenguaje. Tú apruebas qué proveedor, bajo qué contrato y con qué configuración. Apruebas qué puede viajar dentro de esas llamadas. El segundo aparece cuando el asistente utiliza un canal de mensajería.

Si la conversación entra por WhatsApp o por Telegram, ese canal recibe el contenido íntegro y es un tercero más de la cadena, con su propio contrato y su propia valoración de transferencias. Un asistente web o interno no tiene esa segunda salida. Los proveedores de modelos firman contratos de encargo del tratamiento, que obligan a un proveedor a tratar datos solo según tus instrucciones.

Los principales proveedores ofrecen opciones de procesamiento en regiones europeas. Si una configuración concreta satisface las reglas de transferencias internacionales es una valoración de tus abogados. Nuestro trabajo es entregarles el detalle completo de qué datos salen, a qué proveedor y bajo qué configuración, para que puedan hacer esa valoración.

El control de la infraestructura es la base sobre la que construimos el aislamiento, los registros y las medidas específicas para datos de salud.

La minimización deja de ser abstracta en cuanto miras dentro de una llamada. Una petición a un modelo de lenguaje lleva tres cosas: las instrucciones que le dicen cuál es su trabajo, el contexto que puede usar para esta respuesta y la pregunta que acaba de hacer la persona. Esos son los datos que pueden llegar al modelo.

El modelo nunca se conecta a tu base de datos, nunca navega por tus sistemas y nunca recibe lo que el código no metió en el sobre.

El código construye esa petición, así que la cuestión de ingeniería es qué datos decide incluir. Ese criterio debe poder explicarse y comprobarse. Un agente bien construido manda las pocas filas o párrafos a los que esa persona tiene derecho, ya filtrados, en vez de volcar tablas enteras y confiar en que el modelo cite la parte correcta.

Enviar solo los datos necesarios reduce el riesgo. Enviar menos datos también reduce el coste y puede mejorar la calidad de la respuesta.

Cuando tu DPD pregunte qué puede ver el proveedor, el sobre es la respuesta, documentado caso de uso por caso de uso. En nuestros despliegues, el volumen de datos que sale del sistema es reducido y queda documentado por caso de uso. El asistente que responde preguntas de producción no exporta tu base de datos de producción.

El asistente manda la pregunta de una persona y la porción de contexto a la que esa persona tiene derecho. Después escribe la respuesta en los mismos registros que todo lo demás.

Es una pregunta habitual, pero por sí sola no permite determinar si el uso cumple el RGPD, porque «ChatGPT» nombra varios productos distintos con condiciones de datos distintas. Una pestaña gratuita del navegador, una suscripción de empresa y un contrato de API, que es la interfaz de máquina a máquina que llama un sistema como los nuestros, son tres situaciones distintas a ojos de la ley.

Las condiciones sobre entrenamiento, conservación y procesamiento europeo cambian entre ellas. Y cambian con el tiempo, así que cualquier respuesta cerrada que diéramos hoy estaría caducada dentro de un mes.

La pregunta útil es qué producto se utiliza, qué datos recibe y bajo qué contrato. Un empleado pegando el correo de un cliente en una herramienta gratuita es una situación.

Un sistema que utiliza una API bajo un contrato de encargo, con procesamiento europeo, sin uso de los datos para entrenamiento y enviando solo el contexto necesario, es una situación distinta, aunque el modelo de debajo se llame igual. Tus abogados valoran el contrato. Nosotros construimos la segunda situación y les entregamos la prueba de que es lo que corre de verdad.

Por eso prohibir las herramientas de IA sin ofrecer una alternativa controlada puede reducir el control de la empresa.

Prohibir una herramienta no elimina necesariamente su uso; puede desplazarlo a cuentas y dispositivos que la empresa no controla. Un asistente autorizado con la arquitectura correcta da a la gente la capacidad dentro de un perímetro que alguien gobierna de verdad.

La soberanía del dato puede significar cosas distintas, así que conviene concretar qué control ofrece realmente cada arquitectura. Para nosotros, significa que la ubicación de tus datos, las claves que los abren y el sistema de identidad que dice quién es quién responden ante ti. La jurisdicción es otra cosa y esto no la resuelve. Una cuenta propia dentro de una nube estadounidense sigue teniendo detrás a una empresa estadounidense, con las leyes de su país.

Por eso tener los datos en una determinada ubicación no significa por sí solo tener el control sobre ellos. Un sistema puede almacenar los datos en Frankfurt y seguir dejando las claves, las cuentas de administración y los registros bajo el control de un proveedor.

¿Entonces quién controla realmente los datos? No es una pregunta que se pueda responder solo con la ubicación del servidor. Hay un abanico y contarlo entero vale más que un eslogan.

En un extremo está el software compartido, donde tus datos viven dentro del producto de otro bajo sus condiciones. Después viene correr en una región europea de una nube grande, luego una cuenta propia dentro de esa nube y por último tus propios servidores en tu propio edificio. Cada opción ofrece un nivel distinto de control y de complejidad operativa.

Por defecto construimos en una cuenta propia de tu empresa dentro de una nube, porque ofrece control sobre los datos, las claves y la identidad sin obligar a tu equipo a gestionar servidores físicos.

Hay una distinción importante que conviene dejar clara. La aplicación que construimos corre entera dentro de infraestructura tuya. El modelo de lenguaje normalmente no, porque lo llamamos como servicio al proveedor que tú apruebes. Ejecutar un modelo abierto sobre tu propio hardware eliminaría también esa dependencia del proveedor externo de modelos. Es otro proyecto, con otros costes y otro equilibrio de calidad.

Si necesitas que hasta el modelo corra en tus instalaciones, dilo en la primera conversación, porque cambia la arquitectura desde el principio.

Las preguntas sobre gobiernos extranjeros alcanzando tus datos, incluidas las leyes estadounidenses, van en esa misma primera conversación. Son terreno jurídico y tu asesoría tendrá su criterio. Lo que nosotros controlamos es la ingeniería que determina cuánto hay de lo que preocuparse, que es de lo que van las dos secciones siguientes.

Una versión temprana de uno de nuestros asistentes mantenía separadas a las empresas diciéndole al modelo, en sus instrucciones, que no se saltara nunca el filtro. Funcionaba en todas las pruebas que hicimos.

Aunque funcionara en las pruebas, seguía teniendo un problema: una instrucción a un modelo de lenguaje es una petición. Un modelo puede dejar de atender una petición por motivos que nadie predice desde fuera.

Lo explicamos como la diferencia entre una garantía técnica y una instrucción que el modelo puede incumplir. Cambió nuestra manera de construir. La seguridad tiene que aguantar incluso cuando el modelo falla.

El sistema donde mejor se ve es el de Savian, un agente que trabaja con datos de varias empresas y contesta a cada responsable solo sobre lo que le corresponde. Corre en la cuenta de Savian, que es quien lo encarga. Ahí la separación se impone en cuatro sitios. Ninguna de esas capas depende del modelo.

Todos nuestros sistemas siguen el mismo reparto de responsabilidades. El código decide qué puede ejecutarse, el modelo interpreta el lenguaje y los datos contienen el conocimiento.

El modelo interpreta la pregunta y devuelve un formulario estructurado con campos definidos por nosotros. El código valida ese formulario, comprueba los permisos de la persona y decide qué acción puede ejecutarse.

Las consultas que tocan tus datos las construye el código a partir del formulario validado, con los valores pasados como parámetros y los nombres de columna sacados de una lista cerrada, nunca ensamblados con texto que escribió el modelo.

Donde los registros importan más damos un paso adicional. En uno de nuestros asistentes el modelo ni siquiera devuelve el texto que acaba delante del usuario. Devuelve una clave, un identificador. El código busca el texto aprobado al que esa clave apunta. Lo que la persona lee es con seguridad lo que se aprobó, palabra por palabra, sin importar lo que el modelo generase alrededor.

La identidad sigue la misma regla. Cuando un asistente consulta un sistema interno en nombre de alguien, lleva la credencial de esa persona, la misma que tus sistemas ya usan para saber quién pregunta. Cada llamada posterior corre con los permisos del humano, no con los permisos amplios de una cuenta de robot. Si la persona no puede abrir un registro a mano, el asistente no puede abrírselo.

Buena parte de las preguntas de acceso del RGPD se simplifican ahí, porque el modelo de acceso del asistente pasa a ser el que tu empresa ya auditó. Esto vale cuando el asistente actúa por un usuario identificado.

Cuando alguien escribe a un número de WhatsApp sin identificarse, como pasa en un asistente de citas, la identidad se resuelve de otra manera y lo que limita el acceso es lo poco que el sistema puede alcanzar.

Wazzy, nuestro propio producto de citas, funciona en clínicas dentales, de fisioterapia y de estética. Una nota de cita que dice quién visita qué clínica y por qué es un dato de salud, que el RGPD mete en las categorías especiales de su artículo 9, sin jerarquía entre ellas y con los datos penales del artículo 10 todavía más restringidos.

Quien trata esos datos es la clínica, que es la responsable. Se apoya en el artículo 9.2.h, el que cubre la prestación de asistencia sanitaria. Nosotros tratamos por cuenta suya, como encargados.

No elegimos la categoría más difícil para presumir. El producto la necesitaba. El resultado es que nuestras prácticas quedaron moldeadas por el caso más estricto desde el principio.

Cada campo sensible va cifrado por su cuenta, con AES-256-GCM, en vez de confiar en que el disco esté cifrado por debajo. La diferencia importa en la práctica.

El cifrado de disco te protege si alguien se lleva el hardware, mientras que el cifrado por campo protege el dato de quien toca la base de datos sin pasar por la aplicación, que es el caso de una copia robada o de quien la administra.

La aplicación tiene la clave, así que quien la opera sí ve el dato. Por eso los permisos y los registros importan tanto como el cifrado.

Y el borrado está diseñado alrededor de lo que la ley exige, no alrededor de lo que parezca razonable. Wazzy retiene lo que la ley obliga a retener, ni más ni menos. Ese plazo no lo fijamos nosotros.

Lo fija la clínica, que es la responsable del tratamiento, con la ley de autonomía del paciente delante, la 41/2002, que marca un mínimo de cinco años para la historia clínica y más en algunas comunidades. Una cita en un chat no es la historia clínica, que vive en el sistema de la clínica, pero la lógica es la misma.

Una petición de supresión tiene que respetar al paciente sin incumplir en silencio una obligación legal de conservación, así que el sistema separa lo que se borra ahora de lo que se retiene por obligación y puede enseñar cuál es cuál.

Todo eso lo construimos porque no había alternativa. Es la razón de que esta página pueda hablar desde la experiencia y no desde una lista de comprobación. Y es el nivel que hereda el resto de nuestro trabajo con clientes.

Las conversaciones sobre cumplimiento tienden a fijarse en las bases de datos y a olvidar a la persona que está escribiendo. Ahí se cruzan dos deberes. El RGPD espera claridad sobre cómo se usan los datos personales. El reglamento europeo de IA, en su obligación de transparencia, que es de las que sí mantuvieron su fecha, exige que a la gente se le diga cuándo está hablando con una máquina.

Ninguno de los dos es difícil de montar, pero los dos son fáciles de incumplir por omisión, un mensaje de bienvenida vago cada vez.

Nuestros sistemas conversacionales se presentan como lo que son. El camino a una persona forma parte del diseño en vez de ser una disculpa. En Wazzy, un caso urgente no recibe un párrafo tranquilizador de un modelo. Se escala al personal de la clínica, porque una máquina que reconoce su límite y entrega es más segura que una que improvisa seguridad.

La misma forma se repite en el trabajo con clientes. El asistente hace el volumen repetitivo. Los momentos que necesitan a un humano llegan a un humano, con el rastro de la conversación puesto.

Hay un beneficio más callado. Cuando el traspaso está diseñado, los humanos detrás del asistente dejan de ser una ficción de la política de privacidad y pasan a ser una bandeja de casos real, con personas concretas que la atienden, que es exactamente la clase de afirmación que una autoridad puede verificar y encontrar cierta.

Se registra la decisión, no solo el resultado. Cada paso con significado queda escrito, qué entendió el asistente, qué pidió, qué rechazó el validador y por qué. El registro es de solo añadir, es decir que se pueden sumar entradas pero nunca editarlas ni borrarlas. El sistema no lo lee de vuelta durante la ejecución, así que no puede influir en una respuesta ni siquiera en principio.

Existe para una cosa, para que alguien con una pregunta lo revise después. Ese alguien puede ser tu DPD, un auditor o la AEPD. Lo que reciben es el registro de lo que pasó, no una reconstrucción de memoria.

Que nadie lo edite no significa que sea eterno. Contiene datos personales, así que tiene su plazo de conservación y una petición de supresión puede alcanzarlo, lo que se resuelve poniéndole fecha de caducidad y separando el dato de la persona, en vez de con la tecla de borrar.

Hasta la caducidad está diseñada para verse. Las credenciales temporales que demuestran quién está preguntando caducan en torno a la hora. Repetir una petición vieja con una credencial caducada produce un error claro y visible en vez de tomar prestadas credenciales más frescas en silencio.

Preferimos que un sistema falle de forma ruidosa y visible a que acierte de una manera que nadie puede explicar. Un error nuevo y visible es mejor postura que un silencio cómodo.

Comprar IA en Europa implica hoy una revisión predecible. El departamento legal y el DPD van a querer una evaluación de impacto relativa a la protección de datos, el estudio estructurado de qué puede salir mal para las personas cuyos datos se tratan. Van a querer un contrato de encargo con cada proveedor de la cadena. Esa revisión no la hacemos nosotros, es suya.

¿Qué ponemos nosotros, entonces? Lo que hacemos es acortar esa revisión, porque los materiales que necesita son cosas que nuestros sistemas producen de todas formas.

Un cumplimiento que era cierto el día del estreno y no se volvió a medir es un cuento. Estos sistemas cambian por debajo. Los proveedores actualizan modelos sin cambiarles el nombre, tu documentación crece y tus datos se mueven con el tiempo. Por eso hacemos dos cosas distintas.

Antes de publicar cualquier cambio, una batería de pruebas, un banco de casos anotados y anonimizados que el sistema debe responder bien, frena la publicación si la calidad baja. Y cada semana, sobre el sistema vivo, lanzamos una tanda de conversaciones de prueba anonimizadas de principio a fin y comprobamos qué pasó de verdad en cada una.

Es la misma disciplina que caza a un modelo empeorando en silencio, aplicada a las promesas de esta página. El aislamiento, los registros y las negativas se prueban como funcionalidades, porque eso es lo que son.

Cuando tu DPD pregunte en marzo si las garantías de la revisión de septiembre siguen en pie, la respuesta que vale es un resultado de pruebas, no un encogimiento de hombros.

La introducción prometía que saldrías de aquí sabiendo qué preguntar. Estas son las preguntas que haríamos nosotros si estuviéramos en tu lado de la mesa, en el orden que más destapa.

Esta página no es un producto aparte y no se puede comprar suelta. Es cómo están construidas las cuatro cosas que hacemos. Cada una se encuentra con la pregunta desde un ángulo distinto.