Accueil › Glossaire › Compliance IA Cloud

Compliance IA Cloud

La compliance IA cloud désigne l’ensemble des certifications, normes et réglementations que les systèmes d’intelligence artificielle déployés sur le cloud doivent respecter pour garantir la sécurité des données, la gouvernance des modèles, la transparence et la conformité juridique.

Pourquoi la compliance IA est devenue critique

L’IA n’est plus un projet expérimental isolé dans un lab. Les LLM sont intégrés dans les systèmes de production : support client, copilotes de développement, automatisation de workflows, assistants internes, pipelines de données. Dès que l’IA touche des données réglementées ou influence des décisions business, elle entre dans le périmètre d’audit.

La compliance IA est plus complexe que la compliance logicielle classique pour trois raisons :

Les entrées sont non fiables par nature. Un logiciel classique traite des entrées structurées (formulaires, APIs). Un LLM interprète du langage naturel, ce qui ouvre des vecteurs d’attaque inédits (injection de prompt, manipulation de contexte). Les frameworks de compliance doivent couvrir ces risques spécifiques.

Les sorties sont non déterministes. Le même prompt peut produire des réponses différentes. Prouver à un auditeur que votre système IA se comporte de manière contrôlée et prévisible nécessite des mécanismes de logging, de validation de sortie, et de monitoring continu qui n’existent pas dans les audits traditionnels.

La chaîne de responsabilité est partagée. Quand vous appelez l’API d’un fournisseur LLM (OpenAI, Anthropic), votre compliance dépend à la fois de vos propres contrôles et de ceux du fournisseur. C’est le modèle de responsabilité partagée, bien connu dans le cloud, mais amplifié par l’IA.

Les certifications et normes essentielles

SOC 2 Type II

SOC 2 (Service Organization Control 2) est la certification la plus demandée par les clients enterprise B2B, en particulier aux États-Unis. Elle évalue les contrôles d’une organisation selon cinq Trust Services Criteria : sécurité, disponibilité, intégrité du traitement, confidentialité, et protection de la vie privée.

Type I vs Type II. Le Type I vérifie que les contrôles sont en place à un instant T. Le Type II vérifie qu’ils fonctionnent effectivement sur une période d’observation (généralement 6 à 12 mois). Les acheteurs enterprise exigent quasiment toujours le Type II.

Impact IA. SOC 2 intègre progressivement des critères spécifiques à l’IA : gouvernance des modèles, provenance des données d’entraînement, contrôle d’accès aux systèmes IA, et validation des sorties. Les auditeurs veulent savoir quelles données vous envoyez aux fournisseurs LLM, comment vous protégez les données client dans les prompts, si les données sont utilisées pour l’entraînement (ou non), et comment vous gérez les sous-agents IA qui héritent des permissions d’accès.

Exigences concrètes pour un produit IA : classification des données avant envoi à l’API LLM, chiffrement en transit et au repos documenté, politique de rétention des données du fournisseur, DPA (Data Processing Addendum) ou BAA (Business Associate Agreement) avec le fournisseur, logs d’accès et d’utilisation de l’IA, et évaluation de risque du fournisseur comme sous-service organization.

ISO 27001

ISO 27001 est la norme internationale pour les systèmes de management de la sécurité de l’information (SMSI / ISMS). Elle est particulièrement demandée en Europe et à l’international (81 % des organisations la certifient ou la planifient). La norme couvre 93 contrôles de sécurité (Annexe A, version 2022) organisés en 4 thèmes : contrôles organisationnels, contrôles humains, contrôles physiques, et contrôles technologiques.

Impact IA. Les contrôles de l’Annexe A s’appliquent directement aux infrastructures IA : A.5 (politiques de sécurité) couvre la gouvernance IA, A.8 (gestion des actifs) inclut les modèles comme actifs informationnels, A.9 (contrôle d’accès) s’applique aux endpoints d’inférence, A.10 (cryptographie) protège les poids et les données, A.12 (sécurité des opérations) couvre la configuration des clusters GPU, A.13 (sécurité des communications) segmente les workloads IA du réseau corporate.

Environ 30 % des contrôles nécessitent une interprétation spécifique pour les infrastructures IA (contrôle d’accès aux modèles, gestion des versions de modèles, segmentation des workloads GPU, etc.).

