EU AI Act Compliance:
A 6-Obligation Build Guide
for Regulated Organisations

Most compliance guides treat the EU AI Act as a classification question: is our AI system high-risk? If yes, do the heavy compliance work. If no, carry on. This framing is wrong in two directions.

First, it understates the obligations that apply universally. Article 4 (AI literacy) and Article 50 (transparency) have been in force since 2 February 2025. Articles 25 and 53 (GPAI supply chain verification) apply to every organisation deploying a large language model — which, in 2026, means almost every organisation with an AI tool of any kind. These obligations do not wait for a classification assessment. They are already live.

Second, the classification question itself is an obligation. A wrong answer — classifying a high-risk system as not high-risk, or over-classifying a standard tool as high-risk — carries regulatory, operational, and financial consequences. The classification register is not a prerequisite to compliance; it is a compliance deliverable in its own right.

The obligation sequence

The six obligations in this guide form a logical sequence, not an arbitrary list. Each one builds on the previous, and the overall architecture is more than the sum of its parts.

1. 01
   Article 4 — AI Literacy Establish who in your organisation uses which AI tools, and prove that each person received appropriate training. This is the foundation of every subsequent obligation — you cannot demonstrate human oversight without first demonstrating that the humans are qualified to provide it.
2. 02
   Article 50 — Transparency Publish a formal statement of your AI use, human oversight procedures, and the limits of automated output. This obligation has a hard deadline of 2 December 2026 and applies even where all your AI systems are classified as not high-risk.
3. 03
   Annex III — Classification Screen every AI system against the eight high-risk use-case areas in Annex III. The classification outcome is a gateway: it determines whether obligations 04 and 05 are mandatory or precautionary. Get this wrong and you either carry unnecessary compliance burden or expose yourself to unregistered high-risk systems.
4. 04
   Article 27 — Fundamental Rights Impact Assessment If any system is classified as high-risk under Annex III, a FRIA is mandatory before deployment. If no system is high-risk, a non-trigger confirmation is still required — the absence of a FRIA without a documented assessment of why it is not needed is itself a governance gap.
5. 05
   Article 26(5) — Incident Notification Maintain a documented procedure for identifying, classifying, and notifying AI incidents. The notification obligation to providers and competent authorities applies to high-risk systems; the incident logging obligation applies to all systems as a matter of professional governance.
6. 06
   Articles 25 & 53 — GPAI Verification Verify that every general-purpose AI model provider — OpenAI, Microsoft, Google, and their equivalents — has met their Article 53 documentation obligations. Maintain a per-provider, per-model supply chain governance record updated annually.

The regulatory timeline in force

What Article 4 actually requires

Three elements carry legal weight in that clause. First, the obligation is context-sensitive: the required level of literacy is calibrated to the role, the AI system in scope, and the population it affects. A fee earner using a drafting tool is not the same compliance subject as an IT administrator maintaining the infrastructure it runs on. Second, the obligation is ongoing: literacy is not a one-time event. As AI systems are updated, replaced, or added, the literacy obligation refreshes. Third, the obligation requires evidence: "measures to ensure" is not satisfied by policy alone. It requires documented records that training occurred, at the appropriate level, for the appropriate person, on the appropriate system.

The gap most organisations have

In practice, the Article 4 gap takes one of two forms. The first is the absence of any structured training record: staff have used AI tools, received vendor onboarding, or attended general awareness sessions, but no per-person, per-system record exists. The second — more dangerous — is the existence of generic training records (a CPD log, a team meeting attendance sheet) that cannot be connected to specific AI systems or specific competency levels. Neither satisfies Article 4's evidential requirement.

REG-AIMS-LIT-001 — five fields that constitute Article 4 evidence

REG-AIMS-LIT-001 is a structured register — database schema, automation workflows, and frontend dashboard — that produces per-person, per-AI-system training records with a competency level, an evidence link, and a responsible-officer verification. Each record maps directly to an Article 4 evidential requirement.

Where ISO 42001 reaches — and where it stops

