Souveraineté IA en Suisse : ce que vos auditeurs FINMA et ISO vont vraiment vous demander en 2026

On a passé les six derniers mois à câbler des assistants IA dans des banques privées, des gestionnaires de fortune et deux assureurs. Le mouvement est lancé. Les copilotes sortent des POC et entrent en prod. Et derrière, on voit arriver une autre vague, beaucoup plus discrète : les auditeurs.

Auditeurs internes, réviseurs externes, gens de la conformité, parfois la FINMA en personne. Tous posent à peu près les mêmes questions. Et on s'aperçoit qu'une PME suisse régulée sur deux n'a pas les réponses prêtes.

Cet article, c'est ce qu'on aurait aimé avoir sous les yeux il y a un an. Pas un livre blanc. Une cartographie de terrain de ce qui est en train de se passer en 2026 sur la conformité IA en Suisse, et de ce qu'on met concrètement en place chez nos clients régulés.

Le décor 2026 : AI Act, FINMA, ISO 42001 et nFADP

Quatre textes structurent la conversation. Ils n'ont pas le même poids, et c'est là que la plupart des dirigeants se font piéger.

L'AI Act européen est entré en application progressivement depuis 2025. Le règlement classe les systèmes IA par niveau de risque — inacceptable, élevé, limité, minimal — et impose des obligations correspondantes. La Suisse n'est pas membre de l'UE, mais une PME suisse qui exporte un service IA vers l'Europe, ou qui a une filiale dans l'UE, est rattrapée. Pour une banque privée vaudoise avec un bureau à Luxembourg ou Munich, l'AI Act s'applique sur ce périmètre. Point.

La FINMA, elle, n'a pas publié de circulaire IA dédiée à ce jour. C'est important de le dire honnêtement, parce qu'on lit beaucoup de bêtises là-dessus. Les attentes de la FINMA sur l'IA se déduisent du cadre prudentiel existant : Circulaire 2008/21 sur les risques opérationnels, Circulaire 2023/1 sur les risques opérationnels et la résilience, et plus largement les exigences de gouvernance, de maîtrise des risques de modèle, et de surveillance des prestataires tiers. La FINMA traite l'IA comme un risque opérationnel. Et elle attend du conseil d'administration qu'il sache de quoi il parle.

ISO/IEC 42001, publiée en décembre 2023, est la première norme internationale de management de l'IA. Ce n'est pas contraignant — c'est un référentiel. Mais en pratique, c'est en train de devenir la grille de lecture des audits IA dans le secteur financier suisse. Si vous voulez parler le même langage que votre réviseur, ISO 42001 est le vocabulaire commun.

La nFADP est en vigueur depuis septembre 2023. Elle s'applique à toute donnée personnelle traitée par vos systèmes IA, y compris quand le traitement passe par un modèle hébergé chez un fournisseur tiers. Le décideur, c'est vous. Pas OpenAI, pas Anthropic, pas Mistral.

5 questions que vos auditeurs vont vous poser

On a fait l'exercice avec une dizaine de clients régulés. Voici les cinq questions qui reviennent à chaque fois, dans cet ordre.

1. Qui est responsable du modèle ?

La première question, ce n'est pas technique. C'est de la gouvernance.

L'auditeur veut un nom. Une personne, dans votre organigramme, qui répond du système IA. Pas un comité flou. Pas "l'équipe data". Quelqu'un qui peut être appelé à 14h00 un mercredi et qui sait répondre.

