EU AI Act Compliance

Classification

A KYB/AML system is not automatically high-risk under the EU AI Act. Recital 58 of Regulation (EU) 2024/1689 explicitly excludes AML and fraud detection from the Annex III use cases, so TrustRelay does not assert an Annex III high-risk classification for its core KYB/AML function. The EU AI Act acts as a conditional driver only where a specific deployment brings the tool into Annex III scope (for example, using the platform for creditworthiness scoring of a natural person, Annex III Point 5(b)).

Instead, TrustRelay implements the Art. 11-15 style controls — technical documentation, automatic logging, transparency, human oversight, accuracy monitoring, and quality management — as defensible good practice. These controls are independently grounded in GDPR Art. 22 (automated decisions producing legal or similarly significant effects on a person), the AMLR requirement for a documented, demonstrable risk-based methodology with 5-year retention, and AMLA supervision. TrustRelay makes or informs decisions that affect individuals' access to financial services and business relationships, and this obligation framework maps directly onto the architectural requirements for a production-grade KYB/KYC compliance platform — regardless of whether any given deployment is formally in scope of Annex III.

Article-by-Article Mapping

Article 11 — Technical Documentation

Requirement	Implementation	Evidence
General description of the AI system	Architecture docs at trust-relay.pages.dev	Product overview, data flow, tech stack pages
Design specifications and development methodology	S4U Methodology with design-before-code principle	ADR records (81 ADRs documented, latest ADR-0082)
Information about training data	Not applicable — TrustRelay uses deterministic algorithms + LLM API calls, no custom-trained models	EVOI engine uses mathematical decision theory, not ML training
Development and testing procedures	PoC methodology with 90% workflow coverage target	pytest + testcontainers, no mocking without approval
Intended purpose and foreseeable misuse	KYB/KYC compliance for financial services onboarding	Documented in PRD and business context
Post-market monitoring plan	Case intelligence pattern detection, officer decision calibration	Episodic memory, cross-case pattern analysis

Article 12 — Automatic Logging

Article 12 requires high-risk AI systems to automatically record events during operation to enable post-hoc traceability and auditability.

Requirement	Implementation	Evidence
Automatic recording of events	evoi_decisions table logs every AI decision	31 rows per case: belief state, EVOI score, decision rationale
Traceability of AI operations	audit_events table with full event history	Case lifecycle from creation to decision
Identification of input data	Every finding has source field citing data origin	INSEE, NorthData, OpenSanctions, GLEIF, VIES
Network investigation audit trail	Each entity scan logged with EVOI decision, depth, connection weight	Compound risk scores are deterministic and reproducible
Immutability	audit_events is append-only and DB-enforced — a BEFORE UPDATE OR DELETE trigger, REVOKE UPDATE, DELETE on the app role, and an FK RESTRICT (migration 066, ADR-0064)	Structural, not by convention: even a superuser must deliberately drop the trigger to mutate history
Retention period	Minimum 5-year retention aligned with 6AMLD/AMLR	Deletion only on explicit officer action; case data retained per AML rules

The evoi_decisions log is the primary compliance artifact for Article 12. Every inference, every investigation decision, every skipped agent is recorded with the inputs that produced it. An auditor can reconstruct the exact state of the belief model at any point in a case's lifecycle.

Article 13 — Transparency

Article 13 requires that high-risk AI systems be designed so that deployers and affected persons can interpret their output and understand the basis for recommendations.

Requirement	Implementation	Evidence
Users can interpret output	Confidence scoring with 4-dimension breakdown	Evidence completeness, source diversity, consistency, calibration
Logic behind alerts documented	Every finding includes description + cited sources	"Credible adverse media: Le Monde (2026-03-20), Reuters (2018-04-25)"
Risk scores explainable	Compound risk scoring uses deterministic formula	Jurisdiction +30, dissolved +20, shared directors +10 each
Recommendation reasoning	ESCALATE verdict includes specific risk drivers	"ESCALATE: corruption allegations; 5 secrecy entities; SPF missing"
Model identification	Every LLM call records model version and prompt template	PydanticAI all_messages() captured; PromptRegistry tracks version
Limitations disclosed	Investigation scope, missing sources, and data freshness surfaced	SPF check failures, VIES API unavailability reported in findings

The confidence score decomposition — evidence completeness, source diversity, consistency, historical calibration — is specifically designed to satisfy Article 13(2)(b): the system must be interpretable to persons with reasonable technical knowledge. A compliance officer does not need to understand EVOI mathematics to understand "3/7 sources returned data; findings are internally consistent."

