AI Act et modèle d’IA à usage général appelé par API

Le règlement européen sur l’IA (Intelligence Artificielle), dit AI Act (règlement (UE) 2024/1689), répartit les obligations entre ceux qui fabriquent les modèles et ceux qui s’en servent. Une organisation qui appelle l’API (Application Programming Interface) d’un fournisseur de modèle pour animer son propre service se croit souvent cliente et rien de plus ; elle est en réalité, selon le cas, fournisseur d’un système d’IA, déployeur, ou les deux. La page traite ce que cela change pour l’architecture et la sécurité, pas l’interprétation juridique, qui reste l’affaire du service juridique.

→ Lire l’explication complète de la marmotte

Fournisseur, déployeur, modèle d’IA à usage général : qui porte quoi

Le texte distingue trois objets, et l’erreur fréquente consiste à les confondre.

Le modèle d’IA à usage général (en anglais GPAI, General-Purpose AI) est ce que vend le fournisseur de l’API. Ses obligations propres (documentation technique, informations destinées aux intégrateurs en aval, politique de respect du droit d’auteur, résumé des contenus d’entraînement, et exigences renforcées pour les modèles présentant un risque systémique) pèsent sur celui qui le met sur le marché. L’organisation cliente n’a pas à les remplir, mais elle a intérêt à récupérer la documentation destinée à l’aval : c’est sa seule source officielle sur les limites connues du modèle.

Le système d’IA est ce que l’organisation construit autour : l’assistant de support, le classeur de tickets, le rédacteur de réponses. Qui le développe et le met en service sous son propre nom en est le fournisseur au sens du règlement, même si le modèle vient d’ailleurs. Les obligations de fournisseur du système s’ajoutent donc à celles de déployeur.

Le déployeur est celui qui utilise le système sous sa propre autorité. Pour un service interne, c’est la même organisation. Le cumul des deux rôles est la situation normale de l’intégration par API, pas l’exception.

Point d’architecture qui en découle : la frontière de responsabilité se situe au code d’intégration. Tout ce qui est fait entre l’appel API et l’utilisateur (instructions système, filtrage, outils exposés au modèle, affichage) relève de l’organisation.

Classement par niveau de risque : l’usage décide, pas le modèle

Le règlement classe les systèmes par usage : pratiques interdites, systèmes à haut risque (les domaines listés en annexe, dont le recrutement, l’accès au crédit ou aux services essentiels, certains usages éducatifs), systèmes soumis à des obligations de transparence, et le reste. Le même appel API, avec le même modèle, peut tomber dans la catégorie minimale pour résumer des tickets et dans la catégorie haut risque pour présélectionner des candidatures.

C’est là que la sécurité intervient : le classement d’un système n’est pas figé à sa conception. Un assistant généraliste ouvert à tous les services finit par recevoir des CV (curriculum vitae), parce que c’est pratique, et bascule sans que personne n’ait rouvert le dossier. Le contrôle efficace n’est pas juridique mais technique : restreindre le périmètre fonctionnel par les instructions, les outils exposés et les populations autorisées, puis surveiller les usages réels dans les journaux. Pour les systèmes à haut risque, le texte exige du fournisseur du système robustesse et cybersécurité, en citant l’empoisonnement de données, les exemples adversariaux et les attaques sur la confidentialité ; côté déployeur, supervision humaine par des personnes compétentes et conservation des journaux générés. Le calendrier et le détail de ces obligations dépendent de normes harmonisées et d’actes d’exécution encore en cours : se référer au texte consolidé et aux lignes directrices de la Commission plutôt qu’à une frise trouvée dans une présentation commerciale.

Transparence, maîtrise et documentation vues depuis la sécurité

Transparence (article 50). Un système qui dialogue avec des personnes doit leur faire savoir qu’elles échangent avec une IA, sauf évidence. Les contenus synthétiques doivent être marqués de façon détectable par machine côté fournisseur du système, et les hypertrucages divulgués par le déployeur. Le piège d’intégration : la mention affichée dans l’interface web disparaît dans le canal courriel ou dans l’export PDF (Portable Document Format). La transparence se teste sur chaque canal de sortie, pas sur la maquette.

Maîtrise de l’IA (article 4). Fournisseurs et déployeurs prennent des mesures pour assurer un niveau suffisant de compréhension chez les personnes qui exploitent ces systèmes. Pour une équipe sécurité, cela se traduit en contenu concret : ce que le modèle ne garantit pas (exactitude, confidentialité des instructions, résistance à l’injection de consignes), et quand un humain doit reprendre la main. Une supervision humaine confiée à quelqu’un qui ignore que le modèle peut inventer une référence n’est pas une supervision, c’est un tampon.

