Qu’est-ce que le risque lié aux fournisseurs d’IA ?
Le risque lié aux fournisseurs d'IA désigne l'exposition de votre organisation lorsqu'un tiers fournit, héberge, entraîne ou intègre des capacités d'IA à vos produits, processus ou décisions. Ce risque est plus large que celui des fournisseurs informatiques classiques, car un fournisseur d'IA ne se contente pas de traiter vos données ; il peut influencer les résultats sur lesquels vos employés et vos clients s'appuient, avec un comportement qui évolue au fil du temps à mesure que les modèles sont réentraînés et mis à jour.
Dans la plupart des organisations actuelles, les fournisseurs d'IA se répartissent en quatre catégories qui se chevauchent :
- fournisseurs de modèles de fondation telles que OpenAI, Anthropic, Google, Mistral et Cohere, accessibles via API et intégrées dans les outils internes, les agents ou les fonctionnalités destinées aux clients.
- Outils SaaS natifs de l'IA comme les preneurs de notes, les assistants de codage, les copilotes du support client, les outils d'aide à la vente et les plateformes d'analyse où l'IA est le produit.
- IA intégrée dans les logiciels d'entreprise par exemple, la synthèse par IA dans les systèmes CRM, la notation par IA dans les systèmes RH, la révision par IA dans la gestion des contrats ou le triage par IA dans la gestion des services, où l'IA est une nouvelle fonctionnalité dans une relation fournisseur existante.
- Fournisseurs de données d'étiquetage et d'entraînement qui se situent en amont de tout modèle que vous construisez, avec une influence significative sur les biais, la qualité et la base légale de la formation.
Chaque catégorie comporte des risques différents, mais elles partagent un problème commun : le fournisseur contrôle les comportements dont vous êtes responsable. Les organismes de réglementation, les clients et les assureurs exigent de plus en plus que vous prouviez avoir activement évalué et supervisé ces comportements, et non pas simplement signé un contrat et passé à autre chose.
Pourquoi le risque lié aux fournisseurs d'IA est-il devenu un sujet de discussion en conseil d'administration ?
Trois facteurs ont fait passer la supervision des fournisseurs d'IA d'une tâche d'approvisionnement à une préoccupation au niveau du conseil d'administration.
Dépendance concentrée. Une poignée de fournisseurs de modèles de base sous-tendent désormais des milliers de fonctionnalités d'IA présentes dans la quasi-totalité des infrastructures d'entreprise. Les pannes de modèles, les changements de politique, les modifications de prix et les restrictions géographiques se répercutent immédiatement sur vos produits et le parcours client. Il s'agit d'un risque de concentration que le conseil d'administration doit assumer.
Comportement non déterministe. Contrairement à un fournisseur SaaS traditionnel dont le logiciel fonctionne de la même manière aujourd'hui qu'hier, un fournisseur d'IA peut modifier les pondérations du modèle, les messages système, les filtres de sécurité et les données d'entraînement sans préavis. Les résultats validés lors des tests peuvent différer de ceux que votre client verra en production six mois plus tard.
Responsabilité réglementaire. ISO 42001, la Loi de l'UE sur l'IALes organismes de réglementation du secteur (FCA, PRA, NHS Digital, Ofcom) et les autorités de protection des données imposent désormais des obligations explicites au déployeur d'un système d'IA, et non plus seulement au concepteur. Se défausser de sa responsabilité sur son fournisseur n'est plus une excuse. Il faut démontrer avoir choisi un fournisseur compétent et avoir assuré un suivi rigoureux de ses activités.
Conséquence pratique : le risque lié aux fournisseurs d’IA doit figurer dans le registre des risques de l’entreprise, dans le dossier du comité d’audit et dans le Politique d'IA, non pas enfouis sous les procédures d'approvisionnement.
Que dit la norme ISO 42001 sur la surveillance des fournisseurs d'IA ?
ISO 42001 L’annexe A.10, l’un des neuf domaines de contrôle de l’annexe A, aborde directement les relations avec les tiers en matière d’IA. Ce domaine de contrôle couvre les fournisseurs, la répartition des responsabilités entre les organisations et les clients, car dans une chaîne d’approvisionnement en IA, une organisation peut cumuler ces trois rôles : fournisseur pour une partie, déployeur pour une autre et client pour une troisième.
L'annexe A.10 vous demande de :
- Mettez en place un processus d'identification des fournisseurs d'IA et des systèmes d'IA qu'ils vous proposent.
- Répartissez clairement et par écrit les responsabilités entre vous et vos fournisseurs afin d'éviter tout manque de transparence concernant les risques, l'impact et les performances de l'IA.
- Tenez compte des spécificités de l'IA dans la sélection des fournisseurs, la contractualisation et la gestion continue, et non pas seulement des termes génériques relatifs à la sécurité de l'information.
- Assurez-vous que les clients de vos systèmes d'IA disposent des informations nécessaires pour les utiliser de manière responsable.
L’annexe B (normative et non informative) fournit des orientations de mise en œuvre pour chaque contrôle de l’annexe A, notamment le contrôle A.10. Outre l’annexe A.10, la surveillance des fournisseurs d’IA concerne également les contrôles A.2 (politiques relatives à l’IA), A.3 (organisation interne et responsabilités), A.5 (évaluation des impacts des systèmes d’IA), A.7 (données des systèmes d’IA) et A.8 (informations destinées aux parties intéressées). Pour consulter l’ensemble des contrôles, veuillez vous référer à notre [référence manquante]. Contrôles de l'Annexe A référence et le dédié Annexe A.10 Relations avec les tiers et les clients .
Votre Déclaration d'applicabilité Vous devez documenter la manière dont vous appliquez chacun de ces contrôles à votre parc de fournisseurs d'IA, y compris les exclusions et leur justification.
Tout ce dont vous avez besoin pour ISO 42001
Contenu structuré, risques cartographiés et flux de travail intégrés pour vous aider à gouverner l'IA de manière responsable et en toute confiance.
Comment évaluer un fournisseur d'IA ?
L'évaluation préalable des fournisseurs d'IA doit aller au-delà d'un simple questionnaire de sécurité. Il s'agit d'évaluer non seulement la manière dont le fournisseur protège vos données, mais aussi comment il conçoit, exploite, fait évoluer et met hors service le système d'IA dont vous dépendez. Le cadre ci-dessous couvre les neuf domaines que toute évaluation de fournisseur d'IA devrait aborder, avec des exemples de questions à poser et les signaux d'alerte qui devraient vous empêcher de conclure un contrat.
| Région | Questions à poser | drapeau rouge |
|---|---|---|
| Formation aux données | Sur quelles données le modèle a-t-il été entraîné ? Nos données ont-elles été utilisées par défaut pour l’entraînement ? Pouvons-nous nous y opposer par écrit ? Quel est le fondement juridique du traitement des données d’entraînement (consentement, intérêt légitime, licence) ? | Le fournisseur est incapable de vous indiquer les sources des données d'entraînement, utilise par défaut les données client pour l'entraînement sans possibilité de retrait, ou s'appuie sur des données collectées illégalement sans justification légale. |
| Transparence du modèle | Pouvez-vous fournir une fiche technique ou une fiche système ? Quelles sont les limitations et les modes de défaillance connus ? Comment le modèle est-il versionné ? Serons-nous informés des changements de modèle ou des mises à jour majeures ? | Absence de documentation du modèle, changements de modèle silencieux, absence de versionnage, ou refus total de décrire le modèle (boîte noire sans aucune garantie). |
| Dispositif de sécurité | Le fournisseur est-il certifié ISO 27001 et SOC 2 ? Comment les données client sont-elles segmentées ? Quels sont les mécanismes de chiffrement, de gestion des clés et de contrôle d’accès appliqués au trafic d’inférence et aux journaux ? | Absence de certification reconnue, environnement mutualisé sans séparation des tâches, enregistrement permanent des invites et des résultats en clair, absence d'authentification unique (SSO) et d'authentification multifacteur (MFA). |
| Confidentialité et RGPD | Où les données sont-elles traitées et stockées ? Un accord de traitement des données est-il en place ? Des mécanismes de transfert adéquats sont-ils prévus pour les flux internationaux ? Comment les droits des personnes concernées sont-ils gérés pour les données entrantes et sortantes ? | Absence de DPA, transferts hors du Royaume-Uni et de l'EEE sans garanties, absence de mécanisme pour faciliter les demandes d'accès ou d'effacement des données, ou conservation imprécise des messages d'avertissement. |
| Certifications | Êtes-vous certifié ISO 42001 ? Détenez-vous les certifications ISO 27001 et SOC 2 Type II ? Quand ont eu lieu les derniers audits de surveillance ? Pouvons-nous consulter les certificats et les déclarations de périmètre ? | Absence de certification ISO 42001 (ou absence de feuille de route crédible pour l'obtenir), certificats expirés, énoncés de portée excluant le service acheté, ou simple auto-attestation |
| Réponse aux incidents | Comment définissez-vous un incident d'IA ? Quel est votre délai de notification aux clients ? Comment gérez-vous les anomalies de modélisation, les résultats nuisibles, les incidents de biais et les failles de sécurité ? Pouvons-nous consulter un rapport d'incident expurgé ? | Absence de définition d'incident spécifique à l'IA, délais de notification supérieurs à 72 heures, absence de rapport post-incident, ou incapacité à démontrer la gestion complète d'un incident antérieur. |
| Gestion du changement | Comment gérez-vous les modifications apportées aux poids des modèles, aux invites système, aux filtres de sécurité et aux garde-fous ? Sommes-nous avertis ? Pouvons-nous conserver une version fixe ? Comment les modifications sont-elles testées avant leur déploiement ? | Mises à jour continues sans préavis, sans option de verrouillage de version, sans tests préalables sur le trafic d'entreprise, ni mécanisme de retour en arrière |
| Sous-processeurs | Qui sont vos sous-traitants, notamment pour l'hébergement, l'hébergement des modèles, l'évaluation et l'étiquetage des données ? Comment sont-ils agréés et audités ? Sommes-nous informés des changements ? | Liste incomplète des sous-traitants, utilisation opaque des sous-sous-traitants, absence de droit de s'opposer à de nouveaux sous-traitants ou utilisation de sous-traitants dans des juridictions défavorables |
| Plan de sortie | Comment récupérer nos données ? Combien de temps sont-elles conservées après l’arrêt du programme ? Les invites, les résultats et les données de paramétrage sont-ils entièrement supprimés ? Existe-t-il un format portable pour les données de configuration ou d’évaluation personnalisées ? | Aucune sortie définie, une rétention mesurée en années plutôt qu'en jours, aucun format d'exportation, ni verrouillage via des données d'évaluation propriétaires |
Attribuez une note à chaque domaine, pondérez-la en fonction du risque lié au cas d'utilisation de l'IA, et associez le résultat à la fiche fournisseur dans votre registre. L'objectif est de prendre une décision justifiée, et non d'obtenir une note parfaite.
Quelles clauses contractuelles devez-vous exiger des fournisseurs d'IA ?
Les contrats avec les fournisseurs d'IA doivent aller au-delà des conditions SaaS standard. Les plans de sécurité et les accords de traitement des données gèrent la couche de données, mais le comportement, l'évolution et la responsabilité de l'IA nécessitent des clauses spécifiques. La liste ci-dessous représente le minimum attendu dans tout contrat important avec un fournisseur d'IA :
- Droit à l'audit. Un droit contractuel d'auditer le fournisseur ou de s'appuyer sur des rapports d'assurance indépendants (certificat ISO 42001, SOC 2 Type II, résumés de tests d'intrusion) à une cadence définie, couvrant le système d'IA spécifique que vous achetez.
- Avis de changement de modèle. Avis écrit des modifications importantes apportées aux poids des modèles, aux invites du système, aux filtres de sécurité ou aux garde-fous, avec un délai de préavis défini (généralement de 30 à 90 jours pour les cas d'utilisation en entreprise) et une option d'épinglage de version pour les charges de travail réglementées.
- Restrictions d'utilisation des données. Interdiction explicite d'utiliser les données d'entrée, de sortie, de réglage fin ou les métadonnées du client pour entraîner les modèles généraux du fournisseur sans consentement écrit, avec des engagements de ségrégation des données.
- Engagements en matière de précision des résultats. Les déclarations concernant l'utilisation prévue, les limitations connues et toutes les normes de précision ou de sécurité publiées par le fournisseur, avec des recours si le fournisseur supprime des fonctionnalités documentées.
- Notification d'incident. Un SLA de notification d'incidents d'IA défini (visant 24 à 72 heures selon la gravité) couvrant les violations de sécurité, les incidents de biais, les événements de sortie nuisibles et la dégradation prolongée du service.
- Propriété intellectuelle. Attribution claire des droits de propriété intellectuelle sur les entrées, les sorties et toutes les œuvres dérivées, avec indemnisation contre les réclamations de tiers en matière de propriété intellectuelle découlant des résultats du modèle.
- Indemnisation et responsabilité. Des indemnités sur mesure pour les violations de la protection des données, les atteintes à la propriété intellectuelle dans les résultats des modèles et les amendes réglementaires lorsque la conduite du fournisseur en est la cause directe, avec des plafonds de responsabilité proportionnels au risque du cas d'utilisation de l'IA.
- Sortie et retour des données. Processus de sortie défini avec des formats d'exportation garantis, des certificats de suppression et une période de conservation maximale des données résiduelles après la résiliation (généralement de 30 à 90 jours).
- Avis au sous-traitant. Une liste des sous-traitants actuellement inscrits au contrat, un préavis écrit de toute modification et un droit d'opposition fondé sur des risques documentés.
- Maintien de la certification. Un engagement à maintenir les certifications déclarées (ISO 42001, ISO 27001, SOC 2) pendant toute la durée du contrat, avec notification en cas d'expiration d'une certification ou de changement de portée.
Ces clauses doivent être adaptées au niveau de risque. Un fournisseur de modèle de base intégré à un processus décisionnel orienté client justifie l'utilisation de l'ensemble des clauses ; un outil de productivité interne à faible risque peut se contenter d'un ensemble allégé avec des renouvellements contrôlés.
Comment surveiller les fournisseurs d'IA après la signature du contrat ?
Une vérification préalable rigoureuse est nécessaire, mais insuffisante. Les fournisseurs d'IA évoluent, tout comme votre utilisation de leurs services. Un suivi continu doit donc combiner des réévaluations planifiées et des alertes déclenchées par des événements.
Activités planifiées qui devraient figurer dans votre calendrier de supervision des fournisseurs d'IA :
- Vérification préalable annuelle pour les fournisseurs à haut risque, bisannuelle pour les fournisseurs à risque moyen, couvrant les neuf mêmes domaines que l'intégration, avec un examen complémentaire.
- Examen trimestriel des journaux de modifications des modèles de fournisseurs, des sous-traitants et des politiques par rapport à votre référence établie
- Examen annuel des certifications ISO 42001, ISO 27001 et SOC 2 du fournisseur et des déclarations de portée
- Examen des rapports d'incidents et de transparence publiés par les fournisseurs (lorsqu'ils sont disponibles) à chaque cycle de revue de direction
- Réexamen de la section fournisseur de votre Déclaration d'applicabilité chaque fois que le périmètre du fournisseur change de manière significative
Déclencheurs événementiels qui devraient entraîner une réévaluation immédiate :
- Un fournisseur vous informe d'un changement de modèle de matériel, d'un changement de sous-traitant ou d'un changement de politique.
- Le fournisseur est victime d'un incident de sécurité, de sûreté ou de partialité rendu public.
- Le fournisseur perd, modifie la portée ou omet de renouveler une certification sur laquelle il s'appuie.
- Vous modifiez le cas d'utilisation de l'IA (par exemple, en intégrant un outil interne dans un flux de travail orienté client ou dans un contexte à haut risque au sens de la réglementation européenne sur l'IA).
- Une nouvelle réglementation, des directives sectorielles ou une mesure d'exécution modifient sensiblement vos obligations en tant que déployeur.
Chaque activité de suivi doit produire des preuves liées au dossier fournisseur, aux contrôles pertinents de l'annexe A et aux entrées du registre des risques liés à l'IA auxquelles le fournisseur contribue. C'est ainsi que l'on transforme le contrôle des fournisseurs, d'une simple formalité d'approvisionnement, en une gouvernance auditable.
Démarrez facilement avec une démonstration de produit personnelle
L'un de nos spécialistes de l'intégration vous guidera à travers notre plateforme pour vous aider à démarrer en toute confiance.
Comment la loi européenne sur l'IA modifie-t-elle les obligations des fournisseurs d'IA ?
Le Loi de l'UE sur l'IA Cela crée un ensemble structuré d'obligations qui s'appliquent à l'ensemble de la chaîne d'approvisionnement en IA. Si vous déployez un système d'IA à haut risque ou si vous êtes un fournisseur qui intègre un modèle tiers, vos choix de fournisseurs deviennent des choix de conformité.
Principales implications en aval pour la surveillance des fournisseurs d'IA :
- Les obligations des fournisseurs s'appliquent également à vos prestataires. Les fournisseurs de modèles d'IA à usage général (GPAI) ont leurs propres obligations en matière de documentation technique, de résumés des données d'entraînement, de politique de droits d'auteur et (pour les modèles de risque systémique) de tests adverses, de signalement des incidents et de cybersécurité. Vous devriez demander aux fournisseurs de modèles de base de démontrer comment ils respectent ces obligations.
- Les obligations du déployeur vous concernent. L’utilisation d’un système d’IA à haut risque implique des obligations de supervision humaine, de conservation des journaux d’activité, de surveillance, de signalement des incidents et, dans de nombreux cas, d’évaluation d’impact sur les droits fondamentaux. Le respect de ces obligations nécessite des informations de la part du fournisseur, lesquelles doivent faire l’objet d’un contrat.
- L'information circule en cascade. Les fournisseurs doivent remettre aux utilisateurs la documentation technique et les instructions d'utilisation nécessaires pour leur permettre de remplir leurs obligations. Il vous appartient de vérifier que cette documentation existe bien pour tout composant d'IA à haut risque que vous vous procurez.
- Risque de modification important. Si vous personnalisez, adaptez ou réutilisez un modèle standard au point d'y apporter des modifications substantielles, vous pouvez devenir un fournisseur à part entière, avec les obligations d'évaluation de la conformité qui en découlent. Les contrats fournisseurs doivent clairement indiquer les modifications autorisées et interdites, ainsi que les garanties qui y sont associées.
- Pratiques interdites. Certaines utilisations de l'IA (évaluation sociale, extraction non ciblée de données faciales, déduction des émotions au travail et dans l'éducation, etc.) sont interdites. Votre politique en matière d'IA et l'évaluation de vos fournisseurs doivent vérifier la conformité des cas d'utilisation avec ces interdictions avant la conclusion du contrat, et non après.
La norme ISO 42001 et la loi européenne sur l'intelligence artificielle sont complémentaires. La norme fournit la structure du système de management ; la loi définit les obligations légales que cette structure doit respecter. Un processus de supervision des fournisseurs bien mené est bénéfique aux deux.
Comment ISMS.online gère la gestion des risques liés aux fournisseurs d'IA
ISMS.en ligne La plateforme offre une solution intégrée pour la supervision des fournisseurs d'IA au sein de votre système de gestion de l'IA. Au lieu de disperser les données fournisseurs dans des documents d'approvisionnement, des questionnaires de sécurité, des dossiers juridiques et des outils de suivi de la conformité, elle consolide le cycle de vie dans un espace de travail unique et connecté.
- Registre des fournisseurs avec champs spécifiques à l'IA. Chaque fournisseur d'IA possède une fiche avec le type de fournisseur (modèle de base, SaaS d'IA, IA embarquée, étiquetage des données), les cas d'utilisation, le niveau de risque, les certifications, les sous-traitants et les liens de contrôle pertinents de l'annexe A.
- Questionnaires de diligence raisonnable en matière d’IA. Modèles préétablis couvrant les neuf domaines d'évaluation, avec notation, validation et preuves archivées, joints au dossier du fournisseur.
- Suivi des contrats et des clauses. Les clauses clés relatives à l'IA (droit d'audit, avis de modification du modèle, utilisation des données, SLA en cas d'incident, sortie) sont suivies en tant que champs dans la fiche fournisseur, ce qui vous permet de rendre compte de votre parc d'IA en un coup d'œil.
- Flux de travail de surveillance continue. Réévaluations planifiées, alertes d'expiration de certificats, examens du journal des modifications et réévaluations déclenchées par des événements, le tout lié à la fiche fournisseur et au registre des risques liés à l'IA.
- Évaluations des risques et des impacts liés à l'IA. Les entrées des fournisseurs se connectent directement aux entrées du registre des risques liés à l'IA (clause 6.1.2) et aux évaluations d'impact des systèmes d'IA (clause 6.1.4), de sorte que le risque fournisseur est traité comme faisant partie du tableau global des risques liés à l'IA, et non comme un univers parallèle.
- Preuves d'audit au niveau du contrôle. Chaque évaluation, examen et réévaluation produit des éléments de preuve liés au contrôle spécifique de l'annexe A qu'ils soutiennent, prêts pour les audits de surveillance.
Résultat pratique : lorsqu'un auditeur vous demande comment vous respectez l'annexe A.10 pour votre chaîne d'approvisionnement en IA, la réponse est une analyse approfondie unique — fournisseur, évaluation, contrat, historique de surveillance, preuves — et non une semaine de captures d'écran et de feuilles de calcul.
Pourquoi choisir ISMS.online pour la gestion des risques liés aux fournisseurs d'IA ?
ISMS.en ligne Elle est conçue pour une gouvernance de l'IA de bout en bout ; la supervision des fournisseurs est donc une composante essentielle de la plateforme et non une simple option ajoutée après coup. Voici ce que vous obtenez :
- Registre des fournisseurs spécifiques à l'IA. Des champs conçus spécifiquement pour le type de fournisseur d'IA, les cas d'utilisation, le niveau de risque, les certifications, les sous-traitants et les versions du modèle, et non une liste de fournisseurs générique réutilisée à partir d'un outil de gestion des actifs informatiques.
- Modèles de vérification préalable par IA préconfigurés. Les questionnaires sont alignés sur l'annexe A.10 de la norme ISO 42001, les lignes directrices de l'annexe B et les obligations en aval de la loi européenne sur l'IA, afin que les équipes partent d'une base de référence conforme aux normes plutôt que de rédiger des questions à partir de zéro.
- Intégré au registre des risques liés à l'IA. Les risques liés aux fournisseurs sont directement liés aux risques liés à l'IA (article 6.1.2) et aux évaluations d'impact des systèmes d'IA (article 6.1.4), avec des cycles de notation, de traitement et d'examen réunis en un seul endroit.
- Live Déclaration d'applicabilité. La section relative aux fournisseurs de votre déclaration d'accord reste à jour au fur et à mesure que les fournisseurs, les contrôles et les justifications changent, au lieu d'être figée dans un document Word.
- Surveillance continue intégrée. Des réévaluations planifiées, des alertes d'expiration de certificats et des examens déclenchés par des événements permettent de maintenir une surveillance active des fournisseurs tout au long du cycle de vie du contrat.
- Réutilisation multi-normes. Les enregistrements des fournisseurs sont partagés entre la norme ISO 42001 et les contrôles fournisseurs de vos systèmes de management ISO existants ; vous n’avez donc qu’un seul programme fournisseurs à gérer. Pour plus d’informations sur les points communs, consultez la section correspondante. ISO 42001 contre ISO 27001.
- Méthode de résultats assurés. Une approche de mise en œuvre éprouvée, un soutien à l'adoption et une assistance en direct permettent une supervision des fournisseurs d'IA opérationnelle en quelques semaines, et non en plusieurs trimestres.
Que vous partiez de zéro ou que vous mettiez un programme de gestion des risques tiers existant aux normes spécifiques à l'IA, ISMS.en ligne vous fournit les outils nécessaires pour gérer les risques liés aux fournisseurs d'IA conformément à la norme ISO 42001 et à la réglementation européenne sur l'IA. Pour plus d'informations sur la mise en œuvre, consultez notre guide de mise en œuvre, ou la tête retour au hub ISO 42001.
Prêts à voir la plateforme en action ? Demander demo.
FAQ
Qu’est-ce que la gestion des risques liés aux fournisseurs d’IA ?
La gestion des risques liés aux fournisseurs d'IA consiste à identifier, évaluer, contractualiser et superviser les tiers qui fournissent des capacités d'IA à votre organisation. Elle englobe les fournisseurs de modèles de base, les outils SaaS natifs d'IA, les fonctionnalités d'IA intégrées aux logiciels d'entreprise, ainsi que les fournisseurs de données d'étiquetage ou d'entraînement. Elle étend la gestion classique des risques liés aux tiers en y intégrant des considérations spécifiques à l'IA, telles que les données d'entraînement, la transparence des modèles, les comportements non déterministes et la gestion des modifications des pondérations des modèles et des alertes système.
La norme ISO 42001 exige-t-elle une évaluation des fournisseurs d'IA ?
Oui. L’annexe A.10 de la norme ISO 42001 traite directement des relations avec les tiers et les clients, exigeant des organismes qu’ils identifient leurs fournisseurs d’IA, répartissent les responsabilités et gèrent les aspects spécifiques à l’IA tout au long du cycle de vie du fournisseur. L’annexe B (normative) fournit des recommandations de mise en œuvre. ISMS.en ligne La déclaration d'applicabilité doit documenter la manière dont vous appliquez ces contrôles à votre parc de fournisseurs d'IA, en justifiant toute exclusion.
Quels sont les principaux signaux d'alarme lors de l'évaluation d'un fournisseur d'IA ?
Les principaux obstacles à la conclusion d'un contrat sont les suivants : formation par défaut sur les données clients sans possibilité de retrait, absence de documentation ou de contrôle de version des modèles, absence de certifications reconnues (ISO 42001, ISO 27001, SOC 2) ou certifications expirées, absence de SLA spécifique aux incidents d'IA (réponse ou notification), modifications silencieuses des modèles sans préavis, accords opaques avec les sous-traitants et absence de procédure de sortie définie. Chacun de ces points doit déclencher une évaluation des risques par la direction avant la signature du contrat.
À quelle fréquence devrions-nous réévaluer les fournisseurs d'IA ?
Une réévaluation annuelle constitue une base raisonnable pour les fournisseurs d'IA à haut risque, une évaluation bisannuelle pour les fournisseurs à risque moyen et un suivi allégé pour ceux à faible risque. En plus de ce calendrier, des événements déclencheurs – modification importante du modèle ou d'un sous-processeur, incident rendu public, perte de certification, changement de cas d'utilisation, nouvelle réglementation – doivent entraîner une réévaluation immédiate, indépendamment du calendrier.
La loi européenne sur l'IA a-t-elle une incidence sur nos contrats avec les fournisseurs de services d'IA ?
Oui. La loi européenne sur l'IA impose des obligations aux fournisseurs, aux déployeurs et aux importateurs de systèmes d'IA, et l'information doit circuler tout au long de la chaîne pour que ces obligations soient respectées. Les contrats avec les fournisseurs de modèles de base et les fournisseurs d'IA en aval doivent exiger la documentation technique, les instructions d'utilisation, les informations de transparence et les notifications d'incidents nécessaires pour vous permettre de remplir vos obligations de déployeur ou de fournisseur. Le paramétrage ou la modification substantielle d'un modèle générique peut également transformer un déployeur en fournisseur, ce qui doit être prévu contractuellement.
Un fournisseur certifié ISO 27001 est-il suffisant pour les cas d'utilisation de l'IA ?
Non. La norme ISO 27001 couvre la gestion de la sécurité de l'information et constitue une base solide, mais elle ne traite pas des risques spécifiques à l'IA, tels que la provenance des données d'entraînement, la transparence des modèles, l'impact sur les personnes concernées, les biais ou la gestion des modifications des modèles. Pour les cas d'utilisation importants de l'IA, il convient également de rechercher la norme ISO 42001 (ou une feuille de route crédible pour y parvenir), la certification SOC 2 Type II couvrant le service d'IA concerné, et des clauses contractuelles explicites relatives à l'IA qui vont au-delà des simples exigences en matière de sécurité de l'information.
ISMS.online peut-il gérer les risques liés aux fournisseurs d'IA en plus des risques généraux liés aux fournisseurs ?
Oui. ISMS.en ligne Cette plateforme multi-normes permet aux fournisseurs d'IA d'être inscrits au même registre que vos autres prestataires, avec des champs spécifiques à l'IA, des modèles de vérification préalable et des flux de travail de suivi intégrés. Ainsi, un seul programme fournisseur, un seul ensemble de preuves et une seule piste d'audit couvrent l'annexe A.10 de la norme ISO 42001 et les contrôles fournisseurs de vos systèmes de gestion existants, le tout dans une vue unique.
