La réponse rapide : évaluer un fournisseur d'IA signifie demander des preuves au lieu des promesses. Avant de signer, vous voulez quatre choses par écrit : des résultats de tests indépendants que vous pouvez vérifier, des termes clairs sur la façon dont vos données sont utilisées et conservées, un engagement à surveiller le système après le déploiement, et un moyen de vérifier chaque affirmation de sécurité du fournisseur sans vous fier à sa parole. Le reste de ce guide transforme cela en un processus opérationnel, une liste de questions que vous pouvez envoyer aux fournisseurs, et les termes contractuels qui rendent les réponses contraignantes.

La diligence raisonnable en matière d'IA diffère d'un audit logiciel ordinaire parce qu'un système d'IA peut produire une réponse confiante mais inexacte, être dévié de ses propres règles, fuir des données, ou changer de comportement après une mise à jour de modèle que le fournisseur déploie un mardi. Vous identifiez ces risques en testant le comportement, et vous les contrôlez avec des termes contractuels qui spécifient ce qui se passe quand le comportement s'écarte de ce prévu.

Pourquoi la diligence raisonnable envers les fournisseurs d'IA est désormais une attente formelle

L'achat d'IA était autrefois traité comme un achat de logiciel avec un paragraphe supplémentaire sur les données. Les acheteurs publics et les législateurs de part et d'autre de l'Atlantique ont changé cela.

Les acheteurs fédéraux américains : directive OMB M-25-22

Le 3 avril 2025, le Bureau de la Gestion et du Budget de la Maison-Blanche a émis le mémorandum M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government. Il s'applique aux contrats attribués à la suite d'appels d'offres lancés 180 jours ou plus après le mémo, et aux options de renouvellement exercées après cette date. La section 4(d) indique que les agences « doivent inclure des termes qui traitent » une liste de sujets dans les contrats pour les systèmes et services d'IA. Parmi eux :

• Suivi des performances en continu. Les contrats doivent permettre à l'agence de surveiller et d'évaluer régulièrement les performances, les risques et l'efficacité du système, avec des révisions trimestrielles ou biennales données comme exemples.
• Tests indépendants. Les agences doivent tester avec leurs propres ensembles de données qui « ne doivent pas être accessibles au fournisseur », les fournisseurs doivent fournir « l'accès et le temps nécessaires aux agences pour effectuer une évaluation indépendante », et les résultats des tests doivent être « suffisamment détaillés pour que les tests puissent être indépendamment vérifiés ou reproduits, si possible ».
• Protection contre le verrouillage. Les termes peuvent inclure le transfert de connaissances, la « portabilité des données et du modèle », et la transparence sur les licences et les tarifs.
• Limites sur l'entraînement avec vos données. La section 3(e) exige que les contrats « interdisent définitivement l'utilisation des données d'entrée non publiques et des résultats générés par l'agence » pour former davantage d'IA disponibles publiquement ou commercialement, sauf si l'agence en donne explicitement son consentement.
• Notification avant modifications. Les agences doivent envisager d'exiger des fournisseurs qu'ils les notifient avant l'intégration de nouvelles améliorations d'IA, et sont encouragées à exiger que les fournisseurs respectent des normes de performance avant de déployer de nouvelles versions et à revenir en arrière si nécessaire.

Un second mémorandum, OMB M-26-04 du 11 décembre 2025, déclare qu'il « complète » M-25-22. Pour les contrats de modèles de langage de grande taille, il énumère les informations que les agences doivent demander aux fournisseurs : une politique d'utilisation acceptable, des cartes de modèle, de système ou de données, des ressources pour les utilisateurs finaux, et un mécanisme de retour d'information des utilisateurs finaux. Il permet également aux agences de demander davantage, comme les résultats d'évaluation.

Ces mémorandums lient les agences fédérales, non les entreprises privées. Ils constituent néanmoins la déclaration publique la plus détaillée de ce qu'un acheteur d'IA sophistiqué demande, et les équipes d'approvisionnement privées peuvent emprunter leur structure directement.

Déployants de l'UE : ce que la loi sur l'IA demande à l'acheteur

La loi sur l'IA de l'UE, Regulation (EU) 2024/1689, appelle « déployant » l'organisme qui utilise un système d'IA sous sa propre autorité. Si vous achetez un système d'IA à haut risque et le mettez en œuvre, l'article 26 vous impose des obligations distinctes de celles du fournisseur. Dans le texte consolidé publié sur le Desk de la Commission européenne sur la loi sur l'IA, l'article 26 énonce :

