Ce que les DSI doivent savoir sur le contrôle de l’IA

Des contrôles de l’IA plus sophistiqués peuvent compliquer la réponse d’un DSI à une question élémentaire : qui contrôle en dernier ressort une action de l’IA ? Chaque nouvel agent, modèle ou capacité d’IA intégrée peut introduire des systèmes qui déterminent l’orchestration, la sélection des modèles, l’accès aux données, l’identité, les autorisations, l’observabilité et le déploiement. Chaque système peut résoudre un problème légitime, mais leurs décisions peuvent se croiser. Le résultat peut être une architecture dans laquelle plusieurs produits exercent une autorité connexe sur une même action de l’IA.

Davantage de contrôles de l’IA peuvent laisser les DSI avec un contrôle moins cohérent

Ce chevauchement fait du contrôle de l’IA un problème d’architecture pour les DSI. Les décisions produit s’accumulent dans les environnements applicatifs, de données, de sécurité et d’infrastructure, de sorte que l’entreprise doit déterminer comment leurs contrôles interagissent. Le vocabulaire s’élargit avec la technologie : orchestration, gestion du contexte, harnesses et control planes décrivent de plus en plus des fonctions qui se recoupent entre produits et couches.

À mesure que ces fonctions se diffusent dans la stack IA, une formulation éditoriale non attribuée résume bien la tension : « Les fonctions de contrôle sont peut-être en train de converger. Les endroits où ces contrôles résident se multiplient. » Des systèmes pris individuellement peuvent fournir des contrôles plus solides tout en donnant à l’entreprise davantage d’endroits où des décisions importantes sont prises. Les DSI doivent donc comprendre l’autorité sur l’ensemble du workflow ainsi que les capacités de chaque composant.

Cette question d’architecture commence une fois qu’une technologie donnée a été choisie. Un DSI doit encore savoir si un modèle ou un agent fonctionne pour un cas d’usage particulier, puis déterminer quel système régit son comportement, quels autres systèmes le contraignent et quelle décision prévaut lorsque les contrôles se chevauchent. Ces réponses déterminent si la gouvernance fonctionne de manière cohérente depuis la demande initiale jusqu’à l’action de l’IA qui en résulte.

Le contrôle de l’IA émerge simultanément de plusieurs couches

La multiplication commence avec l’orchestration, dont le rôle initial consistait à coordonner les agents, les applications et les workflows. Un agent harness étend cette fonction environnante en fournissant la gestion du contexte, la mémoire, les outils, les garde-fous, la supervision, la gestion des erreurs et la gouvernance autour d’un modèle. Un harness agnostique vis-à-vis des modèles peut réduire la reconstruction nécessaire lorsqu’une entreprise change de modèle sous-jacent, même si le remplacement d’un modèle peut encore nécessiter d’autres travaux.

Salesforce étend cette approche à des agents issus de plusieurs fournisseurs. Son Enterprise AI Harness est conçu pour orchestrer et gouverner les agents à travers les systèmes, tout en intégrant l’identité, les autorisations, la gouvernance, l’observabilité, l’orchestration et la visibilité sur les coûts dans l’environnement global. Salesforce appelle le composant d’observabilité situé sous ce harness plus large son « AI Control Plane ». Salesforce commercialise des produits d’IA d’entreprise et en tire un bénéfice commercial lorsque les clients utilisent sa technologie pour ces fonctions de contrôle ; la terminologie doit donc être lue en parallèle de l’architecture : le control plane s’inscrit dans un ensemble plus large de contrôles et exerce son autorité sur les fonctions qui lui sont attribuées.

Une autre décision de contrôle apparaît à l’exécution, où HydraFusion, expérimental chez GitHub, peut sélectionner dynamiquement un modèle ou une combinaison de modèles en fonction du travail effectué. Une partie de l’autorité de sélection des modèles peut ainsi passer de l’adoption initiale de l’outil à l’exécution, permettant au système de choisir comment une unité de travail donnée doit être traitée. GitHub a un intérêt commercial dans les plateformes pour développeurs et les plateformes d’IA qui gèrent cette exécution, tandis que HydraFusion illustre la conséquence architecturale plus large du routage à l’exécution.

Une fois le routage devenu dynamique, la sélection des modèles devient une décision d’exécution gouvernée, car le résultat peut affecter le coût, le comportement et les systèmes impliqués dans l’exécution. Une plateforme qui fait ce choix détient une autorité significative sur le modèle ou l’ensemble de modèles qui reçoit le travail. HydraFusion place donc le contrôle à une frontière différente de celle d’un harness qui entoure et gouverne un agent.

