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.<\/p>\n
This is about the second way. The thesis is simple and blunt: governance that can't be bypassed technically is not a document \u2014 it's a control plane.<\/strong><\/p>\n <\/p>\n 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.<\/strong> Three questions it answers:<\/p>\n Accounting has internal controls \u2014 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.<\/p>\n It matters what governance is not<\/strong>. It's not "slow the AI down," and it's not a legal department writing bans. Good governance, in fact, enables<\/strong> moving fast \u2014 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.<\/p>\n Regulators turned this from "nice to have" into "mandatory" between 2024 and 2026: the EU AI Act<\/strong> requires specific technical measures and threatens fines based on company revenue, and ISO\/IEC 42001<\/strong> is the international standard against which governance can be certified. This is no longer goodwill \u2014 it's a market and legal requirement.<\/p>\n 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.<\/p>\n Policy is a specification. The control plane is its implementation. This course refuses to write specifications that nothing can enforce.<\/p>\n It's the control layer between applications and models through which all<\/strong> traffic to LLMs passes \u2014 self-hosted, cloud APIs, agentic calls. Inside it sits a set of control planes, each closing one category of risk:<\/p>\n No single plane is self-sufficient. ZDR without access control hands out someone else's data \u2014 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.<\/p>\n 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 \u2014 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.<\/p>\n So the patterns assemble into one system rather than a scatter of disjointed tricks, the whole course runs on one fictional product \u2014 Kovcheg<\/strong>. It's an AI assistant for a bank (or an insurer \u2014 the difference doesn't matter for the course). The name was invented specifically so it isn't confused with real systems or cases.<\/p>\n Kovcheg was deliberately chosen to touch every<\/strong> governance plane at once \u2014 hence its two faces:<\/p>\n Why a bank, and why with exactly these functions. First, the data: names, passport numbers, accounts \u2014 personal data under GDPR plus banking secrecy, so the cost of a breach is at its maximum (chapters 1\u20132). Second, regulation: creditworthiness assessment is explicitly classified as a high-risk system under the EU AI Act<\/strong> \u2014 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" \u2014 it's real damage (chapter 9).<\/p>\n Kovcheg isn't the simplest example \u2014 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.<\/p>\n Chapters 1\u20139 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\u20132; 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.<\/p>\n 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.<\/p>\n 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 \u2014 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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" Governance that can’t be bypassed technically is not a document \u2014 it’s a control plane. Every model call physically passes through PII masking, access control, guardrails, and audit.<\/p>\n","protected":false},"author":0,"featured_media":171,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[147,149,148],"tags":[150,151,153,141,154,152],"class_list":["post-172","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-governance","category-ai-security","category-llmops","tag-ai-governance","tag-control-plane","tag-eu-ai-act","tag-guardrails","tag-iso-42001","tag-llmops"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tWhat AI Governance means, in plain terms<\/h2>\n
\n
Why policy doesn't work<\/h2>\n
What an AI Control Plane is<\/h2>\n
\n
Principles the course stands on<\/h2>\n
\n
\n
\n
Compliance theater<\/h2>\n
Running case \u2014 Kovcheg<\/h2>\n
\n
How to read the course<\/h2>\n
Where it breaks<\/h2>\n