Passer au contenu principal
Vous placez un agent IA devant des données clients et votre auditeur veut savoir quelles clauses Trust Services vous pouvez réellement attester. Sur une passerelle hébergée, la réponse honnête est : les clauses qui correspondent à un contrôle tournant sur le chemin de requête — accès logique, surveillance, et audit des appels d’outils — plus les clauses organisationnelles qu’un proxy ne peut jamais appliquer et doit divulguer comme des lacunes. Cette page est le parcours SOC 2 IA : quelles clauses TSC le pack SOC 2 couvre, l’unique contrôle qu’il matérialise pour la confidentialité, et comment les preuves résultantes sont signées. Pour le flux d’installation et le format de rapport en profondeur, suivez les liens à la fin — cette page est la carte spécifique à SOC 2, pas la référence Compliance complète.

​
1. Ce que le pack SOC 2 IA couvre

Le pack SOC 2 fait correspondre les AICPA Trust Services Criteria à des contrôles qui tournent sur chaque requête franchissant la passerelle. Trois clauses correspondent à une application en direct ; deux sont organisationnelles et sont divulguées comme des lacunes plutôt que revendiquées.
Clause TSCPlanContrôle
CC6.1 Contrôles d’accès logiqueguardrailbloquer les PII confidentielles dans les prompts
CC7.2 Surveillance du systèmeguardrailenregistrer chaque décision de guardrail comme preuve
CC7.2 Détection d’anomaliesfirewallauditer chaque dispatch d’outil
CC8.1 Gestion du changement et CC3.1 Évaluation des risques sont des clauses de personnes-et-processus. Un proxy ne peut pas les appliquer, donc le pack les remonte comme des lacunes divulguées (ou des lignes attestées par le propriétaire) à la fois sur la console et le rapport — jamais comme une couverture automatisée. Les lacunes honnêtes sont ce qui rend le reste des preuves digne de confiance. Voir la matrice de contrôles.
Les deux plans d’application sont la même machinerie Guardrails et Firewall que vous configurez à la main. Le pack est la correspondance rédigée qui dit quel contrôle existant satisfait quelle clause — il ne livre aucun nouveau moteur d’exécution. Voir Contenu du pack pour l’anatomie complète.

​
2. Installer le pack — un exemple concret

