You cannot design proportionate controls until you know what you are being held to, and the first surprise for most teams is that "AI regulation" is not a single rulebook. It is a stack of overlapping regimes, each written by a different body, each with its own definitions, its own enforcement machinery, and its own idea of what "good" looks like. A single credit-decisioning model might simultaneously fall under horizontal AI legislation, financial-conduct rules, prudential model-risk expectations, data protection law, and anti-discrimination statute. Each speaks to a different facet of the same system, and you must satisfy all of them at once.
This part builds the mental map you need to navigate that stack. We will not catalogue every statute — laws change and vary by jurisdiction — but the structure of the landscape is durable, and understanding it lets you place any specific rule in context.
The four layers
Think of the obligations on an AI system as four layers, stacked from the most AI-specific to the most general.
Layer 1: Horizontal AI regulation
The newest layer is legislation written specifically about AI, cutting horizontally across all sectors. The archetype is the EU AI Act, but similar risk-based frameworks are emerging in many jurisdictions. These regimes share a common logic: they classify AI systems by the risk they pose and attach obligations accordingly. Some uses are prohibited outright; some are "high-risk" and carry heavy duties around data quality, documentation, human oversight, transparency, and conformity assessment; most are low-risk and carry little beyond basic transparency. The crucial move these laws make is to tie obligations to use and impact, not technology — the same algorithm can be high-risk in one application and unregulated in another.
Layer 2: Sectoral regulation
Long before AI existed, the decisions AI now makes were already regulated. Lending was governed by consumer-credit and fair-lending law; insurance by conduct and solvency rules; healthcare by clinical-safety and medical-device regimes; markets by conduct and market-abuse rules. This sectoral layer does not disappear when you automate a decision — it applies with full force to the automated version. A regulator does not care whether a human or a model denied the loan; it cares that the denial was lawful, fair, and explainable. In practice this layer often bites hardest, because it is mature, specific, and backed by regulators who know the domain intimately.
Layer 3: Data protection
AI runs on data about people, which pulls it squarely into data-protection law — GDPR and its many descendants. This layer governs the lawful basis for processing, purpose limitation, data minimisation, individuals' rights over their data, and — critically for AI — special protections around automated decision-making and profiling. Data protection is the layer most likely to constrain how you train a model, not just how you deploy it, because training is itself processing of personal data and must have its own lawful basis.
Layer 4: Internal policy and risk appetite
The final layer is self-imposed but frequently the most demanding: your own organisation's model-risk-management standards, ethics principles, and board-level risk appetite. Mature institutions, especially in finance, have long-standing internal frameworks that set a higher bar than the law requires, because the institution has more to lose than a fine. Ignoring this layer is a common rookie error: a system can be perfectly legal and still be rejected by your own risk committee.
Why the overlap matters
The layers do not partition neatly; they overlap, and the overlaps are where teams get caught. Consider explainability. Horizontal AI law may require technical transparency and documentation. Sectoral lending law may require that a declined applicant receive specific reasons. Data protection may grant the individual a right to meaningful information about the logic of an automated decision. These are three different obligations, with three different audiences and three different standards of "explanation", all landing on the same model. Satisfy one and you have not necessarily satisfied the others.
The art is not to handle each regime in isolation but to design controls that discharge multiple overlapping obligations at once — one robust explanation capability that serves the regulator, the customer, and the data subject.
Knowing your regulators
Rules are enforced by people and institutions, and understanding who they are changes how you prepare. A few principles hold broadly:
- Regulators are not monolithic. A single firm may answer to a conduct regulator, a prudential regulator, a data-protection authority, and a competition authority — each with different priorities. What reassures one may not satisfy another.
- Supervisors value engagement. Regulators generally prefer firms that come to them early and openly over firms they have to chase. A proactive conversation about a novel AI use case is almost always cheaper than a reactive one after something has gone wrong.
- Examiners reason from evidence. Supervisory review is, at bottom, a request for evidence: show me your model inventory, your validation reports, your monitoring, your governance minutes. Firms that generate this evidence as a by-product of operation breeze through; firms that assemble it reactively suffer.
- Guidance signals intent. Beyond hard law, regulators publish guidance, discussion papers, and "Dear CEO" letters that telegraph where supervision is heading. Reading these is one of the cheapest forms of risk management available.
Building an obligation map
The practical output of understanding the landscape is a single artefact: an obligation map for each significant AI system. This is not a legal treatise; it is a working document, ideally a structured table, that you maintain alongside the system.
For each system, the map captures, on one axis, every distinct obligation that applies — drawn from all four layers — and on the other, the specific control that satisfies it and the evidence that proves the control runs. Building it forces three valuable disciplines:
- It makes overlaps explicit. When you list obligations side by side, you see where one control can discharge several duties, and where a gap leaves a duty unmet.
- It turns law into engineering backlog. Every obligation without a satisfying control is a concrete task for the build team. The map becomes the bridge between counsel and code.
- It becomes the spine of your regulatory story. When a supervisor asks how you comply, the obligation map is the answer — a clear, evidenced account of which duty each control addresses.
The obligation map is a recurring character in this course. Several later parts — on documentation, validation, and the operating model — hang directly off it.
Working across jurisdictions
Many institutions operate in several jurisdictions at once, and the regimes do not agree. A defensible strategy rarely means complying with each in isolation; it usually means identifying the most demanding applicable standard for each obligation and meeting that, so a single control satisfies the strictest regulator and, by implication, the others. This "highest common denominator" approach trades some efficiency for enormous simplicity, and it ages well: as regimes converge upward, you are already there.
There are exceptions — occasionally two regimes conflict outright, demanding incompatible things — and those genuine conflicts need legal resolution and documented decisions. But they are rarer than teams fear; most apparent conflicts dissolve into "satisfy the stricter one".
Classify early, classify honestly
Almost every regime turns on classification — how risky, how impactful, how sensitive the system is. Because classification determines how heavy your obligations are, there is a constant temptation to argue your way into a lighter tier. Resist it. A system that decides credit, eligibility, clinical pathways, or employment is high-impact regardless of what you call it, and an over-light classification is the first thing a skilled examiner will challenge — at which point every control you scoped to the lighter tier is suddenly inadequate. Honest classification, covered in depth in the next part, is the foundation the rest of the apparatus rests on.
A worked example: one model, four regimes
Consider a model that decides which insurance claims are paid automatically and which are routed for investigation. Walk it through the four layers and the overlap stops being abstract.
- Horizontal AI law may classify claims handling that materially affects people's access to money as high-risk, triggering duties around data quality, documentation, human oversight, and transparency.
- Sectoral insurance-conduct rules require that claims be handled fairly, that customers be treated reasonably, and that declines be justifiable — obligations that predate AI and apply with full force to the automated version.
- Data-protection law governs the personal and sometimes special-category data the model uses, demands a lawful basis for both training and deployment, and gives claimants rights over automated decisions that significantly affect them.
- Internal policy may set a model-risk standard requiring independent validation and board-level oversight before such a system goes live, regardless of what the law strictly requires.
A single declined claim can therefore implicate a fairness duty, a transparency duty, a data-subject right, and an internal validation requirement at once. Designing four separate compliance efforts for this would be wasteful and brittle; designing one robust set of controls — fair and tested decisions, clear reasons, honoured rights, independent validation — that discharges all four is the craft the obligation map exists to support.
Reading the direction of travel
Regulation is not static, and a mature programme watches where it is heading rather than only where it stands. Several trends are durable enough to plan around:
- Convergence toward risk-based frameworks. Jurisdiction after jurisdiction is settling on the same basic logic — classify by impact, impose obligations accordingly — which means investment in honest classification and proportionate controls ages well wherever you operate.
- Rising expectations on transparency and contestability. The right of affected people to understand and challenge automated decisions is strengthening, pushing explainability and human recourse from good practice toward legal requirement.
- Growing attention to foundation and third-party models. As reliance on external models grows, regulators are turning to the accountability gap they create — a theme that gets its own part later in this course.
- Supervisory capability is maturing. Regulators are building AI expertise and asking sharper, more technical questions. The era in which a vague assurance sufficed is closing.
Building the obligation map in practice
The obligation map introduced above is worth a few practical notes, because its usefulness depends on how it is maintained. Treat it as a living artefact owned by a named person, not a document produced once for a launch and abandoned. Populate it collaboratively — counsel supplies the obligations, engineering supplies the controls, risk confirms the mapping — so that no single function owns a view it cannot fully see. Review it on a schedule and whenever the system's use changes, because a new population or purpose can pull in obligations that did not previously apply. And keep it concrete: an obligation expressed as "be fair" is not actionable, while "test for disparate impact across protected groups quarterly and remediate deviations beyond the agreed threshold" is both a control and its own evidence. The discipline of forcing every obligation down to a specific, testable control is what turns the map from a comfort blanket into a genuine instrument of compliance.
An obligation without a named control is a risk you have written down but not addressed. The map's value is in closing that gap, line by line.
In the next part: risk classification itself — how to tier AI systems by impact so that governance effort lands where the harm could be greatest, and how to defend your classification when it is questioned.