--- title: "EU AI Act Readiness" description: "How Norcaster supports EU AI Act readiness workflows: supported runtime paths, evidence APIs, retention, and customer responsibilities — not legal compliance." canonical: https://www.norcaster.com/docs/eu-ai-act-readiness --- # EU AI Act readiness Norcaster supports EU AI Act readiness by enforcing runtime policy and producing exportable evidence — policy decisions with pinned versions, traces, redaction events, approval records, and signed exports — on supported production paths. It is not a conformity assessment or a legal compliance guarantee. Readiness, not legal compliance Norcaster provides runtime policy enforcement and exportable evidence on **supported production paths** to help teams build **EU AI Act readiness** and broader AI governance workflows. It is **not** legal advice, a conformity assessment, CE marking, or a guarantee of regulatory compliance. Risk classification, DPIAs, and legal interpretation remain your responsibility. ## Supported runtime paths | Path | Policy before model | Enforcement events | run\_id link | | --- | --- | --- | --- | | POST /run | Yes | Yes | Yes | | Playground (via /run) | Yes | Yes | Yes | | Gateway /v1/chat/completions | Yes | Yes | Yes | | Gateway /v1/messages | Yes | Yes | Yes | | Gateway /v1/embeddings | Yes | Yes | Yes | | Workflow model/agent nodes | Yes | Yes | When workflow run exists | | Workflow external\_model node | Yes (input + egress) | Input + output | When workflow run exists | | Action gateway POST /v1/mcp/{deployment\_id} | Yes (before upstream) | Yes (event\_type=action) | Deployment-scoped | | POST /rag/run | Yes | Yes (org-scoped when no deployment\_id is sent) | Yes | | K8s async worker | Yes (pre-inference) | Yes | When job has run\_id | | POST /demo | No | No | — | The `external_model` workflow node adds input and egress enforcement around a model you host elsewhere. See [Runtime Layer Extraction (BYO model)](https://www.norcaster.com/docs/runtime-layer-extraction). ## Customer readiness checklist Map typical Act themes to product capabilities and responsibilities your team still owns. ### Risk management (Art. 9) Norcaster: Policy manifest export; optional risk\_tier / intended\_purpose; enforcement events with policy version; obligations map (runtime-evidenced vs attestation zones) You own: Risk register, classification, mitigation sign-off ### Data governance (Art. 10) Norcaster: Contextual packs; block/redact on supported paths; optional SHA-256 content hashes (no raw text) You own: Lawful basis, minimization, training data governance ### Record-keeping (Art. 12) Norcaster: Enforcement events, runs, traces; JSONL + signed export; investigation API; composed audit bundles (PDF/CSV/JSON with manifest and verification guide) You own: Retention policy, access control, audit archival ### Transparency (Art. 13) Norcaster: Structured policy decisions in API; masked contextual audit payloads; trace summaries with policy version pinned per request You own: End-user disclosures and deployer instructions ### Human oversight (Art. 14) Norcaster: Workflow approval nodes; MCP action approval gates; audited deployment stop/resume (POST …/stop, …/resume); block/warn outcomes You own: Oversight procedures and escalation playbooks ### Accuracy & robustness (Art. 15) Norcaster: Eval hooks; observability metrics; provider failover events (event\_type=provider\_failover) on gateway paths with primary/fallback attribution You own: Validation methodology and production monitoring ### Cybersecurity Norcaster: MFA, SSO/OIDC, API key scopes and expiry, region residency gates, external reviewer scoped access You own: SOC program, pen tests, vendor reviews ## Agentic action coverage Where agents take actions (tool and MCP calls), each obligation is tagged by how the evidence is produced: captured automatically at runtime, or still requiring your own attestation. Runtime-evidencedRequires attestation ### Risk management (Art. 9) Runtime-evidenced Per-action runtime decisions (allow / block / require-approval) recorded with policy version for each agent tool and MCP call. ### Record-keeping (Art. 12) Runtime-evidenced Agent action events sit alongside model calls in the Decision Audit and signed audit bundles, preserving model call → action → result trace continuity with hash-chained verification. ### Human oversight (Art. 14) Runtime-evidenced High-impact MCP tool calls held for human approval; approval state (pending / granted / denied) captured as evidence next to the action. Authorized users can stop or resume a deployment; lifecycle events appear in audit bundles. ### Risk classification & sign-off (Art. 9) Requires attestation Tool/action risk tiering, residual-risk acceptance, and mitigation sign-off. ### Oversight procedures (Art. 14) Requires attestation Who approves which actions, escalation paths, and reviewer training records. Runtime-evidenced items produce captured evidence — not a determination of compliance. Conformity assessment remains your responsibility. ## Evidence APIs - `GET /enforcement-events` — list/filter by deployment, org, `event_kind` (e.g. `human.approval.*`), or `event_type` (e.g. action, provider\_failover) - `GET /enforcement-events/export` — JSONL (optional `signed=true`) - `GET /governance/investigations` — bundle by request\_id or run\_id, including agent action evidence and approvals with model call → action → result continuity - `GET /governance/deployments/{id}/policy-manifest` — effective policy snapshot (includes `provenance` when rules were human-applied from a policy proposal) - `POST /orgs/{org_id}/audit-bundles` — composed export (PDF/CSV/JSON) with enforcement records, action evidence, provider activity (including failover rows), change history, coverage statement, and source-document digests on policy configuration when present - `POST /deployments/{id}/stop` and `…/resume` — audited lifecycle control (blocks new runs until resumed) **Policy provenance:** rules can cite the governing document they implement. Derivation is proposal-based and human-approved — source documents never auto-apply enforcement. Decision Audit links an event to the applied proposal and source-document digests when provenance is present. Dashboard: generate bundles at [Audit bundles](https://www.norcaster.com/dashboard/audit-bundles). Independent verification: [verify an audit bundle](https://www.norcaster.com/trust/integrity#verify-audit-bundle). See also [Article 26 AI Register](https://www.norcaster.com/docs/ai-register), [Security & compliance](https://www.norcaster.com/docs/security-compliance), and the [Trust center](https://www.norcaster.com/trust). ## Retention & stronger evidence Org `retention_config` keys: `audit_days` (unified enforcement + runs), `enforcement_events_days`, `runs_days`. Plan defaults apply when org keys are unset. Optional: enable `store_content_hashes` on deployment or org settings for SHA-256 input/output fingerprints without storing raw prompt text. Investigation API and run detail surfaces hashes when present. ## Common questions ### Does Norcaster make my company EU AI Act compliant? No platform can. Compliance determinations require qualified legal counsel and, for certain high-risk systems, a conformity assessment by a notified body. Norcaster produces runtime readiness evidence: enforcement records with pinned policy versions (Art. 9), redaction events (Art. 10), hash-chained record-keeping (Art. 12), approval gates and stop controls (Art. 14), and adversarial-input detection (Art. 15). Its status language is deliberate — evidence captured, controls active — never compliant. [EU AI Act readiness evidence →](https://www.norcaster.com/docs/eu-ai-act-readiness) ### How do auditors verify Norcaster evidence without trusting Norcaster? Every CSV and PDF audit-bundle export ships with bundle.json, HOW\_TO\_VERIFY.txt, and a standalone verify\_audit\_bundle.py script. The script recomputes the manifest content digest and, where trace-chain anchoring is active, confirms segment Merkle roots against the public Sigstore Rekor transparency log — no Norcaster software, account, or API access required. [How proof works →](https://www.norcaster.com/evidence) ### Does Norcaster replace Vanta, Drata, or Secureframe? No — it complements them. A readiness platform covers the organization: laptops, people, policies, org-wide controls. It cannot see inside AI runtime traffic. Norcaster evidences that slice — the requests, redactions, policy decisions, and approvals on gatewayed AI traffic. Two different evidence surfaces, one audit; HR, endpoints, physical security, BCP, and org-wide vendor management remain readiness-platform territory, and Norcaster states that boundary in the product and in every SOC 2 bundle. [Working alongside readiness platforms →](https://www.norcaster.com/docs/norcaster-and-readiness-platforms) ## Approved wording for sales Supports teams building EU AI Act readiness evidence through runtime controls, logging, and signed enforcement exports where enabled — not a conformity assessment or legal compliance guarantee. Companion reference — the same evidence store projected for SOC 2 examinations: [SOC 2 runtime evidence](https://www.norcaster.com/docs/soc2-evidence)