ISO 42001 (AI Management Systems)

ISO/IEC 42001:2023 est la première norme internationale spécifiquement dédiée à la gouvernance des systèmes IA. Elle établit un AI Management System (AIMS) qui couvre le cycle de vie complet : sourcing des données, entraînement, évaluation, déploiement, monitoring, et retrait du modèle.

Différence avec ISO 27001. ISO 27001 sécurise les systèmes d’information en général. ISO 42001 sécurise les systèmes IA spécifiquement, avec des contrôles pour la gouvernance des données (qualité, lignage, droits), le développement des modèles (tests adversariaux, explicabilité), les opérations (monitoring runtime, réponse aux incidents), et la gouvernance (rôles, éthique, transparence).

Adoption. Anthropic a été parmi les premiers labs IA frontier à obtenir la certification ISO 42001 (janvier 2025, certifié par Schellman). OpenAI affiche aussi la certification. ISO 42001 devient rapidement le standard de facto pour les entreprises qui développent ou déploient des systèmes IA en production. La norme s’aligne naturellement avec les exigences de l’EU AI Act, ce qui en fait un point de départ solide pour la conformité européenne.

Autres certifications et frameworks

EU AI Act : la réglementation qui change tout

L’EU AI Act est le premier cadre juridique complet au monde pour l’IA. Il classe les systèmes IA par niveau de risque et impose des obligations proportionnelles :

Risque inacceptable (interdit). Systèmes de scoring social, manipulation subliminale, identification biométrique temps réel dans l’espace public (sauf exceptions). Ces interdictions sont déjà en vigueur.

Haut risque. Infrastructure critique, éducation, emploi/recrutement, services publics essentiels, migration, justice. Ces systèmes doivent se soumettre à des évaluations de conformité, documenter leur fonctionnement, maintenir des logs, et intégrer un contrôle humain. Échéance : 2 août 2026 pour les obligations sur les systèmes à haut risque.

Risque limité. Chatbots, deepfakes, systèmes de génération de contenu. Obligation de transparence : l’utilisateur doit savoir qu’il interagit avec une IA.

Risque minimal. La majorité des applications IA (filtres anti-spam, recommandation de contenu). Pas d’obligations spécifiques.

Modèles à usage général (GPAI). Les LLM comme GPT, Claude ou Mistral sont classés comme modèles à usage général. Les fournisseurs doivent fournir une documentation technique, respecter le droit d’auteur, et publier un résumé des données d’entraînement. Les modèles présentant un « risque systémique » (critère de puissance de calcul) sont soumis à des obligations renforcées (évaluation des risques, tests adversariaux, signalement des incidents).

Sanctions. Jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial pour les violations les plus graves (systèmes interdits). Jusqu’à 15 millions d’euros ou 3 % pour les violations des obligations des systèmes à haut risque.

Modèle de responsabilité partagée pour l’IA

Le cloud classique a un modèle de responsabilité partagée bien compris : le fournisseur sécurise l’infrastructure « du » cloud, le client sécurise ce qui est « dans » le cloud. L’IA ajoute une troisième couche :

Le piège : une plateforme IA compliant ne rend pas votre application compliant. AWS Bedrock supporte le chiffrement, le logging, et s’aligne avec les programmes de conformité ISO et SOC. Mais c’est à vous de décider quelles données vos utilisateurs peuvent envoyer dans les prompts, comment vous validez les sorties avant de les présenter, quels workflows d’approbation existent pour les actions déclenchées par l’IA, et si vos pipelines RAG injectent des données sensibles dans le contexte.

Implémenter la compliance IA en pratique

1. Inventaire des systèmes IA

Première étape : documenter chaque système IA dans votre organisation. Pour chaque système, enregistrez le fournisseur (OpenAI, Anthropic, self-hosted), le modèle utilisé, les données traitées (classification), les décisions influencées, les utilisateurs concernés, le niveau de risque EU AI Act, et l’évaluation HITL (human-in-the-loop : un humain valide-t-il les décisions ?). L’EU AI Act exige explicitement ce registre pour les systèmes à haut risque.

2. Évaluation des fournisseurs IA

Chaque fournisseur LLM que vous utilisez est un sous-traitant de données (subservice organization). Pour l’évaluation de risque :

