La mayoría de las conversaciones sobre protección de datos en el gobierno de IA empiezan en el sitio equivocado. Preguntan qué certificaciones tiene un proveedor, qué subencargados lista, en qué región está su nube. Son preguntas legítimas. Pero para la categoría concreta de herramientas que vigilan tus agentes de IA — descubriendo cada agente, sesión, modelo y servidor MCP de tu infraestructura y mapeando lo que cada uno puede alcanzar — debajo se esconde una pregunta más fundamental: ¿la propia herramienta de gobierno llega a recibir tus datos?
Si la respuesta es sí, acabas de crear un nuevo encargado del tratamiento, una nueva copia de material sensible, un nuevo sitio que puede ser comprometido, requerido judicialmente o hecho llamar a casa. Si la respuesta es no — de forma estructural, por diseño — entonces casi todas las preguntas de RGPD que vienen después se vuelven mucho más pequeñas. Este es el argumento para self-hostear una plataforma de IA, y conviene hacerlo con precisión, sin exagerar.
La garantía de privacidad que importa es estructural, no un certificado
Un informe SOC 2 o un certificado ISO 27001 te dice que un proveedor tiene procesos sobre los datos que guarda. Es útil, pero es una afirmación sobre el gobierno del acceso a tus datos. Una garantía mucho más fuerte es no guardar el dato en primer lugar. No puedes filtrar, gestionar mal ni verte obligado a divulgar lo que nunca recibiste.
Self-hostear entrega exactamente eso. Cuando el control plane se ejecuta dentro de tus propios hosts, clústeres o nubes — incluido totalmente air-gapped, sin egress — el material sensible que observa nunca cruza tu perímetro. El proveedor no es subencargado de tus datos operativos porque el proveedor nunca los ve. Eso es un hecho arquitectónico, no una promesa de política que tengas que auditar.
Para ser claros sobre dónde está este producto: Olivares AI es pre-release. No está certificado bajo SOC 2, ISO/IEC 27001, el Reglamento de IA de la UE ni ningún otro marco, y no hay auditoría en curso. El producto está diseñado hacia los objetivos de control que esos marcos examinan — registro de auditoría, control de acceso, integridad, cifrado, gestión de cambios — para estar listo para auditarse cuando llegue el momento. El argumento de residencia que viene a continuación no depende de ninguna certificación, que es justamente el punto.
Aristas, no payloads
La decisión de diseño central es qué se almacena. Una herramienta de gobierno de IA tiene que entender quién puede tocar qué. No necesita el contenido de las consultas, los cuerpos de los prompts, los secretos ni los datos personales que fluyen por esos accesos.
Así que el grafo almacena aristas, no payloads: la relación de acceso entre un agente y un recurso, y si ese acceso es lectura (R) o lectura/escritura (RW). data-export-job → prod-postgres (RW) es una arista. Las filas que ese trabajo leyó no se almacenan. El mapa registra que un agente alcanzó un objeto en s3://billing-exports; no copia el export.
| Almacenado (el mapa de acceso) | No almacenado |
|---|---|
| Identidad del agente (rol / nombre de aplicación) | Valores de credenciales, tokens, claves |
Recurso alcanzado (prod-postgres) | Cuerpos de consulta, filas de resultado |
| Tipo de acceso — R o RW | Payloads de prompt y respuesta |
| Marca de tiempo, resultado, nivel de confianza | Secretos, PII en tránsito |
Las entradas que puedan llevar secretos o datos personales se redactan y se escanean en busca de secretos antes de escribir nada, de modo que la redacción ocurre en el borde de la recogida y no como una limpieza posterior. Lo que no almacenas, no lo puedes filtrar — y lo que no puedes filtrar no amplía tu huella de tratamiento bajo RGPD.
Cómo el dato se queda dentro del perímetro
Tres propiedades mantienen esto honesto en operación:
Observación read-first. El colector observa a través de señales que ya produces — logs de aplicación y de auditoría, OpenTelemetry, y eBPF como respaldo de verdad a nivel de kernel. No es un proxy en la ruta de datos del agente, así que ve la forma del acceso, no su contenido, y si falla nunca rompe producción. No hay un man-in-the-middle obligatorio copiando tu tráfico.
Sin telemetría a casa. Seguro por defecto significa sin phone-home. La telemetría del proveedor está apagada salvo que la actives explícitamente. Nada sobre tu parque — ni los nombres de los agentes, ni el mapa de acceso, ni contadores de uso — se envía de vuelta al proveedor por defecto.
Air-gapped con cero egress. En redes desconectadas, reguladas o clasificadas, el control plane se ejecuta enteramente en local, con la licencia validada offline. No hay camino de salida, punto. Para un requisito de residencia que diga que los datos de la UE deben permanecer en infraestructura de la UE bajo tu control, un despliegue self-hosted air-gapped es la respuesta más literal posible: el dato no se mueve porque no hay adónde moverlo.
La retención y el purgado son configurables, así que controlas cuánto persiste incluso el mapa de acceso.
Mapeo al Artículo 28 del RGPD — con honestidad
El Artículo 28 del RGPD regula la relación responsable–encargado y lo que debe cubrir un Acuerdo de Tratamiento de Datos. La observación relevante es que, en un despliegue self-hosted, la habitual relación proveedor-como-encargado para tus datos operativos prácticamente se disuelve: como la herramienta se ejecuta en tu infraestructura y nunca recibe esos datos, en la mayoría de los despliegues sigues siendo responsable y encargado de tus propios datos dentro de tu propio entorno.
Eso no deja un DPA sin sentido. Una relación comercial sigue beneficiándose de formalizar responsabilidades — para la cadena de suministro de software, para el acceso de soporte, para cualquier componente gestionado futuro. Hay un Acuerdo de Tratamiento de Datos bajo el Artículo 28 disponible bajo petición para compras enterprise. Lo que cambia es el alcance: no hay una lista de sitios a los que se han enviado tus datos personales, porque nunca se enviaron. Esa es una conversación mucho más corta y mucho más defendible con un DPO o un equipo de compras que “confía en nuestra lista de subencargados”.
Es un argumento estructural, así que trata los límites con la misma honestidad. Self-hostear traslada la responsabilidad de residencia y tratamiento a ti; no la elimina. Sigues asegurando el host, controlando la retención y gobernando quién puede leer el mapa de acceso — y ese mapa es en sí mismo sensible, por lo que cada vista privilegiada de él se audita y los componentes se autentican entre sí con TLS mutuo. El producto reduce la superficie del proveedor a casi cero; no exime al operador.
Conclusión
Si un regulador, un DPO o tu propio equipo de seguridad pregunta “¿adónde van nuestros datos cuando adoptamos esta herramienta de gobierno de IA?”, la respuesta más fuerte posible es “a ninguna parte — nunca salen, y la herramienta nunca los ve”. Esa respuesta viene de la arquitectura: ejecución self-hosted, almacenamiento de aristas-no-payloads, redacción antes de escribir, sin telemetría a casa, y operación air-gapped con cero egress. Un certificado puede corroborar un buen proceso; no puede igualar la garantía de un dato que nunca se recibió.
Si quieres la versión completa y honesta de esta postura — incluida la posición de cumplimiento aún-no-certificada y cómo encaja un DPA del Art. 28 del RGPD — mira /es/security. Y si prefieres leer el código que respalda la afirmación, el producto completo es self-hosteable bajo AGPL-3.0 en la página /es/open-source.