Vai al contenuto principale
Quando un auditor chiede come il tuo gateway AI applica un Trust Services Criterion, gli screenshot di una dashboard non bastano. Questa ricetta trasforma i controlli che già esegui su OrcaRouter in evidenza SOC 2 AI che gli auditor possono verificare indipendentemente: installa il pack SOC 2, osservalo in observe mode, passa a enforce, poi esporta un report di readiness firmato crittograficamente e condividi un link in sola lettura. Tutto quanto segue è configurazione del workspace nella console — la tua app continua a chiamare /v1/chat/completions invariata.
Sfogliare il catalogo e leggere la readiness sono aperti a qualsiasi Member e gratuiti. Installare un pack, generare un report, andare live e impostare la residency sono azioni Admin del workspace e richiedono un piano a pagamento — il gateway applica entrambi lato server. Le rotte di gestione della compliance sotto /api/compliance/* usano la tua sessione di console, non una chiave di relay.

​
1. Il workflow di evidenza SOC 2 AI in quattro mosse

Una traccia di evidenza SOC 2 su OrcaRouter è quattro passi che esegui una volta, poi ri-esegui il report ogni volta che l’auditor vuole uno snapshot fresco:

Installa il pack

Il pack soc2 materializza un guardrail e una policy del firewall mappati sui Trust Services Criteria — installati prima in modalità observe.

Osserva, poi applica

Observe raccoglie evidenza “avrebbe-bloccato” con zero blast radius; il go-live porta gli stessi controlli all’applicazione.

Genera un report firmato

Esporta un report di readiness firmato con Ed25519, con hash SHA-256, come PDF, JSON o CSV.

Condividi con l'auditor

Consegna un link di condivisione in sola lettura; l’auditor verifica la firma contro la chiave pubblica di OrcaRouter — nessun account necessario.
Il resto di questa pagina percorre tutti e quattro con un esempio SOC 2 concreto.

​
2. Installa il pack SOC 2

Apri Compliance nella console e sfoglia il catalogo (GET /api/compliance/catalog, Member). Il pack soc2 mappa sui AICPA SOC 2 Trust Services Criteria. I suoi controlli applicati dal gateway sono la gestione di dati riservati (TSC CC6.1), il monitoraggio del sistema (TSC CC7.2) e una traccia di audit delle chiamate a tool (TSC CC7.2). Installalo (Admin del workspace, piano a pagamento): 
POST /api/compliance/packs/soc2/install
Installare materializza due oggetti di applicazione in un’unica transazione atomica:
  • un guardrail di workspace — il piano della content-policy (PII, segreti, e il resto dei criteri che filtrano il testo di richiesta/risposta), e
  • una policy del firewall di workspace — il piano delle azioni (chiamate a tool, dispatch MCP ed egress che mappano sui criteri di accesso e change-management).
Il pack atterra in modalità observe per default. In observe, le azioni dei guardrail sono forzate a flag e la policy del firewall gira in shadow — ogni controllo registra cosa avrebbe fatto senza toccare una singola richiesta live. Quello è il tuo primo lotto di evidenza.
Alcune clausole dei Trust Services sono organizzative — formazione del personale, accordi con i vendor — e un gateway non può applicarle. Il report le dichiara onestamente come gap anziché rivendicare una copertura che non può produrre. Vedi modalità di applicazione per come differiscono observe, shadow ed enforce.

​
3. Leggi la tua readiness live

Con il pack installato, Compliance → Readiness (GET /api/compliance/readiness, Member) mostra la tua postura per framework: quanti controlli sono enforcing, quanti sono ancora in observe, e quanti restano gap. Ogni clausola mappa sul controllo di guardrail o firewall che la soddisfa, con uno stato di copertura in cui puoi entrare in dettaglio.
Esegui una settimana in observe prima di applicare. La vista di readiness più il feed Matches del guardrail e il feed Events del firewall ti dicono esattamente cosa avrebbe bloccato — così metti a punto i falsi positivi prima che qualsiasi richiesta reale sia governata.

​
4. Passa da observe a enforce

Una volta che l’evidenza avrebbe-bloccato sembra pulita, porta il pack live (Admin): 
POST /api/compliance/packs/soc2/golive
Il go-live ripristina le azioni dichiarate del guardrail (flag diventa block/mask come progettato) e toglie la policy del firewall dalla shadow mode, così gli stessi controlli ora applicano sul percorso di relay. Opzionalmente promuovi il guardrail del pack a default del workspace nella stessa chiamata, così ogni chiave lo eredita.
Enforce è un cambiamento di postura reale: un prompt bloccato ora restituisce HTTP 400 guardrail_blocked e una chiamata a tool negata restituisce HTTP 400 firewall_blocked. Un block non costa quota — i block di input sono pre-metering e i block di output sono rimborsati — ma fermerà il traffico che viola un controllo. È quello il punto; solo conferma prima la tua evidenza di observe.

​
5. Genera un report firmato

Questo è l’artefatto che consegni all’auditor. Generalo (Admin): 
POST /api/compliance/reports
{
  "framework": "soc2",
  "format": "pdf"
}
format è uno tra pdf, json o csv. Ogni report è firmato con Ed25519 sull’hash di evidenza canonico e porta un hash di contenuto SHA-256, quindi è a prova di manomissione e verificabile indipendentemente — l’auditor non deve fidarsi del tuo screenshot, verifica la firma.
La matrice di copertura di ogni framework installato: clausola → controllo → stato (enforcing / observe / gap), più l’evidenza avrebbe-bloccato catturata durante observe. Le clausole organizzative sono elencate come gap dichiarati, non silenziosamente eliminate.
La firma lega l’hash di evidenza del report alla chiave di firma di OrcaRouter. Chiunque — incluso un auditor senza account OrcaRouter — può confermare che il report non è stato alterato dopo la generazione controllandolo contro la chiave pubblica.

​
6. Condividilo con il tuo auditor

Crea un link di condivisione in sola lettura per il report (Admin): 
POST /api/compliance/reports/:id/share
L’auditor apre l’endpoint di condivisione pubblico — nessun login: 
GET /api/public/compliance/share/:token
Poi verifica la firma da sé contro la chiave pubblicata di OrcaRouter:
EndpointScopo
GET /api/public/compliance/pubkeyRecupera la chiave pubblica Ed25519.
POST /api/public/compliance/verifyConferma la firma + hash di un report.
Un link di condivisione è revocabile. Emettine uno per ingaggio di audit, e revocalo (DELETE /api/compliance/share/:shareId, Admin) quando l’ingaggio si chiude — il report stesso resta nella history del tuo workspace.

​
7. Fissa dove vive il report

Auditor e regolatori spesso tengono a dove è memorizzata l’evidenza. Imposta la regione a cui sono fissati gli artefatti dei report di compliance (us, eu, uk, ap, cn, global) tramite PUT /api/compliance/residency (Admin). Le letture cross-region di un report sono negate.
La residency fissa solo la regione dell’artefatto del report — non è geo-pinning dei dati di inferenza. Controlla dove vive la tua evidenza firmata, non dove vengono instradate le richieste.

​
8. Verifica prima dell’audit

Dimostra che la traccia sia reale prima che qualcuno la revisioni:
1

Conferma la copertura

Apri Readiness e conferma che i controlli SOC 2 che ti aspetti mostrino enforcing, non observe, senza gap a sorpresa.
2

Round-trip della firma

Genera un report, poi fai POST /api/public/compliance/verify contro la chiave pubblica — conferma che validi prima di condividere.
3

Apri il link di condivisione disconnesso

Colpisci GET /api/public/compliance/share/:token in una sessione browser pulita per vedere esattamente cosa vedrà il tuo auditor.

​
Correlati

Riferimento Guardrails

Il piano della content-policy che il pack SOC 2 materializza.

Riferimento Firewall

Il piano delle azioni dietro i controlli di accesso e change del pack.

Modalità di applicazione

Come differiscono observe, shadow ed enforce — e perché observe-first.

Deployment HIPAA

Lo stesso workflow pack-and-report per un framework sanitario.

Logging PII-safe

Tieni le PII grezze fuori dai log da cui la tua evidenza attinge.

Checklist di go-live

Attiva il zero trust prima di portare i controlli a enforce.