Lessons

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.

Guardrails you have not attacked are guardrails you have only hoped about. This lesson covers manual and automated red-teaming: the attack methods worth knowing, how to run an exercise that produces findings rather than reassurance, what to measure, and how to turn results into regression tests that survive the next model update.

Guardrails are a layered control system around a model that cannot police itself. This lesson covers the rail types, rules versus classifiers versus model-based judges, the tools that implement them, the latency and false-positive budget that constrains every design, and why architectural containment beats filtering.

Guardrails exist because a language model cannot reliably distinguish instructions from data. This lesson builds the threat model: the OWASP Top 10 for LLM Applications, direct and indirect prompt injection, jailbreaks, data leakage, and why tool-using agents turn a content problem into a security one.

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.

A high-risk system reaches the market through a defined gate and stays there under continuing obligations. This lesson covers which conformity assessment procedure applies and when a notified body is involved, the declaration of conformity and CE marking, registration, substantial modification and reassessment, post-market monitoring, and serious incident reporting with its tiered deadlines.

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.

High-risk classification determines whether an organisation faces a substantial compliance programme or almost none. This lesson works through both routes: the Annex I product-safety route as narrowed in 2026, the eight Annex III use-case areas with the boundaries that get argued, and the Article 6(3) derogation, its conditions, and the assessment you must document to rely on it.

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.

Retrieval solved the read side, so the constraint moved to what gets written down. This lesson covers the capture write path: architecture decision records, docs-as-code, change-triggered updates, and making capture cheap enough to survive. Then how to evaluate a company brain with golden questions, groundedness, and a permission regression suite, plus the failure modes that end these projects.

The hard parts of an internal knowledge system are not the ones a public RAG tutorial covers. This lesson builds the architecture: connectors and the ingestion path, the permission problem and why early binding beats late binding, oversharing inherited from your existing access control, entity resolution across silos, and the staleness and conflicting-truth problems that break internal corpora.