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).

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. Independent verification: verify an audit bundle.

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 →

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 →

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 →

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