ISO/IEC 42001:2023 Clause 7.2 (Competence) establishes the framework for identifying required AI competencies and maintaining evidence of their achievement. It provides the governance structure but does not produce the per-person, per-system database record that Article 4 requires as evidence. REG-AIMS-LIT-001 is the instrument that converts the ISO 42001 framework into Article 4 evidence — the data layer beneath the governance layer.

Three components, one Article 4 evidence record

1. 1
   Supabase PostgreSQL register (REG-AIMS-LIT-001) Six tables: staff, AI systems in scope, training records, exemptions, system requirements, and immutable audit log. Four compliance views: coverage by person, coverage by system, overdue records, and executive summary. Row-Level Security so responsible officers see only their scope.
2. 2
   Three n8n automation workflows WF-LIT-001 (training log intake via webhook), WF-LIT-002 (responsible officer verification gate — routes each new record for sign-off before marking it verified), WF-LIT-003 (daily overdue monitor — identifies records past their refresh date and sends a flagged notification).
3. 3
   HTML dashboard frontend Register view, compliance gaps view (showing which person/system combinations are not yet logged), and training log submission form that fires to the n8n intake webhook. Exportable to PDF for evidence submission.

What Article 50 actually requires

Article 50 operates at two levels. At the system level, it requires that natural persons know when they are interacting with an AI system. At the content level, it requires that recipients of AI-generated text, image, audio, or video know it was generated by AI. For organisations using generative AI tools — for drafting documents, generating correspondence, producing summaries, or creating reports — the content-level obligation applies to every output shared externally unless it has been subject to material human editorial transformation.

Article 50(4) includes a conditional exemption: where the content has been editorially reviewed and substantially modified by a human, the disclosure obligation may not apply to the final output. But the exemption is narrow. It requires documented evidence of the editorial process — not a general human-in-the-loop policy, but a record of review of the specific output. DOC-AIMS-ART50-001 includes the disclosure template for outputs shared without such editorial transformation, and the HITL procedure reference for outputs where the exemption is claimed.

The four gaps in a typical Article 50 position

DOC-AIMS-ART50-001 — six sections that constitute a compliant statement

1. §1
   Scope and purpose Names the organisation, the AI systems in scope (by reference to the classification register, REG-AIMS-CLASS-001), and the purpose of the statement — to satisfy Article 50(1) and 50(4) disclosure obligations and to establish the organisation's public AI transparency position.
2. §2
   AI systems in use A structured table listing each AI system, its provider, the use cases it is applied to, and the population of persons likely to interact with or receive outputs from it. This section maps directly to the AI system register built in Chapter 03.
3. §3
   Disclosure method per use case Documents exactly how disclosure is made for each use case: footer notice on correspondence, verbal notification at the start of an AI-assisted interaction, document-level watermark, or system notification. Each method shall be documented — not assumed.
4. §4
   Human-in-the-loop procedure reference References the HITL procedure (PROC-AIMS-HITL-001) that governs the editorial review of AI-generated outputs. Where the organisation claims the Article 50(4) exemption for reviewed outputs, this section is the documentary anchor for that claim.
5. §5
   Responsible officer and review schedule Names the AI Risk Owner who owns the statement, the review frequency (at minimum annual, or on any material change to the AI system portfolio), and the sign-off authority for amendments.
6. §6
   Document control block Version, status, issue date, next review date, related documents (REG-AIMS-CLASS-001, PROC-AIMS-HITL-001, REG-AIMS-LIT-001), and retention schedule. ISO 9001:2015 Clause 7.5.3 compliant document control.

How Annex III works — the eight areas

The EU AI Act classifies AI systems as high-risk if they fall within one of eight use-case areas defined in Annex III. The classification is use-case dependent, not technology dependent — the same AI model may be not high-risk in one application and high-risk in another. This is a critical distinction: the question is not "what kind of AI is this?" but "what is this AI being used to do, and in which context?"

REG-AIMS-CLASS-001 — the gateway decision tree

1. Step 1
   Does the system fall within any of the eight Annex III use-case areas? Screen the specific use case — not the technology — against all eight areas. A legal drafting tool does not fall within Area 8 simply because it "relates to" legal work. Area 8 covers AI used by judicial or quasi-judicial bodies, not by solicitors preparing materials for submission to a court. Document the area-by-area assessment and the rationale for each Not In Scope outcome.
