Skip to main content
You are standing up an AI management system (AIMS) and your assessor wants to see that the safety, transparency, and monitoring clauses of ISO/IEC 42001 are backed by controls that actually run — not a binder of intentions. On a hosted gateway, the honest answer is that the lifecycle clauses map to controls on the request path, while leadership and impact-assessment clauses stay organizational and must be disclosed as gaps. This page is the iso 42001 walkthrough: which clauses the ISO/IEC 42001 pack materializes, the controls it writes to your workspace, and how the resulting evidence is signed. For the install flow and report format in depth, follow the links at the end — this is the ISO 42001-specific map, not the full Compliance reference.

​
1. What the iso 42001 pack controls

The ISO/IEC 42001 pack maps AIMS clauses to controls that run on every gateway-crossing request. Three clauses map to live enforcement; two are organizational and are disclosed as gaps rather than claimed.
AIMS clausePlaneControl
A.6 AI system lifecycleguardrailblock jailbreak attempts against the AI system
A.8 Information for interested partiesguardrailflag definitive legal/financial advice in output
A.9 Use of AI systemsguardrailrecord every guardrail decision as evidence
Clause 5 Leadership & AI policy and A.5 AI system impact assessment are people-and-process clauses. A gateway cannot enforce them, so the pack surfaces them as disclosed gaps (or owner-attested rows) on both the console and the report — never as automated coverage. Disclosing what a proxy cannot do is what makes the rest of the evidence trustworthy. See the control matrix.
All three live controls are ordinary Guardrails rules — the same machinery you author by hand. The pack is the authored mapping that says which existing control satisfies which AIMS clause; it ships no new runtime engine. See Pack contents for the full anatomy.

​
2. Install the iso 42001 pack — one concrete example

Installing materializes the mapping into guardrail policy in your workspace, each control tagged with the pack’s provenance. You do this from the console, not a relay key: Compliance → Catalog → ISO/IEC 42001 → Install That is a workspace-Admin action on a paid plan, and the server enforces both. Under the hood your console session calls: 
POST /api/compliance/packs/iso_42001/install
Never hand a relay sk-orca-… key to a configuration route. The /api/compliance/* routes authenticate with your console session, not the relay key — only /v1/* model calls use sk-orca-…. Browsing the catalog, installed packs, and readiness is free and open to every workspace member; install, go-live, report, and residency are the gated Admin actions.
After install, the AIMS clauses stop being prose:
A regex guardrail rule on the request that blocks common jailbreak and role-play attempts (“do anything now”, “developer mode”, “ignore previous instructions”) before they reach the model — the evidence that your AI system lifecycle has a safety control on the input side.
A regex guardrail rule that flags output giving definitive legal/financial advice (“you are entitled to damages”, “guaranteed return”). It annotates rather than blocks, so flagged calls go to team review — the transparency-to-users control for your interested parties.
A flag-only pii rule that records every guardrail decision as management-system evidence without blocking or modifying traffic — the monitoring trail an assessor reads for “use of AI systems”.
Each of these is a real rule you can open, read, and tune like any other guardrail. None is a black box.

​
3. Observe first, then go live

An ISO 42001 install does not start blocking traffic on day one. Installs land in observe mode: enforcing guardrail actions are coerced to flag, so you collect “would-have-blocked” evidence against real traffic before anything enforces. The A.8 and A.9 controls already flag-only, so their behavior is unchanged; the A.6 safety guard is the one that holds its block verdict until go-live. When the evidence looks right, a workspace Admin promotes the pack to go-live, which restores the declared actions — the A.6 jailbreak guard starts blocking — and optionally promotes the materialized policy to workspace default. This is the same discipline described in Observe vs enforce.
ISO 42001 is an AI management system standard, so the monitoring evidence matters as much as the blocking. Run the pack in observe for a review period, watch the Guardrails matches feed, then go live on the surfaces where the evidence supports it.

​
4. Signed evidence for your AIMS

The point of the pack is the report. ISO 42001 evidence is generated as an Ed25519-signed report with a SHA256 content hash, exportable as CSV, JSON, or PDF, and publicly verifiable — your assessor checks the signature without an OrcaRouter login.
Each AIMS row carries its status — covered, observe, gap, or attested — and how many times the control actually fired over the period. An A.6 safety guard that blocked real jailbreak attempts reads differently to an assessor than one with zero matches, and the report shows both.
Every materialized control records its control_id (e.g. iso42001.safety), the verbatim clause (ISO/IEC 42001 A.6 AI system lifecycle), the plane, and the id of the live policy object enforcing it — so the assessor walks clause → control → enforcing policy → matches, with no inferred step.
Fetch the signing public key at GET /api/public/compliance/pubkey, submit the report to POST /api/public/compliance/verify, or open a scoped assessor share link at GET /api/public/compliance/share/:token. No account required.
See the signed report for the full layout and Verify a report for the verification walkthrough.

​
5. Region-stamp your ISO 42001 evidence

ISO 42001 reports are stored and served under your declared residency region — us / eu / uk / ap / cn / global — and a report is only served under a matching region; cross-region reads are withheld. A workspace Admin sets it via PUT /api/compliance/residency.
Residency here is the evidence artifact region — where signed reports live and are served. It is not inference-data geo-pinning. See Data residency and Cross-region for the boundary.
Request logs default to a 30-day retention (server-clamped to a 180-day hard max), and a user deletion runs a 30-day grace window then a PII scrub — both relevant when an assessor asks about your retention posture. See Retention and Right to erasure.

​
6. Where to go next

Pack contents

The full anatomy of a pack — planes, statuses, and provenance.

Install a pack

The end-to-end install flow, observe mode, and go-live.

NIST AI RMF

The other AI-governance framework — GOVERN, MAP, MEASURE, MANAGE.

EU AI Act

The regulatory AI framework and its risk tiers.

Frameworks

The full catalog — SOC 2, HIPAA, GDPR, ISO 27001, and more.

Guardrails

The content-layer reference the ISO 42001 controls write to.
ISO 42001 on a hosted gateway is the discipline of an AI management system in miniature: map the lifecycle clauses a gateway can enforce to live controls, disclose the leadership and impact-assessment clauses it cannot, and sign the evidence so the line between the two holds up under assessment.