Traçabilité des agents IA : ce que le droit suisse exige réellement

Le droit suisse impose-t-il de journaliser les agents IA ?

Non, pas sous cette forme. Un conseiller à la protection des données qui cherche dans la LPD l'article énumérant les champs d'un journal ne le trouvera pas : il n'existe pas pour les responsables du traitement privés. La tentation est de conclure que rien n'est exigé — l'erreur la plus coûteuse du dossier, car l'exigence existe, sans être écrite comme une liste.

Elle résulte de trois sources qui se recoupent :

• L'art. 21, al. 2, LPD — le contrôle par une personne physique. Il fixe le standard : ce dont cette personne a besoin pour se prononcer doit exister quelque part.
• L'art. 8, al. 3, LPD — les exigences minimales de sécurité des données, concrétisées par l'OPDo. Leur méconnaissance intentionnelle est réprimée par l'art. 61.
• L'attente FINMA de reproductibilité, pour les établissements assujettis. La communication FINMA 08/2024 du 18 décembre 2024 demande de pouvoir expliquer et reproduire les résultats face aux parties prenantes et aux autorités de surveillance, jusqu'aux hypothèses, limites et mécanismes de repli.

Ailleurs, le droit nomme les champs : l'autorité danoise de protection des données prescrit explicitement de journaliser toute utilisation de données personnelles — lecture, ajout, recherche, modification, extraction, suppression. La comparaison n'a pas valeur de norme ici ; elle mesure l'écart avec un régime qui laisse le responsable les déduire.

Le PFPDT a levé l'ambiguïté le 8 mai 2025 : la LPD est formulée de manière neutre sur le plan technologique et s'applique donc directement aux traitements assistés par l'IA. Attendre une loi suisse sur l'IA n'aide pas : le Conseil fédéral a arrêté le 12 février 2025 une approche sectorielle, écartant expressément une loi horizontale.

Pourquoi rejouer une décision ne prouve-t-il rien ?

Dans un processus déterministe, le contrôle est trivial : mêmes règles, mêmes entrées, même résultat. La réexécution est l'explication. Avec un système agentique, l'équivalence tombe : la sortie n'est pas reproductible, et le modèle derrière l'interface peut avoir été remplacé par le fournisseur sans qu'aucun paramètre n'ait bougé chez vous. Rejouer la décision fabrique un second événement, comparé à un résultat dont on ignore la genèse.

De là dépend la faisabilité du contrôle de l'art. 21, al. 2, LPD. Faute de trace, il ne reste à la personne qui contrôle qu'à reprendre la décision à son compte et à présenter son résultat comme une confirmation — non un contrôle, mais une seconde décision portant le même nom. Cela devient concret là où l'exception de l'art. 21, al. 3, let. a, ne joue pas : elle ne vaut que si la demande est acceptée ; en cas de refus, elle ne couvre rien. Voir la décision individuelle automatisée selon l'art. 21 LPD.

Quels champs un processus déterministe n'a-t-il pas besoin d'écrire ?

La plupart des journaux ont été conçus pour des enchaînements déterministes : ils consignent que quelque chose s'est produit et abandonnent le pourquoi au code, réputé inchangé. Appliqués à un agent, ils laissent des trous précis.

Champs d'un journal d'agent : exigés par quoi, et pourquoi le déterministe s'en passe

Champ	Exigé par quoi	Pourquoi le déterministe s'en passe
Déclencheur de l'opération	Art. 8, al. 3, LPD ; LSI, art. 74a ss	Le déclencheur est la planification : connu par construction
Données d'entrée sur lesquelles la décision a reposé	Art. 21, al. 2, LPD	Reconstituables depuis l'état des données : la règle est connue
Version du modèle et de la configuration au moment de l'opération	Art. 21, al. 2, LPD ; attente FINMA	Se déduit de la version livrée : le code ne change pas seul
Version de la règle appliquée et seuil d'approbation en vigueur	Communication FINMA 08/2024 ; art. 8, al. 3, LPD	La règle est le code : pas de politique séparée à dater
Validation : qui a approuvé, et ce qui lui a été affiché	Art. 21, al. 2, LPD	Aucune étape d'appréciation humaine à documenter
Tentatives échouées, interrompues ou refusées	LSI, art. 74a ss ; art. 8, al. 3, LPD	Un échec déterministe ne laisse pas d'ambiguïté