2. Step 2
   Does any Article 6(3) exclusion apply? Article 6(3) excludes AI systems intended for narrow preparatory tasks, AI systems performing a previously human-conducted activity, AI systems detecting patterns and deviations, and AI systems intended to prepare an assessment for human review. These exclusions are interpreted strictly — they are not a general escape from classification but a narrow carve-out for specific technical functions.
3. Step 3
   Responsible officer sign-off on the classification outcome Every classification outcome — High-Risk, Not High-Risk, or Requires Legal Advice — shall be reviewed and signed off by the AI Risk Owner or COLP before entry into the register. The classification tool is guidance; the responsible officer's approval is the compliance record. A classification record without a sign-off date and a named officer is not a compliance record.

Why most organisations are outside the high-risk categories

Area 8 — administration of justice and democratic processes — is the area that generates the most classification uncertainty for regulated professional services firms. The area covers AI systems intended to be used by a judicial or quasi-judicial body to assist in researching and interpreting facts and the law. The key phrase is "judicial or quasi-judicial body." A solicitor, compliance officer, or professional services firm is not such a body.

An organisation using GPT-4o to draft documents, research case law, or summarise reports is engaged in professional services activity — preparing material for use by people who may later interact with courts, regulators, or tribunals. The courts and regulators themselves may use AI in their processes, and that use would fall within Area 8. The organisation's preparation of material does not.

This distinction matters because the most common misclassification risk is organisations classifying their drafting or research tools as High-Risk under Area 8 on the basis that the output "relates to" regulated activity. A misclassification in this direction triggers Articles 9–15, Article 26, and Article 27 — substantial and disproportionate obligations. The correct outcome is Not High-Risk, with a documented rationale explaining precisely why Area 8 does not apply.

What Article 27 requires — and when

Three conditions determine whether a FRIA is mandatory. First, the system must be classified as High-Risk under Annex III — the Chapter 03 gateway. If REG-AIMS-CLASS-001 records Not High-Risk for every system, Article 27 does not apply in its primary form. Second, the deployer category matters: public law bodies and private operators providing public services are explicitly covered. Private operators in other sectors may be covered by Article 27(2) and by delegated acts the Commission may issue. Third — and this is where most organisations fall short — even where Article 27 does not strictly apply, the absence of a documented assessment of whether it applies is itself a governance gap.

FRIA-AIMS-001 — one document, two functions

What a full Article 27(1)(a)–(h) FRIA covers

A FRIA activated by a High-Risk classification shall address all eight dimensions specified in Article 27(1). These are not optional sections — each must be completed before the system is deployed in the high-risk use case.

1. (a)
   Description of the system and its purposeThe use case, the population affected, the decision or output the system produces, and the human oversight mechanism in place.
2. (b)
   The geographic area and duration of useWhere and for how long the system will be deployed in the high-risk context.
3. (c)
   Assessment of impact on fundamental rightsWhich rights are placed at risk by the system, including privacy, non-discrimination, dignity, and fair trial rights relevant to the use case.
4. (d)
   Safeguards appliedThe technical and organisational measures that mitigate identified fundamental rights risks — human review gates, access controls, bias monitoring, and audit procedures.
5. (e)
   Consultation of affected personsEvidence that persons or groups on whom the system will be used were consulted or their interests were represented in the assessment.
6. (f)
   Competent authority to notifyIdentification of the national competent authority to whom the FRIA must be submitted under Article 27(5).
7. (g)
   FRIA review scheduleFrequency and conditions under which the FRIA will be reviewed and updated — at minimum annually, or on any material change to the system or its use context.
8. (h)
   Responsible officer sign-offNamed individual with authority to approve the FRIA and date of approval. The FRIA is not complete until a named responsible officer has signed it.

Two notification obligations, one procedure

