# 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](#high-risk-classification-posture)
2. [Article 9 — Risk management system](#article-9--risk-management-system)
3. [Article 10 — Data and data governance](#article-10--data-and-data-governance)
4. [Article 11 — Technical documentation](#article-11--technical-documentation)
5. [Article 12 — Record-keeping (logging)](#article-12--record-keeping-logging)
6. [Article 13 — Transparency and deployer information](#article-13--transparency-and-deployer-information)
7. [Article 14 — Human oversight](#article-14--human-oversight)
8. [Article 15 — Accuracy, robustness, and cybersecurity](#article-15--accuracy-robustness-and-cybersecurity)
9. [Article 5 prohibitions](#article-5-prohibitions)
10. [GPAI model obligations](#gpai-model-obligations)
11. [Deployer-side obligations relevant to Concordia](#deployer-side-obligations-relevant-to-concordia)
12. [Maat / Themis / Kuanyin review-gate mapping](#maat--themis--kuanyin-review-gate-mapping)
13. [Coverage matrix](#coverage-matrix)
14. [Named gaps and follow-ups](#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`](../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`](../research/source-matrix.md) and
   bibliography at [`../research/bibliography.md`](../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

| AI Act obligation               | Contracts landed                         | Orchestrator / deferred         | Release gate         |
| ------------------------------- | ---------------------------------------- | ------------------------------- | -------------------- |
| Art. 9 risk management          | partial (NIST mapping pending 179.1.3.3) | 179.5.3.4, 179.10.\*            | 179.10.7             |
| Art. 10 data governance         | partial (consent module landed)          | 179.5.4.\*, 179.5.5.5           | 179.10.11, 179.10.14 |
| Art. 11 technical documentation | partial (source matrix + bibliography)   | 179.1.3.4 model/system cards    | —                    |
| Art. 12 logging                 | partial (retention on use-case profile)  | 179.2.2.3, 179.6.3.4            | 179.10.1             |
| Art. 13 transparency            | partial (banners landed)                 | 179.4.3.\*, 179.5.3.3           | —                    |
| Art. 14 human oversight         | landed (escalation, boundaries)          | 179.5.3.\*, 179.5.5.1           | 179.10.7             |
| Art. 15 accuracy/robustness     | not in contracts                         | 179.3.2.4, 179.5.1.5, 179.5.2.3 | 179.10.5, 179.10.6   |
| Art. 5 prohibitions             | partial (hard boundaries)                | 179.4.3.5, 179.6.3.5            | —                    |
| GPAI obligations (Art. 53+)     | not in contracts                         | 179.5.1.3, 179.5.3.3            | —                    |

---

## 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`](../research/refresh-gate.md)
§R3.