¿Adónde van nuestros datos? IA, RGPD y AI Act para directivos

La mayoría de los proyectos de IA que vemos no se atascan en el modelo. Se atascan en una sala de reuniones, cuando el delegado de protección de datos (DPD) pregunta adónde van los datos de los clientes y nadie en la sala sabe responder.

La respuesta corta: adonde usted decida. Alojados en Europa, en su nube o en sus propios servidores. El trabajo de verdad consiste en decidirlo el primer día, no cuando el prototipo ya funciona.

Este artículo recoge las preguntas que resolvemos antes de escribir una sola línea de código. No es asesoramiento jurídico: su abogado o su DPD tienen la última palabra sobre su caso.

Empiece por los datos, no por el modelo

Antes de elegir un modelo, anote lo que el sistema va a leer. Correos de clientes, contratos, historiales médicos, nóminas, tickets de soporte: cada uno pesa distinto ante el RGPD.

Después, siga un registro a través del sistema. Dónde se guarda, dónde se procesa, quién puede leerlo y cuánto tiempo permanece allí. Si alguna respuesta es «en algún sitio del proveedor», ya tiene su primera tarea.

En la práctica, tres preguntas cubren casi todo:

• ¿Contiene datos personales? Un nombre dentro de un PDF cuenta. También un identificador de cliente que remite a una persona.
• ¿Tienen que salir de sus sistemas? A menudo solo sale un fragmento. Un asistente de soporte puede necesitar la pregunta y el artículo de ayuda pertinente, no todo el historial del cliente.
• ¿Se pueden eliminar o enmascarar antes de que salgan? Seudonimizar nombres e identificadores antes de llamar a un modelo cuesta poco al principio y mucho si se añade después.

Una primera versión que envía menos datos suele aprobarse antes. Solo eso puede ahorrar semanas de idas y venidas con el departamento jurídico.

RGPD y proveedores de modelos: lea las condiciones, no la portada

Cuando usted llama a un modelo a través de una API, el proveedor pasa a ser encargado del tratamiento de todo lo que le envía. Según el RGPD, eso exige un contrato de encargo del tratamiento, y usted debe saber lo que dice.

• Entrenamiento. La mayoría de los grandes proveedores declaran que, por defecto, los datos enviados por sus API para empresas no sirven para entrenar sus modelos. Las aplicaciones para particulares siguen a menudo otras reglas. Compruebe qué oferta usan realmente sus equipos.
• Conservación. Algunos proveedores guardan las peticiones y las respuestas durante un tiempo limitado para detectar abusos. Otros ofrecen conservación reducida o nula si se solicita. Conozca el número de días, por escrito.
• Ubicación. Dónde se procesan las peticiones y dónde se guardan los registros. Varios proveedores ya ofrecen procesamiento en la UE, a veces solo en ciertos planes o regiones.
• Subencargados. La lista, publicada por el proveedor, de quién más accede a los datos. Cambia; alguien de su lado debería recibir los avisos.
• Todo lo que rodea al modelo. Las peticiones acaban a menudo en herramientas de registro y monitorización, y los documentos acaban en un índice de búsqueda en forma de embeddings. Cada uno es otro encargado, con su propia ubicación y su propio plazo de conservación. Y cuando alguien pide que se borren sus datos, también tienen que salir del índice.

Si el proveedor es una empresa estadounidense, la transferencia de datos necesita una base jurídica: el Marco de Privacidad de Datos UE-EE. UU. o cláusulas contractuales tipo. Alojar en una región de la UE ayuda, pero algunos DPD miran también a qué jurisdicción está sujeto el propio proveedor, porque algunas leyes estadounidenses pueden alcanzar datos que empresas estadounidenses guardan en el extranjero. El peso de esta cuestión para sus datos es algo que debe valorar su asesor jurídico.

Alojar la IA en Europa, en su nube o en sus servidores

Construimos las tres opciones. La adecuada depende menos del modelo que de sus datos y de quién mantendrá el sistema tras el lanzamiento.

