Déployer un assistant IA dans un métier réglementé (santé, banque, assurance, juridique, public), c'est ajouter quatre contraintes structurelles aux contrôles sécurité classiques :
- Confidentialité : secret professionnel, données particulièrement sensibles.
- Traçabilité : qui a vu quoi, quand.
- Auditabilité : reconstituer une décision a posteriori.
- Explicabilité : justifier une réponse à un utilisateur ou un régulateur.
Voilà comment je les structure en mission, sans transformer le produit en usine à gaz.
Confidentialité — au-delà du chiffrement classique
Le minimum
- Chiffrement au repos et en transit (TLS 1.3, AES-256).
- Hébergement souverain ou conforme (HDS pour santé, secret professionnel pour juridique, etc.).
- DPA explicite avec le fournisseur LLM (voir DPA fournisseur LLM 7 clauses).
- Pas d'envoi à un LLM provider dont la politique d'usage n'autorise pas votre cas (data retention, training).
Les ajouts pour le métier réglementé
- Filtrage des PII et données sensibles à l'entrée du LLM : un assistant médical doit savoir détecter les informations qu'il a le droit de traiter et celles qu'il doit refuser ou anonymiser.
- Cloisonnement utilisateur strict côté RAG (voir RAG sécurité et isolation tenant).
- Pas d'entraînement / fine-tuning sur des données utilisateur sans base légale documentée et anonymisation.
- Effacement opérable et testé (droit à l'oubli RGPD + obligations métier).
Traçabilité — au-delà du log technique
Le minimum
- Log structuré de chaque requête : timestamp, utilisateur, prompt, modèle, réponse, durée, coût.
- Stockage immuable.
- Rétention conforme à la politique métier (souvent 5-10 ans en santé/finance).
Les ajouts pour le métier réglementé
- Identification utilisateur forte : pas de "utilisateur anonyme". Auth qui supporte une justification a posteriori.
- Traçabilité des sources RAG : pour chaque réponse, quels documents ont été retournés au LLM. Stockés et associés à la session.
- Traçabilité du contexte : version system prompt, version modèle, températures utilisées au moment de la réponse.
- Pas de PII en clair dans les logs (paradoxe à régler : logger pour auditer sans violer la confidentialité). Solution : pseudonymisation côté logs, table de correspondance accessible uniquement aux fonctions habilitées.
Voir logging agent IA SOC 2 / ISO 27001 / AI Act.
Auditabilité — reconstituer une décision
Le minimum
- Capacité à retrouver, à partir d'un identifiant de session, l'intégralité du contexte et de la réponse.
- Retention auditable.
- Procédure de réponse à demande d'audit documentée.
Les ajouts pour le métier réglementé
- Reconstitution complète d'une décision : prompt, contexte RAG, version modèle, paramètres, output, validation humaine éventuelle.
- Capacité de replay : pouvoir rejouer la même configuration et vérifier si on obtient la même réponse (utile pour expertise).
- Préservation du contexte sur plusieurs années si réglementaire (santé, banque).
- Accès auditable à l'historique : qui a consulté l'historique d'un utilisateur, quand.
Explicabilité — justifier la réponse
C'est la contrainte la plus délicate côté LLM, parce que les LLMs sont opaques par nature.
Approches qui marchent
- Citation des sources : pour chaque réponse RAG, retourner explicitement les passages utilisés et leur source. L'utilisateur ou l'auditeur peut vérifier.
- Décomposition de raisonnement : utiliser des prompts qui forcent le LLM à expliciter son raisonnement avant de répondre. Pas une explication "vraie" mais traçable.
- Distinction certitudes / hypothèses : politique prompt qui demande au modèle d'indiquer son niveau de confiance et ce qu'il ne sait pas.
- Disclaimer clair : l'utilisateur (médecin, juriste, banquier) reste le décideur final, l'assistant fournit un input à valider.
Approches qui ne marchent pas
- Croire que les "explications" générées par le LLM sont fidèles. Elles sont plausibles, pas démontrées.
- Utiliser des outils d'interprétabilité (LIME, SHAP) sur des LLMs — pertinent sur du ML classique, peu sur du gen-AI.
Le pattern utile
Pour chaque réponse :
- Le texte de réponse.
- Les sources utilisées (avec liens).
- Les disclaimers (limites du modèle, périmètre, recommandation de validation).
- L'identifiant de session pour audit ultérieur.
La gouvernance qui va avec
- Comité de validation des cas d'usage : qui valide qu'un nouveau cas d'usage IA peut être déployé dans le périmètre métier réglementé.
- DPIA systématique sur les cas d'usage qui touchent des données personnelles (voir DPIA agent IA méthodologie).
- Formation utilisateurs : les professionnels qui utilisent l'assistant doivent connaître ses limites et leur responsabilité.
- Audit interne périodique : revue trimestrielle des cas d'usage actifs et de leur conformité.
Les pièges classiques
Déployer le PoC vite, ajouter la conformité plus tard
Coût énorme de refonte. La traçabilité et l'explicabilité sont des choix d'architecture, pas des features greffables.
Confondre explicabilité et plausibilité
Une "explication" générée par le LLM peut être totalement fausse tout en étant cohérente. Documenter clairement que c'est une explication plausible, pas une justification formelle.
Sous-estimer le coût de stockage
10 ans de logs avec prompts + contextes + outputs sur un assistant utilisé par 5000 professionnels : ce n'est pas négligeable. À provisionner dès la conception.
Pas de plan de continuité si LLM provider tombe
Un assistant santé en panne 4h pendant des consultations = problème. Plan de continuité (cf. PCA SaaS dépendance LLM provider DORA).
Mon avis en 1 ligne
Confidentialité, traçabilité, auditabilité, explicabilité sont quatre exigences à embarquer dans l'architecture dès le départ. Greffées en fin de projet, elles coûtent 3 à 5 fois plus cher. Compter 4-8 semaines supplémentaires sur un projet d'assistant IA pour atteindre un niveau défendable métier réglementé. Et planifier la revue annuelle indépendante.