Vai al contenuto principale
Stai mettendo un agent AI davanti ai dati dei clienti e il tuo auditor vuole sapere quali clausole Trust Services puoi effettivamente evidenziare. Su un gateway hosted, la risposta onesta è: le clausole che mappano su un controllo in esecuzione sul percorso della richiesta — accesso logico, monitoraggio, e audit delle chiamate a tool — più le clausole organizzative che un proxy non può mai applicare e che deve dichiarare come gap. Questa pagina è il walkthrough soc 2 ai: quali clausole TSC copre il pack SOC 2, l’unico controllo che materializza per la confidenzialità, e come le evidenze risultanti sono firmate. Per il flusso di installazione e il formato del report in profondità, segui i link in fondo — questa pagina è la mappa specifica per SOC 2, non il riferimento completo della Compliance.

​
1. Cosa copre il pack soc 2 ai

Il pack SOC 2 mappa gli AICPA Trust Services Criteria su controlli che girano su ogni richiesta che attraversa il gateway. Tre clausole mappano su applicazione live; due sono organizzative e sono dichiarate come gap anziché rivendicate.
Clausola TSCPianoControllo
CC6.1 Controlli di accesso logicoguardrailblocca le PII confidenziali nei prompt
CC7.2 Monitoraggio del sistemaguardrailregistra ogni decisione del guardrail come evidenza
CC7.2 Rilevamento anomaliefirewallaudit di ogni dispatch di tool
CC8.1 Change management e CC3.1 Risk assessment sono clausole su persone-e-processo. Un proxy non può applicarle, quindi il pack le fa emergere come gap dichiarati (o righe owner-attested) sia nella console che nel report — mai come copertura automatizzata. I gap onesti sono ciò che rende affidabile il resto delle evidenze. Vedi la matrice dei controlli.
I due piani di applicazione sono la stessa macchina di Guardrails e Firewall che configuri a mano. Il pack è il mapping autorato che dice quale controllo esistente soddisfa quale clausola — non porta alcun nuovo motore di runtime. Vedi Contenuti del pack per l’intera anatomia.

​
2. Installa il pack — un esempio concreto

Installare materializza il mapping in una policy di guardrail e una policy di firewall nel tuo workspace, ciascuna taggata con la provenienza del pack. Lo fai dalla console, non da una chiave di relay: Compliance → Catalog → SOC 2 → Install Quella è un’azione da Admin del workspace su un piano a pagamento, e il server applica entrambi. Sotto il cofano la tua sessione di console chiama: 
POST /api/compliance/packs/soc2/install
Non passare mai una chiave di relay sk-orca-… a una rotta di configurazione. Le rotte /api/compliance/* si autenticano con la tua sessione di console, non con la chiave di relay — solo le chiamate al modello /v1/* usano sk-orca-…. Sfogliare il catalogo, i pack installati e la readiness è gratis e aperto a ogni membro del workspace; install, go-live, report e residency sono le azioni Admin gated.
Dopo l’installazione, la riga CC6.1 smette di essere prosa. Il controllo di confidenzialità diventa una regola di guardrail pii reale — azione block, stage input — che puoi aprire, leggere e regolare come qualsiasi altra regola. Il controllo di monitoraggio CC7.2 registra ogni decisione del guardrail come evidenza, e il controllo del firewall imposta ogni dispatch di tool al verdetto audit.
Questo controllo agisce sulla richiesta: le PII confidenziali sono bloccate in fase di input prima che il modello le veda. La gestione live delle PII su output / streaming è in roadmap, quindi per il lato output l’evidenza di monitoraggio è ciò che un auditor legge per CC7.2 sul periodo del report.

​
3. Prima osserva, poi vai live

Un’installazione SOC 2 non inizia a bloccare il traffico dal primo giorno. Le installazioni atterrano in observe mode: le azioni del guardrail sono forzate a flag e la policy del firewall gira in shadow (solo-log). Ottieni evidenze “avrebbe-bloccato” contro il traffico reale prima che qualcosa applichi. Quando le evidenze sembrano giuste, un Admin del workspace promuove il pack al go-live, che ripristina le azioni dichiarate — il controllo CC6.1 inizia a bloccare, il controllo del firewall continua ad auditare — e opzionalmente promuove le policy materializzate a default del workspace. Questa è la stessa disciplina descritta in Observe vs enforce.

​
4. Evidenze firmate che il tuo auditor può verificare

Il punto del pack è il report. Le evidenze SOC 2 sono generate come un report firmato Ed25519 con un hash di contenuto SHA256, esportabile come CSV, JSON o PDF, e verificabile pubblicamente — il tuo auditor controlla la firma senza un login OrcaRouter.
Ogni riga TSC porta il suo status — covered, observe, gap o attested — e quante volte il controllo si è effettivamente attivato sul periodo. Un controllo CC6.1 che ha bloccato 4.000 richieste si legge diversamente per un auditor rispetto a uno con zero match, e il report mostra entrambi.
Ogni controllo materializzato registra il suo control_id (es. soc2.confidentiality), la clausola verbatim (TSC CC6.1 Logical access controls), il piano, e l’id dell’oggetto policy live che la applica — così l’auditor percorre clausola → controllo → policy applicante → match, senza alcun passo inferito.
Recupera la chiave pubblica di firma su GET /api/public/compliance/pubkey, invia il report a POST /api/public/compliance/verify, o apri un link di condivisione per auditor con scope su GET /api/public/compliance/share/:token. Nessun account richiesto.
Vedi il report firmato per il layout completo da copertina a footer e Verifica un report per il walkthrough di verifica.

​
5. Region-stamp delle tue evidenze SOC 2

I report SOC 2 sono archiviati e serviti sotto la tua regione di residency dichiarata — us / eu / uk / ap / cn / global — e un report viene servito solo sotto una regione corrispondente; le letture cross-region vengono trattenute. Un Admin del workspace la imposta tramite PUT /api/compliance/residency.
La residency qui è la regione dell’artefatto di evidenze — dove i report firmati vivono e sono serviti. Non è geo-blocco dei dati di inferenza. Vedi Data residency e Cross-region per il confine.
I log delle richieste hanno default di retention di 30 giorni (server-clamped a un massimo massimo di 180 giorni), e una cancellazione utente esegue una finestra di grazia di 30 giorni poi uno scrub PII — entrambi rilevanti quando un auditor chiede della tua postura di retention. Vedi Retention e Diritto alla cancellazione.

​
6. Dove andare dopo

Contenuti del pack

L’intera anatomia di un pack — entrambi i piani, status e provenienza.

Installa un pack

Il flusso di installazione end-to-end, observe mode e go-live.

Report firmato

Cosa contiene il report di evidenze firmato Ed25519.

Matrice dei controlli

Ogni clausola, il suo piano, e se è covered, observed o un gap.

Framework

L’intero catalogo — HIPAA, GDPR, l’EU AI Act, ISO 27001, e altro.

Guardrails vs Firewall

I due piani su cui un pack SOC 2 scrive, eseguiti da un unico resolver.
SOC 2 su un gateway hosted è la disciplina di essere precisi: mappa le clausole che un proxy può applicare su controlli live, dichiara quelle che non può, e firma le evidenze così la linea tra le due regge all’audit.