Le champ de version manque presque toujours. Sans lui, une décision atypique reste ininterprétable : erreur, ou comportement correct sous la configuration alors active ? Les deux hypothèses sont identiques a posteriori. Une version déduite d'un journal de déploiement ne règle rien : elle atteste ce qui était déployé, non ce sur quoi l'opération a tourné.

Sur les données d'entrée, l'excès est le risque symétrique : un journal qui recopie tout le contexte devient lui-même un traitement de données personnelles — parfois de données sensibles —, avec ses propres questions de conservation, d'accès et de communication à des tiers. Ce périmètre se définit lors de l'AIPD — l'analyse d'impact relative à la protection des données personnelles — que l'art. 22 LPD impose en cas de risque élevé, « notamment en cas de recours à de nouvelles technologies ».

Où les fournisseurs citent-ils faux ?

Quelques affirmations récurrentes ne résistent pas à la lecture des textes. Or un budget justifié par une citation fausse est contesté au premier arbitrage.

Affirmations courantes et état du droit

Ce que l'on entend	Ce qu'établit le droit suisse
« La journalisation des systèmes d'IA est obligatoire en Suisse. »	Aucune prescription expresse pour les responsables privés : exigence dérivée des art. 21, al. 2, et 8, al. 3, LPD.
« Vous avez 72 heures pour annoncer. »	Aucun délai de 72 heures en droit suisse : l'annonce au PFPDT se fait « dans les meilleurs délais ». Les 24 heures de la LSI valent pour l'OFCS, infrastructures critiques uniquement.
« Un journal lacunaire expose l'entreprise à CHF 250'000. »	Les art. 60 à 63 LPD visent des personnes physiques ; l'entreprise n'est condamnée qu'à titre subsidiaire, jusqu'à CHF 50'000 (art. 64, al. 2). Le PFPDT ne les prononce pas : il rend des décisions.
« Notre plateforme permet de rejouer la décision. »	Rejouer produit une décision nouvelle, non l'explication de l'ancienne : ce n'est pas le contrôle de l'art. 21, al. 2, LPD.

Pourquoi l'horloge de 24 heures de la LSI est-elle le vrai moteur ?

Pour les exploitants d'infrastructures critiques — et pour eux seuls —, une contrainte opérationnelle dure s'ajoute. Selon les art. 74a ss LSI (RS 128), une cyberattaque doit être signalée à l'OFCS dans les 24 heures suivant sa découverte, un signalement initial incomplet devant être complété dans les 14 jours. Le régime est en vigueur depuis le 1er avril 2025, les sanctions depuis le 1er octobre 2025, avec des amendes jusqu'à CHF 100'000.

Vingt-quatre heures ne suffisent pas à établir ce qui s'est produit lorsque des processus autonomes ont enchaîné des actions : libérer des paiements, exporter des données, modifier des droits d'accès. L'incident n'est plus un événement mais une chaîne, et la question du premier jour est de savoir quels maillons étaient autorisés. La vitesse de reconstitution détermine la qualité du signalement initial : qui ne l'a pas signale sur une base incertaine, puis reprend la chaîne sous pression.

Le vocabulaire départage deux processus : on signale un cyberincident à l'OFCS au titre de la LSI, on annonce une violation de la sécurité des données au PFPDT au titre de la LPD. Les obligations sont indépendantes ; un seul incident peut déclencher les deux.

Quand un défaut de journalisation devient-il sanctionnable ?

La précision est payante, parce que le marché cite mal. Les art. 60 à 63 LPD sont des amendes pénales visant des personnes physiques, d'un maximum de CHF 250'000 — le texte légal parle d'une amende de « 250 000 francs » au plus —, et non des sanctions administratives frappant l'entreprise. Selon l'art. 64, al. 2, celle-ci ne peut être condamnée qu'à titre subsidiaire et jusqu'à CHF 50'000.

