There are two ways to do AI governance. The first is to write a policy. A forty-page document: responsible AI principles, a committee, a role matrix, a requirement to "use AI ethically." It gets signed, filed in SharePoint, and revisited at the next audit. The second way is to build governance into the request path: every model call is physically unable to bypass PII masking, access control, guardrails, limits, and audit, because they stand in the way of the packet, not in the developer's head.
This is about the second way. The thesis is simple and blunt: governance that can't be bypassed technically is not a document — it's a control plane.
What AI Governance means, in plain terms
Without the jargon: AI governance is the set of rules and mechanisms that determine what an AI system in a company is allowed to do, what it isn't, and how you make sure it actually stays within that. Three questions it answers:
- What is the AI allowed to do? What data it sees, what actions it takes, who and what it answers to. The assistant may read the knowledge base but not salaries; it may create a ticket but not transfer money without a human.
- How do you guarantee it complies? Not "we asked the model to behave" — technical constraints that stand in the way and that the model cannot talk its way around.
- How do you prove it? To a regulator, an auditor, a customer — that the system operates within bounds, that decisions are explainable, and that data is protected.
Accounting has internal controls — not because accountants are bad people, but because money flows through it, and that requires procedures, separation of duties, an audit trail. AI governance is the same thing for AI systems: not distrust of the technology, but recognition that money, personal data, and decisions affecting people now flow through AI.
It matters what governance is not. It's not "slow the AI down," and it's not a legal department writing bans. Good governance, in fact, enables moving fast — because when protection is built into the platform, teams don't have to reinvent it and negotiate it by hand every time. Bad governance creates drag; good governance removes friction.
Regulators turned this from "nice to have" into "mandatory" between 2024 and 2026: the EU AI Act requires specific technical measures and threatens fines based on company revenue, and ISO/IEC 42001 is the international standard against which governance can be certified. This is no longer goodwill — it's a market and legal requirement.
Why policy doesn't work
Policy describes the behavior people are supposed to have. But in production, behavior is determined by code and infrastructure, not intentions. Between policy and production is a gap that every high-profile incident falls into: PII in a provider's logs, a RAG that handed an employee their colleagues' salaries, an agent that executed an injection from an email, a six-figure token bill overnight. None of these happened because someone didn't read the policy. They happened because nothing stood in the request path to stop them.
Policy is a specification. The control plane is its implementation. This course refuses to write specifications that nothing can enforce.
What an AI Control Plane is
It's the control layer between applications and models through which all traffic to LLMs passes — self-hosted, cloud APIs, agentic calls. Inside it sits a set of control planes, each closing one category of risk:
- Data plane — what leaves the perimeter: PII masking, Zero Data Retention (ch. 1).
- Identity plane — who sees what: RBAC/ABAC at the RAG level (ch. 2).
- Safety plane — what the model accepts and returns: guardrails against injections, jailbreaks, toxicity, hallucinations (ch. 3).
- Audit plane — what happened: an immutable trace of every decision (ch. 4).
- Cost/resilience plane — what it costs and whether it stays up: gateway, cache, budgets, fallback (ch. 5).
- Compliance plane — conformance: EU AI Act, ISO 42001, provenance (ch. 6).
- Quality plane — is it degrading: continuous evaluation, drift, fairness (ch. 7).
- Supply-chain plane — what it's built from and what's unauthorized: AIBOM, Shadow AI, kill-switch (ch. 8).
- Autonomy plane — what the agent is allowed to do on its own (ch. 9).
- Operating model — who owns all of this and how it lives as an AIMS (ch. 10).
No single plane is self-sufficient. ZDR without access control hands out someone else's data — not to the provider, but to your own employee. Guardrails without audit can't be proven to a regulator. Audit without budgets bankrupts you. The control plane assembles them into one system.
Principles the course stands on
- Governance-by-design, not bolt-on. Control is built into the architecture at design time, not screwed on as a review after an incident. It's cheaper, and it's the only thing that scales.
- Explicit state transitions, not encapsulated logic. Every control is an external, observable state (a status in a manifest, an entry in the audit log, a policy engine verdict), not an "if" buried deep in a service's code. Governance that can't be seen from the outside can't be verified or proven.
- An honest boundary. Every pattern has a failure mode. PII masking breaks on unstructured names; pre-filtering RAG breaks on complex ABAC rules; guardrails break on new classes of injection. A "Where it breaks" section exists in every chapter: the engineer who knows the boundary of their control is more reliable than the one who believes in its completeness.
Compliance theater
Most "AI governance" on the market today is compliance theater: documents, committees, checklists that create the feeling of control without creating control. Regulators have already caught on — the EU AI Act demands not declarations but technical documentation, logs, risk management systems, and machine-readable labeling. Fines are calculated off revenue. A company whose governance lives in a PDF, not a control plane, is a company that finds out about the gap at the moment of an incident or an audit.
Running case — Kovcheg
So the patterns assemble into one system rather than a scatter of disjointed tricks, the whole course runs on one fictional product — Kovcheg. It's an AI assistant for a bank (or an insurer — the difference doesn't matter for the course). The name was invented specifically so it isn't confused with real systems or cases.
Kovcheg was deliberately chosen to touch every governance plane at once — hence its two faces:
- The RAG assistant answers employee questions against the company's internal systems (the Confluence wiki, Jira tickets, SharePoint documents, a PostgreSQL database). "RAG" — retrieval-augmented generation — means the model doesn't answer from memory; it first retrieves relevant documents, then formulates an answer from them. The key requirement: an employee should see through the assistant exactly what they have access to in the source systems — no more.
- The agent doesn't just answer, it acts: creates tickets, drafts customer decisions (including credit decisions), calls internal APIs. "Agent" here means an AI given tools and the right to use them on its own.
Why a bank, and why with exactly these functions. First, the data: names, passport numbers, accounts — personal data under GDPR plus banking secrecy, so the cost of a breach is at its maximum (chapters 1–2). Second, regulation: creditworthiness assessment is explicitly classified as a high-risk system under the EU AI Act — which brings in the strictest set of requirements (chapter 6). Third, actions: an agent drafting decisions about a customer's money is no longer "the chatbot made a mistake" — it's real damage (chapter 9).
Kovcheg isn't the simplest example — it's the most demanding one. If a governance pattern works on it, it will work all the more so on a lower-risk product. Every chapter shows its own control plane on Kovcheg; chapter 10 assembles them into a single reference architecture.
How to read the course
Chapters 1–9 are control planes, each self-contained and delivering a working pattern. Chapter 10 assembles them into an operating model and the reference architecture of Kovcheg as a whole. The order is recommended, not mandatory: if privacy or access is on fire, start with 1–2; if the regulator is on fire, start with 6; if you're building agents, start with 9. The running case, Kovcheg, threads through every chapter so the patterns assemble into one system rather than a scatter of disconnected fixes.
Where it breaks
Every control plane in this course has a failure mode, and every chapter names it. PII masking breaks on unstructured names that don't match your regex or NER patterns. Pre-filtering RAG on access rules breaks when ABAC policies get complex enough that the pre-filter can't evaluate them without running the full query. Guardrails break on novel injection classes the classifier hasn't seen. Zero Data Retention breaks when a provider's sub-processor logs the prompt before your masking layer ever sees it.
The engineer who knows the boundary of their control is more reliable than the one who believes in its completeness. The "Where it breaks" section in every chapter is not a disclaimer — it's the most operational piece of documentation you'll write, because it tells the on-call engineer exactly what to watch for at 3 AM.
If your AI governance lives in a PDF, the regulator will find out at the audit. If it lives in a control plane, the audit is a read-only query.