EU AI Act Articles 9–15 Architecture Checklist 2026: 7 Artefacts

Q: When exactly do the Article 9–15 obligations apply to my system?

For high-risk AI systems newly placed on the EU market, Articles 9–15 apply from 2 August 2026. For high-risk AI systems already in use as components of large-scale IT systems listed in Annex X (Schengen Information System, Eurodac, etc.), the obligations apply from 2 August 2027 with a transition period. For high-risk systems that are safety components of products covered by Annex I harmonisation legislation (medical devices, machinery, etc.), the obligations apply from 2 August 2027. The Article 5 prohibitions applied from 2 February 2025, the GPAI provider obligations from 2 August 2025, and the Article 50 transparency obligations apply from 2 August 2026 alongside the Article 9–15 obligations. The single date most teams need to plan around is 2 August 2026 for new high-risk systems being placed on the market, and that date is now within the architectural backlog window for any team that has not started.

Q: How do I know if my system is actually high-risk under Article 6?

There are two paths to high-risk classification under Article 6. Path one: the system is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I (medical devices, in-vitro diagnostics, machinery, lifts, radio equipment, automotive, civil aviation, marine equipment, two- and three-wheel vehicles, agricultural vehicles, recreational craft, cableway installations, personal protective equipment, gas appliances, pressure equipment, pyrotechnics, etc.) AND that legislation requires third-party conformity assessment for placing it on the market. Path two: the system is intended for use in one of the eight Annex III categories — biometric identification and categorisation, critical infrastructure operation, education and vocational training assessment, employment and workforce management decisions, access to and enjoyment of essential private and public services and benefits, law enforcement, migration/asylum/border control, or administration of justice and democratic processes. Article 6(3) provides a carve-out: a system in an Annex III category that does not pose a significant risk of harm because it performs a narrow procedural task, improves a previously completed human activity, detects decision-making patterns without replacing human judgement, or performs preparatory work, can be self-assessed as not high-risk, but the self-assessment itself is a regulated artefact under Article 6(4). Many borderline systems qualify for the exception properly applied; many wrongly claim it without the documentation.

Q: What is the difference between the technical file (Article 11) and the risk file (Article 9)?

The risk file is the living, hazard-by-hazard register of foreseeable harms with their evaluation, treatment, and residual-risk acceptance — it is one of the inputs to the technical file. The technical file is the comprehensive system documentation as listed in Annex IV: a general description, a detailed description of the system architecture and design choices, the data and training methodology, the validation and testing procedures and results, the metrics for accuracy/robustness/compliance, the cybersecurity measures, the risk management documentation (which references the risk file), the post-market monitoring plan, and the EU declaration of conformity. The risk file is operational and updated continuously as production telemetry feeds in; the technical file is the consolidated artefact that is shipped with the system and updated at each material change. The architectural pattern is to maintain the risk file as a versioned API, the technical file as a generated build artefact that consumes the risk file as one of its sources, and to retain both as immutable bundles for ten years per Article 18.

Q: How granular do the Article 12 logs need to be? Can I use my existing observability stack?

The granularity required is sufficient to enable post-market monitoring per Article 72, to support traceability of system functioning per Article 12(2), and to enable competent authorities to investigate complaints — which in practice means per-inference event logging with affected-person traceability. Existing application observability stacks typically capture API latency, error rates, and infrastructure metrics but do not capture the AI-event payload (which model version, which prompt version, what input identifier, what output identifier, what guardrail signals fired, what human-oversight signal was recorded) and do not have the affected-person traceability that Article 72 investigations require. The architecture pattern is a typed AI event stream that runs alongside the standard observability stack, with PII handling at the producer (hashing or tokenising affected-person identifiers before write), append-only storage with retention aligned to the post-market monitoring plan, and a queryable index that can answer "show me all inferences affecting this person on this date" in minutes. Most teams reuse OpenTelemetry as the transport, add an AI-event semantic convention on top, and route to a dedicated immutable store separate from the application logs.

Q: Article 14 talks about "human oversight". Does that mean a human reviews every output?

Not necessarily — Article 14 requires that human oversight be designed appropriately for the risk. The required oversight measures are listed in Article 14(4): the natural person must be able to fully understand the system's capabilities and limitations, remain aware of automation bias, correctly interpret outputs, decide not to use the system or to disregard its output, and intervene through a stop button or similar. For some systems (high-risk biometric identification per Article 14(5)) two-person verification is mandatory before any decision based on the output. For others, sample-based review with a kill switch and well-designed UI affordances may be sufficient. The architectural deliverables that compose into a defensible oversight architecture are: a real-time kill switch operating per-affected-person and globally, a human review queue for outputs above configurable risk thresholds, automation-bias mitigation in the reviewer UI (mandatory rationale capture, conspicuous uncertainty surfacing, no one-click acceptance), a decision-record artefact capturing every override and every accept-without-override, and role-based access control limiting oversight authority to trained operators. The level of automation varies; the architectural primitives are required.

Q: How do I demonstrate "appropriate level of accuracy" under Article 15 if my model is non-deterministic?

