EU AI Act High-Risk Requirements — Concordia Mapping

Mapping date: 2026-04-23

Scope: Phase 179 Concordia task 179.1.3.2.

This document maps the EU AI Act's high-risk AI system requirements (Regulation (EU) 2024/1689, Articles 8–15 and adjacent obligations) to Concordia product requirements and Phase 179 task pointers. It focuses specifically on the justice and democratic-process adjacent uses Concordia supports through Maat procurement, Themis governance, and Kuanyin restorative moderation, and explicitly identifies which Concordia use-case classes the Act's high-risk regime most likely applies to.

Sources:

• Regulation (EU) 2024/1689 of the European Parliament and of the Council (the "AI Act"), published in the Official Journal 2024-07-12, effective in staged waves from 2025-02 through 2027.
• European Commission AI Act portal: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (fetched 2026-04-23).

The mapping is an engineering artifact, not a legal-compliance certification. It names the Concordia positions and follow-ups the product team must close before any Concordia offering is marketed as AI Act conformant. Specific conformity-assessment procedures, CE marking obligations, post-market monitoring, and specific deployer obligations require counsel review and are called out as Phase C / D follow-ups.

Table of contents#

1. High-risk classification posture
2. Article 9 — Risk management system
3. Article 10 — Data and data governance
4. Article 11 — Technical documentation
5. Article 12 — Record-keeping (logging)
6. Article 13 — Transparency and deployer information
7. Article 14 — Human oversight
8. Article 15 — Accuracy, robustness, and cybersecurity
9. Article 5 prohibitions
10. GPAI model obligations
11. Deployer-side obligations relevant to Concordia
12. Maat / Themis / Kuanyin review-gate mapping
13. Coverage matrix
14. Named gaps and follow-ups

High-risk classification posture#

The AI Act's high-risk categories in Annex III most relevant to Concordia are:

• Annex III §5 — access to essential private and public services and benefits, including credit scoring, public assistance benefits, and access to essential services. Not directly Concordia, but adjacent when Concordia mediates refunds, subscription access, or benefit disputes.
• Annex III §6 — law enforcement. Concordia stays out of this; criminal_matter_settlement hard boundary refuses criminal-matter outputs.
• Annex III §7 — migration, asylum and border control management. Concordia stays out; immigration_decision hard boundary refuses.
• Annex III §8 — administration of justice and democratic processes. This is where Concordia's legal_claim, dao_governance, and platform-moderation mediation paths can be implicated.

Concordia's Phase 179.1.2 posture is that the legal_claim, regulated_financial, employment_sensitive, family_sensitive, medical_sensitive, and dao_governance use-case classes are presumed high-risk under Annex III §8 (administration of justice and democratic processes) when deployed to EU-resident parties. This is a precautionary posture — whether any specific Concordia deployment technically meets the Annex III criteria depends on the use case and must be confirmed with counsel during tenant onboarding.

Low-risk / transparency-only posture. The remaining use-case classes (low_stakes_personal, community_restorative, creative_collaboration, commerce_negotiation, supplier_procurement, agent_to_agent_contract, simulation_only) default to the transparency obligations in Article 50 (disclosing that content is AI-generated; informing the person they are interacting with an AI system) rather than the full high-risk regime. Tenant deployments may elevate a use case to the high-risk regime by policy; they may not downgrade it.

Article 9 — Risk management system#

AI Act requirement. Providers of high-risk AI must establish, implement, document, and maintain a continuous risk management system over the AI system's lifetime. It identifies foreseeable risks, estimates them under intended use and foreseeable misuse, evaluates risks from post-market data, and adopts mitigation measures.

Concordia product requirement.

