Pourquoi le risque devrait déterminer votre architecture d’IA
Lorsqu’un conseil d’administration demande à son DSI à quoi ressemble la gouvernance de l’IA, la réponse est généralement un document de politique, un cadre d’éthique ou une liste de principes. Il s’agit rarement d’une norme applicable aux achats. C’est dans cet écart que réside le véritable risque.
Déployer un système d’IA est toujours une décision critique. Pourtant, cette décision est prise par un développeur, parfois par un fournisseur et rarement par une personne responsable du résultat. La décision porte sur le point suivant : quel type d’IA utilisons-nous ? Dans la plupart des entreprises aujourd’hui, la réponse honnête est souvent que nous ne le savons pas et que nous ne disposons pas du vocabulaire nécessaire pour le déterminer.
Le choix d’une architecture d’IA n’est pas une préférence technique. Il s’agit d’une décision de gouvernance calibrée en fonction du risque, qui détermine l’auditabilité, la responsabilité et les conséquences. Cette décision détermine non seulement le comportement du système, mais aussi qui en est juridiquement et opérationnellement responsable en cas de défaillance.
Cette approche doit changer. Le risque lié à votre cas d’utilisation doit déterminer la forme d’IA que vous déployez, et vos critères d’achat doivent en tenir compte.
Participez à n’importe quelle conversation sur les technologies d’entreprise et l’IA sera décrite comme une catégorie unique. Les entreprises parlent de « déployer l’IA », de « gouverner l’IA », d’« auditer l’IA », comme si le terme désignait une technologie uniforme aux propriétés cohérentes. En réalité, ce n’est pas le cas.
Le marché de l’IA contient actuellement au moins trois types de systèmes distincts sur le plan architectural, chacun présentant des propriétés radicalement différentes en matière de gouvernance, d’explicabilité et de responsabilité :
• IA probabiliste : moteurs de reconnaissance de formes statistiques (la plupart des grands modèles de langage, l’IA générative, la plupart des modèles de ML modernes). La même entrée peut produire une sortie différente d’une exécution à l’autre. L’explicabilité est partielle et dépendante du modèle. L’attribution causale est difficile.
• IA probabiliste avec orchestration du contexte (et contrôles) : les modèles probabilistes fonctionnent avec des sources de données définies et une logique de routage fondée sur des politiques. Vous pouvez contrôler les éléments sur lesquels le modèle se base. Il n’est pas possible de garantir des résultats identiques dans des conditions identiques.
• IA déterministe : systèmes gouvernés par une logique, basés sur des règles ou pilotés par des ontologies. Chaque résultat peut être vérifié par rapport à une logique définie. Les résultats sont cohérents et reproductibles, avec une traçabilité complète possible dès la conception : quelles données, quelles règles, pourquoi ce résultat.
En pratique, la plupart des déploiements d’entreprise combinent ces architectures : un modèle probabiliste intégré à une couche de routage déterministe, avec un pipeline de retrieval et des garde-fous fondés sur des politiques. L’obligation de gouvernance consiste à savoir quels composants fonctionnent selon quelles propriétés et à soumettre chacun d’eux aux contrôles qu’exige son niveau de risque.
Les implications de gouvernance de ces trois types ne sont pas équivalentes. Pourtant, la plupart des achats d’IA les traitent comme s’ils étaient équivalents.
Lorsqu’un système peut produire deux réponses différentes à la même question dans les mêmes conditions et que les deux peuvent donner lieu à une action, cela révèle un problème. Il n’a pas le niveau de rigueur exigé pour la prise de décisions à fort enjeu.
L’utilisation de l’IA probabiliste n’est pas en soi un échec de gouvernance. Cependant, cela devient un problème lorsque des entreprises l’utilisent quel que soit le niveau de risque du cas d’utilisation, puis tentent d’ajouter a posteriori une gouvernance à un système qui n’a pas été conçu pour la prendre en charge.
La bonne séquence est l’inverse. Commencez par une évaluation lucide du niveau de risque du cas d’utilisation. Spécifiez ensuite, dans vos exigences, dans vos contrats et dans votre revue d’architecture, le niveau d’explicabilité, de traçabilité et de responsabilité exigé par ce niveau. Procédez ensuite aux achats en conséquence.
La colonne Architecture n’est pas une suggestion. C’est une exigence. Un cas d’utilisation à haut risque, impliquant des décisions lourdes de conséquences pour des personnes, une exposition financière élevée ou des conséquences difficilement réversibles, exige un niveau d’explicabilité propre aux systèmes déterministes. Ce niveau peut être atteint grâce à une conception déterministe ou à des contrôles hybrides aux limites strictement définies.
La supervision humaine est la couche qui rend la gouvernance de l’IA réelle. Mais seulement lorsqu’elle est conçue pour être réelle.
Réfléchissez à ce dont un examinateur humain a besoin pour assurer une supervision pertinente du résultat d’une IA. Nous imposons à nos collègues des normes de fiabilité : crédibilité, fiabilité, alignement des intérêts et intégrité au fil du temps. Le domaine de l’IA a développé un vocabulaire spécifique pour les propriétés équivalentes dans les systèmes. Ils doivent être capables d’interroger quatre éléments :
• La transparence est une question concernant le modèle : quelles données, quelle méthodologie, et ces méthodes étaient-elles les bons choix validés pour ce cas d’utilisation ?
• L’explicabilité est une question concernant le résultat : non pas comment le modèle fonctionne généralement, mais pourquoi il a produit cette décision spécifique pour cette personne en particulier.
• L’observabilité est une question relative au comportement d’un agent au fil du temps : le système fonctionne-t-il toujours correctement lorsque les conditions changent, que les données évoluent et qu’il interagit avec d’autres systèmes ?
• La robustesse face aux adversaires est une question de cybersécurité : quelqu’un a-t-il falsifié le modèle après votre dernière évaluation ? Fonctionne-t-il toujours dans les limites de sa conception et de sa mission d’origine ?
Votre architecture d’IA actuelle permet-elle à un examinateur humain d’accéder à ces éléments ? Si le système est probabiliste et que l’examinateur n’a aucune visibilité sur la traçabilité des données, aucune trace de raisonnement et aucune garantie de cohérence, qu’examine-t-il exactement ?
La réponse, dans la plupart des déploiements, est le résultat. Ils examinent un chiffre, une recommandation ou un indicateur. Ils n’examinent pas le raisonnement. Ils n’examinent pas les preuves. Ils ne sont pas, au sens véritable du terme, dans la boucle.
Vous obtenez davantage les comportements que vous mesurez. Si votre examinateur humain est mesuré sur le débit plutôt que sur la qualité de la supervision, vous avez conçu une chambre d’enregistrement et vous avez appelé cela « gouvernance ».
Voici à quoi ressemble le blanchiment de responsabilité. Un humain est impliqué dans le processus. Leur approbation est documentée. La case responsabilité est cochée. Mais les conditions d’une véritable supervision, c’est-à-dire la transparence architecturale, la formation, le pouvoir d’arrêter et le mécanisme de feedback, n’étaient pas réunies.
La solution consiste à construire une architecture permettant une véritable supervision humaine et à choisir des personnes possédant l’expertise métier nécessaire pour comprendre comment cette IA est utilisée dans son environnement. Mesurez ensuite ces personnes en fonction des bons critères.
C’est dans le vocabulaire des achats et de la gouvernance que la plupart des entreprises pèchent, et non dans leur compréhension de la technologie. Les entreprises qui réussiront seront celles qui développeront le vocabulaire et les leviers contractuels nécessaires pour préciser ce qu’elles attendent des systèmes d’IA.
Quatre choses doivent changer :
1. 1. Exiger la communication de l’architecture pour tout achat de solution d’IA. Les fournisseurs devraient être tenus de spécifier si leur système est probabiliste, déterministe ou hybride, et quelles sont les propriétés d’explicabilité de chaque composant.
Ils doivent également permettre une validation indépendante au moyen d’audits, de tests et d’une surveillance continue. « IA » n’est pas une catégorie suffisante pour une décision d’achat. « Modèle de langage probabiliste avec génération augmentée par récupération » en est une.
2. Associer les cas d’utilisation aux niveaux de risque avant de sélectionner une architecture. Tous les cas d’utilisation de l’IA ne nécessitent pas une architecture déterministe. Un outil de résumé de contenu à faible risque est soumis à des exigences différentes de celles d’un système d’IA qui prend des décisions de crédit ou effectue le triage des soins aux patients.
L’évaluation des risques doit avoir lieu avant la sélection des fournisseurs, et non après le déploiement. Et l’architecture requise, avec ses propriétés d’explicabilité et de responsabilité, devrait être inscrite dans les exigences, et non laissée à la discrétion du fournisseur.
3. Opérationnaliser les principes sous forme d’exigences fonctionnelles et non fonctionnelles, et non de déclarations d’intention. « Nous nous engageons en faveur d’une IA explicable » est une déclaration d’intention. « Au niveau Vigilant, le système doit fournir une piste d’audit complète pour chaque sortie, y compris les données source dont la traçabilité et la provenance sont documentées, la fiabilité validée par des tests ou des retests et des contrôles garantissant que les explications sont liées au dossier de preuves. »
Cette spécification est une exigence fonctionnelle. La différence réside dans le caractère contraignant. L’une de ces exigences doit être incluse dans un contrat. L’autre a sa place dans un communiqué de presse.
4. Établir des valeurs de référence pour les résultats avant le déploiement. Il est impossible de mesurer si un système d’IA cause des dommages à moins d’établir une base de référence avant de le déployer. Sans données sur les résultats antérieurs au déploiement, vous pouvez observer les sorties, mais vous ne pouvez pas attribuer les changements : vous n’avez aucun moyen de distinguer l’effet du système de ce qui se serait produit indépendamment.
Chaque déploiement d’IA devrait nécessiter une base de référence documentée pour les résultats qu’il est censé influencer, par rapport à laquelle les performances après le déploiement sont mesurées en permanence. Lorsqu’il n’existe pas de base de référence, en créer une est un prérequis, et non une tâche ultérieure.
Ces normes ne sont pas de simples aspirations. Elles ont déjà force de loi ou constituent des directives contraignantes dans plusieurs juridictions. Le règlement européen sur l’IA (article 9) exige que les systèmes d’IA à haut risque disposent, avant leur déploiement, d’un système documenté de gestion des risques comprenant des mesures de contrôle humain et des exigences en matière d’exactitude.Aux États-Unis, les directives fédérales relatives à l’utilisation de l’IA dans le recrutement ont été retirées en janvier 2025. Les obligations sous-jacentes prévues par le titre VII et l’ADA demeurent applicables, et la responsabilité des employeurs en cas de résultats discriminatoires produits par l’IA fait actuellement l’objet de contentieux devant les tribunaux fédéraux. Les directives SR 11-7 de la Réserve fédérale sur la gestion des risques liés aux modèles imposent des obligations continues de validation et de gouvernance aux modèles d’IA utilisés pour prendre des décisions dans le secteur des services financiers.
Les entreprises présentes dans ces juridictions n’ont plus à décider si elles doivent appliquer une gouvernance rigoureuse de l’IA. Elles doivent choisir entre agir de manière proactive et attendre une mesure coercitive des autorités.
Une gouvernance de l’IA qui se limite à des documents de politique interne reste au stade de l’ambition. Une véritable gouvernance est intégrée à l’architecture des systèmes qui sont achetés, déployés et évalués.
La plupart des entreprises ont une politique d’éthique en matière d’IA. Elles sont bien moins nombreuses à disposer de systèmes d’IA capables de remplir les obligations de responsabilité qu’elles ont assumées envers leurs clients, leurs régulateurs et les personnes les plus touchées par ces décisions.
Le risque devrait guider les choix d’architecture. L’architecture doit être intégrée aux exigences. Les exigences doivent être assorties de garanties contractuelles contraignantes.
Les organisations qui prendront les devants en matière de gouvernance de l’IA au cours des cinq prochaines années ne sont pas celles qui disposeront des cadres éthiques les plus sophistiqués. Ce sont celles qui ont traduit ces cadres dans le langage des achats, de l’architecture et de la mesure, et qui ont fait en sorte que leurs fournisseurs s’y conforment.
Ce travail commence par apprendre à poser la bonne question : non pas « avons-nous mis en place une gouvernance de l’IA ? », mais « notre architecture d’IA nous permet-elle d’assumer la responsabilité à laquelle nous nous sommes engagés ? »