AI Governance Foundations for Engineers
Why this module exists
Most AI governance material is written for lawyers, risk officers and auditors. You are none of those. You are the person who has to build the thing, and someone above you has just said “make sure it’s compliant” without telling you what that means in a pull request.
This module reframes governance as an engineering concern: a set of architectural decisions and code patterns, not a policy document. By the end you will be able to look at any AI feature and say precisely where governance needs to live in the stack, and what is currently missing.
Lesson 1.1: What governance actually means at the code level
“AI governance” is a vague term that hides four concrete, buildable requirements.
1. Traceability. For any AI interaction, can you reconstruct what was sent, what came back, who or what triggered it, which model actually served it, and what decision followed? If the answer involves grepping application logs and guessing, you don’t have traceability — you have debugging output.
2. Control. Can a human or a policy intervene before an AI action takes effect, in the cases where the stakes require it? Note the qualifier. Control is not “a human reviews everything”; that design fails in production for reasons covered in Module 3.
3. Boundedness. Does the system have enforced limits — cost, rate, scope, data access — or does it rely on the model behaving well and the code not looping? Enforced means in code, not in a runbook.
4. Evidence. Can you prove that 1–3 are happening, to someone who is not you, without a week of work? This is the requirement engineers most reliably underestimate, and the one that turns up under deadline pressure.
Every governance requirement you will ever be handed — from legal, from a customer’s security questionnaire, from an internal audit — decomposes into some combination of these four. The remainder of this course implements each one.
A distinction worth fixing early: governance is not content moderation or model safety. Those concern what the model produces. Governance concerns what your system does with what the model produces — the machinery around it. A well-behaved model wrapped in an ungoverned system is a completely normal outcome, and it is the gap this course addresses.
Lesson 1.2: The regulatory landscape, minus the legalese
You do not need to become a lawyer. You need enough of a map to know which decisions are yours and which need a conversation with someone else.
GDPR / UK GDPR. Engages any time personal data enters a prompt, a log, or a fine-tuning pipeline. The developer-relevant pressure points are data minimisation, right to erasure, and recognising when a Data Protection Impact Assessment is triggered. Module 9 covers this properly.
EU AI Act. A risk-tiering framework. Most internal tooling, copilots and drafting assistants land in the limited-risk tier, where obligations are mostly about transparency — telling people they are interacting with AI. Systems that materially affect someone’s access to employment, credit, education or essential services land in high-risk, where obligations become substantial: risk management, logging, human oversight, documentation. Your job is to know which tier your feature sits in, because it changes what Modules 4 and 8 demand of you.
Sector rules. Financial services, healthcare, legal and public sector work layer additional audit, retention and explainability requirements on top. Not covered in depth here, but everything in this course composes with them rather than conflicting.
Customer and procurement requirements. In practice this is what will actually land on your desk. Not a regulator — a prospect’s security questionnaire, a SOC 2 auditor, or an enterprise customer’s vendor review asking to see your AI system’s audit trail and access controls. This is the most common real-world trigger for engineering work, and Module 8 is built around it.
The reframe: you are not being asked to interpret regulation. You are being asked to build a system flexible enough that when a requirement arrives in legal language, you can map it to traceability, control, boundedness or evidence — and already have the pattern.
Lesson 1.3: Where governance lives in your architecture
There are two broad homes for governance logic, and the split has long-term consequences.
Gateway / proxy level. A single layer that every AI call passes through, whatever application is on one side and whatever provider is on the other.
- Consistent by construction — one place to enforce policy, log and limit
- New applications inherit governance for free
- Can become a bottleneck or single point of failure
- Awkward for feature-specific rules
Application level. Each service implements its own logging, approval logic and limits.
- Fine-grained and contextual
- Inconsistent by default; one team forgetting a check is invisible until it matters
- Duplicated logic, duplicated bugs
In practice the answer is both, split by concern:
| Concern | Home |
|---|---|
| Provider abstraction, base request/response logging | Gateway |
| Rate limiting and cost budgets | Gateway |
| PII / DLP scanning | Gateway — catches everything, including calls you forgot about |
| Compliance report generation | Gateway — single source of truth |
| Approval workflows tied to business rules | Application |
| Feature-specific escalation thresholds | Application |
The rule of thumb: anything you want to be unmissable goes in the gateway. Anything that depends on business context goes in the application. The gateway guarantees a floor; the application adds ceiling-specific rules.
This is the architecture Module 2 builds and the rest of the course assumes.
Lesson 1.4: The three failure patterns
Before building anything, it helps to recognise the three ways governance programmes fail, because you will be tempted by all of them.
Governance as documentation. A policy document describes controls that do not exist in code. This survives until someone tests it — usually an auditor, sometimes an incident. The tell: your controls live in a wiki rather than in a function.
Governance as ceremony. Controls exist but produce no signal. Every AI action requires approval; reviewers approve everything in eight seconds; the audit log records that a human “reviewed” outputs nobody read. This is worse than no control, because it manufactures false confidence.
Governance as blocker. Controls are real and strict enough that teams route around them — calling providers directly, using personal API keys, standing up shadow services. The tell: your gateway’s traffic doesn’t match your organisation’s actual AI spend.
The design goal throughout this course is governance that is enforced by default, cheap enough that nobody routes around it, and productive of real evidence rather than ceremony.
Practical exercise: governance gap audit
Pick an AI feature — one you have shipped, one you are planning, or a hypothetical (say, AI-assisted support ticket triage).
Answer honestly, in writing:
- Traceability. If a customer disputes an AI-driven decision six months from now, can you reconstruct what the model saw and returned, and which model version served it? What is missing?
- Control. Which actions does this system take that no human reviews before they take effect? For each, is that the right call, or just the default that happened?
- Boundedness. What stops a runaway loop making ten thousand calls? What stops this feature reading data it shouldn’t? Is that enforced in code, or assumed?
- Evidence. If asked tomorrow to demonstrate any of the above to an auditor or an enterprise customer, how long would it take and what would you be unable to produce?
Deliverable: a one-page gap list. Do not fix anything yet — Modules 2 through 9 build the fixes. The point is to see your own system clearly, which is the step teams most reliably skip.
Keep this document. Module 10 asks you to revisit it and turn it into a rollout plan.
Next: Module 2 — Building the AI gateway layer, where we start closing these gaps.
That's Module 1 in full. The remaining nine build the gateway, the audit schema, the approval workflow, the budget guards, the injection defences and the reporting that turns all of it into evidence.
See the full course →