AI Governance Studio
INSIGHT
AI adoption inside the enterprise has outrun the mechanisms built to govern it. McKinsey put a number on the gap in 2024: over 65% of enterprises had already put generative AI into at least one business function — up from 33% a year earlier. The regulatory response is arriving on a slower clock: EU AI Act high-risk provisions phasing in through 2025–2026, NIST AI RMF becoming the default US benchmark, ISO 42001 turning into the certification vendors get asked for. Most organizations still have no way to turn any of it into a decision on one specific use case.
That gap showed up directly while codifying AI governance policy for an LLM-powered chatbot initiative at Coca-Cola. Business teams could describe what they wanted to build. What didn't exist was a structured way to score the risk, a consistent way to map it to the right framework, or — once a policy was actually approved — anything that stopped an agent from acting outside it. That last piece, enforcement after approval, is what this project is built to answer.
DECISION
"Flagging risk is easy. Enabling responsible deployment is the product."
The core product decision in this system is about where enforcement authority lives.
WHY
An LLM-decided allow-list is a plausible-sounding string, not an enforced boundary. If the model hallucinates, or is prompt-injected into agreeing an action is fine, nothing underneath catches that. Routing the enforcement decision through ordinary, reviewable code means a security reviewer can read the rule set and know exactly what will happen for a given risk profile — independent of what any single model generation returns. The LLM still adds real value where generative synthesis genuinely helps: the narrative, the framework mapping, the suggested controls. It's kept out only of the one place where a wrong answer has direct consequences.
THE TRADE-OFF, STATED PLAINLY
This means the enforcement rules are hand-written and don't automatically adapt to risk combinations I didn't anticipate. That's an intentional MVP ceiling, not an oversight — the next step is a rules format a compliance team could edit without needing an engineer, not a move toward giving the model more control.
SYSTEM
FLOW
LangGraph orchestrates steps 2-6 as a single StateGraph with a fixed edge sequence. Only step 4's narrative half an LLM call - every enforcement relevant decision is ordinary, reviewable code.
STATUS
Everything on the left is measured or verified in the working system. Everything on the right is where this could go next — stated as vision, not a claim about what exists today.
REASONING
Before writing any code, each screen was wireframed and pressure-tested against the PRD — including the inconsistencies that got caught and fixed along the way. This is that process, notes included.
Why plot risk on two axes first?
Why 8 factors - and why binary?
1.consistency"Is this a 3 or a 4" is a judgment call. "Is PII present" isn't. Severity gets encoded once, in the weight — not re-judged by every reviewer.
2. resolution8 binary factors → 256 combinations across 0–130. Enough range to tell "barely High" from "maximally High," not three flat buckets.
3. interlock with F-03Personal Data → GDPR. Autonomous Decision → EU AI Act high-risk. Each factor maps to a real regulatory concern — 8 isn't arbitrary.
CAUGHT AND REVERSED
An earlier wireframe pass added a "Confidence — 94%" readout to the risk panel, to look more like a live model.
But F-02 is explicitly non-probabilistic — "Not Machine Learning. Not Probabilistic. 100% Deterministic." A confidence score has no valid meaning in a rule-based system — there's no probability distribution to be confident about.
A coarse 2×2 sets an initial routing hint — before the 8-factor score exists. If the two ever disagree, the score wins: it reflects the specific combination, not a coarse approximation.
A realistic ceiling for a form filled in the time an "expense report" takes.
Replaced with the real, deterministic score instead.
Wireframe
WHY
THIS
EXISTS
This project exists because a policy document that stops at "here's the recommendation" isn't actually governance — it's advice waiting for someone else to enforce it, or not. Everything above was built to close that gap end to end: a risk score that reproduces itself on demand, a Playbook that names an owner and a date, a policy gate that actually says no.
None of it asks anyone to trust the author's judgment. The test suite, the audit log, and the source code do that work instead —which is the standard this project holds itself to, and the one worth holding any AI governance decision to, including this one.
What comes next isn't really about AI, or governance specifically. It's about systems complex enough that getting them right matters, where the proof has to live in the system itself, not in how well the pitch reads