• Home
  • AI Governance

AI Governance

Why enterprise AI governance programs fail under regulatory scrutiny — and the control architecture that makes the difference between a program that looks complete and one that actually is.

The Problem
What I Keep Seeing

The failure mode is consistent. And it is almost never the technology.

The governance documentation is comprehensive. The lifecycle is mapped. Evidence templates are complete. The program passed the first examination. Then the regulator comes back six months later and asks to see the controls actually running — and things go quiet.

Not because the controls don't exist. Because they were designed to document compliance rather than to enforce it. The lifecycle governance lives in a PDF that nobody updated between model deployments. The KRIs are defined but the monitoring infrastructure was never built. The board reporting was generated for the meeting and not touched again until the next one.

This gap — between governance that exists and governance that functions — is where regulatory credibility breaks down. It is also entirely predictable, because building programs that actually run requires the same discipline as any other engineering problem. You need the right architecture. And you need someone accountable for the whole thing, not just their piece of it.

I have spent 18 years closing that gap inside some of the most scrutinized financial institutions in the country. This is what I have learned about what it takes.

The Architecture
Three Things That Have to Be Built Together

Lifecycle controls. Continuous assurance. Executive accountability. You cannot sequence them.

Every AI governance program I have seen succeed had these three components operational simultaneously. Every program I have seen fail was missing at least one — usually the second, occasionally the third, sometimes the first in the places that mattered most.

01
Lifecycle Controls — From the First Line of Code to Retirement
SR 11-7 and NIST AI RMF are not governance programs. They are frameworks. The gap between knowing a framework and having built a program inside one is the difference between advisory familiarity and operating depth — and OCC examiners can tell the difference in the first thirty minutes of a review. Lifecycle controls mean that every stage of a model's existence — identification, development, validation, deployment, monitoring, retirement — produces structured, traceable evidence. Evaluation protocols with defined thresholds, not narrative summaries. Prompt governance standards with documented rationale, not general principles. Change management processes that actually capture what changed and who approved it. The evidence does not exist to satisfy the examiner. It exists because the program runs that way every day.
02
Continuous Assurance — The One That Almost Nobody Has Built Correctly
Point-in-time reviews are structurally insufficient for AI risk. Models drift. Data distributions shift. Operational context changes. A governance program running quarterly assessments is measuring a prior state of a system that is no longer in that state. The question I ask when I evaluate a program's monitoring infrastructure: if a model's behavior changed materially yesterday, how long before someone at the executive level knows? For most programs, the honest answer is the next scheduled review. That is not continuous assurance. That is periodic documentation with a continuous-sounding name. Continuous control monitoring is a data engineering problem as much as a governance problem. It requires KRI frameworks that detect drift in real time, automated dashboards that surface control health without human intermediation, and incident trend analytics that identify emerging exposures before they become findings. Building that infrastructure is why dual fluency across technical depth and governance strategy is not optional for this work.
03
Executive Accountability — What Boards Actually Need to Provide Oversight
Governance programs that cannot be explained to a board are governance programs that cannot be defended to a regulator. The challenge is that boards and audit committees need enough specificity to provide genuine challenge without the technical detail that obscures rather than illuminates. That translation is harder than it looks, and most programs get it wrong in one of two directions: reporting that is so high-level it becomes uninformative, or reporting that is so detailed it requires a technical interpreter to make sense of it. Neither produces real oversight. What I have built, and what works, is an accountability architecture that synthesizes model risk exposures, lifecycle gaps, control coverage ratios, and regulatory posture into a narrative that enables the board to ask hard questions, receive direct answers, and make informed decisions. Not compliance theater. Actual governance at the highest level of the organization.
The Standards
Applied in Practice, Not Studied from the Outside

The regulatory frameworks that shape what auditable AI actually requires.

The difference between knowing what NIST AI RMF says and having codified it into operational controls is not subtle. Examiners see the difference immediately. The frameworks below are not reference material — they are the vocabulary of programs I have built.

NIST AI RMF
Operationalized as living controls, not a documentation checklist. Codified into escalation pathways and lifecycle controls for enterprise GenAI and agentic deployments at a Tier-1 regulated institution.
ISO 42001
AI Management System standard integrated into GRC program infrastructure — risk assessment, organizational context, and continuous improvement architecture built to function, not to certify.
SR 11-7 / OCC & Fed
Bank-wide model governance aligned to SR 11-7 guidance. Decision rights mapped across the full MRM lifecycle. Regulatory examination posture built as a persistent operational state, not a pre-examination preparation mode.
SOX / GDPR / PCI-DSS
Cross-framework compliance programs designed for institutions operating under multiple simultaneous regulatory regimes — US and European contexts, without the usual gaps that appear at the intersections.
BCBS 239
Board reporting acceleration and data quality governance. Control use cases defined. Automated monitoring established. Trusted data foundation built for Commercial Banking at enterprise scale.
COBIT for AI
Governance and management objectives applied to AI-specific risk domains — bridging enterprise IT governance with the accountability architecture that AI programs require at scale.
Start a Conversation

Discuss what your organization
needs to build.

For organizations building GenAI assurance programs, navigating OCC or Fed examination cycles, or designing the control infrastructure for enterprise AI adoption at scale.

Start a Conversation View Executive Profile →