1. NIST AI RMF mapping at 179.1.3.3 provides the engineering-grade risk register (Govern / Map / Measure / Manage functions).
2. Incident reporting at 179.5.3.4 captures post-market risk signals (unsafe recommendations, privacy leaks, biased outcomes, unauthorized acceptance, execution mismatch) and routes them into the refresh gate in ../research/refresh-gate.md §R5.
3. Red-team and adversarial suites in §179.5.2, §179.7.6.4, and §179.8.3 enumerate misuse modes Concordia specifically tests against.
4. Release gates in §179.10.* block advancement when fairness (179.10.6), privacy (179.10.5), authorization (179.10.10), or consent (179.10.11) tests regress.

Phase 179 task pointers. 179.1.3.3, 179.5.2.*, 179.5.3.4, 179.7.6.4, 179.8.3, 179.10.5–179.10.11.

Gaps. Concordia's risk register as a living document that is versioned with the product is not a named deliverable today. Add a docs/compliance/risk-register.md follow-up under 179.1.3.3.

Article 10 — Data and data governance#

AI Act requirement. Training, validation, and testing data must meet quality criteria: relevance, representativeness, freedom from error where possible, and fitness for purpose. Governance must address data collection, processing, assumptions, biases, gaps, and appropriate prevention / mitigation of bias.

Concordia product requirement.

1. Training-data governance at §179.5.5.5: de-identification review, re-identification risk scoring, sensitive-case exclusion, consent propagation, dataset lineage, removal / unlearning policy, and model-card linkage for any trace reused in Phases 85-96.
2. Consent module at @concordia/contracts/consent landed for §179.1.2.4 controls the upstream training-data eligibility: the training_data_reuse purpose is always opt-in and revocable.
3. Use-case-class profiles carry a trainingDataReuseEligible flag (sensitive classes are false — cannot train on them regardless of individual party consent).
4. Evidence chain-of-custody at §179.5.4.3 and redaction / minimization at §179.5.4.4 prevent unconsented / unredacted evidence from entering benchmarks or training corpora.
5. Benchmark dataset governance at §179.8.1 ensures synthetic suites rather than production traces when licensing is unclear.

Phase 179 task pointers. 179.5.4.3, 179.5.4.4, 179.5.5.5, 179.8.1.*, 179.10.14 (training-data gates).

Gaps. A per-dataset data sheet (Gebru et al. style) documenting source, consent chain, representativeness, known biases, and licensing is not a named task today; add under 179.5.5.5.

Article 11 — Technical documentation#

AI Act requirement. Providers maintain comprehensive technical documentation (Annex IV): system description, purpose, provider identity, development process, design rationale, main components, hardware requirements, integration, data requirements, training methods, evaluation metrics, expected accuracy, validation procedures, monitoring mechanisms, and change management.

Concordia product requirement.

1. Model-card and system-card templates at §179.1.3.4 — required for every mediation model, evaluator, domain policy bundle, and optimization strategy.
2. Source matrix at ../research/source-matrix.md and bibliography at ../research/bibliography.md give academic grounding traceable per model.
3. ADR / proposal documents under docs/proposals/ and docs/adr/ (referenced in 179.2.4.5 service-layer decision) document architectural decisions.
4. Generated OpenAPI docs at libs/openapi/docs/concordia/ (per 179.2.4.2) provide integration surface documentation.

Phase 179 task pointers. 179.1.3.4, 179.2.4.2, 179.2.4.5, 179.5.3.3 (model and optimizer version pinning).

Gaps. The bundling of model cards + system cards + data sheets + ADRs into a single Annex-IV-shaped document per release is not a named task; add a docs/compliance/technical-documentation/ follow-up under 179.1.3.4.

Article 12 — Record-keeping (logging)#

AI Act requirement. High-risk systems must automatically log events over their lifetime ("logs") sufficient to trace operation and to identify situations of risk. Logs must be kept by the provider for an appropriate period.

Concordia product requirement.