Article 14 — Human Oversight

Article 14 is the most architecturally consequential EU AI Act requirement. It mandates that high-risk AI systems be designed to allow effective oversight by natural persons.

Requirement	Implementation	Evidence
Human-in-the-loop by design	REVIEW_PENDING state requires officer decision	System never auto-approves — workflow waits for officer_decision signal
Override capability	Officers can accept/reject/follow-up/escalate	Decision recorded with timestamp and reasoning
System recommends, human decides	Recommendation is advisory ("ESCALATE"), not binding	Officer can approve despite escalation recommendation
Cannot suppress risk signals	Architectural constraint — findings cascade UP only	Network insights propagate to parent case as HIGH findings
Fallback mechanisms	Manual document review always available	Officer can upload/review documents independently of AI
Awareness of automation tendency	Confidence scores and source citations prevent blind trust	Officers see exactly which sources are missing
Audit of oversight decisions	Officer identity, timestamp, and reasoning recorded	audit_events table; decision immutable post-submission

This is not a paper commitment. The Temporal workflow is structurally incapable of transitioning from REVIEW_PENDING to APPROVED without a human signal. There is no code path that bypasses this gate. The system can recommend ESCALATE, APPROVE, or REJECT — but the state machine will not advance until an officer issues the officer_decision signal.

Article 15 — Accuracy, Robustness, Cybersecurity

Requirement	Implementation	Evidence
Accuracy monitoring	Confidence scoring tracks prediction quality	Historical calibration dimension (agreement rate with officer decisions)
Multi-source corroboration	7+ independent data sources per investigation	Cross-referencing reduces single-source errors
Bias mitigation	Fuzzy name matching with diacritics normalization	"Zoë" and "Zoe" matched correctly
Data freshness	OpenSanctions auto-refresh (sanctions daily, PEPs weekly)	831K entities, last refreshed tracked
Resilience to data gaps	Guard-and-swallow pattern — individual check failures don't block investigation	PEPPOL failure does not prevent OSINT completion
Resilience to adversarial inputs	Source diversity prevents manipulation via single-source poisoning	A false record in one registry is contradicted by others
Cybersecurity	Tenant isolation with PostgreSQL Row Level Security (set_config('app.current_tenant', ...) GUC + per-table policies)	RLS enforced at the DB layer — the app connects as the non-superuser trustrelay_app role (ADR-0050/0051), so FORCE ROW LEVEL SECURITY policies apply; the full test suite runs under enforcement

Article 17 — Quality Management System

Article 17 requires providers of high-risk AI systems to implement a documented quality management system covering the entire lifecycle.

Requirement	Implementation	Evidence
Risk management process	EVOI engine with asymmetric utility function	cost_false_negative (10,000) >> reward_correct_approve (100) — 100x penalty for false approvals
Data governance	Source attribution on every fact	source field on all findings, SourceBadge in UI
Post-market monitoring	Case intelligence learns from officer decisions	Episodic memory, pattern detection across cases
Documentation management	ADR records + Docusaurus site	81 ADRs, 250+ documentation pages
Testing and validation	Mandatory quality gates before every commit	ruff F-codes + TypeScript strict before merge
Corrective action process	ADR process for any deviation from PRD	New ADR required before implementing significant change
Traceability of changes	Git history + ADR records	Every architectural decision recorded with rationale

---

EVOI Decision Framework

The Expected Value of Investigation (EVOI) engine is the core AI decision-making component. It satisfies EU AI Act transparency requirements because every decision is mathematically grounded and auditable.

Mathematical Foundation

EVOI(agent) = E[V(b_after)] - V(b_now) - cost(agent)

Where:

• b_now = current belief state (probability distribution over clean / risky / critical)
• b_after = expected belief state after running the agent
• V(b) = expected utility of making the optimal decision given belief state b
• cost(agent) = normalized cost of running the agent (time + API calls)

An agent is run if and only if EVOI > 0. This means: "the expected improvement in decision quality exceeds the cost of obtaining the information."

Utility Function (Asymmetric by Design)

Decision	Outcome	Utility
Approve	Entity is clean	+100
Approve	Entity is risky	-1,000
Approve	Entity is critical	-10,000
Reject	Entity is clean	-50
Reject	Entity is risky	+500
Reject	Entity is critical	+1,000

