On vend aux entreprises une histoire bien nette : « Nous auditerons vos automatisations et vous rendrons conformes. »
Parfois, le vendeur est un avocat qui ne voit jamais comment le système fonctionne réellement. Parfois, c’est un consultant en automatisation qui formule des affirmations juridiques qu’il n’est pas qualifié pour faire. Le livrable final est souvent un document de politique, une session de formation et une case verte dans un tableur.
Rien de tout cela ne prouve que le système déployé respecte encore l’intention humaine d’origine qui a justifié sa construction.
Une illustration utile de la facilité avec laquelle cet écart s’ouvre vient d’une recherche publiée en juillet 2026. Reuters a examiné plus de 80 articles universitaires et brevets chinois. Des chercheurs avaient utilisé les sorties de grands modèles américains comme données d’entraînement pour des systèmes plus petits et spécialisés, conçus pour fonctionner en local, avec une puissance de calcul limitée, pour des tâches telles que l’analyse de code, le traitement d’images ou le fonctionnement quand les connexions réseau tombent.
Certaines capacités se transfèrent bel et bien. Anthropic note que lorsque de grands modèles sont distillés en modèles plus petits, certaines des protections de sécurité d’origine peuvent être affaiblies ou perdues.
Mais la recherche ne montre pas que des comportements de sécurité essentiels, comme refuser les demandes dangereuses, exprimer l’incertitude ou faire remonter les cas sensibles, aient été testés de manière systématique et confirmés comme absents.
Et c’est là le vrai problème : nous ne savons tout simplement pas ce qui se transmet et ce qui ne se transmet pas. Un modèle plus petit peut paraître tout aussi capable tout en perdant discrètement les règles et les limites qui encadraient le comportement attendu du système d’origine.
Ce n’est pas seulement une histoire militaire. Le même problème d’architecture peut apparaître quand une entreprise affine un modèle, crée un agent interne ou entraîne un système spécialisé moins coûteux. Le comportement utile peut se transférer. L’objectif d’origine, les règles de refus et les limites de décision, eux, peuvent ne pas suivre.
Un avocat qui examine le contrat du fournisseur peut ne pas le voir. Un consultant en automatisation qui vérifie que le flux de travail « fonctionne » peut ne pas le voir non plus. Tous deux peuvent produire un dossier de conformité impeccable alors que le système en production s’est éloigné de l’intention qui devait le gouverner.
L’AI Act n’exige pas qu’un avocat valide chaque automatisation. Il n’exige pas 2 personnes à temps plein dans chaque entreprise. Ses obligations dépendent du rôle de l’organisation et de l’usage particulier : statut de fournisseur ou de déployeur, classification du risque, transparence, documentation, supervision humaine, suivi et autres exigences.
Depuis le 2 août 2026, certaines obligations de transparence sont devenues applicables. La Commission a également ouvert 3 canaux à portée limitée : un outil de plaintes AI Act pour les infractions présumées éligibles, un outil de lancement d’alerte AI Act pour les lanceurs d’alerte internes éligibles, utilisable de façon anonyme, et un canal de plaintes dédié aux fournisseurs en aval qui signalent d’éventuels manquements de fournisseurs de modèles à usage général.
Ces outils ne deviennent utiles que lorsque des preuves existent déjà. Un document de politique ne peut pas reconstituer des journaux, des versions de modèles, des pistes d’approbation ou une documentation fournisseur manquante que le système n’a jamais enregistrés.
Ces 3 canaux sont déjà ouverts. L’une des premières choses qui peuvent désormais être signalées est un manque de transparence.
À compter du 2 août 2026, les obligations de transparence de l’article 50 s’appliquent. Les utilisateurs doivent être clairement informés lorsqu’ils interagissent avec un système d’IA, par exemple un chatbot ou une voix d’IA à la place d’un humain.
Certains contenus générés ou manipulés par l’IA doivent être signalés de façon visible. Cela inclut les deepfakes et, dans des conditions précises, les textes générés par l’IA publiés pour informer le public sur des questions d’intérêt public lorsqu’il n’y a eu ni relecture humaine véritable ni responsabilité éditoriale. Les fournisseurs de systèmes génératifs ont aussi des obligations en matière de marquage lisible par machine et de détectabilité. La mention exacte dépend du type de système, de contenu et d’usage : tout ce qui est créé avec l’IA n’exige pas la même étiquette visible. Pour l’audio, par exemple les podcasts générés par l’IA, cela signifie généralement un avertissement oral dès le début. Pour les textes écrits, l’attente pratique est une mention visible de l’IA placée au-dessus du texte ou près du titre.
Les fournisseurs de systèmes génératifs doivent aussi intégrer des marquages lisibles par machine afin que d’autres systèmes puissent détecter que le contenu a été produit par l’IA.
Les systèmes déjà sur le marché avant le 2 août disposent jusqu’au 2 décembre 2026 uniquement pour la partie lisible par machine. L’obligation d’informer les utilisateurs qu’ils parlent à une IA et celle d’étiqueter les contenus générés par l’IA s’appliquent déjà.
Les amendes en cas de violation de ces règles peuvent atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial. Les petites et moyennes entreprises ne sont pas exemptées de l’obligation, même si le montant de l’amende peut être ajusté par proportionnalité.
Un grand nombre d’entreprises qui utilisent l’IA générative ou des chatbots en contact avec les clients sont encore en train de rattraper leur retard. Un document de politique qui affirme « nous respectons l’AI Act » ne place pas automatiquement les avertissements oraux ou les étiquettes visibles requis sur les sorties réelles que les gens voient ou entendent. C’est une autre raison pour laquelle la signature d’un avocat ou une liste de contrôle d’automatisation ne suffit pas. Le système en fonctionnement doit produire le comportement transparent que la loi exige désormais. Les entreprises ont donc besoin de 3 choses, pas de 2 intitulés de poste :
Quelqu’un capable de montrer ce que le système fait réellement : quels modèles, outils et données sont connectés, quelles actions il peut proposer ou exécuter, ce qui se passe quand il se trompe, quels enregistrements existent et qui est responsable quand les choses dérivent.
Quelqu’un capable d’interpréter ce que la loi exige pour cet usage précis.
Un responsable désigné au sein de l’entreprise, qui décide du risque résiduel, peut arrêter le système et définit quelles preuves doivent exister avant que l’automatisation ne s’étende.
Des conseillers externes peuvent apporter des constats techniques ou un avis juridique. Mais ils ne peuvent pas absorber la responsabilité de l’organisation en se contentant de signer un rapport.
Ici, le modèle de conception de Palantir est utile parce qu’il est opérationnel. Ses Deployment Strategists et Forward Deployed Engineers (structure d’équipes Echo et Delta) abordent le même problème institutionnel par des rôles complémentaires mais qui se recoupent. Le Deployment Strategist (Echo) peut se concentrer davantage sur la compréhension de l’organisation, la remise en question de la demande initiale et la définition du résultat opérationnel, tandis que le FDE (Delta) peut se concentrer davantage sur la transformation de cette compréhension en logiciel fonctionnel. Mais aucun des deux rôles ne commence seulement après que l’autre a terminé, et aucun ne suppose que chaque problème exige de l’IA.
En étudiant de plus près certains de leurs cadres et leur plateforme de déploiement, Palantir AIP (Artificial Intelligence Platform), j’ai constaté que les utilisateurs humains peuvent examiner les actions proposées par l’IA, inspecter les règles et l’historique d’exécution, et approuver les décisions critiques par des points de contrôle structurés. Ses recommandations de gouvernance traitent le système complet (pipelines de données, autorisations, interfaces, pistes d’audit, flux d’évaluation et de test, décisions humaines) et pas seulement le modèle.
Son cadrage de l’IA souveraine ajoute un autre test : l’organisation peut-elle fonctionner dans le cloud, sur site, dans un cloud souverain ou en périphérie, changer de modèle, préserver ses données et continuer à fonctionner sans abandonner le contrôle ?
Utiliser un fournisseur américain ne rend pas automatiquement une entreprise européenne souveraine. La souveraineté se démontre par le contrôle, la portabilité, l’auditabilité et un réel pouvoir de sortie.
Un bouton d’approbation humaine reste vide de sens lorsque le réviseur n’a ni le temps, ni le contexte, ni la compétence, ni l’autorité pour rejeter l’action.
Avant d’approuver la prochaine automatisation, demandez-vous :
Pouvons-nous identifier le modèle, sa version et son origine ? Quelles actions exigent une approbation humaine, et cette personne peut-elle réellement les arrêter ? Si quelqu’un collectait 100 000 sorties, quelle partie de notre logique de décision pourrait-il reproduire ? Pouvons-nous continuer à fonctionner et conserver nos données si le fournisseur ou le réseau disparaît ? Si une plainte arrive demain, quelles preuves pourrions-nous produire ?
Une IA responsable ne commence pas quand un document de politique reçoit une coche. Elle commence quand ce qui est écrit dans la politique correspond réellement à ce que fait le système en pratique, et quand un humain peut encore comprendre, contrôler et arrêter le système s’il se met à se comporter d’une manière qui n’était pas prévue.
C’est cet écart sur lequel je travaille.
Sources
[1] Reuters, « Chinese military researchers tap US AI models to train defence systems », 31 juillet 2026. reuters.com
[2] Commission européenne, AI Act Service Desk FAQ. ai-act-service-desk.ec.europa.eu
[3] Commission européenne, AI Act Complaints Tool. digital-strategy.ec.europa.eu
[4] Commission européenne, AI Act Whistleblower Tool. digital-strategy.ec.europa.eu
[5] Commission européenne, Complaints channel for downstream providers using GPAI models. digital-strategy.ec.europa.eu
[6] Palantir, documentation AIP Ethics & Governance. palantir.com
[7] Palantir, Protect Your Sovereignty (cadrage de l’IA souveraine). palantir.com