Trois manquements réputés graves ne sont pas punissables en tant que tels : l'absence de registre des activités de traitement (art. 12 LPD, avec la dispense de l'art. 24 OPDo pour les organisations privées de moins de 250 collaborateurs, sauf traitement à grande échelle de données sensibles ou profilage à risque élevé), l'omission d'une AIPD et une violation de la sécurité des données non annoncée. Ils ne deviennent sanctionnables qu'indirectement, par une décision du PFPDT et l'art. 63.

Pour la journalisation, la voie est ailleurs : l'art. 61 LPD vise la méconnaissance intentionnelle des exigences minimales de sécurité des données de l'art. 8, al. 3, LPD. « Mal journaliser » n'est donc pas une infraction ; ce qui est réprimé, c'est de rester en deçà des exigences minimales, en connaissance de cause. Et la sanction vise une personne : une exposition individuelle, non une ligne de risque d'entreprise.

Comment vérifier que votre journalisation tient ?

Le test de reconstitution

Il coûte une demi-heure. Prenez une opération au hasard, remontant à trois mois au moins, et reconstituez : déclencheur, données d'entrée, version du modèle et de la règle, validation — y compris ce qui a été affiché à la personne qui a validé — et résultat. Condition : sans journaux applicatifs, sans solliciter le développement.

Trois issues. En moins de cinq minutes depuis une source unique : la journalisation constitue une preuve. Possible, mais avec le concours du développement : la preuve n'existe pas ; il existe la capacité de reconstitution de quelques personnes — non transmissible, non opposable, indisponible un dimanche. Déclencheur et résultat reconstituables, tentatives antérieures introuvables : l'issue la plus fréquente, celle où l'on a consigné ce qui a réussi et rien de ce qui a été tenté.

Liste de contrôle

1. Menez le test de reconstitution et consignez le résultat par écrit, même mauvais.
2. Écrivez la trace avant l'exécution, non après la réponse : sinon manquera exactement ce qui a échoué.
3. Écrivez la version du modèle et de la configuration avec l'opération, sans la déduire du déploiement.
4. Retenez les seules données d'entrée sur lesquelles la décision a reposé ; journalisez aussi les tentatives échouées, interrompues et refusées.
5. Consignez ce qui a été affiché à l'approbateur : sans cela, la validation humaine n'est pas démontrable.
6. Alignez la conservation sur les délais de conformité, non sur la rotation des journaux.
7. Séparez droits d'écriture et droits de modification, et retirez à l'agent tout accès à la trace : sinon le système se contrôle lui-même.
8. Exigez de toute couche de traçabilité achetée qu'elle inscrive aussi la version du modèle et les données d'entrée : beaucoup consignent l'action, pas son fondement.
9. Pour les assujettis : rattachez la trace à l'inventaire IA et à la classification des risques de la communication FINMA 08/2024.

Questions fréquentes

Le droit suisse impose-t-il de journaliser les agents IA ?

Pas expressément. L'exigence est dérivée des art. 21, al. 2, et 8, al. 3, LPD et, pour les assujettis, de l'attente FINMA de reproductibilité.

Pourquoi ne suffit-il pas de rejouer la décision ?

Parce qu'une réexécution produit une décision nouvelle, non l'explication de l'ancienne : la même entrée peut donner un autre résultat, et le modèle avoir changé entre-temps.

Quels champs manquent le plus souvent ?

Les données d'entrée sur lesquelles la décision a reposé, et la version du modèle et de la configuration au moment de l'opération.

Un défaut de journalisation peut-il être sanctionné ?

Indirectement, par l'art. 61 LPD (méconnaissance intentionnelle des exigences minimales de sécurité de l'art. 8, al. 3). Les amendes jusqu'à CHF 250'000 visent des personnes physiques ; l'entreprise ne répond qu'à titre subsidiaire jusqu'à CHF 50'000 (art. 64, al. 2), et elles sont prononcées par les autorités cantonales de poursuite pénale, non par le PFPDT.

