IA y proteccion de datos: arquitectura de una plataforma

La mayoria de discusiones sobre IA y proteccion de datos se quedan en la herramienta: si este chatbot guarda o no lo que le escribes. Esa es la pregunta pequena. La pregunta grande es donde vive el dato cuando una empresa entera funciona sobre agentes, y quien decidio que viviera ahi.

El cumplimiento se decide en la arquitectura, no en el prompt

Un agente de IA no es una aplicacion que consulta una base de datos. Es un sistema que lee, razona, escribe y actua sobre varios sistemas a la vez. Cada uno de esos verbos toca datos personales en algun momento.

Cuando montas eso encima de una herramienta cerrada, heredas sus decisiones: donde se procesa, cuanto se retiene, que se usa para entrenar, que queda registrado. No las eliges tu. Y son exactamente las decisiones que el RGPD te va a pedir que justifiques.

Por eso construimos Potenciado como plataforma y no como una coleccion de integraciones. La proteccion de datos no es una capa que se anade al final. Es una propiedad del diseno o no existe.

Las cuatro capas donde se juega todo

En un sistema agentico hay cuatro puntos donde el dato personal puede escaparse de control. Si los cuatro estan definidos, tienes una plataforma. Si falta uno, tienes un experimento en produccion.

• →Ingesta: que entra al sistema y con que base legal. Aqui es donde se aplica la minimizacion del articulo 5. Si el agente no necesita el DNI para hacer su trabajo, el DNI no entra.
• →Memoria: que persiste entre conversaciones. Un agente con memoria a largo plazo es un fichero de datos personales aunque nadie lo haya declarado como tal.
• →Orquestacion: que herramientas puede invocar el agente y con que permisos. Un agente con acceso al CRM completo es un tratamiento de datos con alcance ilimitado.
• →Salida: que sale del perimetro y hacia donde. Incluye lo obvio (una llamada a un modelo externo) y lo menos obvio (un log enviado a un servicio de observabilidad de terceros).

Trazabilidad como requisito de producto

El articulo 30 del RGPD exige un registro de actividades de tratamiento. El articulo 22 da derecho a no ser objeto de decisiones automatizadas sin intervencion humana. Ninguna de las dos cosas se resuelve con documentacion escrita a posteriori.

Se resuelven haciendo que la plataforma registre, por diseno, que agente actuo, sobre que dato, con que instruccion y con que resultado. Ese log no es telemetria para depurar. Es la prueba de cumplimiento y es el mecanismo por el que un humano puede revisar o revertir una decision.

Es tambien lo que separa un sistema auditable de uno que solo funciona. La diferencia se nota el dia que alguien ejerce un derecho de acceso y hay que reconstruir que supo el sistema sobre esa persona.

Sobre como se traduce esto a controles concretos dentro de una plataforma agentica, lo desarrollamos en plataformas agenticas seguras.

Las decisiones estrategicas que nadie quiere tomar

Adoptar agentes de IA obliga a decidir cosas que antes se delegaban al departamento de sistemas. Tres en concreto.

La primera: residencia y proveedor del modelo. Cada modelo que llamas es un encargado de tratamiento bajo el articulo 28, con su contrato, sus subencargados y su ubicacion. Cambiar de modelo por rendimiento cambia tu cadena de cumplimiento. Esa decision es de direccion, no de un desarrollador.

La segunda: comprar o construir. Comprar es rapido y te ata a las politicas de retencion de otro. Construir sobre plataforma propia es mas lento al principio y te deja el control de la retencion, el borrado y el aislamiento por cliente. No hay respuesta universal, pero hay que responder de forma consciente.

La tercera: alcance. Un agente que redacta borradores y un agente que ejecuta acciones sobre clientes reales tienen perfiles de riesgo distintos. El segundo suele requerir una evaluacion de impacto previa. Escalar de uno a otro sin revisar el analisis es el error mas comun.

Cuando la empresa entera corre sobre agentes

El salto interesante no es tener un agente. Es tener una red de agentes que cubre marketing, atencion, operaciones y datos, todos sobre la misma base tecnica.

Ahi la proteccion de datos deja de ser un tramite por herramienta y pasa a ser gobierno de plataforma: un unico inventario de tratamientos, una unica politica de retencion, un unico punto donde se revoca un acceso. Es mas trabajo de diseno y mucho menos trabajo de mantenimiento.

El efecto secundario es que el mismo diseno que te hace cumplir te hace mejor. Un sistema que sabe que dato tiene, de donde viene y para que puede usarlo produce mejores respuestas que uno que lo mezcla todo. Cumplir y funcionar apuntan en la misma direccion mas veces de las que se admite.

Cada sector aterriza esto de forma distinta. En automocion, por ejemplo, la casuistica de leads y financiacion tiene sus propias reglas, y la tratamos en la guia RGPD para concesionarios. En visibilidad y contenido, el impacto se ve en otro sitio, y lo explicamos en que cambia en tu SEO y en tu GEO.

Este tema tambien se trata, desde otro enfoque, en All ITs AI · Agent Hub · GEOySEO.

La proteccion de datos en IA no se resuelve eligiendo bien la herramienta. Se resuelve decidiendo, con criterio, como se articula tu empresa sobre agentes: que entra, que persiste, que se registra y quien responde. Si estas en ese punto y quieres contrastar como quedaria esa arquitectura en tu caso, escribenos y lo revisamos contigo sin compromiso.