Confidentialité et Guardian

Dans CoeOS, la confidentialité est une architecture, pas une promesse. Il n’y a qu’une porte de sortie, la box ; chaque requête porte une classe ; le confidentiel ne peut aller que vers des modèles que vous avez marqués sûrs ; et ce qui n’est pas classé est traité comme confidentiel (fail-closed).

Le Guardian est la couche de gouvernance qui applique ces règles et en garde la trace. 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.

1. La classe d’une conversation

Chaque tour porte une classe, confidential ou open, transmise du client à la box par l’en-tête x-coeos-class. Une requête sans classe est traitée comme confidentielle.

Dans l’application, la classe se choisit par conversation avec le bouton Confidentiel, activé par défaut. Passer une conversation en ouvert n’est possible que si l’instance l’autorise.
Le verrou : une conversation qui a envoyé un tour confidentiel, même en échec, ne repasse jamais en ouvert. Son historique partirait sinon vers l’ouvert. C’est l’application qui garde la règle, au changement de classe comme à chaque tour : la box ne voit qu’une requête à la fois.

2. Où part le confidentiel

Chaque fournisseur est déclaré dans la box avec sa sûreté : sûr ou non, et son type, local (vos machines) ou ZDR/DPA (fournisseur cloud sous accord de traitement et sans conservation des données).
La table Local : le routage du confidentiel, axe par axe, est une table à part, composée dans la box à partir des seuls modèles sûrs. C’est l’administrateur qui la gère. Si elle est désactivée, le confidentiel part vers un seul modèle sûr.
Le décideur qui classe une requête confidentielle sur un axe est lui-même un modèle sûr.
Pas de secours. Si la cible confidentielle ne répond pas, le tour échoue. Il ne bascule jamais vers un modèle ouvert.

Classe de destination	Signification
`local`	reste sur vos machines
`cloud_dpa`	fournisseur cloud sous DPA (et ZDR)
`cloud_no_dpa`	cloud générique sans DPA : données ouvertes uniquement
`refuse`	aucune sortie autorisée : erreur, jamais de repli silencieux

3. Où part l’ouvert

Une conversation ouverte suit le routage général : un setting publié par TMB (le banc de The Monocle Bear), tiré par la box et activé par l’administrateur. Si un modèle ouvert échoue, la box relance l’étape sur un autre fournisseur ou un autre modèle (la cascade de secours). Cette cascade n’existe qu’en ouvert.

Le choix entre ces options dépend du niveau : Open, Hybride ou Local.

4. Le verdict de la box

La box est l’unique passerelle de sortie. Le client ne stocke aucune URL ni clé de fournisseur. À chaque réponse, la box renvoie son verdict dans l’en-tête x-coeos-decision : classe demandée, classe servie, fournisseur, modèle, axe, recours au décideur, profil. Le client l’audite avant d’afficher la réponse. Le verdict de la box fait autorité : le client ne re-décide pas.

Isolation réseau : l’application, la recherche documentaire et l’extraction de documents 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. Une base documentaire = 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. Et une base d’entreprise dont le traitement passe par un cloud sans DPA n’est jamais servie à un tour confidentiel. 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 niveau, les trois classes avec leur endpoint / région / référence DPA / test de santé, et la destination du confidentiel. 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. Le Guardian aujourd’hui, et en V2

Aujourd’hui : le Guardian gouverne les sorties (classes, sûreté des fournisseurs, verdict de la box, journal, labels des bases). La classe d’une conversation est choisie par l’utilisateur avec le bouton Confidentiel.
L’interrupteur de l’opérateur : le Guardian s’active ou se désactive au niveau de l’instance. Désactivé, toute requête est traitée comme ouverte, par exemple sur une instance de démonstration sans cible confidentielle.
En V2 : la détection. Le Guardian repérera dans une conversation ouverte les données personnelles, les dossiers clients et les secrets d’affaires, et proposera de basculer en confidentiel. La détection et la décision restent séparées.

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

Les règles sont couvertes par des suites de tests (étiquetage, propagation, recherche documentaire, sorties, topologie, audit) et par des canaris : l’un prouve qu’aucun corps confidentiel n’atteint un endpoint cloud simulé, un autre qu’un tour ouvert ne voit jamais la mémoire confidentielle. La gouvernance est testée, pas seulement affirmée.

Pourquoi — en trois lignes

Secret professionnel : le confidentiel ne va que vers des modèles sûrs ; l’inconnu est confidentiel par défaut ; une conversation confidentielle le reste ; 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.