Conformité RGPD avec un LLM local: là où Powerbrain fait la différence

"Nous hébergeons le modèle nous-mêmes, donc nous sommes conformes au RGPD" - cette phrase revient un premier rendez-vous sur deux. Elle est à peu près aussi exacte que "nous avons un serveur, donc nous avons des sauvegardes". L'inférence locale est une condition nécessaire, mais loin d'être suffisante.

Ce que le RGPD et l'EU AI Act exigent réellement

La réalité réglementaire en 2026 impose quatre exigences à tout usage productif de l'IA avec des données personnelles:

Limitation des finalités et contexte de rôle. Tout collaborateur n'a pas le droit de voir tout enregistrement simplement parce qu'il pourrait atterrir dans le contexte du modèle.
Droit à l'effacement. Les références personnelles doivent pouvoir être supprimées a posteriori - y compris dans les embeddings et les index vectoriels.
Traçabilité. Qui a transmis quel enregistrement à quel modèle, et quand?
Supervision humaine. Il faut un coupe-circuit qui fonctionne, pas un "on redémarre le conteneur".

Une installation brute d'Ollama avec un vector store branché ne couvre rien de tout cela.

Là où un context engine comme Powerbrain intervient

Powerbrain est une couche open source entre les données et l'agent. Elle fournit du contexte via le Model Context Protocol (MCP) - chaque requête passe par un policy engine. Quatre briques comptent côté conformité:

Policy engine (OPA). Les niveaux de classification (public, internal, confidential, restricted) sont évalués par rôle d'agent. La conformité vit comme règle exécutable dans le dépôt, pas comme PDF dans la qualité.
Sealed vault. Les données personnelles sont détectées à l'ingestion (Microsoft Presidio), pseudonymisées avec des sels par projet et stockées dans un coffre à deux couches. Effacer au sens de l'Art. 17, c'est: retirer le mapping du coffre, les pseudonymes deviennent irréversibles.
Audit hash chain. Chaque accès est inscrit dans un journal append-only haché en continu. Les manipulations remontent à la vérification.
Circuit breaker et file d'approbation. Un seul appel HTTP arrête tous les outils de données. Les requêtes confidential émises par des rôles non admin entrent dans une file de revue au lieu d'être validées par défaut.

Ce qui change au quotidien

Trois choses bougent nettement par rapport à un stack RAG fait maison:

La préparation d'un audit prend des heures, pas des semaines. Le générateur "Annex IV" extrait modèles, policies, état de l'audit et registre des risques en direct du système.
Les discussions sur la protection des données deviennent concrètes. Au lieu de "l'IA peut-elle voir cela?", on a des règles Rego que l'on relit, commente et versionne.
Changer de modèle coûte moins de courage. En isolant les policies, on remplace embeddings, reranker ou LLM sans recertifier la couche de contrôle.

Quand l'effort est rentable

Toute recherche interne dans un référentiel n'a pas besoin de cette profondeur. Le seuil tombe typiquement dans trois cas: secteurs régulés (juridique, santé, RH), niveaux de confidentialité mixtes dans le même index, ou plus d'un agent qui accède au même corpus. À partir de là, investir dans un context engine dédié coûte moins cher qu'un audit sur trois mené avec des tableurs maintenus à la main.

Si vous démarrez aujourd'hui avec du RAG local, la question initiale "où tourne le modèle?" mérite une compagne: "qui décide de ce qu'il a le droit de voir - et qui peut le prouver ensuite?".

Ce que le RGPD et l'EU AI Act exigent réellement

La réalité réglementaire en 2026 impose quatre exigences à tout usage productif de l'IA avec des données personnelles:

Limitation des finalités et contexte de rôle. Tout collaborateur n'a pas le droit de voir tout enregistrement simplement parce qu'il pourrait atterrir dans le contexte du modèle.

Droit à l'effacement. Les références personnelles doivent pouvoir être supprimées a posteriori - y compris dans les embeddings et les index vectoriels.

Traçabilité. Qui a transmis quel enregistrement à quel modèle, et quand?

Supervision humaine. Il faut un coupe-circuit qui fonctionne, pas un "on redémarre le conteneur".

Une installation brute d'Ollama avec un vector store branché ne couvre rien de tout cela.

Là où un context engine comme Powerbrain intervient

Policy engine (OPA). Les niveaux de classification (public, internal, confidential, restricted) sont évalués par rôle d'agent. La conformité vit comme règle exécutable dans le dépôt, pas comme PDF dans la qualité.

Sealed vault. Les données personnelles sont détectées à l'ingestion (Microsoft Presidio), pseudonymisées avec des sels par projet et stockées dans un coffre à deux couches. Effacer au sens de l'Art. 17, c'est: retirer le mapping du coffre, les pseudonymes deviennent irréversibles.

Audit hash chain. Chaque accès est inscrit dans un journal append-only haché en continu. Les manipulations remontent à la vérification.

Circuit breaker et file d'approbation. Un seul appel HTTP arrête tous les outils de données. Les requêtes confidential émises par des rôles non admin entrent dans une file de revue au lieu d'être validées par défaut.

Ce qui change au quotidien

Trois choses bougent nettement par rapport à un stack RAG fait maison:

La préparation d'un audit prend des heures, pas des semaines. Le générateur "Annex IV" extrait modèles, policies, état de l'audit et registre des risques en direct du système.

Les discussions sur la protection des données deviennent concrètes. Au lieu de "l'IA peut-elle voir cela?", on a des règles Rego que l'on relit, commente et versionne.

Changer de modèle coûte moins de courage. En isolant les policies, on remplace embeddings, reranker ou LLM sans recertifier la couche de contrôle.

Quand l'effort est rentable

Si vous démarrez aujourd'hui avec du RAG local, la question initiale "où tourne le modèle?" mérite une compagne: "qui décide de ce qu'il a le droit de voir - et qui peut le prouver ensuite?".