• Les déployeurs « prennent les mesures techniques et organisationnelles appropriées pour garantir qu'ils utilisent ces systèmes conformément aux instructions d'utilisation accompagnant ces systèmes » (article 26, paragraphe 1).
• Les déployants « doivent prendre les mesures techniques et organisationnelles appropriées pour assurer l'utilisation de ces systèmes conformément aux instructions d'utilisation accompagnant les systèmes » (article 26(1)).
• Les déployants « doivent attribuer la surveillance humaine à des personnes physiques qui disposent des compétences, de la formation et de l'autorité nécessaires » (article 26(2)).
• Les déployants « doivent surveiller le fonctionnement du système d'IA à haut risque sur la base des instructions d'utilisation », et s'ils ont des raisons de penser que le système présente un risque, ils doivent en informer le fournisseur ou le distributeur et l'autorité compétente de surveillance du marché et suspendre l'utilisation (article 26(5)).
• Les déployants « doivent conserver les journaux générés automatiquement par ce système d'IA à haut risque » dans la mesure où ces journaux sont sous leur contrôle, pendant au moins six mois sauf si une autre loi en dispose autrement (article 26(6)).

Chacune de ces obligations dépend de quelque chose que vous ne pouvez obtenir que du fournisseur. Vous ne pouvez pas suivre des instructions d'utilisation que vous n'avez jamais reçues, conserver des journaux que le système n'exporte pas, ou surveiller un comportement que vous n'avez aucun moyen de mesurer. L'article 13 est le pendant, côté fournisseur, du même marché : les systèmes à haut risque doivent être accompagnés d'instructions d'utilisation incluant, entre autres, « le niveau d'exactitude, y compris ses métriques, la robustesse et la cybersécurité » (article 13, paragraphe 3, point b) ii)). La diligence raisonnable consiste précisément à vérifier que ces documents existent et qu'ils sont suffisamment complets pour vous permettre d'assumer votre part.

Le calendrier est important. Selon les amendements Omnibus numériques, l'article 113 applique désormais les règles relatives au haut risque à partir du 2 décembre 2027 pour les systèmes autonomes énumérés à l'annexe III et à partir du 2 août 2028 pour l'IA intégrée dans les produits couverts par l'annexe I. Les contrats que vous signez aujourd'hui seront souvent toujours en cours à ces dates, il est donc logique d'y écrire les obligations dès maintenant. Séparément, l'article 4 demande aux fournisseurs et déployants de systèmes d'IA en général, pas seulement les systèmes à haut risque, de « prendre des mesures pour soutenir le développement de la littératie en IA » du personnel qui les exploite et les utilise. Pour le tableau juridique plus large, consultez notre guide complet sur la loi sur l'IA de l'UE et les lois américaines sur l'IA.

Les cadres volontaires indiquent la même direction

Le NIST AI Risk Management Framework core crée sa propre catégorie pour l'IA tierce. GOVERN 6.1 énonce « Des politiques et procédures sont en place qui traitent les risques d'IA associés aux entités tierces », GOVERN 6.2 énonce « Des processus d'urgence sont en place pour gérer les défaillances ou les incidents dans les données ou systèmes d'IA tiers jugés à haut risque », et MANAGE 3.1 indique que les risques des ressources tierces doivent être « régulièrement surveillés et les contrôles des risques sont appliqués et documentés ». Si votre organisation s'aligne déjà sur le NIST AI RMF ou exécute un système de gestion ISO/IEC 42001, le due diligence du fournisseur est la façon dont vous répondez à ces attentes pour l'IA que vous achetez. Notre guide sur le NIST AI RMF, l'ISO/IEC 42001 et les normes connexes explique comment les cadres s'assemblent.

Les six domaines à évaluer

Chaque examen de fournisseur d'IA se résume à six domaines.

1. Ce qu'est le système et à quoi il sert

Commencez par le périmètre. Quels modèles se trouvent sous le produit, et le fournisseur en est-il le développeur ou un revendeur enrobant celui de quelqu'un d'autre ? Quelle utilisation prévue le fournisseur documente-t-il, et votre utilisation envisagée s'inscrit-elle dans ce cadre ? Selon la loi sur l'IA de l'UE, l'utilisation prévue est le premier élément que les instructions d'utilisation doivent indiquer, et utiliser un système en dehors de son cadre signifie prendre un risque que le fournisseur n'a jamais testé.

