La confiance est la ressource la plus rare dans les industries reglementees. Elle prend des annees a construire et des secondes a detruire. Avocats, banquiers, responsables conformite et professionnels de la sante ont passe leur carriere a developper leur jugement, a maintenir la confidentialite et a proteger les interets de leurs clients. Leur demander de faire confiance a un systeme IA, c’est demander quelque chose de significatif.
La plupart des entreprises IA abordent ce probleme par le marketing. “Securite de niveau entreprise.” “Certifie SOC 2.” “Utilise par les cabinets leaders.” Ce sont des mots sur un site web. Ce n’est pas de la confiance.
La confiance dans l’IA reglementee se construit par l’architecture. Par des decisions prises au niveau de l’infrastructure qui rendent la confiance verifiable plutot que proclamee. Cet article explique les decisions specifiques que nous avons prises chez Mont Virtua et pourquoi.
Principe 1 : chaque resultat doit avoir une source
C’est le principe fondateur. Sans exception.
Quand Enclava dit “L’article 271 CO exige que la resiliation du bail soit notifiee au moyen du formulaire approuve par le canton”, l’utilisateur voit un lien direct vers l’article 271 CO dans Fedlex, la version en vigueur, l’historique des modifications et la mise en oeuvre cantonale pertinente. Il peut verifier la declaration en trente secondes.
Quand le systeme dit “Le Tribunal federal a traite cette question dans l’ATF 142 III 91”, l’utilisateur peut cliquer pour acceder a la decision reelle, lire le passage pertinent et confirmer la citation.
Ce n’est pas une fonctionnalite que nous avons ajoutee apres avoir construit le systeme. C’est l’architecture. Enclava utilise la generation augmentee par la recherche, ce qui signifie que chaque reponse est generee a partir de documents specifiques recuperes. La citation n’est pas une reflexion apres coup. C’est le mecanisme par lequel la reponse a ete produite.
Pourquoi c’est important : dans le travail reglemente, une affirmation non citee n’a aucune valeur. Un avocat ne peut pas dire a un client “l’IA le dit”. Un responsable conformite ne peut pas rapporter a la FINMA “notre systeme a indique”. Chaque assertion professionnelle doit remonter a une source faisant autorite. Notre systeme est concu pour que cette tracabilite soit toujours disponible.
Ce que nous evitons deliberement : generer des reponses a partir des connaissances parametriques du modele. Si l’information n’est pas dans notre base de donnees verifiee, le systeme dit qu’il n’a pas d’information pertinente plutot que de generer une reponse plausible a partir des donnees d’entrainement. Nous preferons une lacune dans la couverture a une reponse fabriquee.
Principe 2 : les donnees doivent provenir de sources faisant autorite
Notre base de donnees juridiques est construite exclusivement a partir de sources gouvernementales officielles :
- Legislation federale de Fedlex (fedlex.data.admin.ch)
- Legislation cantonale des bases de donnees cantonales officielles
- Decisions du Tribunal federal depuis le portail du TF
- Decisions du Tribunal administratif federal depuis le portail du TAF
- Circulaires et directives FINMA depuis les publications officielles de la FINMA
- Entrees FOSC depuis la Feuille officielle suisse du commerce
- Donnees parlementaires Curia Vista depuis l’Assemblee federale
Nous ne faisons pas de scraping de blogs juridiques. Nous n’ingerons pas de commentaires juridiques (sauf sous licence explicite). Nous n’utilisons pas d’informations juridiques participatives. Nous ne comptons pas sur les donnees d’entrainement du modele pour le contenu juridique.
Chaque source de donnees dispose d’une chaine de provenance documentee : d’ou viennent les donnees, comment elles sont ingerees, comment elles sont analysees et comment elles sont verifiees par rapport a la source. Cette documentation est disponible pour les clients lors de la due diligence.
Pourquoi c’est important : la qualite des resultats d’un systeme IA est limitee par la qualite de ses donnees d’entree. Un systeme entraine sur du contenu juridique scrape sur internet contiendra des erreurs, des dispositions obsoletes et des interpretations non officielles. Un systeme construit sur des sources gouvernementales officielles a la meme autorite que les sources elles-memes.
L’etape de verification : apres l’ingestion et l’analyse, nous effectuons des comparaisons de hash par rapport a la source pour confirmer qu’aucun contenu n’a ete altere pendant le traitement. Nous suivons les numeros de version et les dates d’entree en vigueur pour garantir que les utilisateurs voient toujours la version en vigueur d’une disposition. Lorsqu’une disposition est modifiee, le systeme reflete le changement et maintient l’acces a la version precedente avec la datation appropriee.
Principe 3 : infrastructure suisse, controle suisse
Enclava fonctionne sur une infrastructure suisse. Pas un “centre de donnees suisse exploite par une entreprise americaine”. Une infrastructure suisse exploitee par une entreprise suisse.
Les details :
- Entite juridique : Mont Virtua GmbH, constituee a Zug, Suisse. Pas de societe mere americaine, de filiale ou d’actionnaire de controle.
- Infrastructure de calcul : Cloud GPU suisse (Exoscale, avec des centres de donnees a Geneve et Zurich). Aucune dependance a AWS, Azure ou GCP.
- Modeles IA : Modeles open source (Llama, Mistral, Qwen) deployes sur une infrastructure suisse. Aucun appel API vers des fournisseurs de modeles americains. Aucune donnee ne quitte la Suisse pour l’inference.
- Base de donnees : PostgreSQL avec pgvector, heberge en Suisse. Toutes les donnees clients, les journaux de requetes et les donnees systeme resident sur des serveurs suisses.
Cette configuration fournit une veritable souverainete des donnees. Aucune exposition au US CLOUD Act. Aucun acces par un gouvernement etranger. Aucun transfert de donnees hors de Suisse.
Nous publions notre architecture d’infrastructure parce que la transparence construit la confiance plus efficacement que les assertions. Les clients et leurs equipes conformite peuvent verifier notre configuration d’hebergement, notre structure d’entreprise et notre deploiement de modeles de maniere independante.
Principe 4 : modeles open source, pas de boites noires
Nous utilisons exclusivement des modeles IA open source. C’est un choix delibere avec plusieurs implications.
Auditabilite. Quand un regulateur, un client ou un auditeur demande “comment votre IA prend-elle ses decisions ?”, nous pouvons montrer l’architecture du modele, les poids du modele et le pipeline d’inference. Avec les modeles proprietaires (GPT-4, Claude, Gemini), la reponse est “nous ne savons pas, et le fournisseur non plus”. Pour les applications IA a haut risque au titre du AI Act europeen, cette difference fait la difference entre conformite et non-conformite.
Pas de dependance fournisseur. Si un modele open source particulier est abandonne, nous passons a un autre. Notre valeur reside dans la couche de donnees, l’infrastructure de recherche et la plateforme de livraison, pas dans un modele specifique. Cela nous protege, nous et nos clients, du risque lie aux fournisseurs de modeles.
Pas de partage de donnees avec les fournisseurs de modeles. Quand vous utilisez un modele proprietaire via une API, vos requetes vont aux serveurs du fournisseur de modeles. Meme avec des accords entreprise interdisant l’entrainement sur vos donnees, le fournisseur traite vos requetes sur son infrastructure. Avec des modeles open source deployes localement, aucune donnee ne quitte notre infrastructure. Le modele fonctionne sur nos serveurs, traite les requetes sur nos serveurs et renvoie les resultats depuis nos serveurs.
Previsibilite des couts. Les API de modeles proprietaires facturent par token. A mesure que l’utilisation augmente, les couts augmentent lineairement. Les modeles open source deployes sur une infrastructure possedee ou louee ont des couts fixes independamment de l’utilisation. Cela nous permet d’offrir une tarification previsible aux clients et d’executer des processus gourmands en calcul (comme la re-indexation et l’enrichissement continus) sans se soucier des couts par requete.
Principe 5 : pistes d’audit completes
Chaque interaction avec Enclava est journalisee :
- Quelle requete a ete soumise
- Quels documents ont ete recuperes
- Quels scores de classement ils ont recus
- Quel contexte a ete fourni au modele
- Quelle reponse a ete generee
- Quelles citations ont ete incluses
- Quand l’interaction a eu lieu
- Quel compte utilisateur etait implique
Cette piste d’audit sert plusieurs objectifs :
Conformite reglementaire. Quand la FINMA, une autorite cantonale de protection des donnees ou un superviseur du AI Act europeen demande comment un resultat particulier a ete produit, l’institution peut reconstituer l’integralite de la chaine de la requete a la reponse.
Responsabilite professionnelle. Quand un avocat cite des informations d’Enclava dans une note client, et que le client ou le conseil adverse conteste la citation, l’avocat peut demontrer exactement ce que le systeme a recupere, quelles sources ont ete utilisees et quel etait le resultat du systeme. Le jugement du professionnel en s’appuyant sur le resultat est documente.
Amelioration du systeme. Les pistes d’audit nous permettent d’identifier les echecs de recherche, les erreurs de classement et les comportements utilisateurs qui indiquent que le systeme ne repond pas aux attentes. L’amelioration continue necessite une mesure continue.
Confiance des clients. Savoir que chaque interaction est journalisee et auditable donne aux equipes conformite l’assurance dont elles ont besoin pour approuver l’outil pour le travail reglemente. L’objection courante “nous ne pouvons pas verifier ce que l’IA a fait” est traitee au niveau architectural.
Principe 6 : supervision humaine par conception
Enclava est concu comme un outil pour les professionnels, pas comme un remplacement. Cela se reflete dans l’architecture du produit :
- Les resultats sont presentes avec les sources pour verification, pas comme des declarations faisant autorite
- L’interface encourage la revue et le recoupement, pas l’acceptation aveugle
- Les controles administratifs permettent aux cabinets de restreindre les types de requetes pouvant etre traitees
- Aucune action automatisee : le systeme recherche, synthetise et presente. Le professionnel decide
Ce n’est pas une limitation. C’est une fonctionnalite. Dans les industries reglementees, l’humain dans la boucle n’est pas seulement une bonne pratique. C’est une exigence legale au titre du AI Act europeen pour les systemes a haut risque et une attente dans le cadre de supervision de la FINMA.
Nous croyons que les systemes IA les plus efficaces sont ceux qui rendent les professionnels meilleurs dans leur travail, pas ceux qui essaient de faire le travail a leur place. Le jugement, la relation client, les obligations ethiques et la reflexion strategique restent avec le professionnel. La recherche, la recuperation et la synthese deviennent plus rapides et plus exhaustives.
Pourquoi nous publions cela
La plupart des entreprises IA protegent leur architecture comme une information proprietaire. Nous publions la notre parce que dans les industries reglementees, l’opacite est l’ennemie de la confiance.
Si nos clients et leurs equipes conformite ne peuvent pas verifier comment notre systeme fonctionne, ils ne peuvent pas lui faire confiance. Et ils ne devraient pas. La confiance basee sur un argumentaire de vente n’est pas de la confiance. La confiance basee sur une architecture verifiable, si.
C’est l’approche que nous avons adoptee chez Mont Virtua. Sources verifiables, infrastructure souveraine, modeles open source, pistes d’audit completes et supervision humaine par conception. Non pas parce que ces choix sont faciles, mais parce qu’ils sont les bons pour les marches que nous servons.
Pour voir cette approche en pratique, visitez enclava.ch.