ai-governance

A responsible AI programme is judged by what happens after launch. This lesson covers recognising an AI harm, building a redress route for people affected, reviewing incidents for the decisions that caused them, measuring the programme honestly, and the failure modes that hollow it out over a year.

Controls only work if a team meets them inside their normal process at a point where answers can still change the design. This lesson covers the three gates, writing a checklist that produces decisions rather than ticks, model and system cards, and giving someone the authority to stop a launch.

Almost every organisation has AI principles and almost none can point to a shipping decision they changed. This lesson covers why abstract commitments fail to bind, the specific gap between a value and a decision rule, ethics washing, and what a principle needs before it can affect anything.

Validation was built for models that produce a number, not for systems that produce prose. This lesson covers conceptual soundness, outcomes analysis and ongoing monitoring applied to modern AI, what changes for generative systems, the pre-deployment evidence pack, and how to document a position when no framework covers your system.

Human oversight is the control regulators lean on hardest and the one most often decorative. This lesson covers the four conditions that make it real, how to evidence each rather than assert it, the override rate as the diagnostic, and the audit trail needed to reconstruct a single decision eighteen months later.

Regulated deployment is judged on evidence, not intent. This lesson covers the assurance vocabulary supervisors already use: three lines of defence, effective challenge, independent validation, and the model risk management tradition, including the 2026 shift from SR 11-7 to SR 26-2 and the gap it deliberately leaves.

AI governance sits at the intersection of four competency areas, and almost nobody arrives holding all of them. This lesson sets out what each requires and how deep it must go: regulatory literacy, enough technical understanding to ask the right questions, assurance discipline, and the organisational skill the function runs on. It closes on certifications and what they are worth.

AI governance is a body of work before it is a job title, and most of it is done by people whose title says something else. This lesson sets out what the work consists of, how it splits across legal, risk, data protection and engineering, why a dedicated role appears at some scales and not others, and what the data protection officer precedent does and does not tell you.

Nobody hires for AI governance on the strength of a certificate. This lesson covers what to actually produce: the four artefacts that demonstrate competence, how to build them from work already available inside your current job, routes in from each adjacent profession, what the first ninety days look like, and an honest account of the parts of this work that are unpleasant.

The contract is where a deployer's leverage lives, because almost every duty you hold depends on information the provider controls. This lesson covers the clauses that matter for AI, allocating AI Act obligations between the parties, change notification and substantial modification, monitoring a live system for drift, incident cooperation, and designing an exit before you need one.

Vendor claims are marketing until you test them. This lesson covers the diligence pack worth requesting, why the instructions for use are the single most valuable document in a high-risk purchase, questions about model provenance and the AI-specific attack surface, designing a pilot that can actually fail, shadow-mode evaluation, and the red flags that should end a procurement early.

AI procurement fails at the scoping stage, before any vendor is contacted. This lesson covers what makes an AI purchase different from ordinary software, the regulatory position you inherit from the seller, the questions that determine whether you become a provider yourself, how to specify a problem rather than a product, and the build-buy-or-do-nothing decision that should precede any shortlist.

Once a system is high-risk, Articles 8 to 15 set out what it must satisfy. This lesson works through them as engineering requirements rather than legal text: risk management as a continuous process, data governance including the 2026 change on special category data for bias detection, human oversight as a design property, accuracy and robustness, and transparency toward the deployer.

Governance that leaves no trace is indistinguishable from no governance. This lesson covers the documentation the AI Act requires: Annex IV technical documentation and its simplified SME forms, the quality management system, instructions for use, log retention, the fundamental rights impact assessment, registration, and how to make documentation a byproduct.

With an inventory in place, governance becomes a question of who decides what. This lesson covers the AI policy and what actually belongs in it, acceptable-use rules people can follow, decision rights mapped with RACI, the approval gate a new system passes through, an AI risk register with risks specific to these systems, and escalation that works when something goes wrong at eleven at night.

An AI governance framework that starts with a policy is built on nothing. This lesson covers the artefact everything else depends on: finding the AI systems you actually run, including the ones inside software nobody bought as AI, recording the fields that make the inventory usable, classifying each system, assigning real ownership, and binding the whole thing to triggers so it stays true.

There is no small-business exemption in the AI Act, but there is proportionality, and the 2026 Omnibus widened it. This lesson covers the simplifications for SMEs and the new small mid-cap category, the minimum defensible position for a deployer, how to sequence work against the amended deadlines, where GDPR work can be reused, and when you genuinely need a lawyer.

The AI Act sorts systems into four tiers by what they are used for, not by how sophisticated they are. This lesson covers prohibited practices, the two routes into the high-risk tier, the derogation that lets a listed system out, the transparency duties, and the timeline as amended by the 2026 Digital Omnibus: which dates moved, which did not, and how grandfathering works.

Before any obligation applies, two questions decide everything: is this an AI system under the Act, and what role does your organisation hold in relation to it? This lesson covers the definition of an AI system, the provider, deployer, importer and distributor roles, the acts that turn a deployer into a provider, the Act's reach beyond the EU, and what falls outside it entirely.

A designed program still has to be delivered, kept current as tools change, and documented well enough to show what you did. This lesson covers delivery formats and why attaching training to tool rollout beats annual campaigns, measurement that is useful rather than required, the records that constitute evidence, refresh triggers, and an honest account of what an AI literacy program cannot fix.

A single company-wide e-learning module satisfies nobody and teaches almost no one. This lesson turns the AI Act's own factors into a design method: inventory the AI systems actually in use, segment the population by what they do with them, and build a layered curriculum from a universal baseline through role-specific modules to high-risk operator training, with the content that belongs in each.

AI literacy has a legal definition in the EU AI Act, and the obligation attached to it changed in 2026. This lesson covers Article 3(56), the original Article 4 duty to ensure a sufficient level of literacy, how the Digital Omnibus reframed it as an obligation of effort rather than result, who is bound, which AI systems are in scope, and the adjacent duties that remain hard requirements.

In banking, an accurate AI model is not enough; it must also be fair, explainable, and well-governed. Learn how AI can perpetuate lending bias and why fair-lending law forbids it, why consequential decisions must be explainable, how model risk management keeps banks safe, and why the institution, never the algorithm, remains accountable. The guardrails that make banking AI responsible.

For lawyers, AI is not just a productivity question but an ethics question. Learn how professional duties, competence, confidentiality, candor to the court, and reasonable fees, apply to AI use, why bar authorities now issue formal guidance on it, how to vet a tool and supervise its output, and how to build a simple responsible-AI policy that keeps you on the right side of your obligations.

Map how the EU AI Act sorts systems into four risk tiers with matching duties, and how NIS2 sets a horizontal cybersecurity baseline with strict reporting clocks. Learn who each rule binds and how compliance is structured.