Documentation. Le document qui manque le plus souvent est la carte d’identité du système : quel modèle, quelle version exacte, quel classement, quels contrôles. Les fournisseurs font évoluer les modèles derrière un alias stable ; sans identifiant de version épinglé dans le code et dans le registre, impossible de rattacher un comportement observé au modèle qui l’a produit. Les journaux de requêtes et de réponses, décrits dans la page Observer un LLM (Large Language Model) en production, fournissent la trace ; le registre fournit le contexte.

Une mise en garde qui vaut pour tout le règlement : la conformité ne vaut pas sécurité. Un système parfaitement documenté reste vulnérable à l’injection indirecte de consignes, et aucune case du registre ne remplace un test d’intrusion ciblé.

Exemple : fiche de registre d’un système intégré par API

La fiche suivante tient dans le dépôt du service, à côté du code d’intégration, et se relit à chaque modification des instructions système ou des outils exposés. Le gestionnaire de versions fournit gratuitement l’historique qu’un contrôle demandera.

# registre-ia/assistant-support.yaml : une fiche par système d'IA en service
systeme: assistant-support-clients
roles_organisation: [fournisseur_systeme, deployeur]   # cumul habituel en intégration API
modele:
  fournisseur: exemple-fournisseur
  identifiant: modele-x-2026-06-01    # version épinglée, jamais un alias "latest"
  documentation_aval: docs/modele-x-aval.pdf           # récupérée auprès du fournisseur
classement:
  niveau: transparence                # ni interdit ni haut risque à ce jour
  usages_exclus: [recrutement, credit, decision_sur_personne]
  controle_derive: revue mensuelle des journaux, alerte sur mots-clés ressources humaines
transparence:
  mention_ia: [web, courriel, export_pdf]   # chaque canal de sortie testé
  marquage_contenu_synthetique: metadonnees_export
maitrise:
  formation_operateurs: module-limites-modele-v2
supervision_humaine: validation avant envoi pour les réponses de remboursement
journalisation:
  contenu: requete_reponse_version_modele
  acces: equipe-securite
revue: { derniere: 2026-09-29, responsable: [email protected] }

Le champ usages_exclus n’a de valeur que s’il se traduit en contrôle : filtrage d’entrée, restriction des populations autorisées, alerte sur les journaux. Sinon c’est une déclaration d’intention, et le règlement ne s’intéresse pas aux intentions.

Ce que le règlement ne couvre pas

L’AI Act ne dit rien de la conservation des données par le fournisseur d’API, de la loi applicable à ses serveurs ni du contrat de sous-traitance : ces sujets relèvent du RGPD (Règlement général sur la protection des données) et du droit des contrats, traités dans des pages dédiées. Il ne dit rien non plus de la gestion des clés d’API ni de la facturation incontrôlée. La rubrique Gouvernance rassemble ces cadres, et l’index IA les pages techniques voisines.

🐝 Ce qui arrive si on s’en passe

Sans rôle qualifié ni fiche de registre, la première question d’une personne concernée ou d’une autorité (quel système a produit cette réponse, avec quel modèle, sous quel contrôle humain) reste sans pièce à produire. Le fournisseur du modèle ne détient pas les instructions système ni les outils ajoutés par l’intégrateur, et ne peut donc pas combler le vide. Un système qui a glissé vers un usage à haut risque se découvre alors au moment d’une contestation, sans supervision humaine démontrable ni journaux conservés pour la période en cause.

🦫 Explication de la marmotte 🍫

Beaucoup d’entreprises ne fabriquent pas leur propre intelligence artificielle : elles louent l’accès à un modèle construit par une autre société et le branchent à leurs services, par exemple un assistant qui répond aux clients. Le règlement européen sur l’intelligence artificielle partage les devoirs. La société qui fabrique le modèle doit le documenter et informer ceux qui l’utilisent. L’entreprise qui construit un service autour devient responsable de ce service : elle doit dire aux gens qu’ils parlent à une machine, marquer les contenus fabriqués artificiellement et former les employés qui surveillent l’outil. Le niveau d’exigence dépend de l’usage, pas du modèle. Résumer des messages demande peu de contrôles ; trier des candidatures ou décider d’un prêt en demande beaucoup plus, avec un humain capable de corriger la machine et des traces conservées. Le danger vient du glissement : un outil prévu pour une tâche anodine finit utilisé pour une tâche sensible, sans que personne ne revoie les règles. L’entreprise tient donc une fiche par service, qui indique la version exacte du modèle, les usages interdits et les contrôles en place, et elle vérifie régulièrement dans les journaux que l’usage réel correspond à la fiche. Respecter ce règlement ne protège pas contre les attaques : il faut toujours tester la sécurité à part.

Pages voisines

La citent

AI Act et modèle d'IA à usage général appelé par API

Elle cite

: les deux pages se citent l’une l’autre.