ARCS/Crosswalks/ARCS / EU AI Act Crosswalk
ARCS / EU AI Act Crosswalk
Overview
Regulation (EU) 2024/1689, the EU AI Act, is a risk-based regulatory framework with differentiated obligations depending on system classification and actor role. It entered into force on 1 August 2024 and is generally applicable from 2 August 2026.
ARCS is a separate lifecycle-governance standard for the records AI systems create. This crosswalk maps selected ARCS control families against AI Act obligations relevant to interaction-record governance, documentation, traceability, and lifecycle treatment.
Interpretive status
This crosswalk is an informative legal mapping instrument. It is not an equivalence determination, conformity assessment, certification, CE-marking analysis, or legal opinion. Whether a system falls within the high-risk regime depends on Article 6 and Annex III; ARCS does not replace that classification analysis.
Framework scope
This page addresses selected logging, recordkeeping, and post-creation governance questions. It focuses on provisions that create, require, or presuppose record-generation, logging, retention, monitoring, or documentation duties, and on the lifecycle consequences of those records after creation.
ARCS relevance
Where the EU AI Act requires that logs, documentation, monitoring records, or disclosure artifacts exist, ARCS governs the next layer: custody, lifecycle state, retention duration, deletion posture, preservation status, downstream propagation, and verification of operator or vendor assertions about those records.
Selected mappings
Table A maps selected EU AI Act obligation areas to ARCS control families. The mapping is directional and explanatory. It is intended to aid governance interpretation, not to claim legal compliance or obligation equivalence.
| AI Act obligation area | Reference | ARCS controls | Alignment |
|---|---|---|---|
| High-risk classification boundary | Art. 6; Annex III | ARCS-OPB, ARCS-TAX, ARCS-AGT | Operates alongside |
| Risk management across lifecycle | Art. 9 | ARCS-LIF, ARCS-TAX, ARCS-AGT, ARCS-DEL, ARCS-VER | Meets |
| Data and data governance | Art. 10 | ARCS-TAX, ARCS-LIF, ARCS-OPB, ARCS-AGT | Meets |
| Technical documentation | Art. 11; Annex IV | ARCS-VER, ARCS-TAX, ARCS-OPB, ARCS-AGT, ARCS-DEL | Meets |
| Record-keeping and logs | Art. 12 | ARCS-LIF, ARCS-TAX, ARCS-VER, ARCS-AGT, ARCS-DEL | Exceeds |
| Transparency and information to deployers | Art. 13 | ARCS-TAX, ARCS-OPB, ARCS-VER, ARCS-AGT | Meets |
| Human oversight | Art. 14 | ARCS-OPB, ARCS-AGT, ARCS-DEL, ARCS-VER | Operates alongside |
| Accuracy, robustness, and cybersecurity | Art. 15 | ARCS-AGT, ARCS-VER, ARCS-OPB | Operates alongside |
| Provider obligations and quality system structure | Arts. 16-17 | ARCS-OPB, ARCS-VER, ARCS-CUS, ARCS-LIF | Operates alongside |
| Corrective actions and authority cooperation | Arts. 20-21 | ARCS-VER, ARCS-CUS, ARCS-OPB, ARCS-PV | Meets |
| Transparency obligations for certain AI systems | Art. 50 | ARCS-PUB, ARCS-NCR, ARCS-VER, ARCS-AGT | Meets |
| Post-market monitoring | Art. 72 | ARCS-LIF, ARCS-VER, ARCS-AGT, ARCS-DEL, ARCS-CUS | Meets |
| Serious incident reporting | Art. 73 | ARCS-VER, ARCS-PV, ARCS-CUS, ARCS-AGT | Meets |
Alignment designations. "Exceeds" indicates that ARCS introduces governance or architectural controls beyond the minimum structure contemplated by the cited AI Act provision. "Meets" indicates that ARCS provides controls materially responsive to the cited obligation. "Operates alongside" indicates that ARCS addresses a related governance surface, but the cited provision also depends on product-safety, fundamental-rights, conformity-assessment, market-surveillance, or market-placement requirements outside ARCS's primary scope. These designations are interpretive and informative only.
1. Classification and scope
The first legal question under the AI Act is often not whether controls exist, but whether the system is subject to the Act's high-risk requirements. Article 6 and Annex III provide the main classification structure for high-risk AI systems. ARCS does not determine whether a system is high-risk under Union law. It supports the operator's ability to document system boundaries, execution conditions, and record classes relevant to that analysis. ARCS-OPB, ARCS-TAX, and ARCS-AGT should therefore be understood as supporting classification evidence rather than substituting for classification itself.
2. Lifecycle risk management
Article 9 requires a risk management system for high-risk AI systems that is established, implemented, documented, and maintained throughout the lifecycle of the system. This is one of the strongest points of connection to ARCS-LIF. Where relevant risks turn on persistence, transmission, delegation, reviewability, or downstream record exposure, ARCS helps convert those conditions from implicit technical behavior into declared governance treatment.
3. Data governance and classification
Article 10 addresses data and data governance for high-risk AI systems. ARCS is not a substitute for the AI Act's dataset-oriented requirements concerning appropriateness, governance, and quality of training, validation, and testing data. It is, however, useful for governance of runtime artifacts, retained state, intermediate records, and downstream memory-bearing system outputs. ARCS-TAX, ARCS-LIF, and ARCS-AGT therefore support traceable classification of record classes that may later matter for review, challenge, or enforcement.
4. Technical documentation and traceability
Article 11 requires technical documentation for high-risk AI systems, and Annex IV specifies required content. ARCS-VER, ARCS-TAX, ARCS-OPB, ARCS-AGT, and ARCS-DEL support this area by making record treatment, delegation conditions, and execution-boundary claims reviewable against evidence. ARCS does not by itself satisfy every Annex IV documentation element. It does, however, strengthen the operator's ability to show how record-governance claims were implemented and how runtime-generated artifacts were treated in practice.
5. Record-keeping and logs
Article 12 is the strongest direct point of overlap. It requires logging capabilities for high-risk AI systems appropriate to the intended purpose. ARCS goes beyond this by treating logs, traces, intermediate artifacts, delegated-memory outputs, and record-bearing execution events as governance objects with distinct taxonomy and lifecycle consequences. Where the AI Act requires logging capacity, ARCS supplies a more specific governance model for what those records are, when they should exist, how they should be classified, and under what conditions they should persist or be verified.
6. Transparency and information to deployers
Article 13 requires that high-risk AI systems be accompanied by instructions for use and information to deployers. ARCS contributes where those instructions concern runtime artifacts, retained state, custody conditions, and operator-boundary assumptions. ARCS-OPB, ARCS-TAX, ARCS-VER, and ARCS-AGT support clearer statements about what classes of records may be created, what review surfaces exist, and where governance responsibility begins and ends.
7. Human oversight, robustness, and cybersecurity
Articles 14 and 15 concern human oversight, accuracy, robustness, and cybersecurity. These areas are adjacent to ARCS, but not identical to its center of gravity. ARCS can support evidence, runtime classification, verification, and delegation traceability that make those obligations more reviewable. It should not be presented as a substitute for product-performance validation, safety engineering, or cybersecurity controls required by the AI Act.
8. Provider obligations and quality management structure
The AI Act imposes provider obligations for high-risk AI systems and contemplates a quality management system as part of that compliance structure. ARCS can support the record-governance portion of those obligations, especially where the operator must show auditable lifecycle treatment, custody visibility, boundary control, and evidence discipline. It does not constitute the full provider-side quality management system contemplated by the Act.
9. Transparency obligations for certain AI systems
Article 50 imposes transparency duties for certain AI systems outside the high-risk core, including disclosure duties in specified cases. ARCS-PUB, ARCS-NCR, ARCS-VER, and ARCS-AGT are relevant where publication-boundary events, synthetic outputs, or externally exposed agent actions must be distinguished from internal runtime state. ARCS is useful here because it makes publication and non-creation claims more evidentiary and less rhetorical.
10. Post-market monitoring and incident response
Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the relevant technology and risks. Article 73 addresses serious incident reporting. These obligations depend on the existence, classification, and verifiability of operational and runtime-generated records. ARCS-LIF, ARCS-VER, ARCS-AGT, ARCS-DEL, and ARCS-CUS make those artifacts legible without reducing all system exhaust to an undifferentiated log stream. ARCS-PV becomes relevant when an incident, inquiry, or authority request changes ordinary deletion or minimization posture.
ARCS is not a general EU AI Act compliance framework. Its value is narrower and more specific. It is strongest where the AI Act assumes the existence of auditable documentation, logging, traceability, monitoring, or evidence, but does not itself provide a detailed record-governance architecture for those artifacts. In that respect, ARCS is well matched to Article 12 record-keeping, Article 11 technical documentation support, Article 72 post-market monitoring support, and lifecycle-oriented risk treatment under Article 9.
ARCS may exceed the AI Act in one important respect. The Act often presumes the presence of documentation, logging, and monitoring capability. ARCS adds a more developed framework for determining which artifacts should exist at all, under what boundary conditions, and with what retention consequence. That is where ARCS-NCR and ARCS-PUB should be discussed carefully: not as a means of avoiding obligations to document or log where law requires those functions, but as a governance architecture for avoiding unnecessary creation or unnecessary persistence of record classes outside those obligations.
Outside scope
ARCS also governs several record-lifecycle domains that fall within its scope but outside the stated coverage of the EU AI Act:
Non-creation claim verification
ARCS-NCR (NCR-01 to NCR-06), ARCS-VER (VER-01, VER-02)
The EU AI Act does not address cases in which an operator claims that records are neither created nor retained. ARCS requires that non-creation claims be architecturally verified.
Multi-vendor custody chain mapping
ARCS-CUS (CUS-01 to CUS-12), ARCS-VER (VER-01 to VER-03)
The Act assigns obligations to providers and deployers but does not require mapping record custody across every vendor surface. ARCS requires documenting possession, control, access, and deletion authority at each custodian.
Agent tool-use and downstream record surfaces
ARCS-AGT (AGT-01 to AGT-13), ARCS-CUS (CUS-11)
The Act does not separately govern the record-lifecycle consequences of agent tool use. ARCS requires runtime component enumeration and addresses authorization-gap custody where agent actions create records without explicit human authorization.
Delegation and memory persistence
ARCS-DEL (DEL-01 to DEL-12), ARCS-LIF (LIF-01 to LIF-04)
The Act does not separately govern cross-session memory persistence or delegation-chain record creation. ARCS classifies memory-bearing artifacts as governed record classes subject to lifecycle, custody, and preservation rules.