EU AI Act Compliance for Spatial Autonomy

Regulatory Framework

Regulation (EU) 2024/1689 — the AI Act — applies a risk-tiered regime. The high-risk tier is defined in Article 6 by reference to Annex I (systems that are safety components of products under harmonized Union law) and Annex III (systems listed by use case). Annex III Section 1 covers biometrics; Section 2 covers critical infrastructure including road traffic, water, gas, heating, and electricity supply, capturing most public-space spatial AI; and subsequent sections capture employment, essential services, law enforcement, migration, and administration of justice. Unmanned aircraft systems regulated under Regulation (EU) 2018/1139 and (EU) 2019/947, autonomous vehicles regulated under the General Safety Regulation (EU) 2019/2144, and AI components of public-space surveillance all fall within scope.

For high-risk systems the provider obligations are concrete. Article 9 requires a risk management system maintained across the lifecycle. Article 10 imposes data and data-governance requirements on training, validation, and testing datasets, including representativeness, relevance, and examination for bias. Article 12 requires automatic recording of events (logs) over the lifetime of the system, with logging capabilities ensuring traceability appropriate to the intended purpose. Article 13 requires sufficient transparency to enable deployers to interpret and use the output. Article 14 requires effective human oversight, including the ability to intervene or interrupt. Article 15 requires appropriate levels of accuracy, robustness, and cybersecurity, with resilience against errors, faults, and attempts to alter use or performance through adversarial means.

Deployer obligations under Article 26 include using the system in accordance with its instructions, ensuring human oversight by competent persons, monitoring operation, and retaining logs generated by the system for an appropriate period. Article 72 imposes a post-market monitoring system on providers, requiring them to actively and systematically collect, document, and analyze relevant data on performance throughout the system's lifetime. None of these obligations is discharged by good engineering hygiene; each presumes an architecture that produces, retains, and exposes the underlying evidence as a structural property.

Spatial AI sits inside an additional regulatory perimeter. The Cyber Resilience Act (Regulation (EU) 2024/2847) imposes essential cybersecurity requirements on products with digital elements, including vulnerability handling and SBOM obligations. NIS2 (Directive (EU) 2022/2555) treats operators of essential and important services — including transport and critical infrastructure operators deploying spatial AI — as in-scope for cybersecurity governance and incident reporting. The GDPR adds Article 5 lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, and accountability principles; Article 22 prohibitions on solely automated decisions producing legal effects without safeguards; and Article 35 data protection impact assessment requirements that, for high-risk AI, must be coordinated with the AI Act's fundamental-rights impact assessment.

The Architectural Requirement

Read together, these obligations specify an architecture. Article 12's automatic event logging is not a request for application logs; it is a requirement that the system produce a tamper-resistant record sufficient to reconstruct, after the fact, the operation of the AI system to a degree appropriate to its purpose. For an autonomous vehicle, that means reconstruction of which sensors contributed which observations to which planner decision, with what confidence, under what model version, with what human-oversight state. For a UAS BVLOS operation in U-space, it means reconstruction of which surveillance sources admitted which separation observation, under which authority, at which moment of crew intervention. For a public-space AI under Annex III Section 1 or 2, it means reconstruction of which observation entered the inference and under what lawfulness basis.

Article 13's transparency requires that this reconstruction be intelligible to the deployer and, where relevant, to the affected person. Article 14's human oversight requires that the system expose interruptible decision points and that the human's authority to intervene be itself recorded as part of the operational record. Article 15's robustness against adversarial alteration requires that the recording substrate itself resist tampering by an attacker that has compromised an operating component. Article 26's deployer obligations require that the recording be retainable and queryable on the deployer's authority, not solely on the provider's. Article 72's post-market monitoring requires that the recording aggregate across the deployed fleet without the provider becoming a custodian of personal data beyond what GDPR permits.

Annex III Section 2's critical-infrastructure framing then layers a federation requirement. A water utility's spatial AI does not operate inside a single corporate boundary; it operates across SCADA vendors, integrators, regulators, and public authorities. The architecture must accommodate multi-authority custody of the operational record without forcing any one party to act as the trusted intermediary, because a critical-infrastructure regulator inspecting an incident will not accept a record curated by the operator and will not accept a record curated by the vendor.

Why Procedural Compliance Fails

The dominant compliance posture in the market is procedural. A provider builds an MLOps pipeline that records training-set lineage; an operator builds an observability stack that records inference inputs and outputs; a separate audit pipeline aggregates these into reports for the conformity assessment under Article 43 and Annex VII. The procedural posture treats each Article as a documentation requirement to be satisfied by a bespoke artifact, and treats the underlying evidence as an exhaust to be sampled when the artifact is being prepared.

This posture fails in three specific ways under the Act. First, Article 12's logging obligation is continuous and lifecycle-spanning; sampling-based aggregation cannot satisfy it. Second, Article 15's robustness against tampering is incompatible with logs that live inside the same operational boundary the attacker has already compromised; the recording substrate must be cryptographically distinct from the operating substrate. Third, Article 26's deployer-side retention and Article 72's provider-side post-market aggregation are in structural tension with GDPR Article 5 minimisation unless the substrate supports principled redaction — exposing what each authorized reader is permitted to see and no more, with the redactions themselves recorded.