1. Audit events at §179.2.2.3 cover: case created, party joined, intake completed, issue identified, preference updated, offer generated, offer compared, search completed, draft reviewed, settlement accepted, execution completed, escalation required.
2. GET /concordia/audit/{id} endpoint at §179.2.2.1 exposes the trail with model and optimizer versions pinned (§179.5.3.3).
3. Audit retention per use-case class is encoded in the use-case-class profile (minimumAuditRetentionDays, -1 for indefinite legal hold). Already landed in @concordia/contracts and covered by tests.
4. Observability at §179.6.3.4 records: traces per case, scoring cost, model latency, candidate diversity, preference uncertainty, agreement rate, escalation rate, privacy-gate failures.

Phase 179 task pointers. 179.1.3.5 (retention), 179.2.1.1 (case schema), 179.2.2.3 (event schemas), 179.5.3.3 (version pinning), 179.6.3.4 (observability), 179.10.11 (audit tests).

Gaps. Structured log format alignment with a common auditable schema (OpenTelemetry semantic conventions, or AI Act Annex IV logging schema if published) is not a named task; add under 179.6.3.4.

Article 13 — Transparency and deployer information#

AI Act requirement. High-risk providers must supply deployers with instructions for use that cover: identity and contact details, purpose, performance characteristics, training / validation / testing data characterization, known foreseeable misuse, human-oversight measures, expected lifetime, maintenance updates, interpretability capabilities.

Concordia product requirement.

1. Operational-mode banners at §179.1.2.3 give the end-user a plain-language statement of what Concordia is doing.
2. Per-case disclosure of model and optimizer versions (§179.5.3.3) lets deployers attribute a decision to a specific model build.
3. Pareto-frontier explanation (§179.4.3.1) and party-specific private / shared explanation layers (§179.4.3.2–179.4.3.3) meet the interpretability expectation.
4. Tenant and domain configuration surface (§179.6.3.5) documents legal disclaimers, eligible use cases, model routing, review thresholds, data residency, execution adapters, retention policy for each tenant.

Phase 179 task pointers. 179.1.2.3 (landed), 179.4.3.*, 179.5.3.3, 179.6.3.5.

Gaps. A Concordia deployer guide (per-tenant instructions-for-use pack) is not a named task; add under 179.6.3.5.

Article 14 — Human oversight#

AI Act requirement. High-risk systems must be designed so natural persons can effectively oversee operation, prevent or minimize risks, and intervene or halt the system. Operators must be able to understand the system's capacities, monitor it, override outputs, and stop it.

Concordia product requirement.

1. Reviewer queues at §179.5.3.1 for human mediators, counsel, compliance, DAO stewards, procurement officers, safety teams, domain experts. Landed as ReviewerQueue in @concordia/contracts/escalation.
2. Override, pause, reopen, appeal, and nullification workflows (§179.5.3.2) with complete audit trail.
3. Kill-switch and feature-flag controls (§179.5.5.3) for mediation model routing, autonomous acceptance, smart-contract execution, search kernels, domain adapters.
4. Dual-control and blocking-autonomous-acceptance invariants in the escalation decision landed under §179.1.2.5 — deriveEscalationDecision returns requiresDualControl and blocksAutonomousAcceptance fields that downstream orchestration enforces.
5. Hard-boundary refusal at §179.1.2.2 ensures that certain categories of output (custody, medical, immigration, criminal, disability, coercive-control) are never produced autonomously regardless of reviewer availability.
6. Reviewer-capacity controls at §179.5.5.1: queue SLA, assignment, dual-control, calibration, audit sampling, escalation when no qualified reviewer is available; blocked launch for unstaffed gates.

Phase 179 task pointers. 179.1.2.2 (landed), 179.1.2.5 (landed), 179.5.3.*, 179.5.5.1, 179.5.5.3, 179.10.7 (governance review gate).

Gaps. Operator training material and oversight-competence requirements (reviewers must be qualified to use the system effectively) are not a named task; add under 179.5.3.1.

Article 15 — Accuracy, robustness, and cybersecurity#