Dans nos déploiements, on travaille avec un owner métier (qui définit le cas d'usage et arbitre les décisions de produit) et un owner technique (qui répond du modèle, des évals, et des incidents). Les deux sont nommés par écrit, dans la politique IA de l'entreprise.

Si vous ne savez pas qui répond du chatbot conseiller clientèle de votre banque, vous avez un problème. Et c'est la première chose que l'auditeur va sentir.

2. Où sont hébergés vos modèles et vos données ?

Deuxième question, et celle qui fait le plus souvent transpirer.

"Notre IA tourne sur Azure" n'est pas une réponse. Azure quoi ? Quelle région ? Quel modèle exact ? Sous quel contrat ? Avec quel engagement de non-utilisation des données pour ré-entraînement ?

On a vu des PME utiliser ChatGPT côté grand public — pas l'offre Enterprise — pour traiter des données client. C'est non. Pas seulement pour la FINMA, mais pour la nFADP. L'auditeur va demander à voir les contrats, les régions, les flux de données. Préparez une carte. Littéralement, un diagramme une page qui montre : utilisateur → application → modèle → stockage. Avec les pays.

3. Comment tracez-vous chaque réponse IA en production ?

C'est la question qui coule la majorité des projets IA non préparés.

L'auditeur ne demande pas si vous avez des logs. Il demande si vous pouvez, pour un appel client survenu il y a six semaines, lui dire : qui a posé la question, à quel modèle exactement, dans quelle version, avec quel prompt système, sur quelles sources documentaires, et qui a validé la réponse avant qu'elle parte au client.

Si la réponse est "on a les logs applicatifs", ça ne suffit pas. Un log applicatif dit que la requête est passée. Un audit trail IA dit ce qui s'est passé à l'intérieur du modèle.

4. Comment évaluez-vous la qualité ?

Question piège. Beaucoup répondent "on a fait des tests au lancement, ça marchait bien."

L'auditeur veut une eval grid documentée. Une liste de cas représentatifs — disons 80 à 200 prompts — avec les réponses attendues, les critères de notation, et l'historique des scores au fil des versions. Il veut voir que vous avez une mesure objective de la performance de votre modèle, et que cette mesure tourne en continu, pas une fois par an.

C'est aussi là que la dérive se voit. Un modèle qui marche au lancement et se dégrade après six mois d'usage, ça arrive plus souvent qu'on ne le dit. Sans eval grid, vous ne le verrez pas.

5. Quel est le plan de retombée si le modèle se trompe ?

L'auditeur ne croit pas que votre modèle est parfait. Il sait qu'il va se tromper. Il veut savoir ce qui se passe ce jour-là.

Qui détecte l'erreur ? Comment ? Quel est le délai d'escalade ? Est-ce qu'il y a un humain dans la boucle pour les décisions à fort impact — par exemple, un rejet de crédit ou un conseil de placement ? Existe-t-il un rollback rapide vers une version antérieure du système ?

C'est ce qu'on appelle dans nos politiques internes le plan de continuité IA. Sans lui, votre système n'est pas mature. Et la FINMA, qui regarde la résilience opérationnelle depuis vingt ans, vous le fera sentir.

Hébergement souverain : ce que ça veut vraiment dire

On entend "cloud souverain" partout. Le terme est galvaudé. Décortiquons-le, parce que ça fait une différence quand l'auditeur arrive.

Premier niveau, le plus mou : cloud "européen". Azure EU, AWS eu-central, GCP europe-west. Les données sont stockées en Europe. Mais l'opérateur est américain, et soumis au CLOUD Act. La FINMA regarde cette configuration de travers pour les données sensibles, surtout pour les banques privées dont la clientèle est précisément attachée à la protection des données.

Deuxième niveau : cloud européen souverain. Mistral hébergé en France, modèles open-weights (Llama, Mixtral, Qwen) déployés chez des hébergeurs européens. L'opérateur, l'infrastructure et la juridiction sont européens. La FINMA est nettement plus à l'aise.

Troisième niveau : hébergement suisse. Infomaniak, Exoscale, Swisscom, parfois un déploiement on-prem dans le datacenter de la banque. C'est le standard quand on traite des données client identifiables d'une banque privée. C'est aussi le plus contraignant à opérer.

Pour la plupart de nos clients régulés, on combine. Le RAG sur des données client tourne en Suisse ou en France sur des modèles open-weights. Les tâches non sensibles — résumés de documents publics, génération de templates — peuvent tourner sur Claude ou GPT en région européenne, sous contrat Enterprise avec engagement de non-rétention. La règle qu'on applique : les données identifiantes ne sortent jamais d'un périmètre maîtrisé.

C'est aussi pour cette raison qu'on a souvent l'air de ralentir les projets au début. Le bon hébergement coûte trois semaines de plus en cadrage. Mais il vous évite de devoir tout recâbler dans un an quand l'auditeur passe. Et c'est exactement ce qu'on voit échouer dans les POC qui n'ont pas pensé conformité en amont.

Audit trail : sans ça, pas d'IA en prod

C'est le point où on est le plus intransigeant. Pas de journalisation, pas de mise en production. Point.

Concrètement, voici les champs qu'on logge pour chaque interaction IA en production chez nos clients régulés :

• ID de session et ID utilisateur (ou pseudonyme, selon le cas d'usage)
• Timestamp précis à la seconde
• Prompt utilisateur brut
• Prompt système complet (avec sa version)
• Modèle appelé : provider, modèle exact, version, paramètres
• Sources retrouvées par le RAG : ID document, score de pertinence, extrait utilisé
• Réponse brute du modèle
• Réponse finale affichée à l'utilisateur (après éventuel post-traitement)
• Validation humaine si elle existe : qui, quand, accepté/modifié/rejeté
• Latence et coût de l'appel

Tout ça est stocké dans un système de logs immuable, sur infrastructure souveraine, avec une rétention adaptée à la donnée. Pour des données financières client, on s'aligne sur les durées de rétention bancaires — 10 ans est un standard prudent.

Ce niveau de journalisation coûte. En infrastructure, en temps d'ingénieur, en discipline d'équipe. Mais c'est la seule façon de dormir tranquille quand votre nom est sur la ligne "owner technique".

Ce qu'on met en place chez nos clients régulés

Pour finir, la checklist BUMPSLAB. Ce qu'on installe systématiquement quand on déploie de l'IA dans une PME régulée. Pas pour faire joli — pour passer l'audit.

1. Politique IA écrite, validée par la direction. Un document de 8 à 15 pages qui définit les cas d'usage autorisés, les modèles approuvés, les principes d'hébergement, les responsabilités.
2. Registre des cas d'usage IA. Un tableau vivant qui liste chaque assistant en prod, son owner, son hébergement, son niveau de risque, sa dernière éval.
3. Gouvernance des modèles tiers. Pour chaque provider (Anthropic, Mistral, OpenAI…) : contrat Enterprise, due diligence sécurité, fiche de risque à jour.
4. Eval grid documentée par cas d'usage, scorée à chaque release et au moins une fois par trimestre en monitoring continu.
5. Hébergement souverain par défaut. On part toujours sur Suisse ou France, et on argumente quand on s'en éloigne, pas l'inverse.
6. Journalisation complète comme décrite plus haut, avec rotation et tests réguliers de relecture.
7. Plan de continuité : rollback testé, escalation chain documentée, humain dans la boucle pour les décisions à fort impact.
8. Revue trimestrielle avec le comité de risque ou le responsable conformité. Trente minutes, un slide, les chiffres qui comptent.

Tout ça représente, dans une PME, environ un mois-homme de mise en place initiale, plus une charge récurrente d'un demi-jour par semaine. Ce n'est pas gratuit. Mais c'est ce qui sépare un projet IA d'entreprise d'un projet IA en entreprise — et c'est cette discipline qui fait la différence dans des déploiements comme celui qu'on a documenté avec Loxia.

---

Une dernière question, et on s'arrête là. Si la FINMA vous appelle demain matin pour un check IA inopiné, qu'est-ce que vous pouvez leur montrer en trente minutes ? Le nom de l'owner ? Les contrats d'hébergement ? Les évals du dernier trimestre ? Le log d'une interaction précise sur demande ?

Si la réponse est "il faudrait que je demande à l'équipe", c'est qu'il y a du travail. Et c'est le bon moment de le faire — avant que ce soit eux qui décident du calendrier.