Procedural compliance also fails the cross-regulation seam. NIS2 incident reporting timelines, CRA vulnerability handling obligations, and the AI Act's serious-incident reporting under Article 73 each require that the operational record be queryable on a regulator's clock. A company that learns at 2 a.m. that an Annex III system has produced a serious incident has hours, not days, to begin the reporting process; an architecture in which the underlying evidence must be reconstructed from heterogeneous logs across providers, deployers, and integrators cannot meet that clock at scale.

Finally, the procedural posture concentrates compliance risk in the providers and deployers least equipped to absorb it. Smaller providers cannot bear the integration cost of bespoke conformity artifacts per deployment; smaller deployers cannot bear the legal cost of a substandard provider's documentation gap. Structural compliance is the only path that scales to the breadth of Annex III deployment the Act in fact contemplates.

What the AQ Primitive Provides

The Adaptive Query spatial-mesh primitive provides the recording substrate the Act presupposes. Every observation entering an AI system is a credentialed event signed under the originator's authority, time-bound under a trusted source, and tagged with its lawfulness basis. Every model decision is a credentialed event whose composition is the credentialed observations that admitted to it under the model's declared admissibility profile, under the model version of record. Every human-oversight intervention is a credentialed event signed under the operator's authority, recorded as part of the operational record rather than as a separate audit trail. Every post-market telemetry projection is a federation rule applied to that operational record, not a parallel data flow.

Because the substrate is structural, Article 12 logging is intrinsic rather than added. Because the credentialing is cryptographic, Article 15 robustness against tampering is intrinsic rather than configured. Because federation rules are first-class, Article 26 deployer retention and Article 72 provider post-market aggregation can be satisfied by different projections of the same underlying lineage without violating GDPR Article 5 minimisation. Because the substrate is multi-authority, the critical-infrastructure federation requirement of Annex III Section 2 is intrinsic rather than negotiated per deployment. A regulator inspecting a serious incident under Article 73 issues a credentialed query and receives the lineage admissible to it, without any operator or vendor acting as gatekeeper to evidence that should not be gateable.

For spatial use cases the structural fit is immediate. Autonomous vehicle event data — sensor admissions, planner decisions, driver-monitoring interventions — is the substrate's native vocabulary, mapping cleanly to UNECE WP.29 R155/R156 and EU GSR Event Data Recorder and DSSAD obligations alongside the AI Act. UAS U-space surveillance, separation, and crew-intervention events fall into the same vocabulary. Public-space AI systems under Annex III gain a substrate on which the lawfulness basis of every observation is bound at admission, so the Article 5 GDPR minimisation principle and the AI Act's transparency principle are jointly enforced rather than separately documented.

Compliance Mapping

The mapping from substrate primitives to Act articles is direct. Article 9 risk management maps to declared admissibility profiles whose evolution is itself a recorded event. Article 10 data governance maps to credentialed dataset lineage with bias-examination events bound to the model version. Article 12 logging maps to the substrate's intrinsic event recording. Article 13 transparency maps to deployer-admissible projections of the lineage. Article 14 human oversight maps to credentialed intervention events with structural priority over downstream model decisions. Article 15 robustness maps to cryptographic governance-chain integrity. Article 26 deployer obligations map to deployer-side retention of admissible projections. Article 72 post-market monitoring maps to provider-side federation rules over fleet-aggregated lineage with GDPR-compliant minimisation.

Cross-regulation mapping is equally direct. CRA SBOM and vulnerability-handling obligations attach to the substrate as credentialed software-component lineage. NIS2 incident reporting timelines are met by the queryability of the lineage on regulator clocks. GDPR Article 5 principles attach to per-event lawfulness binding; Article 22 safeguards attach to the structural priority of human-oversight events; Article 35 DPIA evidence is itself a projection of the substrate. The fundamental-rights impact assessment that public authorities must produce under the AI Act for Annex III deployments draws on the same lineage rather than a parallel artifact.

Adoption Pathway

Adoption tracks the Act's own application timeline. Providers preparing for the August 2026 high-risk obligations express their training, validation, deployment, and monitoring events on the substrate; the conformity assessment under Article 43 and the technical documentation under Annex IV are projections of the substrate's lineage rather than parallel deliverables. Deployers in Annex III sectors — critical infrastructure, transport, public services — sign onto the substrate as authority participants, retaining logs under Article 26 by retaining their own credentialed projections without depending on provider goodwill.

Multi-authority deployments — water utilities, urban transport authorities, UAS operators in U-space — establish federation rules with their integrators, vendors, and regulators as declared, signed objects. Notified bodies and market surveillance authorities under Article 74 receive credentialed query access whose own use is itself recorded, closing the audit loop the Act requires. Providers and deployers that adopt the substrate before the application date convert what would otherwise be a recurring per-deployment compliance integration into a one-time architectural change, and they do so on terms that GDPR, NIS2, and CRA simultaneously accept. The substrate is the structural form of high-risk AI compliance the Act has in fact already specified.