--- title: "Norcaster and the EU AI Act: Evidence Layer Reference" description: "Maps Norcaster's shipped capabilities to EU AI Act obligations for AI that touches EU users. Runtime evidence, not a compliance verdict." canonical: https://www.norcaster.com/article/eu-ai-act-evidence-mapping --- # Norcaster and the EU AI Act: Evidence Layer Reference 2026-06-13 · Norcaster For design partners and prospects. This document maps Norcaster's shipped capabilities to the EU AI Act obligations most relevant to US companies deploying AI that affects EU users, employees, or operations. It is a technical reference, not a compliance assessment. Norcaster produces evidence; your legal counsel determines conformity. ## The core distinction: evidence vs. verdict Norcaster does not declare AI systems compliant. It captures the runtime evidence an auditor or legal advisor uses to assess compliance. The distinction matters legally and practically. A software platform cannot issue a compliance determination — only a conformity assessment body, legal counsel, or regulator can. What a runtime platform can do is ensure that when the question is asked, the evidence is there: every policy decision logged, every trace tamper-evident, every approval gate recorded. Norcaster's status language is deliberate: **"evidence captured / controls active"** — never "compliant." ## Who this is for US companies that: - Deploy AI systems used by EU users, employees, or counterparties - Operate AI in domains classified as high-risk under Annex III of the Act (employment, access to services, critical infrastructure, education, law enforcement, migration, justice, and others) - Have AI embedded in products that trigger EU regulated-product classification - Need to demonstrate due diligence on EU AI Act obligations as they phase in — GPAI duties apply since August 2025; high-risk obligations land December 2027 (Annex III stand-alone systems) and August 2028 (AI in regulated products, Annex I). Runtime evidence can't be backfilled: an audit in 2027 needs traces that started accumulating today ## What the EU AI Act requires at runtime Six articles translate directly into runtime platform requirements. The rest of the Act is organizational governance, legal process, and documentation. | Article | Plain-language obligation | What Norcaster produces | | --- | --- | --- | | Art. 9 | Continuous risk management with evidence of mitigation | Enforcement events per request: policy, rule, verdict, why | | Art. 10 | Data governance + production monitoring for drift/bias | Eval runs against a versioned reference, linked to runs; input lineage for RAG; redaction evidence | | Art. 12 | Automatic logging, multi-year retention, regulatory access | Hash-chained trace store; tamper-evident via Rekor; auditor-exportable bundles | | Art. 13 | Output traceability; source provenance; deployer transparency | Per-request trace summaries; citation tracking for retrieval calls | | Art. 14 | Human oversight: interpret, override, stop | Approval gates with logged decisions; RBAC; stop-deployment controls | | Art. 15 | Accuracy, robustness, adversarial resilience | Eval runs linked to the candidate version; prompt injection / jailbreak detection at the boundary | ## Article-by-article evidence map ### Article 9 — Risk management **What Norcaster produces:** - Every request generates an enforcement record: the policy version applied, each rule evaluated, the verdict and its reason - policy\_version travels with every trace — the policy configuration is pinned to each decision, not reconstructed after the fact - Enforcement logs are filterable by verdict, rule, policy, date range, deployment, and environment - The Obligations Map shows which obligations have live enforcement evidence and which require human attestation **Evidence a legal reviewer sees:** "Policy pv-2026-04-01 was active for deployments X, Y, Z during the audit period. N requests were blocked under the PII-redaction rule. M requests were flagged for human review. Enforcement event IDs \[range\] are available in the bundle." ### Article 10 — Data and data governance **What Norcaster produces:** - Eval suites run against candidates and workflows from a separate eval service; results logged with timestamps, suite version, and pass/fail outcome, linked to the run — the quality-regression evidence record - Every RAG answer and workflow retrieval records the knowledge source, the document version and its content hash, the chunk, relevance score, and timestamp — the lineage record for RAG-based systems - Redaction events captured per request: what PII category was detected, what action was taken, at what latency — without retaining the PII itself **Scope note:** Article 10's upstream obligations (training data governance, dataset composition) are outside Norcaster's scope. Runtime monitoring and inference-time evidence is what Norcaster covers. ### Article 12 — Record-keeping **What Norcaster produces:** - Every request generates a trace capturing the full lifecycle: input (post-redaction), model call parameters, policy decisions with verdicts, output, latency, cost, and provider - The trace store is hash-chained: each record includes a digest of the previous, making undetected alteration impossible - Traces are anchored to the public Rekor transparency log (Sigstore) — a third party can verify integrity without trusting Norcaster - Audit Bundles export the trace record in PDF, CSV, and JSON, with a HOW\_TO\_VERIFY document and a standalone verification script that works with no Norcaster software installed - Bundle manifests carry catalogue\_version (which obligation mapping the evidence uses) and policy\_versions — evidence is pinned to the definitions in force when it was produced ### Article 13 — Transparency **What Norcaster produces:** - Every trace includes a human-readable summary: verdict, plain-language explanation, action taken, provider and model, policy version, latency, cost, evidence status - RAG answers record each citation with its relevance ranking and the document version it came from - The trace detail view (five-tab layout: Summary, Enforcement, Redaction, Provider, Raw) is designed for a compliance lead reading evidence, not an engineer reading telemetry - Evidence permalinks connect every governance screen status to the filtered trace set backing it — status claims are always backed, never floating **Scope note:** Article 13's user-disclosure requirements (informing EU users they are interacting with AI) are a product design obligation. Norcaster records the interaction; the disclosure belongs in your application layer. ### Article 14 — Human oversight **What Norcaster produces:** - **Approval gates** — workflow nodes where an authorized user reviews before downstream execution; approval and rejection logged with user identity, timestamp, and request ID - **RBAC** — four governance roles (Owner, Governance Lead, Compliance Viewer, External Reviewer), each scoped to specific permissions - **Deployment stop** — authorized users can disable a deployment immediately; stop event logged with identity and timestamp - **External Reviewer role** — scoped, time-boxed, read-only access for legal reviewers; audit-logged from entry to expiry; never sees API keys, gateway config, provider secrets, or billing — enforced by deny-list, not trust **Access audit log example:** "Reviewer \[identity\] accessed the Evidence Center on \[date\] at \[time\]. Viewed trace range \[IDs\]. Viewed the Obligations Map. Access expires \[date\]. No export actions taken." ### Article 15 — Accuracy, robustness, and cybersecurity **What Norcaster produces:** - **Request-boundary enforcement** — prompt injection detection, jailbreak detection, and input category classification run before the model call; detection events logged with policy rule and confidence signal - **Output validation** — output category constraints enforce content policy at the response boundary; violations blocked or flagged with logged enforcement events - **Eval runs on deployment candidates** — eval suites run on candidates and workflows from a separate eval service, scoring output against a versioned reference; the eval run result (pass/fail, suite version, scores) is logged as evidence and linked to the run - **Provider failover** — multi-provider routing with automatic failover; failover events are logged ## The Obligations Map: evidence vs. attestation Norcaster's Obligations Map distinguishes two types of obligations. **Runtime-evidenced obligations** — Norcaster produces evidence directly from observed traffic: policy enforcement, trace records, redaction events, eval runs, approval gate decisions. These appear in the left zone of the map with live counters and evidence permalinks. **Requires-attestation obligations** — some obligations cannot be satisfied by runtime evidence alone. Estate completeness, technical documentation completeness, and certain organizational obligations require a human decision backed by a documented statement. These appear in the right zone with owner assignment, attestation status, and review dates. An obligation doesn't move to the evidenced side because it would look better there — it moves when Norcaster can back the status with stored data. **Coverage statement:** Norcaster measures and displays "M of N registered AI systems gatewayed." The un-gatewayed gap is a first-class number, never hidden. Estate completeness — the claim that all production AI systems are registered — is an attestation record, not a metric. ## What a Gap Audit on Norcaster looks like 1. **External Reviewer access provisioned** — scoped, time-boxed, read-only account for the legal reviewer; access is audit-logged from day one 2. **Obligations Map reviewed** — reviewer sees which obligations have live evidence and which have owners and attestation status 3. **Evidence Center queried** — reviewer filters trace records by period, deployment, verdict, and rule 4. **Audit Bundle generated** — composed PDF/CSV/JSON: manifest (with catalogue\_version and policy\_versions), policy config, enforcement logs, redaction evidence, provider activity, AI register extract, attestations section, coverage section with gap statement, and HOW\_TO\_VERIFY 5. **Bundle verified independently** — reviewer runs verify\_audit\_bundle.py against the bundle; the Rekor check works without Norcaster software or account access 6. **Gap assessment completed** — reviewer exercises independent legal judgment; Norcaster produces no compliance determination **What Norcaster does not do:** issue compliance certificates, make compliance determinations, produce evidence for systems not running through the gateway, or attest to organizational obligations. ## Evidence coverage | Obligation type | Norcaster status | | --- | --- | | Policy enforcement at runtime | Evidence captured | | Request and response logging | Evidence captured | | PII detection and redaction | Evidence captured | | Provider attribution per call | Evidence captured | | Adversarial input detection | Evidence captured | | Eval runs on deployment candidates | Evidence captured | | Approval gate decisions | Evidence captured | | Reviewer access and activity | Evidence captured | | AI system registration and inventory | Partial — completeness requires deployer attestation | | Technical documentation completeness | Partial — register and enforcement exported; doc completeness is an attestation | | Organizational risk management process | Requires attestation | | Training data governance | Out of scope — upstream of runtime | | Conformity assessment | Out of scope — performed by qualified body | ## Founding partner pricing and access Norcaster is at the design-partner stage. The first 2-3 companies that run a real EU AI Act gap audit on the platform will have input into the obligation catalogue, evidence export formats, and reviewer workflow — and will receive founding-customer pricing (approximately 50% of list rate, 12-month term, reference rights). To discuss fit and timing: norcaster.com/contact --- This document is not legal advice. EU AI Act compliance determinations require qualified EU legal counsel and, for certain high-risk systems, a conformity assessment by a notified body. ### New posts by email Technical posts on runtime policy enforcement and AI evidence. A few a month at most.