The 100x asymmetry between cost_false_negative and reward_correct_approve is an explicit policy decision: the cost of approving a criminal entity is one hundred times greater than the cost of incorrectly rejecting a clean one. This is encoded in the EVOI utility function, not in ad-hoc rules.

This asymmetry is disclosed to officers via the confidence scoring UI and documented in the ADR for the EVOI engine.

Logged State Per Decision

Every row in evoi_decisions records:

Field	Description
case_id	Parent case
iteration	Workflow iteration number
step_number	Sequential step within iteration
decision_type	investigate, skip, or snapshot
candidate_agent	Agent being evaluated for the next step
belief_p_clean	Probability mass on "clean"
belief_p_risky	Probability mass on "risky"
belief_p_critical	Probability mass on "critical"
evoi_value	Computed EVOI score (with v_now, e_v_after, step_cost)
connected_entity_id	Network entity being evaluated
connection_weight	Strength of link to primary entity
network_depth	Depth in ownership/directorship graph
scan_tier	Investigation tier selected
decision	Resulting decision (investigate / skip)
reason	Human-readable decision explanation

For a typical Bolloré SE case, this table contains 31 rows covering the full investigation path: initial belief snapshots, 16 investigate decisions at depth 0, 6 skip decisions (budget exhausted), and 7 depth-1 discoveries.

Budget and Depth Constraints

The EVOI engine operates under two hard constraints:

• Budget cap: Network investigation budget is capped at 3× the primary investigation cost. The system cannot spend unbounded resources on recursive entity discovery.
• Depth cap: Recursive network scanning is bounded at max_network_depth=2. There are no infinite loops; the recursion terminates by construction.

Both constraints are logged. When an investigation is truncated by budget or depth, the truncation reason is recorded in audit_events.

---

Network Investigation Audit Trail

The network investigation module (entity graph scanning) presents a specific Article 12 compliance challenge: the investigation visits dozens of entities, each with its own risk signal, and the final case finding is a compound of all discovered signals. An auditor must be able to reproduce exactly why the system flagged a subsidiary three hops removed from the primary entity.

The audit trail design handles this as follows:

1. Entity scan log: Every entity scanned — primary, subsidiary, director, UBO — is logged with the EVOI decision that authorized the scan.
2. Finding provenance: Every finding records which entity it originated from, what scan tier produced it, and which external source returned the data.
3. Signal propagation log: When a network finding is promoted to a parent case finding, the propagation is recorded with the connection weight and depth that justified promotion.
4. Deterministic reproducibility: Because EVOI is a deterministic mathematical function given the belief state, any historical investigation can be replayed from the logged inputs.

---

Regulatory Alignment Summary

:::info The authoritative status is the live conformity record The table below states the design intent per obligation. The authoritative, per-obligation status is generated at runtime by the conformity record (ADR-0072, GET /api/conformity/ai-act.pdf), which grades each obligation satisfied / partial / gap from live model-tiers and the prompt registry, and names known gaps (SSO/SCIM, ISO, data residency) rather than asserting blanket "Full". Where the two differ, the generated record wins. See Live conformity record below. :::

EU AI Act Article	Design Intent	Implementation Mechanism
Art. 6 + Annex III (Classification)	Not Annex III for core KYB/AML	Recital 58 excludes AML/fraud detection; controls applied as good practice, conditionally in-scope only for e.g. creditworthiness scoring (Point 5(b))
Art. 11 (Technical Documentation)	Satisfied	ADRs, Docusaurus, methodology, PRD; generated conformity record
Art. 12 (Automatic Logging)	Satisfied	evoi_decisions + DB-immutable audit_events (ADR-0064)
Art. 13 (Transparency)	Satisfied (data-subject notice partial)	Explainable scores, cited sources, model identification; full notice template pending legal review
Art. 14 (Human Oversight)	Satisfied	Human-in-the-loop by Temporal design; four-eyes on high-risk decisions (ADR-0070)
Art. 15 (Accuracy & Robustness)	Satisfied	Multi-source, calibration, diacritics normalization; fail-closed "not assessed" (ADR-0067)
Art. 17 (Quality Management)	Satisfied	EVOI asymmetric utility, ADR process, testing gates

---

Live conformity record (ADR-0072)