AI Act requirement. High-risk systems must achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle; accuracy metrics must be disclosed; systems must be resilient to errors, faults, inconsistencies, and attempts to alter outputs.

Concordia product requirement.

1. Preference-stability tests at §179.3.2.4: paraphrase, prompt-template, model-version, order-effect, and adversarial framing.
2. Calibrated uncertainty outputs at §179.3.2.5: posterior mean, credible interval, comparison count, instability warnings.
3. Adversarial candidate tests at §179.5.2.3 for specification gaming; adversarial negotiation tests at §179.7.6.4 for prompt injection, hidden-tool access, budget escalation, side-channel leakage, and collusive agent behavior.
4. Privacy red-team at §179.5.1.5 against prompt injection, tool exfiltration, summary leakage, side-channel inference, shared-explanation leakage.
5. Benchmark gates at §179.10.6 require improvement over baseline systems on at least six domain suites before release.
6. Per-use-case accuracy and fairness thresholds are tracked in 179.8.2.* and gated on at 179.10.6.

Phase 179 task pointers. 179.3.2.4, 179.3.2.5, 179.5.1.5, 179.5.2.3, 179.7.6.4, 179.8.*, 179.10.5, 179.10.6.

Gaps. Supply-chain integrity (software bill of materials, signed dependencies, reproducible builds) is not a named Concordia task; the Phase 179 scope assumes the Oshun-wide build / supply-chain posture applies. Confirm in Phase C pilot readiness under 179.9.3.1.

Article 5 prohibitions#

The AI Act prohibits (not merely restricts) the following. Concordia's hard-boundary enum at §179.1.2.2 is designed so these categories cannot be produced:

• Subliminal / manipulative techniques causing significant harm. Concordia's coercive-choice safeguards (§179.4.3.5) explicitly ban dark patterns, countdown pressure, hidden settlement authority, manipulated anchors. Additionally, coercive_control_decision boundary refuses operationalizing coercive control.
• Exploiting vulnerabilities based on age, disability, or social / economic situation causing significant harm. Concordia's minor_party_without_guardian, medical_settlement, disability_rights_settlement, and the full sensitive-class family prevent this.
• Social scoring by public authorities. Not a Concordia use case. Add explicit refusal in the tenant onboarding policy.
• Real-time remote biometric identification in public spaces. Not a Concordia use case.
• Predictive policing and emotion recognition at work or in education. Concordia's emotional_context consent purpose is strictly advisory-to-mediator and never for workplace-surveillance or education-assessment use. The tenant configuration surface (§179.6.3.5) must block these uses.

Phase 179 task pointers. 179.1.2.2 (landed), 179.4.3.5, 179.6.3.5, 179.7.5.* (commerce adapters), 179.7.1.* (Maat procurement).

Gaps. The tenant onboarding contract must explicitly name these Article-5 prohibitions as "Concordia will not serve." Add under 179.6.3.5.

GPAI model obligations#

Providers of general-purpose AI (GPAI) models have Article 53+ obligations: technical documentation, copyright compliance, training-data summary disclosures, and (for systemic-risk GPAI) red-team testing and incident reporting.

Concordia does not train its own GPAI foundation model; it uses third- party GPAI models (OpenAI, Anthropic, local models per Nous routing in §179.5.1.3) as components. GPAI obligations therefore fall on the underlying provider. Concordia's obligations are:

1. Verify and document the GPAI models Concordia integrates with meet AI Act GPAI obligations (vendor due diligence).
2. Ensure per-model configuration (Nous routing, §179.5.1.3) records which model version was used for each decision (version pinning, §179.5.3.3).
3. Respect GPAI copyright-compliance posture in any training-data reuse under §179.5.5.5.

Phase 179 task pointers. 179.5.1.3, 179.5.3.3, 179.5.5.5.

Gaps. A Concordia model provenance registry that lists every GPAI provider Concordia integrates with and their AI Act conformance posture is not a named task; add under 179.5.5.5.

