Vai al contenuto principale
La prima domanda di un auditor non è mai “hai una policy?” — è “mostrami, clausola per clausola, quale controllo la soddisfa, e dimostra che è girato”. Una matrice dei controlli risponde esattamente a questo: una riga per clausola in scope, il piano su cui mappa, l’oggetto policy live che la applica, e se quel controllo è covered, ancora in observe, un gap dichiarato, o owner-attested. OrcaRouter costruisce questa matrice per te dai pack che installi — lo stesso mapping che alimenta il report firmato, così la vista di readiness e le evidenze non possono mai divergere. Questa pagina mostra come leggere e assemblare la matrice dei controlli di compliance AI per il tuo workspace, con una clausola concreta percorsa end to end. Per cosa contiene davvero un pack, segui i link in fondo.

​
1. Cos’è qui una matrice dei controlli di compliance AI

La matrice è l’unione di due elenchi per framework:
  • le clausole che un pack installato copre — ciascuna unita all’esatta policy guardrail o firewall che l’installazione ha materializzato;
  • le clausole che non possono mai essere automatizzate dal gateway — formazione del personale, Business Associate Agreement, accesso fisico — autorate come gap onesti così la matrice le dichiara anziché implicare un falso 100%.
La matrice è una vista, non un secondo motore. Ogni riga covered punta a una regola guardrail o policy firewall reale e modificabile che già possiedi — aprila, leggila, regolala. La matrice si limita a registrare quale risponde a quale clausola.
Ogni clausola mappa esattamente su uno di due piani:

Piano guardrail

Le clausole di contenuto — PII confidenziali, segreti, disclosure obbligatorie — mappano su una regola di guardrail con un’azione block, mask o flag.

Piano firewall

Le clausole di azione — eccessiva agency, chiamate a tool pericolose, egress — mappano su una regola di firewall con un verdetto allow / audit / deny sulla superficie inbound, response, mcp o egress.

​
2. Gli stati di readiness che una riga può portare

Ogni riga della matrice porta uno stato. Queste sono le parole che un auditor legge, quindi significano esattamente ciò che dicono:
StatoCosa significa
coveredUn controllo del pack è installato e applica la clausola.
observeInstallato ma solo-log — raccoglie evidenze avrebbe-bloccato, non ancora applica.
gapNessun controllo installato copre la clausola (o è organizzativa e non può).
attestedUna clausola organizzativa che un Admin ha owner-attested anziché automatizzato.
Un gap non è un fallimento — è onestà. Una clausola organizzativa come la formazione del personale HIPAA 45 CFR §164.308(a)(5) non può mai essere applicata da un proxy, quindi la matrice la fa emergere come un gap dichiarato (o, una volta che un Admin ne attesta l’ownership, come attested) anziché fingere che il gateway la copra.
C’è anche un overlay drift: se il mapping di un pack installato è in ritardo rispetto alla versione corrente del catalogo, le sue righe rendono come drift così sai di re-installare prima di fare affidamento sulle evidenze.

​
3. Leggi la matrice (una chiamata concreta)

L’endpoint di readiness restituisce l’intera matrice — percentuali di copertura per-framework, i top risk classificati sulla finestra, e una voce coverage_rows per clausola. Sfogliare la readiness è aperto a ogni Member del workspace ed è gratuito, così i tuoi revisori di sicurezza e di audit possono osservare la matrice senza accesso in scrittura. La console guida questa rotta di management sotto la tua sessione — non passi mai una chiave di relay sk-orca-… a una rotta di compliance: 
GET /api/compliance/readiness?window=30d
Authorization: Bearer <your console session>
Una singola riga covered ha questo aspetto — clausola, piano, stato, e l’id della policy live a cui si unisce: 
{
  "framework": "soc2",
  "control_id": "soc2.confidentiality",
  "clause": "TSC CC6.1 Logical access controls",
  "reference": "https://www.aicpa-cima.com/resources/...",
  "plane": "guardrail",
  "state": "covered",
  "guardrail_id": 41,
  "observe_count": 0,
  "organizational": false
}
Il guardrail_id (o firewall_policy_id sul piano firewall) è il campo portante: lega la clausola direttamente a un oggetto che puoi aprire nella console e modificare come qualsiasi altro. È il lineage che un auditor percorre — clausola → id del controllo → policy applicante → i match che ha prodotto.
Leggere la matrice è una capability Member gratuita. Costruirla — installare un pack così i suoi controlli popolano le righe — è un’azione da Admin del workspace su un piano a pagamento, e il server applica entrambi. Un viewer o un workspace gratuito non può materializzare la copertura chiamando l’API direttamente. Vedi Plan gating.

