Points clés
- SOC 2 et ISO 27001 certifient les contrôles de votre organisation, pas un outil — ne dites jamais "Ollama est conforme SOC 2" ou "vLLM est certifié ISO 27001". Présentez tout comme une préparation aux contrôles qu'un auditeur vérifiera.
- SOC 2 évalue selon cinq Trust Services Criteria (sécurité, disponibilité, confidentialité, intégrité du traitement, vie privée) ; ISO 27001 évalue selon les contrôles Annex A au sein d'un ISMS documenté.
- Le point de terminaison d'inférence a besoin de contrôle d'accès et de journalisation structurée — la plupart des moteurs auto-hébergés (Ollama, vLLM, TGI) n'en fournissent rien par défaut et ont besoin d'une passerelle en amont.
- Chiffrez les poids du modèle et les journaux de prompts/réponses au repos (chiffrement disque) et en transit (TLS) — les mêmes contrôles que vous appliquez déjà à tout autre stockage de production.
- Même les modèles open-weight nécessitent une évaluation documentée du risque fournisseur : identité de l'éditeur, vérification de checksum, conditions de licence et CVE connues dans le stack de service.
- Les plateformes d'automatisation de la conformité (Vanta, Drata, Secureframe) collectent des preuves automatiquement pour l'infrastructure cloud, mais un serveur d'inférence auto-hébergé nécessite généralement une intégration sur mesure ou un dépôt manuel de preuves.
- Cet article n'est pas un conseil juridique ou de conformité — votre auditeur prend la décision finale de périmètre et de contrôles.
Ceci Est-Il un Conseil Juridique ou de Conformité ?
Non — ce guide n'est pas un conseil juridique ou de conformité. Il explique, à un niveau technique, les catégories de contrôles qu'un auditeur SOC 2 ou ISO 27001 vérifie généralement et comment elles s'appliquent à un déploiement de LLM auto-hébergé. Le fait qu'un contrôle précis satisfasse votre audit dépend du jugement de votre auditeur, de l'évaluation des risques de votre organisation et de la déclaration de périmètre exacte que vous déposez. Consultez un auditeur qualifié ou votre service conformité avant de planifier un audit ou de formuler une déclaration de conformité.
Que Demandent les Trust Services Criteria SOC 2 ?
SOC 2 évalue une organisation selon cinq Trust Services Criteria (TSC), et chacun s'applique à un système LLM auto-hébergé dès qu'il touche des données de production. Un auditeur ne teste pas le modèle — il teste si votre organisation peut démontrer que le contrôle a existé et fonctionné sur la période de revue.
Utilisez le critère sécurité si votre rapport ne couvre que le critère de base (obligatoire dans tout rapport SOC 2). Ajoutez disponibilité si le LLM sert un flux de production avec un engagement de disponibilité. Ajoutez confidentialité si les prompts ou sorties contiennent des données contractuellement protégées.
| Critère | Ce que vérifie l'auditeur | Contrôle sur le stack LLM |
|---|---|---|
| Sécurité | Contrôle d'accès, journalisation, gestion des vulnérabilités | RBAC + MFA sur la passerelle d'inférence |
| Disponibilité | Disponibilité, redondance, plan de reprise | Service multi-nœuds + sauvegardes testées |
| Confidentialité | Classification des données, besoin d'en connaître | Poids + journaux chiffrés au repos |
| Intégrité du traitement | Exactitude, exhaustivité, rapidité | Modèles figés par version + journaux de sortie |
| Vie privée | Information, consentement, minimisation | Politique documentée de rétention des prompts |
Que Demande l'Annex A d'ISO 27001 ?
ISO 27001 certifie le système de management de la sécurité de l'information (ISMS) d'une organisation, et l'Annex A est la liste de référence des contrôles dans laquelle l'ISMS puise — pas une checklist appliquée directement à un seul système. Un LLM auto-hébergé se situe dans le périmètre de l'ISMS comme tout autre actif : il nécessite une évaluation des risques, une entrée dans la Statement of Applicability, et des preuves que les contrôles pertinents fonctionnent.
| Domaine Annex A | Correspondance sur le stack LLM |
|---|---|
| A.5 Organisationnel | Revue du risque fournisseur pour l'éditeur du modèle |
| A.5.19–22 Relations fournisseurs | Provenance du modèle & vérification licence |
| A.8 Technologique | Durcissement du point d'accès, chiffrement, journalisation |
| A.8.16 Surveillance | Journaux d'audit des requêtes/réponses d'inférence |
| A.8.24 Cryptographie | TLS en transit, chiffrement disque au repos |
| A.5.29 Continuité | Runbook de réponse aux incidents pour le service de modèle |
Quel Contrôle d'Accès et Quelle Journalisation le Point de Terminaison Nécessite-t-il ?
Un auditeur s'attend à voir qui a appelé le modèle, avec quel identifiant, et quand — une exigence qu'aucun des moteurs auto-hébergés courants ne satisfait sans passerelle en amont. Ollama se lie par défaut à `127.0.0.1:11434` et n'a pas de comptes utilisateurs ; vLLM et Hugging Face TGI exposent une API HTTP compatible OpenAI sans authentification intégrée.
Utilisez une passerelle API (Kong, Envoy, ou la couche de gestion API d'un fournisseur cloud) devant le moteur d'inférence pour ajouter des clés API ou OAuth2 par appelant, puis journalisez chaque requête avec identité, horodatage, version du modèle et nombre de tokens vers un système ingérable par votre SIEM.
- Authentification : clés API ou OAuth2 sur la passerelle, jamais un jeton partagé par tous les appelants
- Autorisation : accès basé sur les rôles — qui peut appeler quel modèle, qui voit les points de terminaison admin/métriques
- Champs du journal d'audit : identité de l'appelant, horodatage, modèle + version, point de terminaison appelé, statut de réponse
- Accès admin : MFA requis pour tout accès shell ou configuration à l'hôte d'inférence
Comment Chiffrer les Poids du Modèle et les Journaux de Prompts ?
Les poids du modèle, les journaux de prompts et de réponses ont besoin du même chiffrement au repos et en transit qu'un auditeur attend déjà pour tout autre stockage de production. Le disque du serveur d'inférence contient souvent aussi des prompts en cache, des adaptateurs fine-tunés et des journaux, eux, bien sensibles.
Utilisez le chiffrement complet du disque (LUKS sur Linux, BitLocker sur Windows, FileVault sur macOS) sur l'hôte d'inférence comme base. Ajoutez la terminaison TLS sur la passerelle pour tout appel API entrant — n'exposez jamais le port d'inférence brut en HTTP en clair, même à l'intérieur d'un VPC.
- Au repos : chiffrement complet du disque, volume chiffré pour la base de journaux de prompts
- En transit : TLS entre appelant → passerelle → moteur d'inférence, aucun saut interne en clair
- Gestion des clés : clés stockées dans un KMS/vault, rotation selon un calendrier documenté
À Quoi Ressemble la Gestion du Changement pour les Mises à Jour de Modèle ?
Tout changement de version de modèle, de quantisation ou de prompt système est un changement de production et nécessite la même piste d'approbation qu'un déploiement de code. Les auditeurs cherchent spécifiquement des preuves que les changements ont été revus et approuvés avant la mise en production.
- Figer l'artefact exact du modèle (checksum, pas un tag mutable "latest")
- Exiger une approbation documentée avant tout changement de modèle ou de prompt système en production
- Journaliser chaque changement avec qui l'a approuvé, quand, et pourquoi
- Conserver un chemin de retour arrière vers l'artefact précédent figé par version
Comment Évaluer le Risque Fournisseur pour les Modèles Open-Weight ?
"Open-weight" ne signifie pas "sans fournisseur" — l'éditeur du modèle est un acteur de la chaîne d'approvisionnement au même titre qu'un fournisseur SaaS, et un auditeur attend une évaluation documentée du risque à ce sujet. C'est l'un des contrôles les plus souvent oubliés : les équipes traitent un fichier GGUF ou safetensors téléchargé comme interne, alors qu'il provient de l'extérieur de l'organisation.
- Identité de l'éditeur : organisation connue (Meta, Mistral AI, Alibaba/Qwen, Microsoft) vs. source anonyme
- Vérification de checksum : correspondance SHA-256 avec le hash publié par l'éditeur avant déploiement
- Revue de licence : conditions d'usage commercial, restrictions de redistribution
- CVE du stack de service : suivre les vulnérabilités connues dans llama.cpp, vLLM ou TGI — pas seulement le fichier modèle
À Quoi Ressemble la Réponse aux Incidents pour un Système de Service de Modèle ?
Un système de service de modèle a des catégories d'incidents qu'un runbook d'application web standard ne couvre pas — exfiltration de modèle, injection de prompt qui fuit des données via la sortie du modèle, compromission du point de terminaison — chacune nécessite un chemin de réponse nommé.
- Exemples de déclencheurs : modification non autorisée du fichier de poids, pic de requêtes au niveau d'un identifiant, motif d'injection de prompt détecté dans les journaux
- Étape de confinement : capacité à isoler ou mettre hors ligne le point de terminaison sans panne système complète
- Préservation des preuves : conserver les journaux bruts pour la fenêtre de l'incident
- Fréquence des tests : exercice sur table au moins annuel, documenté
Que Doit Couvrir une Politique de Rétention pour les Journaux de Prompts ?
Les journaux de prompts sont les données les plus à risque produites par votre stack LLM, car ils contiennent souvent le même contenu sensible qu'un utilisateur saisirait dans tout autre système métier. Une politique écrite de rétention est un contrôle qu'un auditeur demandera spécifiquement à voir.
- Fenêtre de rétention : définir un nombre précis de jours/mois, pas "indéfiniment"
- Contrôle d'accès : liste d'accès restreinte propre au stockage des journaux de prompts
- Minimisation : journaliser les métadonnées par défaut ; contenu complet uniquement si justifié et limité dans le temps
- Processus de suppression : documenté et idéalement automatisé
Comment Segmenter le Serveur d'Inférence sur le Réseau ?
Le serveur d'inférence doit se trouver dans sa propre zone réseau, accessible uniquement via la passerelle authentifiée — pas à plat sur le même sous-réseau que les serveurs applicatifs généraux. Utilisez un VLAN ou sous-réseau dédié, avec des règles de pare-feu n'autorisant le trafic entrant que depuis la passerelle API.
Quels Outils Auto-Hébergés Fournissent des Contrôles Pertinents pour l'Audit ?
Aucun des moteurs d'inférence courants ne fournit une piste d'audit finalisée — la différence tient à ce que vous devez construire vous-même par rapport à ce qu'une plateforme fournit déjà. Ceci est une comparaison de préparation, pas une déclaration de conformité sur l'un de ces outils.
| Outil | Auth/Journalisation intégrée | Instrumentation nécessaire |
|---|---|---|
| Ollama | Aucune (lié à localhost) | Reverse proxy + auth + export SIEM |
| vLLM | Métriques Prometheus uniquement | Passerelle API (OAuth2/clés) + journal d'audit |
| Hugging Face TGI | Métriques Prometheus uniquement | Passerelle API + journal d'audit, comme vLLM |
| Plateformes d'entreprise | RBAC + journalisation intégrés | Documentation ISMS toujours requise |
Une Plateforme d'Automatisation de la Conformité Peut-Elle Aider un LLM Auto-Hébergé ?
Les plateformes d'automatisation de la conformité — Vanta, Drata et Secureframe sont les trois les plus utilisées — collectent automatiquement des preuves depuis l'infrastructure cloud, les systèmes RH et les fournisseurs d'identité, mais un serveur d'inférence auto-hébergé sur site se situe généralement hors de leur liste d'intégrations par défaut.
Utilisez une plateforme d'automatisation de la conformité si vous gérez un programme SOC 2 ou ISO 27001 plus large dans l'entreprise et souhaitez une surveillance continue pour tout sauf la couche LLM auto-hébergée.
| Plateforme | Focus |
|---|---|
| Vanta | Large couverture de frameworks, courant chez les startups |
| Drata | Surveillance continue des contrôles, intégrations profondes |
| Secureframe | Workflows combinés SOC 2 + ISO 27001 |
Ces plateformes automatisent la collecte de preuves pour votre environnement de contrôle plus large — elles ne certifient pas votre infrastructure LLM auto-hébergée elles-mêmes, et PromptQuorum n'a actuellement de relation d'affiliation avec aucune d'entre elles (liens produits divulgués uniquement).
Quelles Sont les Erreurs les Plus Courantes de Préparation à l'Audit ?
La plupart des constats d'audit sur les LLM auto-hébergés viennent du fait de traiter le serveur d'inférence hors de l'environnement de contrôle IT normal.
- Erreur : Supposer qu'un outil open source "auditable" (code visible) a déjà été audité. Correction : documenter votre propre évaluation des risques de l'éditeur et du stack de service.
- Erreur : Laisser l'API d'inférence accessible sans passerelle "car elle n'est accessible qu'en interne". Correction : l'accessibilité réseau n'est pas une déclaration de contrôle d'accès — ajoutez l'authentification quand même.
- Erreur : Journaliser le texte complet des prompts dans le même journal d'accès que la surveillance de disponibilité. Correction : séparer les deux stockages.
- Erreur : Traiter un changement de version de modèle comme un déploiement de routine sans piste d'approbation. Correction : appliquer la même approbation de gestion du changement que pour les déploiements de code.
- Erreur : Aucun plan de réponse aux incidents spécifique aux modes de défaillance du service de modèle. Correction : ajouter ces déclencheurs au plan IR existant et le tester au moins une fois.
Quelle Est la Checklist de Préparation à l'Audit pour un LLM Auto-Hébergé ?
Parcourez cette checklist avant le début des travaux de terrain de votre auditeur — chaque élément correspond à une catégorie de contrôle traitée ci-dessus.
- 1Ajouter le système LLM auto-hébergé à votre déclaration de périmètre ISMS/SOC 2
Why it matters: Un système non documenté dans le périmètre est un constat, même si chaque contrôle technique est en place. - 2Cartographier les Trust Services Criteria ou contrôles Annex A pertinents sur votre stack réel
Why it matters: Les auditeurs testent selon la cartographie que vous fournissez. - 3Placer une passerelle authentifiée devant chaque point de terminaison d'inférence
Why it matters: Élimine le constat le plus fréquent : une API de modèle non authentifiée. - 4Activer la journalisation structurée des requêtes avec identité et horodatage
Why it matters: C'est la preuve principale demandée pour le critère sécurité. - 5Chiffrer le disque de l'hôte et le stockage des journaux de prompts ; imposer TLS sur la passerelle
Why it matters: Satisfait le critère confidentialité et les contrôles cryptographiques A.8.24. - 6Rédiger et suivre une procédure de gestion du changement pour les mises à jour de modèle
Why it matters: Prouve l'intégrité du traitement et fournit un chemin de retour arrière documenté. - 7Documenter une évaluation du risque fournisseur pour chaque modèle open-weight en production
Why it matters: Referme le contrôle le plus souvent oublié. - 8Publier une politique de rétention et de suppression pour les journaux de prompts/réponses
Why it matters: Directement requis pour le critère vie privée. - 9Segmenter le serveur d'inférence dans sa propre zone réseau
Why it matters: Limite le rayon d'impact et fournit un diagramme réseau clair. - 10Rédiger un runbook de réponse aux incidents avec déclencheurs spécifiques au modèle et le tester une fois
Why it matters: Les auditeurs vérifient que le plan existe et a été exercé.
Questions Fréquemment Posées
Cet article est-il un conseil juridique ou de conformité ?
Non. Ce guide explique, à un niveau technique, les catégories de contrôles qu'un auditeur SOC 2 ou ISO 27001 vérifie généralement. Il ne remplace pas un auditeur qualifié ou votre service conformité — consultez-en un avant de planifier un audit ou de formuler une déclaration de conformité.
Utiliser Ollama, vLLM ou Hugging Face TGI rend-il notre infrastructure IA conforme SOC 2 ?
Aucun outil unique ne rend une organisation conforme. La conformité est un résultat d'audit portant sur l'ensemble des contrôles de votre organisation. Ollama, vLLM et TGI peuvent soutenir les exigences techniques (une fois authentification, journalisation et chiffrement ajoutés), mais aucun n'est "conforme SOC 2" ou "certifié ISO 27001" en tant que produit logiciel.
Quelle est la différence entre SOC 2 Type I et Type II pour l'infrastructure IA ?
Type I évalue si les contrôles étaient conçus de manière appropriée à un instant donné. Type II évalue si ces contrôles ont fonctionné efficacement sur une période de revue, généralement 6 à 12 mois. Pour un point de terminaison d'inférence, Type II signifie que vos journaux d'accès et preuves de gestion du changement doivent exister en continu sur toute cette fenêtre.
Les modèles open-weight nécessitent-ils une évaluation du risque fournisseur alors qu'il n'y a pas de fournisseur logiciel ?
Oui. L'éditeur du modèle (Meta, Mistral AI, Alibaba/Qwen, ou autres) est un acteur de la chaîne d'approvisionnement au même titre qu'un fournisseur SaaS. Une évaluation documentée doit couvrir l'identité de l'éditeur, la vérification de checksum, les conditions de licence et les CVE connues dans le stack de service.
L'auto-hébergement d'un LLM réduit-il notre périmètre d'audit par rapport à une API LLM cloud ?
Il modifie le périmètre plutôt que de simplement le réduire. L'auto-hébergement supprime la relation de sous-traitant tiers créée par une API cloud, mais votre organisation assume désormais tous les contrôles auparavant gérés par le fournisseur cloud.
Quelle journalisation un auditeur attend-il sur le point de terminaison d'inférence ?
Au minimum : identité de l'appelant, horodatage, modèle et version appelés, point de terminaison, statut de réponse, exportés vers un stockage à accès en écriture restreint. Le contenu complet des prompts/réponses est généralement conservé dans un stockage séparé, avec sa propre politique de rétention.
Combien de temps devons-nous conserver les journaux de prompts comme preuve d'audit ?
Il n'existe pas de chiffre universel — cela dépend de l'évaluation des risques de votre organisation et des attentes de votre auditeur, équilibrées avec les principes de minimisation des données. Définissez une fenêtre de rétention précise par écrit, jamais "indéfiniment".
Les plateformes comme Vanta, Drata ou Secureframe peuvent-elles surveiller un serveur LLM auto-hébergé ?
Elles automatisent bien la collecte de preuves pour l'infrastructure cloud, les fournisseurs d'identité et les systèmes de tickets, mais un serveur d'inférence auto-hébergé sur site se situe généralement hors de leur liste d'intégrations par défaut.
Quel est le constat d'audit le plus fréquent pour une infrastructure IA auto-hébergée ?
Une API d'inférence accessible sans authentification, justifiée en interne par "elle n'est accessible que sur notre réseau". Accessibilité réseau et contrôle d'accès sont deux déclarations distinctes.
Faut-il choisir vLLM/TGI ou une plateforme d'entreprise pour faciliter la préparation à l'audit ?
vLLM et Hugging Face TGI offrent un contrôle total mais exigent de construire vous-même l'authentification, la journalisation et le chiffrement. Les plateformes d'entreprise intègrent souvent RBAC et journalisation d'audit, réduisant le travail d'instrumentation — mais la documentation ISMS environnante reste nécessaire dans les deux cas.
Où Trouver des Sources Complémentaires ?
- AICPA SOC 2 Trust Services Criteria (aicpa-cima.com) — le référentiel officiel Trust Services Criteria
- ISO/IEC 27001:2022 (iso.org) — le texte officiel de la norme et la référence des contrôles Annex A
- OWASP Top 10 for LLM Applications (owasp.org/www-project-top-10-for-large-language-model-applications) — risques de sécurité spécifiques aux déploiements LLM