Que laisse sans réponse le rapport SOC 2 d'un fournisseur concernant l'accès aux réponses de l'IA ?

Le rapport SOC 2 d'un fournisseur confirme des contrôles de sécurité de base, mais laisse trois questions relatives à l'IA en suspens : il ne montre pas si les autorisations sont respectées au moment de la récupération, comment les fournisseurs de modèles utilisent vos données, ni si les réponses s'appuient sur des sources réelles.

Ces lacunes constituent les principales limites de SOC 2 pour l'IA. L'audit présuppose un logiciel déterministe et n'évalue pas si les sorties d'un modèle sont exactes, sûres ou appropriées.

Ce guide explique ce que teste l'audit, où l'IA se situe en dehors de son périmètre, et quelles vérifications ajouter à votre évaluation des fournisseurs pour l'IA.

Ce que couvrent réellement les rapports SOC 2 — et où l'IA sort du périmètre

SOC 2 est une attestation de conformité aux Trust Services Criteria de l'AICPA : sécurité, disponibilité, intégrité du traitement, confidentialité et respect de la vie privée. Aucun des cinq critères n'est spécifique à l'IA.

Chaque rapport est délimité par un système défini et une période couverte. Comme le souligne Code Your Compliance, un rapport sans réserve prouve l'existence d'un environnement de contrôle testé pour ce périmètre et cette fenêtre. Il ne prouve pas que le produit d'IA, le parcours du modèle, le parcours de conservation ou la frontière contractuelle que vous achetez correspondent à ce qui a été audité.

Considérez les déclarations de confidentialité des fournisseurs comme des affirmations à vérifier au regard du rapport et du contrat. Pour en savoir plus sur les raisons pour lesquelles les déclarations de confidentialité en matière d'IA ne sont pas équivalentes à des contrôles audités, consultez cette analyse détaillée.

En quoi les contrôles d'accès à l'IA diffèrent des autorisations d'application traditionnelles

Les autorisations d'application traditionnelles sont binaires. Un utilisateur peut ouvrir un fichier dans un outil de documentation ou ne le peut pas, et l'application vérifie ce droit à chaque fois.

Un assistant IA fonctionne différemment. Une seule réponse peut combiner un enregistrement CRM, une page wiki et un ticket d'assistance, chacun régi par les règles d'accès d'un système différent. Les contrôles d'accès à l'IA doivent vérifier chacune de ces sources par rapport aux droits de l'utilisateur qui pose la question, au moment de la récupération. IBM a constaté que 97 % des organisations signalant une violation liée à l'IA ne disposaient pas de contrôles d'accès à l'IA appropriés.

L'OWASP Top 10 pour les applications LLM 2025 classe ce risque sous LLM08, Faiblesses des vecteurs et des embeddings. L'analyse de Tenable sur la mise à jour 2025 explique que le contenu récupéré via la génération augmentée par récupération (RAG) peut atteindre des utilisateurs non autorisés. Tenable décrit également la fuite inter-contextes, qui se produit lorsque des contextes au sein d'un même locataire sont confondus.

Un rapport SOC 2 ne vous dira pas si les autorisations sont vérifiées au moment de la récupération. La récupération tenant compte des autorisations, qui filtre les résultats selon les droits de chaque utilisateur au niveau des sources avant que le modèle ne les voie, nécessite une évaluation distincte.

Ce qu'il faut demander aux fournisseurs concernant l'application des autorisations

Trois questions révèlent la façon dont un fournisseur gère les autorisations au sein du pipeline d'IA :

1. Appliquez-vous les autorisations avant que le contenu n'entre dans le contexte du modèle, ou filtrez-vous les réponses après génération ?
2. Les modifications d'autorisations sont-elles synchronisées en temps réel ou selon un calendrier, et quel est le délai maximal possible ?
3. Les administrateurs peuvent-ils voir quelles sources ont contribué à une réponse spécifique ?

La première question est la plus importante. Les recommandations de Superwise sur l'OWASP Top 10 pour les applications LLM 2025 préconisent de vérifier l'autorisation avant la récupération et de n'envoyer au modèle que les champs dont une tâche a besoin.

Là où SOC 2 reste muet sur l'exposition des données lors de la récupération et de la génération par l'IA

La sécurité des données de l'IA dépend de ce qui se passe à l'intérieur du pipeline de génération augmentée par récupération (RAG). Un rapport SOC 2 ne montrera pas si ce parcours de données a été couvert. Chaque étape copie ou remodèle votre contenu d'une manière qu'un examen de sécurité devrait retracer :