Vérifiez les certifications du fournisseur (SOC 2 Type II, ISO 27001, ISO 42001). Anthropic détient les trois. OpenAI détient SOC 2 Type II, ISO 27001, et ISO 42001. Documentez que vous avez vérifié ces certifications et évalué les risques résiduels.

Vérifiez la politique de rétention des données. Anthropic et OpenAI proposent le zero data retention (ZDR) pour les clients API et Enterprise, ce qui signifie que les prompts et réponses ne sont pas conservés après le traitement et ne sont pas utilisés pour l’entraînement. Documentez que cette option est activée dans votre configuration.

Signez un DPA (Data Processing Addendum) ou un BAA (Business Associate Agreement pour HIPAA). Ce contrat formalise les obligations de protection des données entre vous et le fournisseur.

3. Contrôles techniques

Classification des données. Définissez quelles données peuvent être envoyées dans les prompts. Les numéros de carte, les identifiants nationaux (numéros de sécurité sociale), et les données médicales en clair ne devraient jamais transiter dans un prompt, sauf si le pipeline est spécifiquement conçu pour (HIPAA-compliant avec BAA).

Logging et audit trail. Chaque appel API au fournisseur LLM doit être loggé avec le timestamp, l’identifiant utilisateur, le modèle appelé, le nombre de tokens consommés, et le statut de la réponse. Les prompts complets peuvent être loggés selon votre politique de rétention, mais attention à ne pas créer un nouveau point de fuite de données en stockant les logs.

Contrôle d’accès. Qui peut utiliser les systèmes IA dans votre organisation ? Quelles équipes, quels rôles ? L’accès est-il provisionné et déprovisionné quand un employé change de rôle ou quitte l’entreprise ? Les auditeurs SOC 2 vérifient systématiquement ce point.

Validation des sorties. Si l’IA influence des décisions (recommandations, scoring, actions automatisées), un mécanisme de validation doit exister. Pour les systèmes à haut risque au sens de l’EU AI Act, un contrôle humain est obligatoire.

4. Monitoring continu

L’ère des audits ponctuels (« point-in-time ») est révolue. Les auditeurs attendent du monitoring continu (Continuous Controls Monitoring / CCM) : collecte automatique des preuves de conformité, alertes en temps réel quand un contrôle est violé, dashboards de compliance accessibles en permanence.

Les plateformes d’automatisation de compliance (Vanta, Comp AI, Delve, Drata) se connectent à vos systèmes cloud, collectent automatiquement les preuves (logs d’accès, configurations de sécurité, certifications fournisseurs), et maintiennent un état de compliance en temps réel. Comp AI est open source et propose une mise en conformité SOC 2 en quelques semaines au lieu de plusieurs mois.

Calendrier de conformité

Bonnes pratiques

Traitez la compliance comme un enabler, pas un frein. Les entreprises avec des certifications SOC 2 et ISO 27001 closent des deals enterprise plus vite. La certification ISO 42001 devient un avantage concurrentiel pour les fournisseurs IA. Investir dans la compliance accélère le go-to-market, pas l’inverse.

Commencez par SOC 2 si vous vendez aux États-Unis, ISO 27001 si vous vendez en Europe. Les deux couvrent 80 % des mêmes contrôles. Un outil GRC avec cross-mapping automatique évite de dupliquer le travail.

Ajoutez ISO 42001 si vous développez ou intégrez de l’IA. C’est la couche de gouvernance spécifique à l’IA qui manque aux normes de sécurité traditionnelles. Elle couvre le lignage des données, les tests adversariaux, l’explicabilité, et le monitoring des modèles.

Documentez tout avant l’audit, pas pendant. Les auditeurs veulent des preuves sur la durée (6 à 12 mois pour SOC 2 Type II). Si vous commencez à documenter au moment de l’audit, vous avez déjà perdu. Les outils d’automatisation (Vanta, Comp AI, Delve) collectent les preuves en continu dès leur déploiement.

Préparez-vous à l’EU AI Act maintenant. L’échéance d’août 2026 pour les systèmes à haut risque est imminente. Commencez par l’inventaire des systèmes IA, la classification par niveau de risque, et la mise en place des mécanismes de documentation et de contrôle humain. ISO 42001 est le meilleur point de départ structurel.