Vai al contenuto principale
Quando un auditor chiede “dimostra che questi controlli erano davvero applicati”, uno screenshot della tua console non regge allo scrutinio — non è firmato, è tuo, ed è modificabile. OrcaRouter genera un report di compliance firmato: un pacchetto di evidenze autocontenuto, snapshottato dai tuoi controlli live del gateway, hashato con SHA256 e firmato con Ed25519 così chiunque tenga il report può verificare che è stato prodotto da OrcaRouter e non è stato alterato da allora. Questa pagina percorre il caso d’uso end to end — genera il report, consegnalo e lascia che l’auditor lo verifichi in modo indipendente. Per il catalogo dei framework e a cosa mappa ogni pack, vedi Framework e Contenuti del pack.

​
1. Cosa contiene il report di compliance AI firmato

Un report è generato per framework su una finestra temporale che scegli, e snapshotta otto sezioni di evidenza al momento della generazione così l’artefatto resta valido anche dopo che i log sottostanti invecchiano sotto la tua policy di retention.
Ogni report copre le stesse sezioni ordinate così due report sono comparabili:
  • Coverage — su quali controlli del framework mappano i tuoi pack installati, ciascuno taggato covered / observe / gap / attested.
  • Enforcement — i match dei guardrail e i verdetti del firewall (allowed / blocked / audited) effettivamente registrati nella finestra.
  • Consent — lo stato del consenso registrato per il periodo, classificato valid / stale / revoked / none.
  • Change log — la history dei guardrail e le righe di audit del workspace sulla finestra.
  • Admin access — chi deteneva i privilegi di admin e quali azioni privilegiate sono state eseguite.
  • Gaps — controlli non coperti, incluse le clausole organizzative (persone/processo) che non possono mai essere automatizzate dal gateway. Il report le dichiara come gap onesti anziché implicare una compliance automatizzata al 100%.
  • AI supply chain — i provider upstream (subprocessor) e i modelli raggiungibili dal workspace, per evidenziarli contro i tuoi DPA.
  • Access reviews — le chiavi API del workspace e l’elenco dei membri privilegiati per l’igiene di rotazione delle chiavi.
Il JSON canonico delle evidenze è hashato con SHA256 (hex minuscolo). Quell’hash di contenuto è firmato con Ed25519, e la firma più un breve key id (es. orca-…) sono incorporati nell’artefatto. Cambia un byte di evidenza e l’hash non corrisponde più; falsifica l’hash e la firma non si verifica più contro la chiave pubblica di OrcaRouter.
  • PDF — la consegna leggibile dall’auditor, con la firma e il key id stampati sopra.
  • JSON — l’export di evidenze leggibile dalla macchina. (La firma è calcolata su una forma canonica dell’evidenza, non sui byte grezzi del file, quindi verificala tramite l’endpoint pubblico di verifica anziché re-hashare l’artefatto da solo — vedi Verifica un report.)
  • CSV — export tabulare piatto per fogli di calcolo e tooling GRC.
Di default, le email dei membri e degli attori sono mascherate in ogni export. Opta esplicitamente per PII non redatte per report quando il tuo auditor ne ha bisogno.
I report sono region-stamped. Ogni artefatto è archiviato e servito sotto la regione di data-residency dichiarata dal tuo workspace (us / eu / uk / ap / cn / global); un report prodotto per una regione non viene servito sotto un’altra. Imposta la residency prima di generare se conta per i tuoi obblighi.

​
2. Chi può generarne uno

Sfogliare il catalogo dei framework, i pack installati e la readiness è aperto a ogni membro del workspace ed è gratuito. Generare un report richiede il ruolo Admin del workspace, e l’export è plan-gated:
  • Il piano gratuito include un PDF, così puoi fare una demo dell’artefatto.
  • L’export CSV / JSON e i report aggiuntivi richiedono un piano a pagamento.
Entrambe le regole sono applicate lato server — non c’è alcun bypass client-only.
Genera dalla console: apri Compliance → Reports, scegli il framework e la finestra temporale, scegli un formato, e clicca genera. La generazione è asincrona — la riga del report appare come pending, passa a generating, e atterra a ready (o failed, senza artefatto parziale). Tutto questo gira contro le rotte /api/compliance/* sotto la tua sessione di console — nessuna chiave di relay (sk-orca-…) è coinvolta.

​
3. Un walkthrough concreto

Un auditor SOC 2 vuole le evidenze di applicazione per il Q1. Il workflow:
1

Installa il framework (una volta)

Come Admin su un piano a pagamento, installa il pack SOC 2 da Compliance → Frameworks. Installare materializza i guardrail e le policy firewall che mappano sui controlli del framework. Vedi Installa un pack.
2

Genera il report

In Compliance → Reports, seleziona soc2, imposta il periodo sulla tua finestra Q1, scegli PDF, e genera. Aspetta che la riga raggiunga ready, poi scarica.
3

Consegnalo all'auditor

Inviagli il PDF (o genera un link di condivisione per auditor in sola lettura così possono recuperarlo da soli). La firma e il key id sono stampati sul report.
4

Lo verificano in modo indipendente

L’auditor non deve mai fidarsi della tua console. Re-hashano l’evidenza, recuperano la chiave pubblica di OrcaRouter, e controllano la firma — tutto contro endpoint pubblici e non autenticati (prossima sezione).

​
4. Come la verifica un auditor

La verifica non richiede account né chiave di relay — gira contro due endpoint pubblici su api.orcarouter.ai. Prima, recupera la chiave pubblica attiva: 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
Poi invia l’hash di contenuto, la firma e il key id del report: 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
Un valid: true significa che l’hash dell’evidenza è stato firmato da OrcaRouter e non è cambiato da allora. Un auditor che preferisce non chiamare affatto il nostro endpoint può prendere la chiave pubblica Ed25519 pubblicata e verificare la firma sull’hash con qualsiasi libreria crypto standard — il report è verificabile offline.
Preferisci non inviare il PDF come allegato? Genera invece un link di condivisione per auditor in sola lettura — un URL tokenizzato che serve il report (e la sua firma) direttamente, senza login. Vedi Export delle evidenze.

​
5. Dove si colloca

Il report firmato è l’artefatto alla fine del flusso di compliance. I pezzi attorno ad esso:

Framework

L’intero catalogo — SOC 2, HIPAA, GDPR, EU AI Act, ISO 27001/42001, NIST AI RMF, PCI DSS, OWASP LLM Top 10, e l’insieme regionale.

Installa un pack

Materializza i guardrail e le policy firewall di un framework prima di rendicontarci sopra.

Data residency

Marca e fissa la regione sotto cui il tuo report firmato è archiviato e servito.

Verifica un report

Il flusso di verifica in profondità — chiave pubblica, hash e controlli offline.
Le evidenze dentro il report provengono dai controlli che hai configurato. Per rafforzare ciò che viene rendicontato, regola i tuoi Guardrails e Firewall, e rivedi il confine di ciò che il gateway può e non può attestare in Responsabilità condivisa.