Rather than a static compliance claim, Trust Relay emits a machine-generated, data-driven conformity record at GET /api/conformity/ai-act.pdf (app/api/conformity.py → app/services/ai_act_conformity_service.py). It builds the Art. 11–15 record from live system state — the configured model-tiers (ADR-0029) and the prompt registry (ADR-0026) — and grades each obligation satisfied / partial / gap with citations to the ADRs that substantiate it (ADR-0021 evidence bundles, ADR-0064 audit immutability, ADR-0070 four-eyes, ADR-0067 fail-closed). Crucially it names its own known gaps (SSO/SCIM, ISO 27001/42001/27701, data residency) instead of asserting blanket completeness — the honest-status posture the platform applies to compliance outputs applies to its own conformity claim too.

---

Additional Regulatory Coverage

The EU AI Act compliance architecture intersects with and reinforces several other regulatory frameworks:

GDPR

Article	Requirement	Implementation
Art. 22	Right to human review of automated decisions	Officer decision required — no automated final decisions
Art. 25	Privacy by design	Tenant isolation via PostgreSQL Row Level Security (18 sensitive tables under FORCE RLS) — implemented. PII at-rest encryption: mechanism only, not an active control — EncryptedText (AES-256-GCM) exists but pii_encryption_enabled defaults to False, and only 3 columns use it (not name/DOB/national-id). See docs/controls-register.md
Art. 30	Records of processing activities	audit_events captures processing steps; DomainEvent correlation/causation chains link related events
Art. 35	Data Protection Impact Assessment	Architecture supports DPIA; formal document pending (known gap)
Art. 15/16/17	Data subject access, rectification, erasure	app/api/data_subject.py — /api/data-subject/{access,rectify,erase}; erasure respects AML 5-year retention via DSRService. Known gap — erasure is incomplete: DSRService deletes from two Postgres tables, but its own declared DSR_SCOPE also covers MinIO ID-documents, goAML draft JSONB, and Neo4j Person nodes, which it does not touch. Tracked as M1-W6

AML Directives (6AMLD / AMLR)

Requirement	Implementation
5-year minimum retention	Audit events and case data retained; deletion requires explicit officer action
SAR-ready audit trail	goAML XML export (Phase 1) generates structured transaction reports
Risk-based methodology	EVOI utility function is a documented, auditable risk-based approach
Documented due diligence	Each case produces a full investigation report with source citations

ISO 42001 — AI Management System

The EVOI framework aligns directly with ISO 42001's risk-based approach to AI governance:

• Clause 6.1 (Risk assessment): EVOI utility function is a formal risk assessment model with documented parameters.
• Clause 8.4 (AI system impact assessment): Confidence scoring provides the required uncertainty quantification.
• Clause 9.1 (Monitoring and measurement): Historical calibration dimension tracks AI decision quality over time.
• Clause 10.2 (Nonconformity and corrective action): ADR process provides the required corrective action mechanism.

ISO 27001 — Information Security Management

Domain	Implementation
A.8 (Asset management)	MinIO object storage with tenant-scoped prefixes
A.9 (Access control)	Keycloak OIDC, JWKS token validation, role-gated endpoints, RLS at DB layer on sensitive tables
A.12 (Operations security)	Audit logging, immutable event records
A.18 (Compliance)	This documentation; ADR process; testing gates

---

Known Gaps

Gap	Status	Mitigation
GDPR Art. 35 formal DPIA document	Architecture supports it; document not yet drafted	Low risk — DPIA can be produced from existing documentation
ISO 42001 formal certification	Not yet pursued	Framework alignment enables rapid certification path
ISO 27001 formal certification	Not yet pursued	Prerequisite for enterprise sales; planned post-PoC
SSO / SCIM enterprise identity	SSO federation design only (ADR-0076); SCIM not implemented	Named as a gap in the conformity record; roadmap item
EU data-residency contract	Not yet in place	Named as a gap in the conformity record
Art. 13 transparency notice to data subjects	Portal discloses AI-assisted review	Full notice template pending legal review

Resolved since 2026-06-11 (previously listed here):

• audit_events immutability — now DB-enforced: migration 066 adds a BEFORE UPDATE OR DELETE trigger, REVOKE UPDATE, DELETE ON audit_events FROM trustrelay_app, and an FK RESTRICT (ADR-0064). See Compliance Controls §1.
• Per-tenant audit isolation — AuditService.log_event(..., tenant_id=...) now opens get_tenant_session(tenant_id); audit events are written under the case's actual tenant.

These gaps are known and tracked. None affect the architectural correctness of the compliance implementation; they represent documentation and process formalization work that follows the PoC phase. The live, data-driven conformity record (below) is the authoritative per-obligation status.