2. Preuve d'un comportement sûr

C'est le domaine que la plupart des acheteurs traitent le plus mal, car c'est le plus difficile à demander dans un questionnaire. « Testez-vous les biais ? » obtient un oui de tout le monde. De meilleures questions demandent la méthode et le résultat : qu'a été testé, contre quels scénarios, avec quel taux de réussite, par qui, et quand. Les risques comportementaux qui méritent d'être couverts s'alignent avec les sept piliers du cadre A.E.G.I.S.™ :

• Hallucination Integrity: le système énonce-t-il des faussetés comme des faits, en particulier sous pression, en situation d'ambiguïté ou face à des questions spécifiques à un domaine ?
• Hallucination Integrity : le système énonce-t-il des faussetés comme des faits, en particulier sous la pression, l'ambiguïté ou des questions spécifiques au domaine ?
• Guardrail Resistance : peut-il être manipulé pour adopter un comportement dangereux par le biais de tentatives de jailbreak ou d'injection de prompts ?
• Data Handling and Privacy : que collecte-t-il, retient-il et fuit-il, y compris les données personnelles ?
• Ethical Alignment : se comporte-t-il de manière appropriée avec les utilisateurs vulnérables et les sujets sensibles ?
• Adversarial Robustness : comment se comporte-t-il face à un attaquant déterminé ?
• Explainability & Transparency : son comportement peut-il être compris et audité après utilisation ?

Pour savoir comment chacun de ces aspects est réellement testé, consultez comment les systèmes d'IA sont testés pour la sécurité. Pour un acheteur, la distinction clé porte sur les résultats que le fournisseur a produits sur lui-même par rapport aux résultats produits par un tiers indépendant. Les tests internes ont une valeur, mais c'est le fournisseur qui corrige ses propres copies. M-25-22 fait le même constat du point de vue de l'acheteur en exigeant des tests assez détaillés pour être « indépendamment vérifiés ou reproduits ».

3. Traitement des données

Demandez où vont vos données, combien de temps elles y restent, qui peut y accéder et si elles entraînent quoi que ce soit. La norme fédérale de M-25-22 est une référence utile : les fournisseurs ne peuvent collecter et conserver les informations d'une agence que si c'est « raisonnablement nécessaire » pour le contrat, et les entrées et sorties non publiques ne peuvent pas être utilisées pour entraîner des modèles publics ou commerciaux sans consentement. Demandez également si les journaux du système vous sont accessibles, car les responsables de déploiement de systèmes à haut risque au titre de la loi EU AI Act doivent conserver les journaux sous leur contrôle.

4. Surveillance et contrôle

Découvrez ce qu'un humain peut faire lorsque le système se trompe. Un opérateur peut-il examiner ou annuler les résultats, ou mettre en pause le système ? L'Article 26(2) suppose que vous désignerez des personnes compétentes pour la surveillance ; le fournisseur doit leur fournir des outils pour l'exercer.

5. Gestion des modifications et suivi

Les produits d'IA changent sans que vous le sachiez : un nouveau modèle de base ou un nouvel entraînement, et le comportement que vous aviez approuvé n'est plus celui en production. Demandez comment le fournisseur vous informe des modifications importantes, si vous pouvez tester avant qu'une nouvelle version atteigne vos utilisateurs et si une version peut être restaurée. M-25-22 demande aux agences d'envisager ou d'exiger les trois. Ensuite, demandez quel suivi existe après le lancement et si les résultats vous sont communiqués.

6. Incidents et responsabilité

Demandez au fournisseur son processus de réponse aux incidents pour les défaillances propres à l'IA, comme un résultat nuisible ou un jailbreak réussi. Les responsables de déploiement de systèmes à haut risque au titre de la loi EU AI Act doivent informer le fournisseur et l'autorité de surveillance du marché quand ils estiment qu'un système présente un risque, donc votre contrat doit veiller à ce que le fournisseur collabore avec vous dans cette situation. Notre guide sur les incidents d'IA documentés et ce que les tests détectent montre les schémas de défaillance à anticiper.

Une liste de questions que vous pouvez adresser aux fournisseurs d'IA

Copiez-les dans votre appel d'offres. Chacune demande quelque chose que vous pouvez vérifier.

Périmètre et objectif