Alteryx place une autre frontière autour des données gouvernées et de la logique métier. Sa position entre les systèmes d’IA d’entreprise et les informations gouvernées lui donne un rôle dans la détermination des contenus métier de confiance que l’IA peut utiliser et selon quelle logique existante. Alteryx bénéficie commercialement lorsque les entreprises utilisent sa technologie de données et d’analytics dans ce rôle, tandis que la fonction architecturale reste distincte : elle façonne ce qu’une action de l’IA peut savoir et sur quoi elle peut s’appuyer.

L’infrastructure crée une autre source d’autorité, que Mistral aborde à travers les choix de déploiement et de fournisseurs. Le fournisseur européen de modèles met en avant la flexibilité de déploiement, le contrôle de l’infrastructure, la localisation des données et une dépendance réduite à des fournisseurs individuels dans son positionnement entreprise. Mistral vend des modèles et des offres associées pour les entreprises, et bénéficie donc de la demande pour ces options de déploiement. Les décisions sous-jacentes déterminent où l’IA s’exécute, où résident les informations et dans quelle mesure une entreprise accepte de dépendre de fournisseurs de modèles particuliers.

L’intégration introduit une autre frontière de contrôle, car un agent peut agir à travers plusieurs systèmes au nom d’une personne. Lors du Boomi World Tour Sydney, le CTO Asie-Pacifique et Japon de Boomi a décrit une gouvernance couvrant le routage des requêtes vers des modèles adaptés et le transfert des droits d’accès d’une personne à un agent agissant pour cette personne. Boomi est un fournisseur d’intégration et bénéficie commercialement lorsque la technologie d’intégration gouverne les connexions entre les systèmes d’entreprise. Son exemple montre pourquoi les décisions d’intégration peuvent devenir des décisions d’identité et d’autorisation dès lors que les agents franchissent les frontières entre systèmes.

Ensemble, ces approches placent l’autorité à différents points d’un workflow IA. Salesforce réunit l’orchestration et la gouvernance des agents ; HydraFusion peut faire de la sélection des modèles une décision d’exécution ; Alteryx se positionne autour des informations gouvernées et de la logique métier ; Mistral donne aux entreprises des choix en matière de déploiement et d’infrastructure ; et Boomi relie le routage à l’identité et aux autorisations. Leurs fonctions se rencontrent lorsqu’un même workflow dépend de plusieurs d’entre elles, même si chaque plateforme remplit un rôle différent.

Ces points de rencontre expliquent l’importance architecturale des agent harnesses. Un harness peut centraliser de nombreuses capacités immédiatement autour d’un modèle ou d’un agent, tandis que l’agent peut toujours utiliser une identité gérée ailleurs, des données gouvernées provenant d’une autre plateforme, un routage à l’exécution issu d’un autre système et une infrastructure contrôlée par une équipe ou un fournisseur distinct. L’autorité à l’échelle de l’entreprise dépend donc de la manière dont le harness interagit avec ces contrôles externes.

Le problème apparaît lorsque des contrôles légitimes se rencontrent dans un même workflow

Une fois ces points de contrôle réunis, des choix technologiques individuellement sensés deviennent un enjeu au niveau du système. Une entreprise pourrait utiliser les contrôles de Salesforce, le routage de GitHub et une couche de données gouvernées d’Alteryx tout en exécutant aussi des agents Microsoft, plusieurs modèles commerciaux, des modèles développés en interne et de l’IA intégrée dans des applications qu’elle possède déjà. Chaque sélection peut répondre à un besoin métier ou technique légitime. C’est dans leur fonctionnement combiné que les DSI doivent raisonner sur le contrôle comme sur une architecture.

Dans cet environnement combiné, une plateforme peut choisir quel modèle exécute une tâche, tandis qu’une autre détermine à quelles données d’entreprise la tâche peut accéder et qu’une troisième gouverne l’agent qui exécute l’action résultante. Le workflow peut traverser une application, les données d’entreprise, l’identité, la sécurité et l’infrastructure avant de s’achever. Les agents dépendent par conséquent de données de confiance, de frontières de sécurité, de l’identité, du contexte et de la supervision, ainsi que de moyens contrôlés d’interagir avec les systèmes d’entreprise et d’autres agents.