Installer matérialise la correspondance en une politique guardrail et une politique firewall dans votre espace de travail, chacune taguée avec la provenance du pack. Vous faites ceci depuis la console, pas une clé de relais : Compliance → Catalog → SOC 2 → Install C’est une action d’Admin de l’espace de travail sur un plan payant, et le serveur applique les deux. Sous le capot, votre session console appelle : 
POST /api/compliance/packs/soc2/install
Ne remettez jamais une clé de relais sk-orca-… à une route de configuration. Les routes /api/compliance/* s’authentifient avec votre session console, pas la clé de relais — seuls les appels de modèle /v1/* utilisent sk-orca-…. Parcourir le catalogue, les packs installés et la readiness est gratuit et ouvert à chaque membre de l’espace de travail ; installer, passer en production, faire un rapport et la résidence sont les actions d’Admin gardées.
Après l’installation, la ligne CC6.1 cesse d’être de la prose. Le contrôle de confidentialité devient une vraie règle de guardrail pii — action block, stage input — que vous pouvez ouvrir, lire et ajuster comme n’importe quelle autre règle. Le contrôle de surveillance CC7.2 enregistre chaque décision de guardrail comme preuve, et le contrôle firewall règle chaque dispatch d’outil sur le verdict audit.
Ce contrôle agit sur la requête : les PII confidentielles sont bloquées au stage input avant que le modèle ne les voie. Le traitement des PII en sortie / streaming en direct est sur la roadmap, donc pour le côté sortie, ce sont les preuves de surveillance qu’un auditeur lit pour CC7.2 sur la période du rapport.

​
3. Observez d’abord, puis passez en production

Une installation SOC 2 ne commence pas à bloquer le trafic dès le premier jour. Les installations atterrissent en mode observe : les actions de guardrail sont contraintes à flag et la politique firewall tourne en shadow (log seul). Vous obtenez des preuves « aurait bloqué » contre le trafic réel avant que quoi que ce soit n’applique. Lorsque les preuves ont l’air correctes, un Admin de l’espace de travail promeut le pack au passage en production, qui restaure les actions déclarées — le contrôle CC6.1 commence à bloquer, le contrôle firewall continue d’auditer — et promeut optionnellement les politiques matérialisées en défaut de l’espace de travail. C’est la même discipline décrite dans Observer vs appliquer.

​
4. Des preuves signées que votre auditeur peut vérifier

Tout l’intérêt du pack est le rapport. Les preuves SOC 2 sont générées comme un rapport signé Ed25519 avec un hash de contenu SHA256, exportable en CSV, JSON ou PDF, et publiquement vérifiable — votre auditeur vérifie la signature sans connexion OrcaRouter.
Chaque ligne TSC porte son statut — covered, observe, gap ou attested — et combien de fois le contrôle s’est réellement déclenché sur la période. Un contrôle CC6.1 qui a bloqué 4 000 requêtes se lit différemment pour un auditeur qu’un avec zéro correspondance, et le rapport montre les deux.
Chaque contrôle matérialisé enregistre son control_id (par ex. soc2.confidentiality), la clause verbatim (TSC CC6.1 Logical access controls), le plan, et l’id de l’objet de politique vivant qui l’applique — de sorte que l’auditeur parcourt clause → contrôle → politique appliquante → correspondances, sans étape inférée.
Récupérez la clé publique de signature à GET /api/public/compliance/pubkey, soumettez le rapport à POST /api/public/compliance/verify, ou ouvrez un lien de partage auditeur à portée limitée à GET /api/public/compliance/share/:token. Aucun compte requis.
Voir le rapport signé pour la disposition complète de la couverture au pied de page et Vérifier un rapport pour le parcours de vérification.

​
5. Estampillez vos preuves SOC 2 par région

Les rapports SOC 2 sont stockés et servis sous votre région de résidence déclarée — us / eu / uk / ap / cn / global — et un rapport n’est servi que sous une région correspondante ; les lectures inter-régions sont retenues. Un Admin de l’espace de travail la définit via PUT /api/compliance/residency.
La résidence ici est la région de l’artefact de preuves — où les rapports signés vivent et sont servis. Ce n’est pas un géo-épinglage des données d’inférence. Voir Résidence des données et Inter-régions pour la frontière.
Les logs de requêtes ont un défaut de rétention de 30 jours (borné par le serveur à un max strict de 180 jours), et une suppression d’utilisateur exécute une fenêtre de grâce de 30 jours puis une purge des PII — les deux pertinents quand un auditeur s’enquiert de votre posture de rétention. Voir Rétention et Droit à l’effacement.

​
6. Où aller ensuite

Contenu du pack

L’anatomie complète d’un pack — les deux plans, les statuts, et la provenance.

Installer un pack

Le flux d’installation de bout en bout, le mode observe, et le passage en production.

Rapport signé

Ce que contient le rapport de preuves signé Ed25519.

Matrice de contrôles

Chaque clause, son plan, et si elle est couverte, observée ou une lacune.

Frameworks

Le catalogue complet — HIPAA, GDPR, l’EU AI Act, ISO 27001, et d’autres.

Guardrails vs Firewall

Les deux plans dans lesquels un pack SOC 2 écrit, exécutés par un seul résolveur.
SOC 2 sur une passerelle hébergée est la discipline d’être précis : faire correspondre les clauses qu’un proxy peut appliquer à des contrôles vivants, divulguer celles qu’il ne peut pas, et signer les preuves de sorte que la ligne entre les deux tienne sous l’audit.