Vai al contenuto principale
Stai mettendo in piedi un sistema di gestione dell’AI (AIMS) e il tuo assessor vuole vedere che le clausole di sicurezza, trasparenza e monitoraggio dell’ISO/IEC 42001 siano supportate da controlli che girano davvero — non un raccoglitore di intenzioni. Su un gateway hosted, la risposta onesta è che le clausole di lifecycle mappano su controlli sul percorso della richiesta, mentre le clausole di leadership e di valutazione d’impatto restano organizzative e devono essere dichiarate come gap. Questa pagina è il walkthrough iso 42001: quali clausole il pack ISO/IEC 42001 materializza, i controlli che scrive nel tuo workspace, 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 è la mappa specifica per ISO 42001, non il riferimento completo della Compliance.

​
1. Cosa controlla il pack iso 42001

Il pack ISO/IEC 42001 mappa le clausole AIMS 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 AIMSPianoControllo
A.6 Ciclo di vita del sistema AIguardrailblocca i tentativi di jailbreak contro il sistema AI
A.8 Informazioni per le parti interessateguardrailsegnala i consigli legali/finanziari definitivi nell’output
A.9 Uso dei sistemi AIguardrailregistra ogni decisione del guardrail come evidenza
Clausola 5 Leadership & policy AI e A.5 Valutazione d’impatto del sistema AI sono clausole su persone-e-processo. Un gateway 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. Dichiarare ciò che un proxy non può fare è ciò che rende affidabile il resto delle evidenze. Vedi la matrice dei controlli.
Tutti e tre i controlli live sono regole ordinarie di Guardrails — la stessa macchina che autori a mano. Il pack è il mapping autorato che dice quale controllo esistente soddisfa quale clausola AIMS; non porta alcun nuovo motore di runtime. Vedi Contenuti del pack per l’intera anatomia.

​
2. Installa il pack iso 42001 — un esempio concreto

Installare materializza il mapping in policy di guardrail nel tuo workspace, ogni controllo taggato con la provenienza del pack. Lo fai dalla console, non da una chiave di relay: Compliance → Catalog → ISO/IEC 42001 → 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/iso_42001/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, le clausole AIMS smettono di essere prosa:
Una regola regex di guardrail sulla richiesta che blocca i comuni tentativi di jailbreak e role-play (“do anything now”, “developer mode”, “ignore previous instructions”) prima che raggiungano il modello — l’evidenza che il ciclo di vita del tuo sistema AI ha un controllo di sicurezza sul lato input.
Una regola regex di guardrail che segnala l’output che dà consigli legali/finanziari definitivi (“you are entitled to damages”, “guaranteed return”). Annota anziché bloccare, così le chiamate segnalate vanno alla revisione del team — il controllo di trasparenza-verso-gli-utenti per le tue parti interessate.
Una regola pii solo-flag che registra ogni decisione del guardrail come evidenza del sistema di gestione senza bloccare o modificare il traffico — la traccia di monitoraggio che un assessor legge per “uso dei sistemi AI”.
Ciascuna di queste è una regola reale che puoi aprire, leggere e regolare come qualsiasi altro guardrail. Nessuna è una scatola nera.

​
3. Prima osserva, poi vai live

Un’installazione ISO 42001 non inizia a bloccare il traffico dal primo giorno. Le installazioni atterrano in observe mode: le azioni applicanti del guardrail sono forzate a flag, così raccogli evidenze “avrebbe-bloccato” contro il traffico reale prima che qualcosa applichi. I controlli A.8 e A.9 sono già solo-flag, quindi il loro comportamento è invariato; il guard di sicurezza A.6 è quello che trattiene il suo verdetto di block fino al go-live. Quando le evidenze sembrano giuste, un Admin del workspace promuove il pack al go-live, che ripristina le azioni dichiarate — il guard jailbreak A.6 inizia a bloccare — e opzionalmente promuove la policy materializzata a default del workspace. Questa è la stessa disciplina descritta in Observe vs enforce.
ISO 42001 è uno standard di sistema di gestione dell’AI, quindi l’evidenza di monitoraggio conta quanto il blocco. Esegui il pack in observe per un periodo di revisione, osserva il feed di match dei Guardrails, poi vai live sulle superfici dove le evidenze lo supportano.

​
4. Evidenze firmate per il tuo AIMS

Il punto del pack è il report. Le evidenze ISO 42001 sono generate come un report firmato Ed25519 con un hash di contenuto SHA256, esportabile come CSV, JSON o PDF, e verificabile pubblicamente — il tuo assessor controlla la firma senza un login OrcaRouter.
Ogni riga AIMS porta il suo status — covered, observe, gap o attested — e quante volte il controllo si è effettivamente attivato sul periodo. Un guard di sicurezza A.6 che ha bloccato tentativi di jailbreak reali si legge diversamente per un assessor rispetto a uno con zero match, e il report mostra entrambi.
Ogni controllo materializzato registra il suo control_id (es. iso42001.safety), la clausola verbatim (ISO/IEC 42001 A.6 AI system lifecycle), il piano, e l’id dell’oggetto policy live che la applica — così l’assessor 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 assessor con scope su GET /api/public/compliance/share/:token. Nessun account richiesto.
Vedi il report firmato per il layout completo e Verifica un report per il walkthrough di verifica.

​
5. Region-stamp delle tue evidenze ISO 42001

I report ISO 42001 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 assessor 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 — piani, status e provenienza.

Installa un pack

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

NIST AI RMF

L’altro framework di governance dell’AI — GOVERN, MAP, MEASURE, MANAGE.

EU AI Act

Il framework AI regolatorio e i suoi tier di rischio.

Framework

L’intero catalogo — SOC 2, HIPAA, GDPR, ISO 27001, e altro.

Guardrails

Il riferimento del content-layer su cui i controlli ISO 42001 scrivono.
ISO 42001 su un gateway hosted è la disciplina di un sistema di gestione dell’AI in miniatura: mappa le clausole di lifecycle che un gateway può applicare su controlli live, dichiara le clausole di leadership e di valutazione d’impatto che non può, e firma le evidenze così la linea tra le due regge all’assessment.