Ces dépendances peuvent accroître les coûts de changement, car les fournisseurs peuvent contrôler des points importants de routage ou d’intégration tandis que la logique métier, le contexte, les autorisations et l’orchestration deviennent liés à des plateformes individuelles. Remplacer un fournisseur oblige alors l’entreprise à identifier les décisions et dépendances intégrées dans cette plateforme et à les déplacer en toute sécurité. L’architecture de l’autorité affecte donc la portabilité future autant que la gouvernance actuelle.

Les mêmes dépendances techniques traversent aussi les frontières organisationnelles. Les équipes applications, données, sécurité, infrastructure, architecture et IA peuvent chacune détenir une partie légitime du workflow ; une forte responsabilité dans un domaine laisse donc encore non résolue la responsabilité de l’action combinée. Les DSI ont besoin d’un moyen de voir comment ces décisions de domaine interagissent lorsqu’un agent IA agit à travers plusieurs d’entre elles.

Cette vue combinée devient critique lorsque deux contrôles affectent la même décision. Les DSI doivent de plus en plus comprendre comment les systèmes qui orchestrent, routent, observent et gouvernent les agents se rapportent les uns aux autres, et quel système prévaut lorsque leurs décisions entrent en conflit. La convergence fonctionnelle crée ces intersections, tandis que les produits et les équipes qui portent ces fonctions peuvent continuer à se multiplier.

Le schéma ressemble à un problème bien connu de l’IT d’entreprise. Les applications, les intégrations, les données et les processus métier se sont souvent développés indépendamment, produisant une fragmentation que les entreprises ont ensuite dû réduire. Les contrôles de l’IA peuvent créer le même type d’accumulation lorsqu’ils sont adoptés indépendamment, même si chaque contrôle vise à rendre un environnement IA complexe plus facile à gérer. Le risque vient des relations entre les achats et les décisions de conception.

L’autorité peut être fédérée entre plusieurs couches de contrôle

Parce que le problème réside dans ces relations, une autorité cohérente peut s’étendre sur plusieurs produits. Un control plane unique à l’échelle de l’entreprise peut être irréaliste tant que la technologie de l’IA et son marché fournisseurs continuent d’évoluer rapidement, et différentes plateformes peuvent être adaptées à la gouvernance de différents domaines. L’objectif architectural est d’attribuer clairement l’autorité à travers l’ensemble du parc et de définir comment ces attributions interagissent.

Salesforce fournit un exemple d’une telle répartition. Une entreprise peut utiliser l’orchestration de Salesforce tout en plaçant l’autorité ultime pour l’identité d’entreprise, la gouvernance des données ou certaines décisions de routage des modèles ailleurs. Dans la même architecture, une plateforme de données peut rester l’autorité de référence pour l’accès à des informations métier de confiance, tandis que la gouvernance des agents reste assurée par un autre système.

Cette répartition fonctionne lorsque chaque couche a des frontières explicites. Une couche peut faire autorité pour l’identité, une autre pour l’accès aux données et une autre pour le routage des modèles, à condition que l’entreprise sache ce que chaque couche contrôle, de quoi elle dépend et quelle décision prévaut là où les périmètres se chevauchent. Plusieurs couches de contrôle forment alors une architecture délibérée plutôt qu’un assemblage accidentel de produits.

La répartition exacte peut varier selon l’entreprise, car les plateformes d’IA, les modèles de déploiement et les exigences de contrôle restent mouvants. Une architecture universelle prescrite aujourd’hui devrait couvrir des environnements avec des applications, des patrimoines de données, des modèles de sécurité et des choix d’infrastructure différents. Attribuer explicitement l’autorité est donc plus utile que de supposer que chaque décision importante finira par être déplacée vers un seul control plane.

Cartographier l’autorité de contrôle de l’IA avant de décider quoi standardiser

Une fois que l’autorité peut être distribuée de manière délibérée, le point de départ pratique consiste à rendre visible la distribution existante. Un inventaire des produits montre quelles technologies l’entreprise possède, tandis qu’une cartographie architecturale doit saisir ce que ces technologies gouvernent et comment leurs décisions s’articulent. Six dimensions rendent cette cartographie concrète :

Ces six dimensions relient la fonction technique d’un contrôle à sa place dans l’architecture plus large. Le périmètre et l’autorité établissent les décisions qu’une couche peut prendre, la responsabilité relie ces décisions à une équipe comptable de ses actes, et les dépendances montrent ce qu’un changement peut affecter. La télémétrie rend visibles l’activité et les décisions de politique pour la supervision, tandis que la prééminence détermine le résultat lorsque l’autorité se chevauche.

