AI Governance
Governance isn't a dirty word
Building AI systems you can actually trust — and defend.
When most engineers hear "AI governance," they picture a committee, a 40-page PDF nobody reads, and someone in compliance saying no. Red tape. Ceremony. The place velocity goes to die. That's not what this is.
Governance is risk engineering — the same instinct that makes a good platform engineer set up monitoring before the outage, back up the database before the disk dies, and put guardrails on a pipeline before someone pushes straight to prod on a Friday afternoon. You already do this everywhere else in your stack. AI governance is applying that exact discipline to the one component that can now write its own code, make its own decisions, and occasionally hallucinate a customer's data into a log file.
As teams race to ship AI features — coding agents, LLM-powered products, automated decisions — the risks are real and genuinely new: leaked data, biased outputs, unpredictable behavior, and a fast-arriving wall of regulation (the EU AI Act's high-risk rules start phasing in from August 2026). Someone has to handle all of that without strangling the speed that made AI worth adopting in the first place. That's the work I do, and I anchor it to a framework I trust.
The framework
NIST AI RMF
I build to the NIST AI Risk Management Framework — the U.S. government's voluntary, vendor-neutral playbook for managing AI risk. I use it because it's practical, because it's becoming the common language for AI risk, and because the regulations coming down the pike (the EU AI Act included) echo its logic. Learn to speak it, and you're ready for most of what's coming.
A word on precision: the NIST AI RMF isn't a certification, and I don't claim to be "certified" in it — nobody is, because there's no exam or accrediting body. It's a set of principles you choose to follow, and I've built my practice around following them. I'll always tell you plainly what I'm aligned with versus what I'm certified in — in a field built on trust, the fastest way to lose it is to overclaim.
The framework organizes AI risk into four functions: Govern, Map, Measure, and Manage. Adopting AI means moving into powerful but largely unfamiliar territory. You could charge in blind and hope for the best — or you could set clear ground rules, map the terrain, bring instruments to read the conditions, and have a plan ready for when something goes sideways. That's the four functions, in order, and here's what I actually do with each one on your systems.
Govern
Set the ground rules
What it is
The foundation. Govern is the culture, policies, and accountability that run through everything else — who's responsible, what's allowed, and where humans stay in the loop. The most consequential decisions happen before anything ships.
What I do for you
Help you establish clear, lightweight policies for how AI is used across your stack — acceptable-use boundaries, who owns each AI system, where a human must review and approve before the machine acts, and what gets documented. Not a binder nobody opens; a short set of rules of engagement that actually get followed.
Map
Chart the territory
What it is
Establish context and identify what could go wrong. Before you can manage a risk, you have to know it's there — what your AI system does, what data it touches, who it affects, and where the hazards live.
What I do for you
Inventory where AI actually operates in your systems — every place a model touches your data, your users, or your production code. Then pin down the failure modes that matter for your context: leaked data, biased results, unpredictable behavior under load, prompt injection. You come away with a clear map of your real AI risk surface, instead of a vague sense of unease.
Measure
Read the instruments
What it is
Assess and track the risks you mapped, with real methods rather than guesswork — the gauges and sensors for whether an AI system is reliable, secure, explainable, fair, and privacy-respecting.
What I do for you
This is where my infrastructure background does the heavy lifting. I stand up the actual measurement — evaluations that test your AI against the failure modes we mapped, monitoring that watches model behavior and catches drift over time, and automated guardrail checks wired into your pipeline. Governance you can't measure is just a nice intention — I make it observable. My open-source project AgentGate is exactly this idea applied to AI-written code: a deterministic checklist that inspects every agent pull request for secrets, scope creep, and dangerous patterns before it's allowed to merge.
Manage
Act on what you find
What it is
Act on the risks — prioritize them, treat them, plan for incidents, and keep improving. Mapping and measuring tell you where the risks are; Manage is deciding how to treat each one: reduce it, avoid it, accept it, or transfer it.
What I do for you
Prioritize your risks by real-world impact so effort goes where it counts, put concrete mitigations and guardrails in place, and build the human-review gates that keep a person in control of consequential decisions — approve before the system acts, don't find out after. Then set up incident response for when the AI misbehaves, and a loop to revisit all of it as your systems and the regulations evolve.
Why this matters for you
Shipping AI features
This is how you move fast without stepping on a landmine — the speed of AI adoption, with guardrails that keep it from doing something you'll have to explain in a postmortem (or a headline).
Facing regulatory pressure
This is how you get out ahead of it — a defensible, documented approach to AI risk that maps to the frameworks regulators are actually using.
And here's the genuinely rare part: most people who can build your AI infrastructure can't speak governance, and most people who speak governance can't build. I do both. I'm a platform engineer who treats AI risk as an engineering problem — because that's exactly what it is.
A note on honesty: I build to the principles of the NIST AI RMF and pair it with practical AI-security guidance like the OWASP Top 10 for LLM Applications. These are frameworks I follow, not certifications I hold — and I'll always draw that line clearly. As I earn formal certifications, you'll find them listed separately.