Le Guardian et la conformité

Le Guardian est la couche de gouvernance qui garantit qu’aucune donnée ne sort du périmètre autorisé. C’est le socle de confiance de CoeOS pour un professionnel soumis au secret : il classe chaque objet, décide où il a le droit d’aller, l’inscrit dans un journal opposable, et refuse plutôt que de laisser passer un doute.

Principe fondateur : on classe des objets, jamais du texte. Le Guardian ne lit pas le contenu des documents — il raisonne sur des étiquettes et des règles déterministes. Et par défaut, ce qui n’est pas classé est confidentiel (fail-closed).

1. Ce que fait le Guardian

C’est un point de sortie unique : tout ce qui quitte le réseau de l’application (appel à un modèle, embeddings, mail, outil, recherche documentaire, compilation mémoire) doit passer par la décision du Guardian. Il n’y a pas d’autre porte.

Deux notions :

La teinte d’un objet : confidential ou open.
La classe de destination autorisée : local, cloud_dpa, cloud_no_dpa, ou refuse.

Classe	Signification
`local`	reste sur la machine, ne sort jamais
`cloud_dpa`	fournisseur cloud sous accord de traitement (DPA)
`cloud_no_dpa`	cloud générique sans DPA — données ouvertes uniquement
`refuse`	aucune sortie autorisée → erreur, jamais de repli silencieux

2. Le profil d’installation (figé)

Chaque déploiement porte un profil, fixé à l’installation et jamais modifiable par un utilisateur :

local (cabinet on-prem) : le confidentiel reste local. Il ne part jamais en DPA. Si l’endpoint local est éteint → erreur, pas de contournement.
vps (cloud dédié, ex. OVH) : le confidentiel part en cloud_dpa (fournisseur sous DPA), jamais en cloud générique.

3. Comment une sortie est décidée

Pour chaque tentative de sortie, le Guardian applique une suite de contrôles déterministes, dans l’ordre, et ne lève jamais d’exception (il renvoie un verdict) :

Pas d’étiquette ou pas de règle identifiée → refus (fail-closed).
Endpoint hors ligne → refus (endpoint_offline, pas de repli).
Confidentiel vers une destination non-locale sans référence DPA → refus.
Confidentiel + profil local + destination non-locale → refus (politique stricte : jamais de DPA en profil local).
Sinon : destination locale → local ; DPA présent → cloud_dpa ; donnée ouverte → cloud_no_dpa ; confidentiel sans DPA vers le cloud → refus.

Pas de repli. Un refus est un refus : si la classe décidée n’a pas d’endpoint disponible, on remonte une erreur (503), on ne bascule jamais en douce vers une autre destination.

4. Le signal « confidentiel » et le routage (D33/D34)

Chaque tour de conversation porte un en-tête de classe (x-coeos-class) envoyé du client à la box. Par défaut, tout est traité comme confidentiel (fail-closed) tant que le bouton dynamique par-objet n’est pas activé.
Le décideur vit dans la box CoeOS : la box est l’unique passerelle d’egress. Le client ne stocke aucune URL ni clé de fournisseur — juste l’adresse de la box. La box renvoie son verdict (x-coeos-decision : classe demandée, classe servie, fournisseur, modèle, axe, profil, empreinte des règles), que le client audite avant d’afficher la réponse. Le verdict de la box fait autorité — le client ne re-décide pas.
Isolation réseau (G-5) : au démarrage, le Guardian vérifie la topologie — l’app, le RAG et l’extraction documentaire n’ont aucune route vers internet ; seule la box en a une. Un contrôle de build interdit tout appel réseau hors du point de sortie unique.

5. Le journal d’audit (opposable)

Chaque tentative de sortie est inscrite, avant l’envoi, dans un journal append-only (guardian_decisions). Chaque ligne enregistre : horodatage, type (chat, embeddings, mail, outil, retrieval, refus…), teinte, classe d’egress, destination, règle appliquée, source de l’étiquette, profil, empreinte des règles, raison d’un refus, et le verdict de la box. Aucun secret (clé API, clé DPA) n’y figure jamais.

Deux invariants sont vérifiés en continu et exportables :

