Most organisations approaching the EU AI Act start with a policy. That is necessary but not sufficient. This document sets out a practical framework — developed from first principles — for building the training architecture, governance mechanisms, and operational discipline that turn a policy into a defensible compliance programme.
← Return to EU AI Act overviewThe EU AI Act creates a set of ongoing organisational obligations. It does not create a checklist that can be completed and filed. Yet the market's initial response has largely been to treat it as exactly that: buy a compliance platform, deliver a training module, declare readiness.
This conflates two things that are related but not identical. Literacy is the capability to understand and act appropriately in an AI-enabled environment. Compliance is the documented, auditable, ongoing demonstration that the organisation is meeting its specific legal obligations. An LMS can help deliver literacy. No product makes an organisation compliant — because compliance requires the organisation to do the work.
The framework set out here treats these as two parallel workstreams that must reinforce each other. Literacy without governance produces trained people operating in an ungoverned environment. Governance without literacy produces documented frameworks that nobody understands or uses.
There is a third problem that neither addresses alone: the Act will change. Guidance is still being written. Articles will be renumbered. National transpositions will vary. A compliance programme built to today's text and never revisited is a liability, not an asset. The framework must include a mechanism for staying current.
The vendor claim to watch out for: any platform that describes itself as making your organisation "fully compliant" with the EU AI Act. Compliance is an organisational obligation, not a product feature. A platform can support delivery of the training that discharges Article 4's literacy obligation. It cannot:
Those obligations belong to you.
The framework has six components. Each solves a distinct problem. None works fully in isolation — they are designed to interlock, with outputs from one feeding inputs to another.
The EU AI Act does not impose identical obligations on everyone in an organisation. It imposes differentiated obligations depending on role and relationship to AI systems. A hiring manager using Copilot to screen CVs has different obligations from a developer building a credit-scoring model, or a compliance officer maintaining the governance framework. One-size training fails because it tries to serve all of these audiences with the same content.
The Swimming Lanes approach treats the Act's obligations as the "functions" to be understood — analogous to the tasks in any role-based training needs analysis — and maps them against organisational lanes defined not by job title but by relationship to AI. The result is a matrix that shows, for every intersection of role and obligation, what depth of training is required.
The framework identifies seven lanes:
It maps nine obligation columns drawn from the Act's own structure (hover over each article number for a précis of what it demands, or click to read the full Article):
| 1 | AI Literacy | Art. 4Staff must have AI literacy appropriate to their role, experience, and the context in which they use AI.
|
| 2 | Risk Classification | Art. 6–9Four risk tiers determine what obligations apply:
|
| 3 | Human Oversight | Art. 14High-risk systems must have meaningful human oversight built in:
|
| 4 | Transparency | Art. 13, 50Two-level obligation:
|
| 5 | Data Governance | Art. 10Training data for high-risk systems must be:
|
| 6 | Technical Documentation | Art. 11–12Two distinct obligations:
|
| 7 | Procurement | Art. 25–26Buying AI makes you a deployer. Obligations include:
|
| 8 | Incident Reporting | Art. 73Serious incidents must be reported to national authorities:
|
| 9 | Conformity Assessment | Art. 43Before deploying a high-risk system:
|
Each cell is coded Full, Partial, Aware, or Not Applicable — establishing the minimum requirement for every role/obligation combination before any training content is designed or sourced.
| Lane | Training depth rationale | Most demanding obligations |
|---|---|---|
| All staff | Universal Article 4 literacy obligation. Everyone must understand what AI is, what risks it presents, and when to flag or escalate. | AI Literacy Full |
| AI users / deployers | Deploying AI in practice triggers human oversight, transparency, and incident reporting obligations. Must understand not just what they're using but what they're responsible for. | Human Oversight Full, Transparency Full |
| Procurement | Buying AI systems makes the organisation a deployer. Due diligence on risk classification and contractual obligations must be understood before any AI procurement decision. | Risk Classification Full, Procurement Full |
| Builders / configurers | Technical obligation owners. Data governance, technical documentation, conformity assessment — the most demanding column in the matrix — all require specialist-level training. | Conformity Assessment Full + Specialist |
| Governance / Legal / Compliance | The only lane where every obligation column requires full training. These are the people who own the framework, maintain the evidence, and face the regulator. | All columns Full |
Knowing who needs training on what is necessary but not sufficient. The same obligation — Human Oversight, for example — requires fundamentally different treatment depending on whether the learner is a line manager using an AI-assisted workflow or a developer building an AI system from scratch. A single module for both fails both.
The framework defines four levels of training depth, each with a distinct purpose and audience:
L1 — Foundation is universal. Plain language, no prior knowledge required. It answers "what is this obligation and why does it exist?" for any employee. It is built once and consumed across all lanes — the lowest cost, highest reach asset in the programme.
L2 — Practitioner is role-specific. The same obligation, applied to how this role actually encounters it in their work. This is where the swimming lanes earn their keep as a design framework, not just a planning one — because you cannot write one L2 module per obligation and serve all lanes. A Human Oversight L2 for a hiring manager is a different course from a Human Oversight L2 for a fraud analyst.
L3 — Specialist is for obligation owners. The technical or legal depth required by governance, legal, procurement, and builders. This is where third-party specialist provision is most likely required — internal teams generally cannot produce L3 content at the rigour these roles require.
L4 — Triggered is not ongoing. It fires on a governance event: a new AI system is deployed, a regulatory change is detected, an incident occurs. The training is just-in-time and targeted to the specific event. Its timescale is event-driven, not calendar-driven.
The production efficiency of L1: because L1 is universal, it is built once and deployed everywhere. For an organisation training thousands of people on nine obligation areas, the ability to produce a single Foundation module per obligation — rather than seven lane-specific variants — represents a significant reduction in development cost and time. The investment goes into L2, where the differentiation is essential.
EU legislation has a history of renumbering. Article 177 of the Treaty of Rome — one of the most cited provisions in European law, governing the preliminary reference procedure — became Article 234 following the Treaty of Amsterdam in 1999. The substance did not change. But every training document, guidance note, and internal policy that cited "Article 177" was technically wrong from that point forward, and anyone who was not watching would not have known.
The EU AI Act is, if anything, more vulnerable to this kind of change than established treaty provisions. It is new legislation, still being operationalised, with guidance being written by the AI Office, member states still transposing obligations, and a simplification package (the Digital Omnibus) already in progress. It will change. The question is not whether, but when and how significantly.
A compliance training programme that does not include a standing mechanism for detecting and responding to regulatory change is not a compliance programme. It is a point-in-time document that will become wrong.
The Regulatory Watch function has four responsibilities:
Every training module carries mandatory metadata. The key design principle: dates are more useful than version numbers. "v3.2" tells you the sequence. "Last reviewed: 20190314" tells you the urgency.
Two date fields are required and distinct. Last reviewed is the date someone confirmed the content is still current — even if nothing changed. Last amended is the date the content itself was substantively changed. If these two dates diverge significantly, that divergence is a governance flag requiring investigation.
Training creates knowledge. The decision gateway applies that knowledge at the moment it is most needed: the point at which someone is about to use AI on a task that may carry compliance implications.
The most common compliance risk in a large organisation is not malicious misuse. It is well-intentioned, resourceful, company-licensed tool use that nobody has evaluated against the Act's obligations. A hiring manager asks Copilot to help shortlist six thousand CVs because the alternative is spending a week doing it manually. A risk analyst uses an AI tool to summarise a customer profile before a decision. Neither person is trying to violate the law. Neither person knows they might be.
The decision gateway is designed to intercept this moment. It is deliberately simple — three plain-English questions that take less than a minute. Simplicity is a design choice, not a compromise. A gateway that requires legal knowledge to use will not be used. The legal rigour sits behind the gateway, not in it.
| # | Question | Why it matters |
|---|---|---|
| 1 | Will the output of this AI be used to make — or to influence — a decision about a person? | Decisions about people are the most regulated use of AI under the Act. This is the Annex III trigger question. |
| 2 | Will a human independently review the AI's reasoning — not just its conclusion? | Accepting output without interrogating it is not human oversight. The Act requires oversight of reasoning, not just results. |
| 3 | Has this specific use of AI been reviewed and documented by your organisation? | A licensed tool is not an approved use. Tool approval and use-case approval are not the same thing. |
The trigger condition is asymmetric by design: Yes to Question 1, and No to Question 2 or 3, means pause and contact the AI Governance team. All three questions must be satisfied for a "proceed with normal care" outcome. The gateway is framed as protection for the individual, not surveillance of them — because employees who experience it as surveillance will route around it.
Note: the decision gateway as published here is a working draft requiring scrutiny by Legal, Compliance, and AI Governance before deployment as employee-facing guidance.
The decision gateway is a policy instrument. Better Angel is its operational counterpart — the mechanism that makes the gateway real at the moment of use, embedded directly in the AI tools employees work with.
The concept is simple: rather than blocking action, Better Angel introduces cognitive friction at the moment of commitment. When a user's request pattern matches a potential compliance risk, the system produces a calm, informative intervention: "It's your call — but here is why this request may require a governance check before you proceed." The user can choose to understand the issue, abandon the request, or escalate to the governance team. Every option creates an audit record.
Better Angel is not a hard block. It is a conscience. It assumes people are trying to do their jobs. Its job is to notice when that intent might be about to collide with an obligation — and say something, before the door closes.
Its practical effectiveness depends on combining three signals rather than relying on request pattern alone:
| Signal | What it evaluates | Technical source |
|---|---|---|
| Request pattern | Does the language match known high-risk patterns — ranking, filtering, scoring, or selecting people? | System prompt pattern rules in Copilot Studio |
| User role | What role group does this person belong to? A hiring manager asking to rank documents is higher risk than a researcher doing the same. | Azure AD / Entra ID role membership |
| File sensitivity | Are the files involved tagged with a sensitivity label indicating AI-governance-relevant content — HR data, credit data, customer profiles? | Microsoft Purview sensitivity labels (taxonomy extension required) |
The three signals working together are substantially more powerful than any one alone. "Summarise these documents" is ambiguous in isolation. "Summarise these documents tagged CANDIDATES-2026, requested by someone in the HR-Recruitment role group" is not ambiguous at all.
Better Angel is proposed architecture, not a finished design. Its limitations are documented honestly: it will not catch ambiguous requests, it cannot see shadow AI tools, and it depends on file labels that must be maintained by the organisation. It improves the odds. It does not guarantee compliance. It works best as part of the full framework — alongside the inventory, the gateway, and the training programme — not as a standalone solution.
Note: Better Angel as described is technically feasible using existing Microsoft 365 infrastructure. Implementation requires coordination between IT, Legal, HR, and AI Governance. The guidance layer (RAG-backed explanations) and audit log require separate design and build work.
Before any other component of this framework can be deployed, the organisation needs to know what AI systems are in use. This sounds obvious. In practice, it is one of the hardest problems in AI governance — because people are using AI tools resourcefully, informally, and often invisibly to the organisation.
Microsoft Copilot is a particular example. It is embedded in the same environment people use for email, documents, and meetings. Using it does not look like "deploying an AI system." It looks like using Word. The capability and the compliance requirement are completely decoupled in the user experience.
The inventory framework categorises every AI system in use into one of three tiers:
| Tier | Description | Governance response |
|---|---|---|
| A — Sanctioned | Formally procured, IT-managed, and known to the organisation. Presents the lowest governance risk but still requires classification and documentation. | Classify, document, register. Standard process |
| B — Tolerated | Known to IT or management but not formally assessed. Grammarly, browser AI extensions, team-level API integrations. Requires urgent retrospective assessment. | Assess, then register or prohibit. Urgent |
| C — Shadow | Entirely outside organisational knowledge. Personal accounts, local model deployments (Ollama), consumer apps used for company work. Highest liability exposure. | Detect, disclose, respond. High priority |
Discovery requires four methods working in combination:
Once found, every system receives a risk register entry assessed against four questions:
The answers determine which Act obligations apply and at what depth.
On liability and shadow AI use: an organisation whose employee uses an unauthorised AI tool in a way that breaches the Act cannot simply point to a policy document and disclaim responsibility. To sustain a defence, the organisation must demonstrate that the policy was communicated and genuinely understood (the training programme), that reasonable controls existed to deter or detect violations (Better Angel, the decision gateway), and that violations were treated as disciplinary matters with a documented escalation path (the governance framework). The policy is necessary. It is not sufficient on its own.
A written policy that nobody was trained on, that was never enforced, and that management tacitly tolerated being ignored, is not a policy. It is a document. The distinction matters to a regulator — and to a court.
The six components are designed as a system. Each one feeds the others. Understanding the dependencies is important — because deploying any component in isolation produces a weaker result than deploying the system as a whole.
The AI inventory is the foundation. Better Angel cannot flag a system it does not know about. The TNA cannot calibrate training depth for a use case that has not been classified. The inventory must be built first, or built in parallel with everything else.
The TNA swimming lanes produce the training architecture. Without it, training provision is either over-engineered (everyone gets everything) or under-engineered (everyone gets the same thin module). The TNA produces a defensible, role-calibrated programme that a regulator can inspect.
The training levels turn the TNA into a delivery plan. L1 is built once and deployed universally — it is efficient. L2 requires lane-specific variants — it is where the real investment goes. L3 is where specialist provision is sourced. L4 is where the regulatory watch and Better Angel feed new training events.
The regulatory watch keeps the whole programme current. Without it, the TNA and training levels describe the world as it was when they were built. Legislation changes. New guidance is issued. Article numbers are renumbered. The watch function detects these changes, assesses their impact, and triggers the appropriate response — a content update, a new L4 event, or simply a confirmed review date in the metadata.
The decision gateway is the human-facing intervention at the point of use. It does not require technical integration. It requires only that employees know it exists, understand why it matters, and feel safe using it — which is why the training programme must deliver this, not just publish a policy document.
Better Angel is the automated complement to the decision gateway — the layer that catches the cases the gateway misses, because the employee did not think to self-assess, or because the request pattern was ambiguous until the file sensitivity and role signals resolved it. It feeds the audit log, which feeds the governance team's visibility of where compliance risks are actually occurring across the organisation.
Together, these six components produce something none of them produces alone: a documented, auditable, continuously maintained compliance programme that can be shown to a regulator, presented to a board, and — most importantly — trusted by the employees who have to live inside it.
The framework set out here is developed from first principles, grounded in the Act's own text, and designed to be practically deployable in a large organisation. It is not a finished product. The TNA cell assignments are the author's reading of the Act and require validation against any specific organisation's AI estate and legal context. The decision gateway requires scrutiny by Legal, Compliance, and AI Governance before employee-facing publication. Better Angel is proposed architecture that requires technical and legal review before implementation.
What the framework is: a coherent starting point. A set of questions to ask. A structure that can be validated, stress-tested, and refined — rather than invented from scratch each time an organisation discovers it needs one.
If you are building an AI compliance programme for your organisation and would like to discuss how this framework might apply to your specific context, I would welcome a conversation.
Framework developed by Julian Franklin / Julian Franklin Consulting, June 2026. Last amended: 20260605. This document will be updated as the regulatory landscape develops. All component documents carry individual review metadata.
If you are building an AI compliance programme — or trying to make an existing one more rigorous — I would welcome a conversation about how this framework applies to your organisation.