Quantlix and the EU AI Act: Evidence Layer Reference
For design partners and prospects. This document maps Quantlix'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. Quantlix produces evidence; your legal counsel determines conformity.
The core distinction: evidence vs. verdict
Quantlix 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.
Quantlix'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 before the 2 August 2026 enforcement date
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 Quantlix 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 in production; 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-gated promotion; prompt injection / jailbreak detection at the boundary |
Article-by-article evidence map
Article 9 — Risk management
What Quantlix 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 Quantlix produces:
- Eval suites run in production; results logged with timestamps, model version, and pass/fail outcome — the drift-detection evidence record
- Every retrieval call records source, 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 Quantlix's scope. Runtime monitoring and inference-time evidence is what Quantlix covers.
Article 12 — Record-keeping
What Quantlix 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 Quantlix
- 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 Quantlix 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 Quantlix produces:
- Every trace includes a human-readable summary: verdict, plain-language explanation, action taken, provider and model, policy version, latency, cost, evidence status
- RAG calls record source citation, relevance ranking, and knowledge source version per output
- 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. Quantlix records the interaction; the disclosure belongs in your application layer.
Article 14 — Human oversight
What Quantlix 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 Quantlix 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-gated deployment promotion — eval suites run on deployment candidates; regression below threshold blocks promotion; eval run result (pass/fail, suite version, scores) is logged as evidence
- Provider failover — multi-provider routing with automatic failover; failover events are logged
The Obligations Map: evidence vs. attestation
Quantlix's Obligations Map distinguishes two types of obligations.
Runtime-evidenced obligations — Quantlix 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 Quantlix can back the status with stored data.
Coverage statement: Quantlix 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 Quantlix looks like
- External Reviewer access provisioned — scoped, time-boxed, read-only account for the legal reviewer; access is audit-logged from day one
- Obligations Map reviewed — reviewer sees which obligations have live evidence and which have owners and attestation status
- Evidence Center queried — reviewer filters trace records by period, deployment, verdict, and rule
- 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
- Bundle verified independently — reviewer runs verify_audit_bundle.py against the bundle; the Rekor check works without Quantlix software or account access
- Gap assessment completed — reviewer exercises independent legal judgment; Quantlix produces no compliance determination
What Quantlix 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 | Quantlix 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-gated deployment promotion | 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
Quantlix 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: quantlix.ai/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.