A.10 — Tiers, fournisseurs et clients
Trois contrôles, et c'est le domaine le plus important pour toutes les organisations qui pensent ne pas faire d'IA parce qu'elles l'achètent.
Le domaine A.10 compte trois contrôles : A.10.2 sur la répartition des responsabilités, A.10.3 sur les fournisseurs, A.10.4 sur les clients.
C’est ici que se traitent les fournisseurs d’IA — et non dans le domaine A.8, où on les cherche souvent. La maîtrise des processus fournis par l’extérieur est par ailleurs exigée par le dernier alinéa de la clause 8.1, ce qui donne au sujet un double ancrage : une exigence de clause et des contrôles d’annexe.
Pourquoi c’est le domaine le plus important pour beaucoup d’organisations
Le raisonnement « nous ne développons pas d’IA, donc l’essentiel de l’Annexe A ne nous concerne pas » est en partie juste : une organisation qui ne conçoit ni ne développe de système d’IA peut justifier d’écarter les contrôles de conception et de développement du domaine A.6. Mais le critère est la conception d’un système, pas l’entraînement d’un modèle : intégrer un modèle tiers dans sa propre application, c’est déjà concevoir un système.
Et il conduit souvent à une conclusion fausse. Une organisation qui appelle un modèle en production exploite un système d’IA, quel qu’en soit l’auteur : le déploiement, l’exploitation, la documentation et les journaux (A.6.2.5 à A.6.2.8) restent pertinents, et l’usage relève du domaine A.9. Ce domaine-ci y ajoute ce qui lui est propre : ce qu’elle sait de son fournisseur, ce qu’elle a négocié avec lui, et ce qu’elle a prévu quand il changera quelque chose sans la prévenir.
A.10.3 — Ce qu’il faut savoir d’un fournisseur d’IA
Les questions qui comptent ne sont pas celles d’un questionnaire de sécurité classique. Cinq sont propres à l’IA :
- Vos données servent-elles à entraîner ou améliorer le modèle ? Et si oui, pouvez-vous vous y opposer ?
- Quelle est la durée de conservation des données transmises, et existe-t-il une option de non-conservation ?
- Comment les versions de modèle évoluent-elles ? Pouvez-vous épingler une version, ou les mises à jour vous sont-elles imposées ?
- Quel préavis en cas de dépréciation d’un modèle que vous utilisez en production ?
- Où le traitement a-t-il lieu, et par quels sous-traitants ?
Ces réponses changent vite, et c’est un point à intégrer : une réponse obtenue il y a un an ne vaut plus grand-chose. C’est aussi pourquoi il est risqué de figer ces informations dans un document distribué — elles vieillissent plus vite que le document.
La due diligence complète, configuration par configuration — API, cloud, assistant intégré, modèle à poids ouverts, logiciel métier, données, prestataire —, fait l’objet de la fiche du contrôle A.10.3.
Trois niveaux de mise en œuvre
Minimal crédible. Une répartition écrite des responsabilités avec chaque partie qui intervient dans le cycle de vie du système — fournisseur, partenaire, client (A.10.2). Un questionnaire court à chaque nouveau fournisseur d’IA, couvrant les cinq questions ci-dessus, et une lecture effective de ses conditions d’utilisation. Dans les contrats, une clause rappelant les engagements attendus. La réponse est conservée, datée. Et si vous fournissez vous-même un produit ou un service d’IA, une trace de ce que vos clients en attendent et de la façon dont vous en tenez compte (A.10.4).
Mature. Un processus de sélection formalisé, avec une grille de cotation et des seuils d’acceptation. Des clauses propres à l’IA dans les contrats : transparence sur les mises à jour, préavis de dépréciation, engagement sur la non-utilisation des données pour l’entraînement, niveau de service. Et une réévaluation périodique des fournisseurs en place, puisque leurs politiques évoluent.
À éviter. Négocier indéfiniment chaque clause avant tout usage, ou exiger qu’un fournisseur n’ait aucun sous-traitant — ce qui est irréaliste pour la plupart des services d’infrastructure et bloque simplement la relation.
Ce que le domaine ne demande pas
Aucune certification du fournisseur, aucun audit sur site, aucun modèle de contrat. Il ne demande pas d’exiger l’impossible : un risque identifié, documenté et assumé faute d’alternative est une réponse recevable — un silence ne l’est pas.