jamais une ligne confidential vers cloud_no_dpa ;
jamais une ligne non-confidentielle sans règle identifiée.

Surface : Paramètres → Audit Guardian (admin/DPO) — bandeau d’invariants (vert/rouge), filtres, et export CSV/JSON complet pour le DPO (« le DPO veut l’historique complet »). C’est la trace opposable au sens de l’art. 30 RGPD.

6. D25 — une collection = un seul label

Le Guardian empêche de mélanger du confidentiel et de l’ouvert dans la recherche documentaire :

une conversation open ne peut recevoir que des passages open ; une conversation confidential peut recevoir les deux (l’étiquette ne redescend jamais toute seule) ;
ingérer un document open dans une collection confidential (ou l’inverse) est refusé au bootstrap ;
un passage d’étiquette inconnue est traité comme confidentiel (fail-closed).

Chaque base RAG porte donc un seul label (open/confidential), affiché dans les paramètres et sur le projet. C’est ce qui rend la connaissance partagée compatible avec le secret.

7. Les surfaces de conformité (Paramètres → Conformité)

Où vont mes données — lit l’état de la box et montre, en clair : le profil, les trois classes avec leur endpoint / région / référence DPA / test de santé, et la destination du confidentiel (non éditable, découle du profil). Transparence RGPD ; aucun secret affiché.
Fiche du système (AI Act) — la classification AI Act du système, le mode moteur, le catalogue des modèles (id, axe, label, région, DPA), les contacts (support + DPO). Base légale : AI Act art. 4 (AI literacy). Le système est auto-classé « risque limité », avec la clause d’exclusion : « outil d’aide à la décision, il ne rend pas de décision produisant des effets juridiques ; la décision finale appartient à l’avocat ».
Audit Guardian — le journal ci-dessus (§5).
Doctrine — les « Golden Rules » du cabinet (§8).

À cela s’ajoute la bannière AI Act (art. 50) : l’utilisateur est informé qu’il interagit avec une IA ; son acquittement est journalisé (avec l’empreinte du texte) comme preuve légale.

8. La doctrine — les « Golden Rules »

La doctrine = un jeu de règles explicites (GR-001, GR-002…) que le workflow de revue injecte dans son analyse. Deux niveaux : cabinet (global) et projet (surcharge, le projet l’emporte). Chaque règle : titre, corps, langue, sévérité par défaut.

Points clés :

Fail-closed : les règles sont livrées désactivées — l’admin les active consciemment.
Ré-évaluée à chaque revue, jamais mise en cache : désactiver une règle la retire de la revue suivante immédiatement.
Aucune règle active = revue refusée (une revue sans doctrine serait vide).

Surface : Paramètres → Doctrine (admin/organiser) — activer/désactiver, éditer, créer, supprimer. C’est l’actif du cabinet : son savoir devient un outil versionné et auditable.

9. Rétention (RGPD)

Purge automatique, quotidienne, journalisée :

données techniques d’inférence : 30 jours ;
journaux d’authentification : 90 jours.

Non purgé automatiquement : la facturation/metering (conservée 10 ans, conformité comptable belge). Chaque purge écrit une trace d’audit (art. 30 RGPD).

10. Une gouvernance vérifiée, pas déclarée

Le Guardian n’est pas une promesse : c’est 100 cas de test répartis en 6 familles (étiquetage 25, propagation 20, retrieval 15, egress 20, topologie 10, audit 10) qui vérifient exactement chaque règle, plus des rapports « canari » prouvant qu’aucun corps confidentiel n’atteint un endpoint cloud simulé. La gouvernance est testée, pas seulement affirmée.

Pourquoi — en trois lignes

Secret professionnel : le confidentiel ne quitte jamais le périmètre autorisé ; l’inconnu est confidentiel par défaut ; un refus n’a pas de repli.
RGPD : journal d’audit opposable (art. 30), transparence « où vont mes données », suivi des DPA, rétention bornée.
EU AI Act : bannière (art. 50), fiche système (art. 4), classification « risque limité » avec la décision finale qui reste à l’avocat.

L’IA propose, l’avocat dispose — et le Guardian prouve que rien n’est sorti du cadre.