• L'indexation stocke des copies du contenu source : demandez donc où elles résident et pendant combien de temps.
• L'embedding transforme le texte en vecteurs : demandez donc si les magasins de vecteurs sont isolés par client.
• La recherche sémantique s'étend aux systèmes connectés : demandez donc quels référentiels une requête peut atteindre.
• L'assemblage du contexte sélectionne des passages pour le modèle : demandez donc quelle quantité de contenu est transmise.
• La construction du prompt regroupe tout pour le modèle : demandez donc ce qui quitte votre environnement.

La frontière de confiance s'étend souvent au-delà du fournisseur, et le SaaS tiers était la source la plus courante d'incidents de sécurité liés à l'IA dans l'étude IBM de 2025. Comme le note ce guide de la DEV Community, le fournisseur de LLM devient un sous-traitant ultérieur dans votre flux de données. Avec la méthode de dissociation (carve-out), le rapport nomme ce fournisseur mais ne teste pas ses contrôles : vous l'évaluez donc séparément.

Un rapport SOC 2 ne vous dira pas non plus si le fournisseur entraîne ses modèles sur vos données. AuditBadger conseille de vérifier plutôt l'accord de traitement des données (DPA). Examinez cet accord pour y rechercher des clauses de non-conservation des données ainsi que les politiques de journalisation des LLM tiers.

L'exposition à ce niveau est une préoccupation reconnue pour la confidentialité des données dans l'IA. La divulgation d'informations sensibles correspond à LLM02 dans l'OWASP Top 10 pour les applications LLM 2025.

Ce que SOC 2 ne révèle pas sur l'exactitude et l'ancrage des réponses de l'IA

Le critère d'intégrité du traitement de SOC 2 a été rédigé en pensant à des logiciels déterministes, où la même entrée produit la même sortie. Les grands modèles de langage génèrent du texte probabiliste. Selon Drel, SOC 2 n'évalue pas si un modèle produit des sorties exactes : un fournisseur peut donc réussir l'audit tout en renvoyant des réponses hallucinées.

L'OWASP Top 10 pour les applications LLM 2025 classe les hallucinations sous LLM09, Désinformation, qui a remplacé la dépendance excessive. L'ancrage, la qualité des citations et les signaux de confiance nécessitent leur propre examen.

Le coût se manifeste dans les workflows quotidiens. Un agent d'assistance cite à un client une politique de remboursement obsolète. Un commercial envoie la grille tarifaire du trimestre dernier, ou un responsable des opérations agit sur la base d'un runbook périmé.

Les équipes de conformité portent le risque le plus aigu. Un analyste qui cite un contrôle remplacé dans une réponse d'audit crée une anomalie que l'IA n'a jamais signalée. Demandez aux fournisseurs de présenter des citations de sources sur chaque réponse et d'expliquer ce qui se passe lorsqu'aucune réponse ancrée n'existe.

Pourquoi la gestion des risques fournisseurs pour l'IA exige des cadres allant au-delà de SOC 2

SOC 2 n'est qu'un élément parmi d'autres de la gestion des risques fournisseurs pour l'IA. Le rapport montre un environnement de contrôle testé pour un système délimité, tandis que les cadres de gouvernance de l'IA traitent du comportement des modèles et de la responsabilité à leur égard. Cette seconde couche fait souvent défaut : 68 % des organisations ayant subi une violation ne disposaient pas d'une gouvernance de l'IA dans le rapport IBM de 2026.

Le cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0, publié en janvier 2023) couvre la gouvernance, l'explicabilité et les biais. Ses quatre fonctions se traduisent en questions à poser aux fournisseurs :

• Gouverner interroge sur qui détient la politique et les décisions relatives au risque IA chez le fournisseur.
• Cartographier interroge sur les cas d'usage, les sources de données et les utilisateurs que le système touche.
• Mesurer interroge sur la façon dont le fournisseur teste l'exactitude, les biais et l'explicabilité.
• Gérer interroge sur la façon dont les risques identifiés sont hiérarchisés, corrigés et surveillés.

Deux autres références élargissent cette couverture. L'ISO/IEC 42001:2023 est la première norme internationale pour les systèmes de management de l'IA. L'AI Act de l'UE est entré en vigueur le 1er août 2024, avec des obligations échelonnées qui incluent la transparence et la supervision humaine pour les systèmes à haut risque.

Une diligence raisonnable à plusieurs niveaux les combine : le rapport SOC 2, la cartographie des cadres, l'examen du contrat et les tests pratiques. Pour approfondir la question de la conformité SOC 2 pour l'IA, consultez cette discussion entre praticiens.

