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

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. Lo que la ingeniería puede aportar son tres respuestas con pruebas en vez de con garantías verbales. 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 uno aterriza en una decisión concreta de ingeniería.

La minimización deja de ser una línea de una política y pasa a ser una pregunta sobre el contexto. 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 es un deber tuyo y no del agente, pasa a ser algo verificable. 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 pasa a ser una pregunta sobre registros. 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 decimos que el papeleo sigue a la arquitectura y no al revés. Un sistema bien construido hace que el contrato de encargo, la evaluación de impacto y el registro de actividades de tratamiento se escriban antes y se defiendan mejor, 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? Ninguna documentación vuelve auditable un sistema que no lo es.

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.

El mapa completo de ese segundo reglamento lo tenemos en su propia página, función por función y deber por deber, porque merece el espacio. 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 importan a un comprador.

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 premian al proveedor que puede enseñar los deberes hechos. La tercera es exactamente por qué el proveedor de modelo se aprueba en vez de heredarse.

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 de nuestro lado para darte luego un usuario. Es poco habitual en el sector y es a propósito, porque quita de golpe toda una familia de preguntas que tu DPD tendría que ir persiguiendo.

No hay una base de datos nuestra con una copia de tus registros ni una negociación de salida si dejamos de trabajar juntos. El sistema se queda donde siempre estuvo, con su documentación y su historia.

Y hay algo más que conviene decir, porque casi ningún proveedor lo 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.

De la cuenta salen dos caminos y los dos hay que tenerlos dibujados. 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 vive en 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 serios ofrecen regiones de procesamiento europeas. Si una configuración concreta satisface las reglas de transferencias internacionales es una valoración de tus abogados. Lo nuestro es entregarles el dibujo completo de qué va a dónde, para que esa valoración lleve días en vez de meses.

El aislamiento, los registros y el trato de los datos de salud parten de ahí, porque una cuenta que controlas es el único sitio desde el que se puede garantizar el resto.

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. Esa es toda la superficie.

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.

Entonces, ¿quién llena el sobre? Lo llena el código, así que la pregunta de ingeniería que importa es qué mete dentro. La respuesta debería ser una que puedas enseñar a cualquiera. 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.

Mandar menos es más seguro. Además sale más barato y acierta más, porque un modelo razona mejor sobre una página relevante que sobre cincuenta de ruido.

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 ese documento es corto. Más de un revisor se ha sorprendido de lo poco que sale de verdad. 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 la pregunta que todo comité hace primero y casi siempre es la pregunta equivocada, 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 en cuál de las tres entran tus datos y bajo qué contrato. Un empleado pegando el correo de un cliente en una herramienta gratuita es una situación.

Un sistema llamando a una API bajo un contrato de encargo firmado, en región europea, con el entrenamiento excluido y con solo un contexto filtrado dentro del sobre (lo que hacemos en Ideasforge), es una situación completamente 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 también una empresa que prohíbe las herramientas de IA a secas acaba muchas veces con menos control, no con más. La demanda no desaparece, se muda a cuentas personales y a teléfonos donde no aplica ningún contrato, ningún registro y ningún filtro.

Prohibir no quita el uso, lo saca de tu vista. 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 se usa como palabra de marketing, así que conviene concretarla. 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 la palabra soberanía se usa con más alegría de la que aguanta. La ubicación sola no te lleva ahí. Un sistema cuyos datos están en Frankfurt pero cuyas claves de acceso, cuentas de administración y registros pertenecen a un proveedor es soberano en el folleto y en ningún otro sitio.

¿Entonces es soberano o no lo es? No es una pregunta de sí o no. 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 escalón compra control y cuesta comodidad.

Nosotros construimos por defecto en el tercero, tu propia cuenta en la nube, porque da el control que importa, la propiedad del dato y el control de las claves y de la identidad, sin pedirle a tu equipo que administre máquinas físicas.

Y ahora el párrafo que casi todos los proveedores se saltan. 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 cerraría ese último hueco. 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 los cimientos.

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.

¿Y si funcionaba, qué había que arreglar? Seguía estando mal, porque 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.

A los clientes se lo hemos contado como la diferencia entre una garantía y una petición educada. 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 responde a los responsables de varias empresas del mismo grupo, cada uno sobre las suyas. Corre en la cuenta de Savian, que es quien lo encarga. Ahí la separación se impone en cuatro sitios. El modelo no es ninguno de ellos.

Las capas de seguridad están bien, pero cambiar el diseño para que el fallo no pueda existir está mejor. Uno de nuestros sistemas enseña la diferencia. Su aislamiento funcionaba originalmente por filtrado, con cada consulta llevando una condición que decía de qué empresa se permitían las filas.

Después rehicimos el almacén de datos para que cada empresa viva en su propio esquema, su compartimento sellado dentro de la base de datos. La vista combinada las une con con la empresa marcada en cada fila. Las consultas del asistente corren contra el esquema de quien pregunta, nunca contra la vista combinada, que existe para otros usos.

Tras ese cambio, sumar dos empresas en una misma cifra dejó de ser un fallo que un filtro debe atrapar y pasó a ser una consulta que el asistente no puede formular.

El efecto práctico se vio enseguida. Una comparación poco estricta de nombres que había sido una preocupación real de seguridad bajo el diseño por filtrado simplemente dejó de importar, porque ni siquiera una coincidencia equivocada podía cruzar la frontera de un esquema.

Arreglar la arquitectura mató la clase entera de fallos, no un caso suelto. Es el nivel al que apuntamos siempre que los datos lo permiten.

Es una pregunta útil para cualquier proveedor. Qué fallos son imposibles en tu diseño, en vez de cuáles se atrapan.

Nuestros sistemas comparten una regla de diseño. El juicio vive en el código, la interpretación del lenguaje vive en el modelo y el conocimiento vive en los datos.

El modelo lee la pregunta de una persona y entrega un formulario estructurado, un contrato en formato fijo cuyos campos definimos de antemano. El código valida ese formulario, comprueba los permisos de quien pregunta y decide qué ocurre de verdad.

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 al amparo del artículo 9.2.h, el que cubre la prestación de asistencia sanitaria, es la clínica, que es la responsable. 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 honrar 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 una vez por semana, sobre el sistema vivo, reproducimos una conversación de prueba anonimizada de principio a fin y comprobamos qué pasó de verdad.

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.