The two obligations must be kept distinct. Article 26(5) is the deployer-to-provider notification — the organisation tells the AI provider (OpenAI, Microsoft, or equivalent) that a serious incident occurred involving their system. Article 73 is the deployer-to-authority notification — the organisation notifies the national competent authority. For SRA-regulated firms, the SRA Code of Conduct incident reporting obligation applies in parallel as a domestic obligation. PROC-AIMS-EUINC-001 routes each incident to the appropriate notification channel based on its classification outcome.

Three types. Four severities. One decision path.

PROC-AIMS-EUINC-001 — what it contains

1. Step 1
   Incident intake (WF-INC-001) An n8n webhook-triggered intake form captures incident date, AI system involved, description, detecting person, and whether the output reached an external party. On submission, the record enters the inc_incident table with a timestamped, immutable audit entry. Every incident is captured — Type A through Type C — before any classification decision is made.
2. Step 2
   Classification assessment The responsible officer classifies the incident by type (A/B/C) and severity (P1 Critical through P4 Low). Classification is not optional and cannot be skipped — an unclassified incident in the register is treated as an open escalation until a classification is entered.
3. Step 3
   Notification assessment For Type B and Type C incidents, a documented notification assessment is completed: did the output reach an external party? Did it cause or risk harm? Is Article 26(5) triggered? The assessment is recorded with the officer's name, date, and conclusion — whether notification is required or not, and the reasoning either way.
4. Step 4
   Notification execution (if triggered) Provider notification email template generated from the incident record. Competent authority notification logged with reference number. For high-risk systems, use is discontinued in the affected context pending formal clearance. All notifications timestamped against the incident awareness date to evidence "without undue delay" compliance.
5. Step 5
   Root cause and corrective action Every Type B and Type C incident generates a root cause record. Systemic root causes — a pattern of hallucinations from the same system, a recurring failure in a specific use case — generate a Problem record in the inc_problem table and trigger a corrective action review. ITIL Problem Management applied to AI system quality failures.

What GPAI means and why it reaches every organisation

The GPAI definition is technology-agnostic, but in practice it captures every large language model in commercial use. GPT-4o is a GPAI model. The GPT-4 series underlying M365 Copilot is a GPAI model. Gemini is a GPAI model. Claude is a GPAI model. The defining characteristics — trained on large data at scale, generalises across tasks, integrable into downstream applications — are met by every AI drafting, research, or workflow tool in use by regulated organisations today.

This matters because the EU AI Act's GPAI obligations follow the model, not the product wrapper. An organisation using M365 Copilot is not merely a customer of Microsoft — it is a deployer of a GPAI model under Chapter V, even though it interacts with the model through a product interface rather than directly via API.

Provider obligations, systemic risk, and deployer verification

REG-AIMS-GPAI-001 — what is verified for each provider

What a complete EU AI Act evidence pack looks like

When an organisation completes all six obligations in this guide, it has produced six specific evidence artefacts. Each one stands alone as evidence of a discrete legal obligation. Together, they constitute a governance architecture that is greater than the sum of its parts.

Why the obligations are structurally interdependent

The six obligations are not a list. They are a dependency graph. The classification register (Chapter 03) is the gateway that determines whether the FRIA (Chapter 04) and the incident procedure (Chapter 05) are mandatory or precautionary. The literacy register (Chapter 01) is the evidential foundation for the transparency statement (Chapter 02) — because you cannot credibly claim human oversight without first demonstrating that the humans are qualified to provide it. The GPAI verification register (Chapter 06) is the supply chain evidence that underpins everything else — because all five other registers depend on AI systems whose providers must themselves be compliant.

An organisation that has only some of these documents is not partially compliant — it is selectively evidenced. The gaps between the documents are where regulatory exposure lives. A perfect literacy register alongside no transparency statement is a firm that trained its staff to use AI tools but never told anyone what it was doing. A perfect classification register alongside no incident procedure is a firm that knows which systems are high-risk but has no way of detecting or reporting when one of them fails.

The governance calendar

Once all six registers are in place, the compliance posture is maintained through a structured annual governance calendar. The review cycle for each document is not optional — it is the mechanism that keeps the evidence pack current as AI systems are added, updated, or retired.