Les organisations qui s’appuient sur un modèle de langage hébergé reçoivent de l’éditeur un modèle entraîné à la sécurité et une plateforme, et restent responsables de l’application qui l’entoure. Microsoft, la Cloud Security Alliance et l’AI Act européen répartissent chacun le travail entre le fournisseur du modèle et la partie qui le déploie, avec un vocabulaire et une portée juridique différents. Cette note compare les trois et propose une répartition pratique pour le cas courant d’un modèle consommé via une API. Elle complète How Anthropic red-teams Claude, and what it leaves to you, qui examine le versant fournisseur à travers un cas publié.
Contexte : le modèle cloud étendu à l’IA
Le modèle de responsabilité partagée du cloud attribue chaque contrôle au fournisseur ou au client selon le type de service : logiciel en tant que service (SaaS), plateforme en tant que service (PaaS) ou infrastructure en tant que service (IaaS). Microsoft et la Cloud Security Alliance (CSA) étendent tous deux cette idée à l’IA générative. Cette extension modifie le vocabulaire plus que la logique : plus un client construit bas dans la pile, plus il possède de contrôles.
Les modèles des éditeurs
Microsoft : plateforme, application et usage
Le modèle de responsabilité partagée de Microsoft pour l’IA décrit une application intégrant l’IA en trois couches : la plateforme IA, l’application IA et l’usage de l’IA. La couche plateforme fournit le modèle via des API et comprend un système de sécurité qui filtre les entrées et sorties nuisibles. La couche application est l’interface utilisée par l’utilisateur, avec ancrage, plugins et connecteurs de données, et elle requiert son propre système de sécurité applicatif. La couche usage porte sur la manière dont les personnes utilisent la capacité, et Microsoft renvoie aux contrôles d’identité et d’accès, aux politiques d’utilisation acceptable et à la formation des utilisateurs. [1]
La part de chaque couche qui revient au client dépend du type de déploiement. La page indique que les responsabilités varient entre SaaS, PaaS et IaaS, et recommande de commencer par des offres SaaS comme Copilot, de ne passer à des services PaaS comme Azure OpenAI Service que lorsque les capacités prêtes à l’emploi ne conviennent pas, et de réserver la construction de modèles sur mesure aux organisations disposant d’une expertise approfondie. La page ajoute que ces indications sont illustratives, s’entendent au sens de la gouvernance et ne modifient aucun contrat conclu avec Microsoft. [1]
Microsoft : l’extension aux agents
Une seconde page de Microsoft traite des agents, qu’elle distingue d’un simple modèle parce qu’un agent agit sans qu’un humain approuve chaque étape, planifie et itère, conserve une mémoire, dispose de sa propre identité et peut se combiner avec d’autres agents. Elle ajoute trois couches : l’orchestration de l’agent, les outils et actions, et la mémoire et l’état. Dans sa matrice de responsabilités, le client conserve, dans le cas PaaS, les instructions et le périmètre de l’agent, les permissions par outil et l’approbation humaine des actions à fort impact, tandis que l’environnement d’exécution et la plateforme d’orchestration relèvent de Microsoft. [2]
La page énumère les responsabilités que le client conserve toujours : les données, l’identité et le moindre privilège, l’autorisation des actions, la supervision humaine, ainsi que l’usage acceptable et la gouvernance. Elle précise aussi que l’autonomie ne réduit jamais la responsabilité. [2]
Cloud Security Alliance : une proposition de 2023
Dans un billet daté du 28 juillet 2023, un fellow de la CSA a proposé un modèle à trois parties : le fournisseur du service d’IA, l’utilisateur du service qui construit une application, et l’entreprise ou l’utilisateur final de cette application. Selon cette proposition, un fournisseur IaaS apporte l’infrastructure et les modèles de fondation, tandis que l’utilisateur prend en charge l’entraînement, la validation des données, le filtrage des prompts et la sécurité applicative ; dans le cas PaaS, l’utilisateur fournit le contexte et la sécurité applicative ; dans le cas SaaS, il gère l’ancrage, le filtrage des prompts et la protection de la propriété intellectuelle. Le billet présente ce modèle comme une proposition de répartition des tâches, et non comme un standard. [3]
Le droit : l’AI Act européen répartit les obligations selon le rôle
L’AI Act attribue les obligations selon le rôle. D’après la FAQ des lignes directrices de la Commission européenne, le fournisseur d’un modèle d’IA à usage général est l’entité qui développe le modèle, ou le fait développer, et le met sur le marché sous son propre nom. Ses obligations comprennent une documentation technique, une documentation destinée aux développeurs en aval sur les capacités et les limites, une politique de respect du droit d’auteur et un résumé public des contenus d’entraînement. Ces obligations s’appliquent depuis le 2 août 2025. Les modèles présumés présenter un risque systémique, à partir de 10^25 opérations en virgule flottante de calcul d’entraînement, sont soumis à des obligations supplémentaires, dont des tests adversariaux et des garanties de cybersécurité. [4]
La même FAQ fixe au 2 août 2026 la date à partir de laquelle les mesures d’exécution, amendes comprises, s’appliquent à ces fournisseurs, et au 2 août 2027 l’échéance pour les modèles mis sur le marché avant le 2 août 2025. Elle précise également qu’un développeur en aval qui modifie un modèle ne devient fournisseur que dans des circonstances exceptionnelles, par exemple s’il utilise plus d’un tiers du calcul d’entraînement d’origine : la plupart des ajustements fins ne transfèrent donc pas le rôle de fournisseur. [4]
Les déployeurs, c’est-à-dire les organisations qui utilisent des systèmes d’IA, portent un ensemble distinct d’obligations. Une analyse d’un cabinet d’avocats datée du 24 juillet 2026 cite, parmi les obligations des déployeurs à compter du 2 août 2026, la signalisation des hypertrucages et l’information des personnes en cas de reconnaissance des émotions et de catégorisation biométrique. Pour les systèmes à haut risque, elle mentionne une supervision humaine compétente, l’information des personnes sur le recours à l’IA et la consultation des travailleurs. [6] La page de calendrier de la Commission ajoute que les déployeurs doivent assurer la supervision humaine et la surveillance, et signaler les incidents graves une fois les systèmes mis sur le marché. [5]
Le report lié au Digital Omnibus
Les échéances relatives au haut risque ont été déplacées. La page de calendrier de la Commission indique le 2 décembre 2027 pour les systèmes à haut risque dans des domaines sensibles comme la biométrie, l’emploi et l’application de la loi, et le 2 août 2028 pour les systèmes à haut risque intégrés dans des produits réglementés, en se référant au Digital Omnibus sur l’IA, dont elle indique l’entrée en vigueur en juillet 2026. [5] L’analyse de Norton Rose Fulbright rapporte les mêmes deux dates et indique que l’Omnibus a été publié au Journal officiel de l’UE. [6] Deux sources indépendantes s’accordent donc sur le fait que le report a été adopté, et non simplement proposé. Les obligations des fournisseurs de modèles à usage général et les obligations de transparence mentionnées plus haut ne sont pas concernées par ces deux dates.
Répartir le travail lorsqu’un modèle est utilisé via une API
Pour le cas PaaS, dans lequel une application appelle un modèle hébergé, les sources étayent la répartition suivante. Les lignes issues de Microsoft suivent les couches plateforme et application décrites ci-dessus ; les lignes relatives aux tests des risques de pointe, à la documentation du système et aux canaux de divulgation reflètent les obligations des fournisseurs dans les lignes directrices européennes et les pratiques que publient les éditeurs de modèles. Le tableau est une synthèse réalisée par FireAI, et non un texte tiré de l’une des sources.
| Domaine | Côté fournisseur | Votre côté |
|---|---|---|
| Comportement du modèle | Entraînement à la sécurité et alignement du modèle | Prompt système et garde-fous applicatifs |
| Tests de risque | Tests des risques de pointe sur le modèle lui-même | Tests de votre application, y compris ses prompts, ses données et ses outils |
| Plateforme | Sécurité de la plateforme et filtres de base sur les entrées et sorties | Contrôles de sécurité applicatifs sur le contenu, les plugins et les connecteurs |
| Documentation | Fiche système et documentation pour les développeurs en aval | La lire, et consigner le modèle et la version déployés |
| Données et outils | Rien au-delà du contrat d’API | Données RAG, outils, agents et leurs permissions |
| Sorties | Renvoie du texte généré | Traitement des sorties en aval : validation, échappement, approbation humaine |
| Exploitation | Canal de divulgation des vulnérabilités du modèle | Journalisation, surveillance et réponse aux incidents pour l’application |
| Personnes | Conditions de la politique d’utilisation | Votre propre politique d’utilisation et la formation des utilisateurs |
Deux domaines sont partagés au sens strict. Le premier est l’injection de prompt : le fournisseur entraîne le modèle à résister aux instructions injectées, et le déployeur limite ce qu’une instruction injectée peut accomplir au moyen des permissions des outils et de l’accès aux données. La page de Microsoft consacrée aux agents décrit la même répartition, en demandant aux clients de traiter le contenu récupéré, les sorties d’outils et les messages d’autres agents comme non fiables, et de soumettre les actions à fort impact à un contrôle. [2] Le second est la confidentialité des données : le fournisseur fixe les conditions de conservation et d’entraînement, et le déployeur décide quelles données entrent dans un prompt ou un index de recherche en premier lieu.
Recommandations
- Identifier d’abord le type de déploiement (SaaS, PaaS ou auto-hébergé) et consigner les lignes de la répartition ci-dessus qui reviennent à l’organisation.
- Tester directement le versant déployeur : le prompt système, les données récupérées, les permissions des outils et le traitement des sorties. Les tests du modèle réalisés par l’éditeur ne les couvrent pas.
- Avant d’adopter un modèle, lire la fiche système du fournisseur et ses conditions de conservation et d’entraînement des données, et repérer son canal de divulgation des vulnérabilités.
- Limiter ce qu’une instruction injectée peut faire : outils au moindre privilège, accès aux données circonscrit et approbation humaine pour les actions irréversibles.
- Décider quelles données peuvent entrer dans les prompts, et conserver des journaux suffisants pour reconstituer un incident.
- Pour des ressources pédagogiques sur les cadres de référence et le red teaming, voir le cours de FireAI University sur les cadres de sécurité de l’IA et le red teaming.
Pertinence pour FireAI
Une app ou un agent local qui appelle l’API d’un modèle est une app du Mac, et ses destinations sont visibles par FireAI. Activité liste les apps qui se sont connectées, et les Règles permettent d’autoriser ou de bloquer une app ou une destination précise. C’est un contrôle du côté du déployeur, sur un seul Mac. FireAI n’inspecte pas les prompts, ne juge pas les sorties des modèles, ne détecte pas l’injection de prompt et n’évalue pas si un fournisseur respecte ses obligations légales.
Limites
- Les pages de Microsoft sont des recommandations d’éditeur pour les produits Azure ; elles se présentent comme illustratives et ne modifient pas les conditions contractuelles. Le texte de la CSA est une proposition de 2023.
- Cette note ne constitue pas un avis juridique. Savoir si une organisation est fournisseur, déployeur ou opérateur à haut risque au sens de l’AI Act dépend de faits que cette note n’évalue pas, et les autorités nationales peuvent interpréter le règlement différemment.
- Les dates du Digital Omnibus proviennent de la page de calendrier de la Commission et d’une analyse de cabinet d’avocats. Le texte du règlement lui-même n’a pas été examiné pour cette note.
- Le tableau sur l’API est une synthèse, et certains fournisseurs placent certaines lignes différemment dans leurs conditions.
Le rôle de FireAI et de HisnLabs
Votre part de la responsabilité inclut ce qui quitte le Mac. FireAI vous le montre et vous laisse décider.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction FireAI Pilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.