AI Act Readiness — Architecture & Compliance Map

Scope. This document describes how the rag-showcase reference architecture maps to the obligations of Regulation (EU) 2024/1689 (the "AI Act"). It serves two audiences: prospects evaluating whether the architecture would be defensible if productionised in the EU, and internal reviewers checking that we haven't over-claimed.

Status of the showcase itself. This deployment is a non-production demonstration for sales and evaluation purposes. It is excluded from the substantive obligations of the Act by Article 2(8) (research, testing and development prior to placing on the market or putting into service). The only obligation that applies regardless of stage is Art. 50 user-facing transparency, which we satisfy via the persistent "KI-generierte Antworten · Demo-System, nicht für den Produktiveinsatz" disclosure under the chat input.

What follows is therefore productionisation guidance: how a customer-side deployment of this architecture would line up against the Act, and which design choices in the codebase already do the work.

1 · Risk classification

The reference use case — retrieval-augmented Q&A over a tenant's own technical, service or product documentation, with literal-quote citations to the source — is limited risk under the Act:

• Not in Annex III (no biometric ID, no education / employment / credit / migration / law-enforcement / democratic-process decisions, no critical-infrastructure control).
• Not a GPAI provider obligation: we deploy Azure-hosted models, we do not train or place a general-purpose model on the market. Provider obligations (Art. 53–55) sit with Azure / OpenAI.
• Not a prohibited practice under Art. 5 (no subliminal manipulation, no social scoring, no real-time biometric ID, no emotion inference in workplace/education, no scraping for facial recognition databases).

Caveat for deployers. If a deployer routes the assistant into a workflow that is high-risk in their own right — e.g. integrating its outputs into the safety chain of machinery under Regulation (EU) 2023/1230, or into product-safety decision-making — the use can inherit high-risk status. That is a deployer-side judgement, not a property of this architecture. The architecture supports either posture; the obligations below are written for the limited-risk deployment.

2 · Obligations map

Each row: the Act obligation, the design choice that addresses it, the file(s) where that choice lives, and any gap a productionising customer would still need to close themselves.

Art. 4 — AI literacy

Art. 50(1) — Disclosure of AI interaction

Art. 50(2) — Marking of AI-generated output

Art. 9 / 13 / 15 — Risk management, transparency, accuracy (high-risk only, but architecture-relevant)

These articles bind only providers of high-risk systems. They are called out because customers in regulated industries will ask whether the architecture could support a high-risk posture without a rewrite. It can:

Art. 53–55 — General-Purpose AI (GPAI) flow-down

We do not place a GPAI model on the market; we use Azure-hosted models. The provider obligations sit with Azure (and upstream model authors). What we owe a customer is a clean inventory of which hosted models we depend on, so the customer can verify provider compliance against their own procurement standards.

3 · Multi-tenant isolation (defence-in-depth)

Single deployment, single Postgres, multiple tenants. Three layers, all funnelling through tenantId:

1. Routing. apps/web/src/middleware.ts matches the request Host against tenant.hosts[] and stamps x-tenant: <id>. In dev, ?tenant=<id> overrides. Server components read via getTenantFromHeaders(); client components receive a serialised prop from the root layout.
2. DB chokepoint. dbFor(tenantId) in apps/web/src/lib/db.ts returns a Prisma extension that auto-injects where.tenantId on reads, stamps data.tenantId on creates, and refuses update/delete/upsert whose where selector doesn't include tenantId (the composite unique keys (tenantId, contentHash) on Document and (documentId, chunkId) on Chunk make that natural). Raw SQL bypasses the extension by design; the only raw-SQL callers (apps/web/src/lib/search.ts) add the filter explicitly with parameter binding.
3. Filesystem. Every served asset is namespaced by tenant: public/figures/<tenantId>/<docId>/…, public/pages/<tenantId>/<docId>/…, corpus/<tenantId>/*.pdf.

Bidirectional leak detection lives in the eval suites: each tenant's fixture includes a few questions targeting other tenants' vocabulary that MUST refuse (e.g. crosstenant-sew-f11 in questions.porsche.json).

This is not a formal Act obligation at limited risk — but it is the single most-asked question in customer security review, and the architecture answers it cleanly.

4 · Gaps a productionising deployer would close

Listed honestly, in priority order, with rough effort.

1. Interaction logging (~½ day). Persist per-request: tenant, timestamp, query, retrieved chunk IDs, model versions used, answer text, citation set. Append-only, retention configurable per tenant. Not legally required at limited risk; required the moment a deployer asks "what did the system tell my engineer last Tuesday?" or a use case drifts toward high-risk.
2. Model inventory page (~2 hours). Auto-render the two MODELS maps as a public /models page. Include provider name and GPAI compliance link per entry.
3. System / model card (~½ day). Intended use, limitations (see CLAUDE.md § "Known limitations"), languages supported (currently German end-to-end), corpus scope, evaluation results from eval/, escalation contact. Public.
4. Tenant-side AI literacy briefing (~2 hours per tenant). One-pager covering what RAG is, when to defer to the source PDF, and the system's intended use boundary.
5. Incident reporting hook (~½ day). A "report a wrong answer" button on each assistant message, writing to the interaction log with a flag. Becomes the input to the deployer's incident process.
6. Export-time output marking (future). If/when the assistant gains export-to-PDF or share-link functionality, attach a machine-readable AI-generated marker at that boundary.

None of these require architectural changes. The system is deliberately designed so the compliance surface is additive.

5 · What this document is not

• It is not legal advice. It is an engineering self-assessment.
• It is not a Conformity Assessment under Art. 43 (which applies to high-risk systems only).
• It does not bind any customer to a particular risk classification of their downstream use. Deployers retain that determination.

6 · Maintenance

When any of the following change, update the relevant section:

• Tenant config / routing logic → Section 3.
• Model registries (ai-models.ts, models.py) → Section 2, Art. 53–55 row.
• Generator prompt (literal-quote rule) → Section 2, Art. 50(2) row.
• Eval coverage (eval/questions.*.json) → Section 2, Art. 15 row.
• UI disclosure copy → Section 2, Art. 50(1) row.