Faut-il une AIPD avant de mettre un agent en production ?

L'art. 22 LPD l'exige en cas de risque élevé, « notamment en cas de recours à de nouvelles technologies » — le moment d'arrêter par écrit les champs à journaliser.

Une loi suisse sur l'IA imposera-t-elle la journalisation ?

Rien ne l'indique. Le Conseil fédéral a retenu le 12 février 2025 une approche sectorielle ; au 2 septembre 2026, aucune consultation n'est ouverte.

Pour aller plus loin

La traçabilité ne se mesure pas au volume journalisé, mais à une capacité : rattacher une action isolée à son autorisation, des mois plus tard, sans son auteur. Tant qu'elle se reconstitue depuis des journaux dispersés, il n'y a pas de preuve, seulement des souvenirs bien documentés.

• Gouvernance de l'IA en Suisse — le guide complet
• Décision individuelle automatisée selon l'art. 21 LPD
• AIPD pour les systèmes d'IA selon l'art. 22 LPD
• Obligation de signaler les cyberattaques : 24 heures à l'OFCS
• Communication FINMA 08/2024
• Constitution de la preuve pour les agents IA (en anglais)

En pratique

L'autorisation avant l'action. La preuve après.

Les obligations décrites ici s'attachent à l'instant où un système automatisé agit : qui l'a autorisé, sur quelles données, sous quelle version de politique, et ce qu'une personne a vu avant de valider. Barzel applique cette décision avant l'exécution et rédige la trace que l'on peut présenter à un auditeur, à une autorité ou à une personne concernée.

En vigueurLPD révisée en vigueur depuis le 1er septembre 2023

BarzelVault

Le pare-feu des actions de l'IA : décider ce qu'un agent peut faire avant qu'il ne le fasse.

• Seuils de validation et contrôles de politique appliqués avant l'exécution ; validations humaines avec expiration et escalade.
• Reçus d'audit signés cryptographiquement : déclencheur, données d'entrée, version de politique, valideur, résultat.
• Isolation des identifiants, plafonds de dépense et d'action, et arrêt d'urgence.

Offre gratuite : 10 000 appels par moisPlans payants à partir de 199 USD par moisDisponible sur MCPize

Commencer gratuitement →Demander par e-mailPage produitDocumentation

Barzel Central Gateway

Le plan de contrôle de la gouvernance de l'IA : un inventaire et une couche de politique uniques pour tous les serveurs MCP et agents.

• Enregistre et synchronise chaque outil ; applique identité, politique, région, coût et état de santé outil par outil.
• Correspondance des identités via OIDC, Entra ID, Okta, SAML et SPIFFE, avec courtage des identifiants.
• Export des traces et des événements SIEM (W3C Trace Context, OTLP) pour l'équipe sécurité et l'autorité.

Offre gratuite : 1 000 appels par moisPlans payants à partir de 10 USD par moisDisponible sur MCPize

Commencer gratuitement →Demander par e-mailPage produitDocumentation

Enterprise : devis écrit par e-mail sous deux jours ouvrés. Sans appel commercial.

Sources

1. LPD, RS 235.1, art. 8, 12, 21, 22, 60 à 64 ; OPDo, RS 235.11, art. 24 — fedlex.admin.ch.
2. PFPDT, communication du 8 mai 2025 : la LPD s'applique directement à l'IA.
3. FINMA, communication sur la surveillance 08/2024, 18 décembre 2024.
4. LSI, RS 128, art. 74a ss ; OFCS, obligation de signaler les cyberattaques, en vigueur depuis le 1er avril 2025, sanctions depuis le 1er octobre 2025 — fedlex.admin.ch.
5. Conseil fédéral, communiqué du 12 février 2025 sur la réglementation de l'IA.
6. Datatilsynet (DK), exigences de journalisation — comparaison, non applicable en Suisse.

Le présent article a une vocation informative et ne constitue pas un conseil juridique. État au 2 septembre 2026.