Sécurité de l'IA d'entreprise : au-delà du SOC 2

Le SOC 2 Type II est désormais le niveau minimal de conformité pour les logiciels d'entreprise. Tout fournisseur en étant dépourvu fait face à une conversation d'achat difficile. Pour les plateformes IA qui indexent vos connaissances internes — contrats, données cliniques, modèles financiers, feuilles de route produit non publiées — le SOC 2 est un point de départ, et guère plus. L'audit couvre un ensemble de contrôles opérationnels conçus pour un modèle de menace pré-IA. Les risques qui comptent vraiment pour la sécurité de l'IA d'entreprise sont presque entièrement en dehors de son périmètre.

Ce que le SOC 2 audite réellement (et ce qu'il manque)

Le SOC 2 audite les contrôles opérationnels selon cinq critères de service de confiance : sécurité, disponibilité, intégrité du traitement, confidentialité et vie privée. En pratique, la plupart des éditeurs de logiciels d'entreprise poursuivent les critères de sécurité et de disponibilité. L'audit vérifie des éléments tels que : les autorisations d'accès sont-elles gérées et révisées ? Existe-t-il un processus de gestion des changements ? Existe-t-il un plan de réponse aux incidents ? Des contrôles de chiffrement sont-ils en place pour les données au repos et en transit ?

Ce sont des contrôles légitimes. Ils comptent. Ils sont également loin d'être suffisants pour évaluer la gestion des données d'une plateforme IA.

Le SOC 2 ne couvre pas : l'endroit où vont vos données lors de l'inférence du modèle. Si vos documents ou journaux de requêtes sont utilisés pour améliorer les modèles du fournisseur. Si vos embeddings indexés sont isolés des données d'autres clients ou mélangés dans un store vectoriel partagé. Ce qui advient de vos données — y compris les embeddings, qui encodent le contenu sémantique de vos documents — si vous résiliez votre contrat. La durée de conservation des journaux de requêtes et les personnes y ayant accès en interne chez le fournisseur.

Un fournisseur peut être entièrement conforme au SOC 2 Type II tout en envoyant chaque document que vous indexez via un cluster d'inférence partagé, en journalisant indéfiniment chaque requête et en utilisant vos données pour affiner sa prochaine version de modèle. Rien de tout cela ne viole les critères SOC 2. L'audit n'atteint simplement pas ces questions.

La surface d'attaque spécifique à l'IA

L'IA d'entreprise introduit trois vecteurs de menace que les cadres de sécurité traditionnels n'ont pas été conçus pour traiter.

Fuite lors de l'inférence. Lorsque vous envoyez une requête à un fournisseur d'IA cloud, votre requête — et le contexte documentaire récupéré pour y répondre — traverse un réseau externe et est traitée sur une infrastructure que vous ne contrôlez pas. Pour la plupart des requêtes, le risque est faible. Pour les requêtes touchant des communications juridiques privilégiées, des données financières non publiées ou des informations de santé protégées, il s'agit d'un événement d'exfiltration de données. Le fait que cela se produise via un appel API chiffré ne change pas la réalité sous-jacente : des informations sensibles ont quitté votre environnement.

Contamination par entraînement. Jusqu'en 2023, plusieurs grands fournisseurs d'IA s'entraînaient par défaut sur les interactions clients. Les accords entreprise se sont considérablement durcis depuis lors, et la plupart incluent désormais des exclusions explicites d'entraînement. Mais les exclusions contractuelles et la réalité architecturale sont deux choses différentes. Si vos requêtes et documents atteignent l'infrastructure d'un fournisseur, vous vous fiez à ses contrôles internes — pas aux vôtres — pour faire respecter cette exclusion. L'application est opaque. La vérification est impossible. Le risque n'est pas théorique : au moins deux grands fournisseurs d'IA ont fait l'objet d'un examen réglementaire sur la façon dont les données clients ont été utilisées dans le développement de modèles.

Rémanence des données. Lorsque vous fermez votre compte auprès d'une plateforme IA, que se passe-t-il avec vos connaissances indexées ? La plupart des fournisseurs s'engagent à supprimer les données dans un délai défini. Les embeddings sont le risque non évident ici. Vos documents sont encodés sous forme de vecteurs denses qui capturent leur contenu sémantique. Les embeddings ne sont pas le texte original, mais ils ne sont pas non plus dénués de sens — avec suffisamment d'efforts de reconstruction, les embeddings peuvent révéler le contenu approximatif des documents à partir desquels ils ont été générés. La question de savoir si les procédures de suppression des fournisseurs s'étendent aux stores d'embeddings, aux systèmes de sauvegarde et aux poids de modèles dérivés est rarement précisée dans les accords entreprise standard.

Le manque des cadres de conformité

HIPAA, GDPR, FINRA et SOC 2 ont été rédigés pour un monde où les données restent dans des périmètres définis. Le modèle de conformité suppose que vous savez où se trouvent vos données, qui peut y accéder et à quoi elles servent. L'inférence IA remet en cause ces trois hypothèses.

Le cadre des accords de partenariat commercial (BAA) de HIPAA exige que les entités couvertes concluent des BAA avec tout fournisseur gérant des informations de santé protégées. La plupart des fournisseurs d'IA d'entreprise signeront un BAA. Mais le BAA gouverne les obligations du fournisseur — il ne modifie pas l'endroit où l'inférence se produit ni si les données sont traitées en toute sécurité pendant cette inférence. Un BAA signé avec un fournisseur d'IA cloud qui exécute l'inférence sur une infrastructure partagée est un instrument contractuel, pas une garantie architecturale.

Les exigences de résidence des données et de limitation des finalités du GDPR sont également mises à rude épreuve par l'IA cloud. L'exigence de l'article 5 selon laquelle les données personnelles doivent être « collectées pour des finalités déterminées, explicites et légitimes, et ne pas être traitées ultérieurement d'une manière incompatible avec ces finalités » crée une véritable ambiguïté lorsque des requêtes contenant des données personnelles sont envoyées à un fournisseur d'IA cloud pour inférence. L'inférence est-elle une finalité compatible ? Constitue-t-elle un traitement au sens du GDPR ? Les équipes juridiques l'interprètent différemment. L'ambiguïté elle-même est un risque de conformité.

Les exigences de supervision des communications de la FINRA exigent que les entreprises tiennent des enregistrements complets des communications avec les clients. Si l'IA aide à rédiger ces communications, la piste d'audit doit capturer les informations utilisées par l'IA et leur provenance. Les fournisseurs d'IA cloud ne génèrent pas de journaux d'audit dans le format attendu par les examinateurs de la FINRA. Les équipes de conformité finissent par construire des systèmes de journalisation manuels en guise de solution de contournement — ce qui est fragile, coûteux et incomplet.

Le choix le moins risqué est de plus en plus architectural plutôt que contractuel. Les contrats lient les fournisseurs à des obligations. L'architecture élimine complètement l'exposition.

12 questions à poser à votre fournisseur d'IA

Avant de signer un accord IA d'entreprise, obtenez des réponses écrites à ces questions. Les réponses vagues sont informatives.

1. Où l'inférence se produit-elle ? Précisément : quelles régions cloud, quels fournisseurs d'infrastructure, et pouvez-vous garantir la résidence des données dans une géographie spécifique ?

2. Mes documents ou requêtes sont-ils utilisés pour l'entraînement des modèles ? Demandez la clause contractuelle spécifique, pas une assurance verbale. Demandez si cela s'applique également au fine-tuning.

3. Mes embeddings sont-ils isolés des autres clients ? L'infrastructure d'embedding partagée est plus courante que les fournisseurs ne l'indiquent.

4. Quelle est votre politique de suppression des données ? Que supprime-t-on, quand et comment ? La suppression s'étend-elle aux embeddings, aux sauvegardes et aux artefacts de modèles dérivés ?

5. Puis-je auditer les données envoyées lors de l'inférence ? Quels journaux existent ? Qui peut y accéder ? Sous quel format sont-ils disponibles pour l'export ?

6. Pouvez-vous prendre en charge un déploiement VPC ou une inférence sur site ? Si oui, à quoi ressemble l'architecture ? Quelles dépendances externes subsistent ?

7. Disposez-vous d'un BAA pour les charges de travail couvertes par HIPAA ? Si oui, couvre-t-il spécifiquement l'inférence IA ?

8. Que se passe-t-il avec mes données si je résilie le contrat ? Délai, processus et mécanisme de vérification.

9. Qui au sein de votre entreprise a accès à mes documents indexés ? Les ingénieurs support ? Les chercheurs en ML ? L'accès est-il journalisé ?

10. Réalisez-vous des tests de pénétration par des tiers ? Date des derniers tests ? Pouvez-vous partager le résumé exécutif ?

11. Comment gérez-vous une violation de données impliquant des bases de connaissances clients ? Précisément : délais de notification, portée de l'enquête et obligations de remédiation.

12. Des sous-traitants interviennent-ils dans l'inférence ? De nombreuses plateformes IA utilisent des infrastructures tierces — fournisseurs de GPU cloud, services d'API d'embedding — qui introduisent des points d'exposition supplémentaires aux données. Qui sont-ils et quelles sont leurs obligations ?

La réponse architecturale

Le déploiement en air-gap élimine ces questions car l'IA ne rappelle jamais l'extérieur. L'inférence sur site signifie que l'ensemble du pipeline de traitement — génération d'embeddings, recherche vectorielle, reclassement, inférence du modèle — s'exécute dans votre infrastructure. Il n'y a pas d'appel API externe lors de l'exécution des requêtes. Il n'y a pas de transfert de données sortant. La surface d'attaque est votre propre infrastructure, que votre équipe de sécurité contrôle et audite.

Ce n'est pas un compromis pour les secteurs hautement réglementés — c'est la seule architecture qui résout pleinement le manque des cadres de conformité. Les protections contractuelles ont de la valeur. Les garanties architecturales en ont davantage. Lorsque le modèle s'exécute sur votre matériel, la réponse à « où sont allées mes données lors de l'inférence ? » est : nulle part. Elles sont restées ici. Vous pouvez le vérifier. Vos auditeurs peuvent le vérifier. Vos clients peuvent le vérifier.

Pour une analyse détaillée de la façon d'évaluer la posture de sécurité IA d'entreprise de votre fournisseur actuel ou potentiel, utilisez les questions complémentaires ci-dessus comme cadre de départ.