Article 15 does not require deterministic outputs; it requires that the system achieve and maintain an appropriate level of accuracy, robustness, and cybersecurity throughout its lifecycle, and that the relevant accuracy metrics be declared in the instructions for use. The architectural deliverable is a continuous evaluation pipeline that produces the declared metrics on a defined cadence and against a defined evaluation set. For non-deterministic LLM outputs, "accuracy" is expressed as a distributional metric — golden-set pass rate scored by a documented methodology, regression-set pass rate, capability sub-set scores, calibration metrics if confidence is exposed, and judge methodology including the choice of judge model and the calibration procedure against human-labelled samples. The metrics are reported with confidence intervals rather than as point estimates, the methodology is documented in the technical file with enough detail to be reproducible, and the evaluation pipeline runs at every material change to the system as well as on a scheduled cadence. The five-gate AI-CICD pipeline described in the companion AppScale article on AI-Native CI/CD is the operational implementation; the AI Act compliance angle adds the documentation requirement and the reproducibility requirement.

Q: What does "compliance-as-code" actually look like in a real repository?

A compliance-as-code repository structure typically includes a compliance/ directory at the root with sub-directories for risk-file/ (versioned hazard register, threat models, residual-risk acceptances), datasets/ (per-dataset card with provenance, lineage references, bias evaluation reports, retention policy), technical-file/ (Annex-IV-aligned templates with sections that pull from generators), logging/ (the AI event schema definition, the producer libraries, the retention policy), oversight/ (the review-queue configuration, the reviewer UI source, the decision-record schema), and tests/ (the eval harness, the robustness suite, the security control test catalogue). A CI pipeline runs on every PR: validates the schemas, checks that risk-file changes have an accountable-role sign-off, regenerates the technical file as a build artefact, and pushes the assembled bundle to a WORM-mode object storage at every release. The audit posture is then "show me the bundle for this release" rather than "let me ask the compliance team to update the document." The transition from a documents-on-SharePoint compliance posture to compliance-as-code typically takes a quarter of focused work and is the single highest-leverage investment a high-risk system team makes.

Q: How does the Article 10 special-category data exception work in practice?

Article 10(5) is the only legal basis under the AI Act for processing GDPR Article 9 special-category data (race, ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data for unique identification, health data, sex life or sexual orientation) when strictly necessary to detect and correct biases in high-risk AI systems. The architectural requirements that follow from "strictly necessary" and the safeguards listed in Article 10(5)(a)–(g) are: documented purpose limitation (the data may only be used for bias detection and correction, not for any other model purpose), strict access control with named accountable roles, processing in an isolated environment with audited entry and exit, deletion at the end of the bias-correction cycle (typically scoped to a specific evaluation run), state-of-the-art security measures including encryption at rest and in transit, no transfer to third parties, and complete logging of every access. The audit posture is to maintain a register of every Article 10(5) processing operation with the legal-basis justification, the data-protection impact assessment reference, the start and end timestamps, the named operators with access, and the cryptographic proof of deletion at end of cycle. This is a high-scrutiny area; the documentation gap is the most commonly cited finding in early audits.

Q: Can I use the same artefacts to demonstrate compliance with non-EU regimes like the Australian AISI standard or the NZ Algorithm Charter?

Largely yes, with deltas. The architectural primitives the AI Act asks for — risk file, dataset cards, technical documentation, logging, deployer instructions, oversight architecture, accuracy/robustness/security testing — are the same primitives the Australian AI Safety Institute voluntary standard, the NZ Algorithm Charter for Aotearoa, the Japanese METI AI Operator Guidelines, the OECD AI principles, the NIST AI Risk Management Framework, and several US state-level proposals reach for. The deltas are: terminology (the AISI uses "model card" where the AI Act uses "technical file"; the NZ charter uses "algorithmic impact assessment" where the AI Act uses "risk file"), specific clause-level requirements (the NZ charter requires explicit Treaty of Waitangi consideration which the AI Act does not), and authority-specific reporting formats (the AI Act asks for the EU declaration of conformity in a specific format that other regimes do not require). The architectural pattern is to build the artefacts once in a regime-neutral form and produce regime-specific projections — the technical file projects to AI Act format, to AISI format, to NZ charter format with section mappings rather than separate documents. The investment in compliance-as-code pays back across regimes because the projections are cheap once the source-of-truth exists.

Q: What happens at audit if my technical file does not match my running system?

Under Article 99, a finding of non-compliance with Articles 9–15 attracts administrative fines of up to EUR 15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. A drift between the technical file and the running system is a non-compliance with Article 11(2), which requires the technical file to be drawn up before the system is placed on the market and kept up to date. In practice the enforcement posture in the early years is expected to be educational and proportionate for first findings, with serious financial penalties reserved for systems that cause harm, for repeat offenders, and for cases of deliberate non-compliance. The architectural risk is not the fine on the first finding but the operational disruption: an authority can require corrective measures, withdrawal from market, or recall under Article 79, any of which is materially worse than the fine for a system that is generating revenue. The defensible posture is compliance-as-code with a regenerated technical file at every release, immutable retention of versioned bundles, and a query-driven audit response that can produce the bundle for any given release date in minutes. Teams that maintain the technical file by hand routinely have drift of three to twelve months between the documented and the running system; teams that generate the file from source-of-truth typically have drift measured in hours.