Comment évaluer la posture de sécurité d'un fournisseur d'IA au-delà du rapport d'audit

Évaluer la posture de sécurité d'un fournisseur d'IA consiste à confronter ses affirmations à des preuves que vous collectez vous-même. Nous recommandons cinq vérifications pour couvrir ce que le rapport d'audit laisse de côté :

1. Demandez un schéma de flux de données qui retrace une requête, du prompt jusqu'au fournisseur de modèle et retour.
2. Révoquez l'accès d'un utilisateur pilote à un document, puis posez une question à laquelle seul ce document répond.
3. Lisez directement les clauses du contrat du fournisseur de LLM, et demandez à être informé avant tout changement de sous-traitants ultérieurs.
4. Demandez pendant combien de temps les journaux d'activité de l'IA sont conservés et s'ils peuvent être exportés vers votre SIEM.
5. Demandez les résultats des tests d'intrusion (red-team) IA couvrant LLM01 Injection de prompt et les tentatives de jailbreak.

La deuxième vérification vous indique où l'application des autorisations se produit. Une application en amont maintient le document restreint entièrement hors du contexte du modèle. Un filtrage en aval signifie que le modèle l'a déjà traité, et que seule la réponse visible a été tronquée.

La cinquième vérification comble une lacune courante dans les tests. Workstreet souligne que les tests d'intrusion traditionnels ne couvrent pas automatiquement les injections de prompt, les jailbreaks ni les évaluations du comportement des modèles.

Le type de rapport compte également. Comme l'explique ce guide de la DEV Community, un rapport de Type I évalue la conception des contrôles à un instant précis. Un rapport de Type II teste l'efficacité opérationnelle sur une période donnée : demandez-le donc lorsque vous prenez des décisions de conformité concernant des outils d'IA.

Pour échanger entre pairs sur la réalisation de ces vérifications, vous pouvez consulter le forum de la Glean Community.

Foire aux questions

Quels aspects précis de l'accès à l'IA ne sont pas couverts par les rapports SOC 2 ?

SOC 2 ne couvre pas les risques liés au RAG, tels que la fuite inter-contextes au sein d'un même tenant, le fait que le fournisseur entraîne ses modèles sur vos données, ou encore l'exactitude des résultats. Les risques du OWASP Top 10 for LLM Applications 2025, comme la fuite de prompt système (LLM07) et le traitement inapproprié des sorties (LLM05), nécessitent eux aussi des tests distincts.

Comment les organisations peuvent-elles évaluer les risques liés à l'IA au-delà de SOC 2 ?

Associez l'examen des documents à des tests en conditions réelles. Envoyez au fournisseur un questionnaire de sécurité de l'IA fondé sur l'OWASP Top 10 for LLM Applications 2025. Validez ensuite les réponses dans un projet pilote utilisant votre propre contenu à accès restreint.

Quelles sont les conséquences de l'utilisation d'outils d'IA sans une couverture SOC 2 adéquate pour les risques propres à l'IA ?

Sans vérifications propres à l'IA, des données à accès restreint peuvent parvenir aux mauvais employés, et des prompts peuvent être transmis à des fournisseurs de modèles que vous n'avez pas examinés. IBM a constaté que des niveaux élevés de shadow AI ajoutaient 670 000 USD au coût moyen d'une violation. Lorsque des agents IA agissent dans des systèmes connectés, le risque LLM06 d'autonomie excessive (Excessive Agency) du OWASP Top 10 for LLM Applications 2025 ajoute la possibilité de modifications non autorisées.

Comment SOC 2 aborde-t-il la confidentialité des données dans le contexte de l'IA ?

La confidentialité est l'un des cinq critères SOC 2, mais la sécurité est le seul critère obligatoire : vérifiez donc si la confidentialité faisait bien partie du périmètre. Même lorsque la confidentialité est incluse, le rapport ne vous dira pas si le fournisseur entraîne ses modèles sur vos données. Demandez séparément comment les données personnelles contenues dans les prompts et les embeddings sont supprimées.

C'est en testant vous-même les autorisations, les contrats et l'ancrage des réponses que vous en apprendrez le plus sur un fournisseur d'IA. Nous appliquons les autorisations en amont du LLM, de sorte que les réponses n'utilisent que le contenu auquel chaque utilisateur a accès, avec des citations que vous pouvez vérifier. Demandez une démo et nous expliquerons à votre équipe de sécurité comment nous gérons la récupération, la conservation et la journalisation d'audit.