Une fois ces propriétés consignées, la cartographie peut suivre les interactions entre les produits. Si une couche gouverne un agent, qu’une autre fournit son identité et qu’une troisième route sa requête vers un modèle, l’entreprise doit retracer comment la politique et la télémétrie traversent ces frontières. Un conflit portant sur le même agent, la même identité, le même workflow ou les mêmes données a alors une issue prédéterminée, en particulier lorsque des équipes distinctes possèdent les systèmes concernés.

Ces interactions montrent aussi quelles politiques doivent se situer au-dessus des choix de produits individuels. Les règles d’identité et d’autorisations, par exemple, peuvent rester cohérentes entre plateformes tandis que l’orchestration spécifique à l’application reste locale. Les applications peuvent alors coordonner les agents selon leurs propres exigences tout en s’appuyant sur une politique d’identité partagée.

L’accès aux données peut utiliser la même répartition de l’autorité. Une entreprise peut établir une source d’autorité unique pour la politique d’accès aux données tout en permettant à des produits distincts de décider comment le travail est routé entre les modèles. L’autorité sur les données décide si l’information peut être utilisée, et les systèmes de routage décident quel modèle traite le travail dans le cadre de leur périmètre défini.

L’observabilité offre une autre opportunité d’exigences communes entre différents produits. Une entreprise peut exiger une observabilité et une auditabilité cohérentes pour des agents de plusieurs fournisseurs tout en conservant différentes technologies d’orchestration et d’agents. Une visibilité commune permet aux équipes d’architecture et de gouvernance d’inspecter l’activité, les coûts, les erreurs et les décisions de politique au-delà des frontières.

L’ordre de ces décisions compte, car la standardisation est plus facile une fois les points de contrôle visibles. Les DSI peuvent identifier les contrôles à travers les modèles, les agents, les données, l’identité et les applications, puis consigner leur responsabilité, leurs dépendances et leurs interactions avant de choisir quels contrôles doivent être communs et lesquels doivent rester locaux. Les déploiements d’agents en cours peuvent se poursuivre pendant ce travail, à condition que chaque nouveau point de contrôle soit ajouté à la cartographie de l’entreprise en matière d’autorité et de dépendances.

Cette cartographie met aussi en lumière une conséquence des technologies conçues pour gérer des environnements d’agents complexes : chaque technologie de gestion peut elle-même devenir une couche de contrôle supplémentaire. Une fois son périmètre, ses dépendances et sa prééminence explicités, l’entreprise peut décider d’unifier cette fonction ou de la maintenir distribuée. Une plateforme peut détenir une décision de routage, une autre peut détenir la politique d’accès aux données et une autre peut fournir l’identité d’entreprise, avec leur comportement combiné défini avant qu’un agent ne franchisse ces frontières.

Principaux enseignements pour les dirigeants

• Traitez le contrôle de l’IA comme un problème d’architecture : les DSI doivent comprendre comment l’orchestration, le routage des modèles, l’accès aux données, l’identité, les autorisations et l’infrastructure interagissent. Davantage de produits de contrôle peuvent créer une autorité qui se chevauche sur une même action de l’IA.
• Identifiez où l’autorité entre dans la stack IA : harnesses, routeurs d’exécution, plateformes de données, systèmes d’intégration et fournisseurs d’infrastructure peuvent chacun contrôler différentes parties de l’exécution. Les équipes d’architecture peuvent utiliser ces frontières pour établir quel système gouverne chaque décision importante.
• Définissez la prééminence entre contrôles qui se chevauchent : un même workflow peut traverser plusieurs plateformes et plusieurs responsables organisationnels, créant des conflits sur le routage, les autorisations, les données et les actions des agents. Les DSI peuvent résoudre ces intersections en précisant quel contrôle prévaut avant que les agents ne franchissent les frontières entre systèmes.
• Fédérez l’autorité avec des frontières explicites : les entreprises peuvent attribuer l’identité, l’accès aux données, le routage des modèles et la gouvernance des agents à différents systèmes faisant autorité. Des périmètres clairs et des règles de prééminence permettent à plusieurs couches de contrôle de fonctionner comme une architecture délibérée.
• Cartographiez l’autorité avant de standardiser les contrôles de l’IA : les DSI peuvent documenter le périmètre, l’autorité, le responsable, les dépendances, la télémétrie et la prééminence de chaque couche de contrôle, puis retracer les interactions entre produits. Cette cartographie révèle où des politiques communes sont utiles et où un contrôle local peut être maintenu.