Un modelo gestionado, alojado en Europa. Usted llama a un modelo comercial a través de una región de la UE. Es lo más rápido de poner en producción, con la mejor calidad de modelo y el menor coste inicial. La contrapartida: depende de las condiciones y los precios del proveedor.

Su propia nube. El modelo se ejecuta en su cuenta de AWS, Azure o Google Cloud, ya sea con la oferta gestionada del proveedor o con un modelo de pesos abiertos que usted despliega. Los datos se quedan dentro del perímetro que su equipo de seguridad ya audita. Requiere más configuración y alguien que lo mantenga.

En sus servidores. Un modelo de pesos abiertos en sus propias máquinas. Nada sale del edificio, algo que algunos sectores exigen. Usted paga el hardware, y los modelos más potentes no siempre están disponibles así.

La elección rara vez es todo o nada. Un esquema habitual: los documentos sensibles los procesa un modelo en su propia nube y el resto va a un modelo gestionado en Europa.

Lo que cambia el Reglamento de IA, según el nivel de riesgo

El Reglamento de IA o AI Act (Reglamento (UE) 2024/1689) no regula la IA en general. Regula usos, clasificados por riesgo. La mayoría de los proyectos de empresa caen en los niveles bajos, y saber en cuál está usted determina la carga de trabajo.

• Riesgo inaceptable: prohibido. Puntuación social, sistemas manipuladores, reconocimiento de emociones en el trabajo, entre otros. Estas prohibiciones se aplican desde febrero de 2025.
• Alto riesgo: obligaciones exigentes. Sistemas usados en contratación, evaluación de empleados, calificación crediticia, acceso a la educación o a servicios esenciales. Necesitan gestión de riesgos, documentación, registros, supervisión humana y controles de calidad de los datos. Estas obligaciones se aplican por etapas y su calendario está en debate a nivel europeo: compruebe las fechas vigentes con su asesor jurídico.
• Riesgo limitado: transparencia. Un chatbot debe indicar que la persona habla con una máquina. Las imágenes, audios o vídeos generados que puedan pasar por reales deben marcarse como tales. Conviene comprobar también sus fechas de aplicación.
• Riesgo mínimo: nada específico. Resumir documentos internos, clasificar tickets, redactar respuestas que revisa una persona. El RGPD sigue aplicándose; el Reglamento de IA añade poco.

Dos puntos sorprenden a las empresas. Primero, el Reglamento distingue al proveedor que construye un sistema del responsable del despliegue que lo usa, y una empresa que despliega una herramienta de terceros también tiene obligaciones. Segundo, el Reglamento espera que las personas que usan sistemas de IA en la empresa tengan un nivel suficiente de alfabetización en IA, y lo que eso exige en la práctica conviene comprobarlo con su asesor.

Un ejercicio útil antes de cualquier proyecto: escriba un párrafo sobre qué decide el sistema, sobre quién y quién lo comprueba. Si afecta a la contratación, al crédito o al acceso de alguien a un servicio, consulte a su abogado antes de firmar el alcance.

Inclúyalo en el alcance, no en una revisión posterior

El cumplimiento que se deja para el final es el más caro. Cambiar de modelo porque las condiciones del proveedor no pasan la revisión obliga a rehacer la integración. Un registro que falta obliga a reconstruir decisiones a posteriori.

Escriba las respuestas en el documento de alcance. Su DPD lee una página en lugar de perseguir respuestas a lo largo del proyecto.

La ficha de datos de una página que le pedirá su DPD

Respondidas pronto, estas preguntas también dan forma a la construcción: el enmascaramiento, los registros y la revisión humana cuestan menos si se diseñan desde el principio que si se añaden tras el lanzamiento. Redactamos un alcance al inicio y construimos dentro de sus reglas sobre datos, con una primera versión en 3 a 6 semanas.

Resuelva primero la cuestión de los datos

Si los datos son la primera pregunta que hará su equipo, traiga a la persona que la hará. Reserve una auditoría gratuita con su DPD o su CTO en la sala: una hora sobre su negocio y, después, un documento breve que dice qué merece la pena construir, con qué datos, y qué no.