Deployer-side obligations relevant to Concordia#

Concordia is typically deployed by another organization (a law firm running mediation; a procurement team running supplier negotiations; a DAO steward running governance). Those deployers carry their own Article 26 obligations:

• Monitor system behavior for risks.
• Keep logs (mirrors Article 12 provider obligations).
• Ensure input data is relevant and representative.
• Suspend use and notify the provider when risks materialize.
• Inform workers before deployment in workplace settings.

Concordia supports deployers by:

1. Surfacing the audit events they need to monitor (§179.2.2.3, §179.6.3.4).
2. Providing per-tenant configuration (§179.6.3.5) that makes deployer-side controls possible.
3. Exposing the kill-switch and feature-flag surface (§179.5.5.3) to tenants.
4. Making the operational-mode banner (§179.1.2.3) visible to every end user, which helps deployers satisfy their workplace-notice obligations.

Maat / Themis / Kuanyin review-gate mapping#

Per §179.1.3.2, the EU AI Act high-risk requirements must route into review gates specific to Maat, Themis, and Kuanyin. The mapping:

Maat procurement (supplier_procurement, commerce_negotiation).

• Article 9 risk management: §179.7.1.5 benchmark against manual historical.
• Article 10 data governance: sanctions / KYC / AML screening in §179.5.5.4.
• Article 12 logging: procurement audit trails in 179.7.1.* and 179.6.3.4.
• Article 13 transparency: banner text for procurement_negotiation mode (landed in @concordia/contracts/banners) explicitly states "every offer and counter is logged."
• Article 14 human oversight: executive approval gates in §179.7.1.4 and §179.5.5.4 (segregation of duties, approval thresholds).

Themis governance (dao_governance, platform_dispute).

• Article 8 high-risk status: presumed under Annex III §8 (administration of democratic processes) when deployed in EU member states with formal-governance characteristics.
• Article 9: DAO-steward review in §179.5.3.1 and §179.7.2.1.
• Article 13: governance-process banner (landed) states "your body still votes."
• Article 14: Themis dispute modules in §179.7.2.3, plus integration with Maat governance (§179.5.3.5) for board-level oversight.

Kuanyin restorative (community_restorative).

• Article 9: safety-specific terms in §179.7.3.2 (no-contact boundaries, content takedown timelines, community participation limits).
• Article 10: sensitive-case training-reuse exclusion (trainingDataReuseEligible: false for community_restorative).
• Article 14: required reviewers are human_mediator + domain_expert (landed); escalation policy is always (landed).
• Hard boundaries: domestic_violence_decision, coercive_control_decision, criminal_matter_settlement are all presumptively active for community-restorative work.

Coverage matrix#

Named gaps and follow-ups#

These gaps are surfaced by the AI Act mapping but are not yet explicit Phase 179 tasks:

• Risk register as a living, versioned document. Add under 179.1.3.3 alongside NIST AI RMF mapping.
• Dataset data sheets (Gebru et al. style) per reused trace corpus. Add under 179.5.5.5.
• Annex-IV-shaped technical-documentation bundle combining model cards, system cards, data sheets, ADRs. Add under 179.1.3.4.
• Structured log schema for audit events (OpenTelemetry-compatible or AI-Act-Annex-IV-compatible). Add under 179.6.3.4.
• Deployer guide (per-tenant instructions for use). Add under 179.6.3.5.
• Operator training material for reviewers on each queue. Add under 179.5.3.1.
• Supply-chain integrity / SBOM / signed dependencies confirmation. Add under 179.9.3.1 Phase C pilot readiness.
• Tenant onboarding policy that explicitly names Article 5 prohibited uses. Add under 179.6.3.5.
• GPAI provider registry listing each integrated model and its AI Act posture. Add under 179.5.5.5.

Refresh: re-check the EU AI Act implementing acts and delegated acts at every gate firing per ../research/refresh-gate.md §R3.