Vai al contenuto principale
Una checklist di framework è un elenco di clausole. Un compliance pack è la stessa checklist con ogni clausola cablata a un controllo che gira davvero sul gateway. Quando installi un pack, OrcaRouter legge il suo mapping clausola-controllo e materializza oggetti di policy reali e modificabili nel tuo workspace — così “SOC 2 CC6.1” smette di essere una riga in un foglio di calcolo e diventa un guardrail che blocca le PII confidenziali prima che raggiungano il modello. Questa pagina spiega cosa contiene un compliance pack AI, come i suoi due piani di applicazione mappano sulle clausole, e la tracciabilità di provenienza che permette a un auditor di seguire qualsiasi clausola fino alla policy esatta che la applica. Per il flusso di installazione e il report firmato, segui i link in fondo.

​
1. Un pack è un mapping clausola-controllo, non una nuova applicazione

Un pack non porta alcun nuovo motore di runtime. Ogni controllo che porta riusa la stessa macchina di Guardrails e Firewall che già configuri a mano — un pack è il mapping autorato che dice quale controllo esistente soddisfa quale clausola. Ogni pack abbraccia due piani di applicazione:

Piano guardrail

I controlli su testo / dati — clausole su dati confidenziali, disclosure di PII, difesa da injection o disclosure obbligatorie mappano su regole di guardrail (pii, regex, llm_judge e affini) con un’azione block, mask o flag.

Piano firewall

I controlli sulle chiamate a tool — clausole su eccessiva agency, azioni pericolose o egress mappano su regole di firewall con un verdetto allow / audit / deny sulla superficie inbound, response, mcp o egress.
Installare il pack fonde i suoi controlli selezionati in un guardrail e una policy di firewall, taggati con la provenienza del pack, così co-applicano attraverso il normale resolver e ogni attachment e percorso di history esistente continua a funzionare.
Un pack copre solo i controlli applicabili dal gateway. Le clausole organizzative — formazione del personale, Business Associate Agreement, accesso fisico — non possono mai essere applicate da un proxy, quindi il report le dichiara come gap (o come owner-attested) anziché rivendicare una copertura falsa. Vedi la matrice dei controlli.

​
2. Una clausola, end to end — un esempio concreto

Prendi il pack SOC 2. Mappa tre clausole dei Trust Services su tre controlli live:
ClausolaPianoControllo
CC6.1 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
Lo installi dalla console — Compliance → Catalog → SOC 2 → Install — che è solo per Admin del workspace e chiama POST /api/compliance/packs/soc2/install per te sotto la tua sessione di console. Non passi mai una chiave di relay sk-orca-… a una rotta di configurazione; contenuti e policy vivono interamente dietro il tuo login di console. Dopo l’installazione, la riga CC6.1 non è più prosa — è una regola di guardrail che puoi aprire, leggere e regolare come qualsiasi altra.

​
3. Tracciabilità di provenienza — dalla clausola alla policy applicante

La ragione per cui un pack è auditabile è che il legame tra una clausola e la policy che la applica è registrato, non implicito. Ogni controllo che il pack materializza porta:
Un control_id stabile (es. soc2.confidentiality) e il testo verbatim della clausola (TSC CC6.1 Logical access controls), più un link alla fonte ufficiale così un auditor legge la regolamentazione, non solo la nostra parafrasi.
Se il controllo vive sul piano guardrail o firewall, e l’id della policy guardrail o firewall esatta che l’installazione ha materializzato. Quell’id è ciò che lega una riga nel report a un oggetto live e modificabile nel tuo workspace.
covered, observe, gap o attested — e, sul periodo del report, quante volte quel controllo si è effettivamente attivato. Una clausola con zero match e una clausola che ha bloccato 4.000 richieste si leggono diversamente per un auditor, e il report mostra entrambe.
Ogni pack porta una riga MappedBy — chi ha autorato il mapping clausola-controllo, la sua versione, e l’onesto disclaimer che copre solo i controlli applicabili dal gateway e che non è esso stesso una certificazione. Quella riga è stampata sulla copertina del report firmato.
Messo insieme, questo è il lineage che un auditor percorre: clausola → id del controllo → guardrail o policy firewall applicante → i match che ha prodotto in questo periodo → chi ha autorato il mapping. Nessun passo è inferito.
La stessa matrice di copertura alimenta sia la console che il report, così le due non possono mai divergere silenziosamente. Una clausola che il framework si aspetta ma che nessun pack installato copre rende sempre come un gap dichiarato su entrambe le superfici.

​
4. Prima osserva, poi applica

Un pack non inizia a bloccare il traffico nel momento in cui lo installi. Le installazioni atterrano in observe mode: le azioni del guardrail sono forzate a flag e la policy del firewall gira in shadow (solo-log). Il pack produce evidenze “avrebbe-bloccato” così puoi vedere esattamente cosa farebbe contro il traffico reale prima che lo faccia. Quando sei soddisfatto, un Admin del workspace chiama go-live, che ripristina le azioni dichiarate dei controlli (mask / block / deny) e opzionalmente promuove le policy materializzate a default del workspace. Questa è la stessa disciplina osserva-poi-applica descritta in Observe vs enforce.
Sfogliare il catalogo, i pack installati e la readiness è aperto a ogni membro del workspace ed è gratuito. Installare un pack e andare live sono azioni da Admin del workspace che richiedono un piano a pagamento — il server applica entrambi i gate, così un viewer o un workspace gratuito non può materializzare l’applicazione chiamando l’API direttamente. Generare un report è anch’esso Admin: il piano gratuito include un report PDF, mentre gli export CSV/JSON e i report aggiuntivi richiedono un piano a pagamento. Impostare la data residency è anch’esso da Admin del workspace, ma non è di per sé a pagamento.

​
5. Cosa un pack non contiene

Per mantenere il confine onesto:
  • Nessuna certificazione. Un pack mappa i tuoi controlli del gateway sulle clausole di un framework e produce evidenze firmate. Non è un audit, un’attestazione dell’intera organizzazione, né consulenza legale.
  • Nessun controllo organizzativo. Le clausole su persone-e-processo emergono come gap dichiarati o attestazioni dell’owner, mai come copertura automatizzata.
  • Nessun catalogo magico. I framework nel catalogo sono quelli con un mapping autorato — SOC 2, HIPAA, GDPR / UK GDPR, l’EU AI Act, ISO 27001 / 42001, NIST AI RMF, PCI DSS, l’OWASP LLM Top 10 e le leggi regionali sulla privacy. Sfoglia l’insieme live su Framework.

​
6. Dove andare dopo

Installa un pack

L’intero flusso di installazione — selezionare i controlli, observe mode e go-live.

Il report firmato

Cosa contiene il report di evidenze firmato Ed25519 e come si rende il lineage per un auditor.

Matrice dei controlli

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

Guardrails vs Firewall

I due piani su cui un pack scrive, e come il resolver li esegue insieme.
Un compliance pack è il ponte tra il linguaggio di un regolatore e l’applicazione del gateway: mappa ogni clausola su un controllo reale, materializza quel controllo in una policy che possiedi e puoi regolare, e registra il lineage così le evidenze reggono all’ispezione.