​
4. Assembla la matrice per i tuoi framework

Costruisci la matrice installando pack. Ogni installazione fonde i suoi controlli in un guardrail e una policy firewall taggati con la provenienza del pack, e le sue clausole iniziano a popolare coverage_rows:
  1. Scegli i tuoi framework. L’installazione si avvia dalla console sotto Compliance → Catalog, come Admin del workspace. Il catalogo copre regimi di sicurezza e di governance dell’AI (soc2, iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, owasp_llm), regimi settoriali (hipaa, pci_dss, glba, nist_800_53), e un’ampia serie di leggi regionali sulla privacy (gdpr, uk_gdpr, ccpa, e altre). Sfoglia l’insieme live su Framework.
  2. Installa prima in observe. Un’installazione fresca atterra in observe mode — azioni del guardrail forzate a flag, la policy del firewall in shadow — così ogni nuova riga inizia come observe e produce evidenze avrebbe-bloccato prima di applicare.
  3. Osserva le righe riempirsi. Ri-recupera la readiness su una finestra reale. Le righe covered mostrano il loro observe_count; i gap restano dichiarati; le clausole organizzative attendono l’attestazione.
  4. Vai live. Quando le righe si leggono pulite, un Admin del workspace va live e le righe observe si ribaltano all’applicazione covered.
L’OWASP Top 10 for LLM Applications è nel catalogo come pack owasp_llm — le sue clausole (per esempio LLM05:2025 Supply Chain) atterrano nella matrice allo stesso modo di ogni altro framework, mappate su controlli live o dichiarate come gap. Vedi OWASP LLM Top 10.

​
5. Dalla matrice alle evidenze firmate

La matrice che leggi nella console è lo stesso dato di copertura che il report serializza — così quando generi le evidenze, l’auditor vede gli identici stati per-clausola, più i conteggi di applicazione che ogni controllo ha prodotto sul periodo. Una clausola che ha bloccato 4.000 richieste e una clausola con zero match si leggono molto diversamente, e il report mostra entrambe. I report sono hashati SHA-256, firmati Ed25519, e verificabili pubblicamente.
Gli esatti oggetti guardrail e firewall che un pack materializza, e come ogni clausola si unisce alla sua policy applicante — vedi Contenuti del pack.
Perché ogni riga inizia in observe, cosa logga, e come il go-live la ribalta — vedi Observe vs enforce.
Come la matrice si rende per un auditor, con stati per-clausola e conteggi di applicazione — vedi Report firmato.

​
6. Dove andare dopo

Installa un pack

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

Tutti i framework

Il catalogo live dei framework le cui clausole puoi costruire nella matrice.

Guardrails vs Firewall

I due piani su cui una riga della matrice può mappare, e come il resolver li esegue insieme.

Responsabilità condivisa

Perché alcune clausole sono applicabili dal gateway e altre restano tue — il confine che ogni riga gap riflette.
Una matrice dei controlli è il ponte tra la checklist di un regolatore e il tuo gateway in esecuzione: una riga per clausola, unita al controllo live che la applica, onesta su ciò che un proxy non può coprire, e identica alle evidenze firmate che consegni a un auditor.