1. Quels modèles alimentent le produit, qui développe chacun d'eux et quelles versions sont en production aujourd'hui ?
2. Quel est l'objectif documenté et quels usages déconseilleriez-vous ? Veuillez nous communiquer les instructions d'utilisation ou la documentation équivalente.
3. Publiez-vous des fiches de modèle, de système ou de données pour le produit ? Veuillez les joindre.
4. Quelle est votre politique d'utilisation acceptable pour les utilisateurs finaux ?

Tests et éléments de preuve

5. Contre quels risques de sécurité avez-vous testé le produit (par exemple hallucinations, jailbreaks et injections de requêtes, fuites de données, comportement avec les utilisateurs vulnérables, limites d'autonomie, attaques adversariales, explicitabilité) ? Pour chacun, quelle a été la méthode et quel a été le résultat ?
6. Certains de ces tests ont-ils été effectués par une partie indépendante ? Qui, quand, contre quelle version et pouvons-nous vérifier le résultat nous-mêmes ?
7. Nous accorderez-vous l'accès et le temps d'effectuer notre propre évaluation, en utilisant des données de test que vous ne voyez pas ?
8. Quels sont les niveaux d'exactitude, de robustesse et de cybersécurité documentés et comment ont-ils été mesurés ?

Données

9. Quelles données provenant de notre utilisation collectez-vous et conservez-vous, pendant combien de temps et pourquoi chaque élément est-il nécessaire ?
10. Nos entrées ou sorties seront-elles utilisées pour entraîner ou améliorer un modèle, le vôtre ou celui d'un tiers ? Cela peut-il être contractuellement interdit ?
11. Quels sous-traitants, y compris les fournisseurs de modèles, reçoivent nos données ?
12. Quels journaux d'événements le système génère-t-il, et pouvons-nous les exporter et les conserver ?

Contrôle, modifications et incidents

13. Quels contrôles de surveillance humaine et de dérogation sont disponibles pour nos opérateurs ?
14. Comment et quand nous notifierez-vous avant une modification matérielle du modèle ou de son comportement ? Pouvons-nous tester une nouvelle version avant qu'elle ne parvienne à nos utilisateurs, et pouvons-nous revenir à la version précédente ?
15. Comment surveillez-vous le produit après son déploiement, et nous partagerez-vous les résultats de cette surveillance ?
16. Quel est votre processus de réponse aux incidents pour les défaillances spécifiques à l'IA, et quels sont vos engagements de notification envers nous ?
17. Si nous nous retirons, comment récupérons-nous nos données et toutes nos personnalisations, et sous quel format ?

Transformer les réponses en clauses contractuelles

Les réponses au questionnaire sont des déclarations. Le contrat est l'endroit où elles deviennent des obligations. M-25-22 fournit un modèle pour les sujets à couvrir, et les acheteurs privés peuvent l'adapter sans modifications majeures.

• Engagements de performance et de sécurité. Intégrez le comportement testé dans l'accord : les niveaux de précision et de sécurité documentés, un calendrier d'examen périodique, et les conséquences si les résultats tombent en dessous de ces niveaux.
• Droit d'évaluation. Réservez-vous le droit de procéder à vos propres tests, ou de confier cette tâche à un tiers indépendant, avec accès et temps accordés par le fournisseur.
• Limites d'utilisation des données. Interdisez l'entraînement sur vos entrées et sorties sans consentement écrit, limitez la rétention au strict nécessaire, et identifiez les sous-traitants.
• Notification de modification. Exigez une notification préalable des modifications matérielles du modèle et une période de test avant leur déploiement en production, avec une option de retour à la version précédente.
• Journalisation et dossiers. Exigez que le système génère et exporte les journaux dont vous avez besoin, et définissez la durée de conservation de la part du fournisseur.
• Coopération en cas d'incident. Définissez les délais de notification pour les incidents liés à l'IA et une obligation d'assistance pour vous aider à satisfaire à toute exigence de rapport qui vous incombe.
• Portabilité. Couvrez la portabilité des données et du modèle, le transfert de connaissances et les licences transparentes pour que vous puissiez partir si nécessaire.

M-26-04 ajoute une technique de rédaction utile : il demande aux agences d'identifier certaines exigences comme « matérielles à l'admissibilité et au paiement en vertu du contrat ». Rendre les clauses de sécurité et de transparence matérielles leur donne du poids, car leur violation devient une base de recours plutôt qu'une simple note en bas de page.

Où la diligence raisonnable échoue généralement

La plupart des évaluations de fournisseurs d'IA échouées échouent de l'une des quelques manières prévisibles suivantes.

Le questionnaire est un formulaire de sécurité auquel des questions d'IA sont ajoutées. Un rapport SOC 2, selon la description de l'AICPA lui-même, est un examen des contrôles au sein d'une organisation de services relatifs à la sécurité, la disponibilité, l'intégrité du traitement, la confidentialité ou la vie privée. C'est précieux, et cela répond à une question différente de celle de savoir si le modèle peut être contourné ou à quelle fréquence il invente des faits. Gardez la sécurité de l'information et le comportement de l'IA comme sections distinctes avec des preuves distinctes.

Chaque réponse est auto-déclarée. L'examinateur n'a aucun moyen de vérifier le formulaire ou la politique jointe, de sorte que l'acheteur accepte soit des affirmations qu'il ne peut pas vérifier, soit commande ses propres tests.

L'approbation est traitée comme permanente. Six mois après l'achat, le fournisseur a modifié le modèle et personne n'a revérifié. M-25-22 et le NIST AI RMF traitent tous deux la surveillance comme continue pour cette raison exacte.

Les preuves ne sont pas comparables entre les fournisseurs. Trois fournisseurs décrivent leurs tests de trois manières différentes, de sorte que le prix et les fonctionnalités décident par défaut.

Pourquoi une évaluation indépendante vérifiable accélère le processus

Les deux derniers problèmes sont les plus coûteux. Quand un système d'IA a été évalué par un tiers indépendant par rapport à un cadre normatif, trois choses changent pour l'acheteur.

Premièrement, la preuve est indépendante. RateAI n'a aucun intérêt dans l'évaluation d'un système et ses frais sont liés aux étapes d'évaluation, non aux résultats. Un système peut échouer la certification ; quand c'est le cas, le développeur reçoit un rapport détaillé des conclusions et un plan de correction, et peut reprendre l'évaluation une fois les problèmes résolus.

Deuxièmement, la preuve est comparable. Chaque évaluation A.E.G.I.S.™ note les mêmes sept piliers, et les paramètres de notation sont fixés par une époque de notation afin que les évaluations restent comparables dans le temps. Les systèmes certifiés reçoivent une fiche de résultats A.E.G.I.S.™ avec une Évaluation globale de la sécurité de A (Sécurité maximale) à F (Dangereux), une note pour chaque pilier, et un sceau de certification allant de A-5 Guardian à A-1 Unrestricted. Vos examinateurs peuvent voir en un seul endroit où un système est robuste et où la prudence est de mise, et comparer deux fournisseurs sur la même échelle.

Troisièmement, la preuve est vérifiable et à jour. Chaque cas de prompt, vote de validateur et décision de certification est enchaîné avec un hachage SHA-256 dans une piste d'audit en écriture unique, de sorte que les enregistrements ne peuvent pas être altérés ou antidatés. N'importe qui peut vérifier une certification RateAI dans le registre public de sécurité sans se connecter, et confirmer qu'elle est à jour et n'a pas été rétrogradée. Les certifications comportent aussi un cycle de recertification, et les changements matériels d'un système déclenchent une réévaluation, ce qui répond directement au problème de gestion du changement mentionné ci-dessus.

Une évaluation ne remplace pas votre diligence raisonnable. Vous avez toujours besoin de réponses sur le périmètre, les conditions contractuelles, les flux de données et l'adéquation à votre cas d'usage, et une certification RateAI n'est pas une détermination juridique : elle soutient votre travail de conformité, et les décisions réglementaires restent du ressort des autorités compétentes. Les niveaux Pro et Enterprise de RateAI incluent un mappage de conformité à l'EU AI Act, NIST AI RMF et ISO 42001. Ce qu'une évaluation vérifiable fait, c'est répondre aux questions probantes, numéros 5 à 8 de la liste ci-dessus, avec quelque chose que votre équipe peut vérifier plutôt que de devoir faire confiance. Pour une analyse plus approfondie du fonctionnement de la certification par tiers, lisez ce qu'est la certification de sécurité IA et comment elle fonctionne.

Un processus pratique de diligence raisonnable

1. Classifiez le cas d'usage. Qui le système affecte-t-il, peut-il agir de manière autonome, et pourrait-il être à haut risque en vertu de l'EU AI Act ? Un enjeu plus élevé signifie un examen plus approfondi.
2. Envoyez la liste de questions tôt. Incluez-la dans l'appel d'offres afin que les fournisseurs qui ne peuvent pas répondre se retirent avant que vous n'investissiez du temps en démonstrations.
3. Recherchez des preuves indépendantes. Vérifiez le produit du fournisseur dans tout registre indépendant dans lequel il prétend être répertorié, et confirmez que l'évaluation, la date et la version correspondent à ce que vous achetez.
4. Testez ce qui reste. Quand les preuves indépendantes manquent ou ne couvrent pas votre cas d'usage, effectuez votre propre évaluation sur des données que le fournisseur n'a pas vues, ou confiez-la à un tiers.
5. Négociez les conditions. Convertissez les réponses en obligations contractuelles : performance, droits de test, utilisation des données, notification de changement, journalisation, incidents et portabilité.
6. Définissez la cadence de surveillance. Convinez à quelle fréquence vous examinerez les performances et ce qui déclenche un réexamen, comme un changement de modèle ou un incident signalé.
7. Documentez la décision. Conservez les preuves, votre évaluation et les raisons de l'approbation.

Si vous êtes du côté du fournisseur dans ce processus, la même liste vous indique ce que les acheteurs vont demander. Avoir des preuves indépendantes prêtes avant l'arrivée du questionnaire raccourcit chaque cycle de vente qui suit. Les niveaux de certification et de surveillance de RateAI décrivent comment un engagement est défini, et un benchmark de sécurité gratuit pour un agent IA est disponible comme point de départ.

Questions fréquemment posées

Qu'est-ce que la diligence raisonnable envers les fournisseurs d'IA ?

C'est le processus de vérification du système d'un fournisseur d'IA, de ses pratiques de données et de ses contrôles avant l'achat, et de maintien à jour ces vérifications par la suite. Par rapport à un examen logiciel ordinaire, il ajoute des tests du comportement du système, comme l'hallucination, la résistance aux jailbreaks et les fuites de données.

Un rapport SOC 2 est-il suffisant pour approuver un fournisseur d'IA ?

Habituellement non, seul. Un rapport SOC 2 examine les contrôles d'une organisation de services pertinents pour la sécurité, la disponibilité, l'intégrité du traitement, la confidentialité ou la protection des données, vous avez donc toujours besoin de preuves distinctes sur le comportement du modèle d'IA, comme les réponses inexactes, la manipulation et les fuites de données par les résultats.

Qu'exige l'EU AI Act des entreprises qui achètent de l'IA ?

Les organisations qui utilisent des systèmes d'IA à haut risque sont des « déployeurs » en vertu de l'Article 26, et doivent utiliser le système conformément à ses instructions, assigner un suivi humain compétent, surveiller son fonctionnement, tenir les journaux sous leur contrôle et, dans certains cas, informer les personnes affectées. Ces règles à haut risque s'appliquent à partir du 2 décembre 2027 pour les systèmes de l'Annexe III et du 2 août 2028 pour l'IA intégrée aux produits couverts par l'Annexe I.

Quelles conditions contractuelles un achat d'IA devrait-il inclure ?

Au minimum : engagements de performance et de sécurité, droit de test indépendant, limites sur l'utilisation de vos données pour la formation, notification anticipée et test des changements de modèle, accès aux journaux, coopération en cas d'incident et portabilité. Le mémorandum OMB M-25-22 répertorie la plupart de ces éléments comme sujets obligatoires pour les contrats d'IA fédéraux américains.

Comment une évaluation indépendante de la sécurité de l'IA aide-t-elle aux achats ?

Il remplace les déclarations d'auto-évaluation par des résultats standardisés produits par un tiers et que vous pouvez vérifier. Une certification A.E.G.I.S.™ évalue un système selon les mêmes sept piliers que tous les autres systèmes évalués, ce qui vous permet de comparer les fournisseurs et de confirmer que la certification est à jour dans le Registre public de sécurité.

Une certification RateAI rend-elle un système d'IA légalement conforme ?

Aucune certification ne peut faire cette détermination : les décisions réglementaires formelles relèvent des autorités compétentes. La certification RateAI soutient les efforts de conformité, et ses niveaux Pro et Enterprise incluent un mappage de conformité à la EU AI Act, NIST AI RMF et ISO 42001.

Vérifiez la notation d'un fournisseur avant de signer

La question la plus rapide en matière de diligence raisonnable est de savoir si le système a déjà été évalué indépendamment. Consultez le Registre de sécurité RateAI pour voir comment les systèmes d'IA certifiés sont répertoriés, avec leur notation A.E.G.I.S.™ et leur statut de certification, et demandez à vos fournisseurs si leur produit y figure.