Why Most AI Governance Efforts Stall Before They Start
Most IT managers I talk to didn’t wake up one morning and decide to build an AI governance program. They got handed the responsibility sideways — a new vendor contract with an AI clause, an auditor asking about model documentation, a department head who quietly spun up a ChatGPT integration. Suddenly governance is on your plate, and the guidance available ranges from abstract framework documents to enterprise software pitched at companies ten times your size.
The problem isn’t a shortage of frameworks. NIST has the AI Risk Management Framework. The EU has the AI Act. ISO has 42001. These are genuinely useful reference documents, and we build on them. But none of them tell you the order in which a real organization — one with 80 employees, no dedicated compliance team, and three AI tools already running in production — should actually stand up governance. They describe what a mature program looks like. They don’t tell you where to start when you’re not there yet.
That’s the gap the RAGP framework addresses. It’s not a competing standard. It’s an operational sequence: React, Assess, Govern, Prove. Four phases, in a specific order, for a specific reason.
The Sequence Is the Point
Every governance framework I’ve seen gets implemented out of order. Organizations jump straight to policy writing before they’ve cataloged what AI tools they’re actually running. They try to prove compliance to an auditor before they’ve governed anything. They assess vendor risk for new tools while ignoring the ones already deployed. The result is documentation that looks complete on paper but has no operational foundation underneath it.
RAGP is deliberately sequenced because each phase creates the substrate the next one needs. You can’t accurately assess risk for tools you haven’t logged as incidents and exposures. You can’t govern effectively without risk data. You can’t prove compliance without governance artifacts. Skip a phase or reverse the order and you’re building on air.
Here’s what each phase actually means in practice.
Phase 1: React
React is where governance starts for almost every organization that isn’t building an AI program from a greenfield state. Something happened — or something is happening — and you need to capture it.
This phase is about incident logging: creating a disciplined record of AI-related events, near-misses, and exposures before they get normalized into background noise. An employee submitted sensitive customer data to a public LLM to speed up a proposal. A vendor’s AI-assisted decision tool produced an output that conflicted with a documented policy. An AI-generated email got sent to a client before anyone reviewed it. These events happen constantly in SMB environments, and without a structured place to log them, they evaporate. The next team meeting moves on, nothing gets tracked, and when an auditor asks whether you’ve had any AI-related incidents in the past year, you genuinely don’t know.
The goal in the React phase isn’t to immediately solve every problem you log. It’s to stop losing information. A log entry doesn’t have to be a five-page incident report. It needs to capture what happened, which system was involved, who was affected, and what the exposure was. That’s enough to feed the next phase.
This is also where you start understanding your actual AI footprint — not the approved tools on your software list, but the AI tools your organization is actually using. For most SMBs, those two lists don’t match.
Phase 2: Assess
Once you have a logging habit in place and some real incident data, you’re ready to assess. This means systematic evaluation of the AI tools and vendors in your environment against a defined risk framework.
Assessment is where most governance programs try to begin, which is exactly the wrong starting point. Without incident history, you’re assessing in a vacuum. You’re filling out a vendor questionnaire based on what the vendor tells you rather than what your organization has actually experienced. And you’re probably assessing the wrong tools — the officially approved ones rather than the ones generating incidents in your log.
A useful AI risk assessment looks at a few dimensions that generic IT vendor risk assessments miss. Data handling is the obvious one — what data does this tool touch, where does it go, and who can see it? But AI-specific risk also includes model transparency (do you know what the model was trained on, and can you explain its outputs to a regulator or a customer?), decision accountability (if this tool influences a business outcome, who owns that decision?), and update risk (AI models change, sometimes significantly, in ways that don’t come with a traditional software changelog).
The NIST AI RMF’s GOVERN, MAP, MEASURE, and MANAGE functions provide a solid conceptual backbone for this kind of assessment. What RAGP adds is the operational trigger: you’re not assessing hypothetically, you’re assessing the tools your incident log told you matter most.
Phase 3: Govern
Governance is where most of the visible work happens — policy development, control assignment, ownership documentation, evidence collection. It’s also where organizations that skipped the first two phases start to struggle, because they’re writing policies for an environment they don’t fully understand and assigning ownership for risks they haven’t quantified.
Done in sequence, the Govern phase is substantially more efficient. Your incident log tells you which risk categories need policy attention most urgently. Your risk assessments tell you which controls are already in place, which are missing, and which vendors require specific contractual language. You’re not writing governance from scratch; you’re formalizing what you’ve learned.
A few things matter in this phase that often get overlooked. First, policy without ownership is theater. Every AI governance policy needs a named person who is accountable for enforcing it and a review cycle that isn’t just “annually” on paper. Second, your controls need to be auditable. That doesn’t mean preparing for a formal audit; it means that if someone asks you in six months whether a specific control was operating, you have evidence, not a recollection. Third, governance documentation should be written for the people who have to operate under it, not for the person who drafted it. If your acceptable use policy for AI tools requires an IT manager to decode it, it’s not operating as a control.
The EU AI Act’s requirements around transparency and human oversight are a useful forcing function here even if your organization isn’t directly subject to them. They describe what a defensible governance posture looks like for AI that touches decision-making processes — which covers more of your environment than you probably think.
Phase 4: Prove
The Prove phase is what separates governance programs that exist from governance programs that work. This is the continuous demonstration layer: the evidence exports, posture reporting, and audit-readiness documentation that let you show — not just claim — that your governance program is operating.
Here’s a useful test for whether your organization is actually in the Prove phase: if an auditor, a customer, or your cyber insurance carrier asked you to demonstrate your AI governance posture in 48 hours, what would you hand them? Not what you would start building — what you would hand them today. For most SMBs, the honest answer is somewhere between very little and nothing organized.
Prove doesn’t mean you’re waiting for an audit to happen. It means your governance program is continuously generating the evidence that makes an audit tractable. Incident logs with resolution documentation. Risk assessments with version history. Policy documents with acknowledged owner and review dates. Control testing records. These artifacts exist as a byproduct of operating the first three phases correctly — the Prove phase is about surfacing and packaging them.
This is also where the full RAGP cycle becomes visible. Incidents you log in React feed into risk signals you track in Assess. Control gaps you identify in Assess become governance priorities in Govern. Evidence you compile in Prove reveals gaps that restart the React cycle. A governance program isn’t a project with an end date; it’s a continuous operational loop.
What This Looks Like for a Real SMB IT Environment
Take a company with 120 employees running five or six AI-assisted tools across sales, marketing, and operations. No dedicated compliance function, one IT manager, and a cyber insurance renewal coming up that’s asking new questions about AI risk. That’s a real scenario, and it’s the environment RAGP was built for.
The starting point isn’t a policy library. It’s a log. Stand up a structured way to capture AI-related incidents and exposures, get your team in the habit of logging instead of normalizing, and spend 30 days building that record. Then use that record to scope your first risk assessments — the two or three tools generating the most exposure, not every tool in the environment simultaneously. Build your governance posture around what those assessments surface. Then build the evidence layer that makes what you’ve built demonstrable.
Done in that order, a small IT team can have a credible, audit-ready AI governance program without a consultant living on-site or an enterprise software budget. Done out of order, the same team can spend months writing policies they can’t operationalize and assembling documentation that doesn’t reflect how their environment actually works.
The Framework Underneath Everything We Build
Every product and engagement at InfoDefenders maps to a RAGP phase because the sequence isn’t a product decision — it’s an operational reality. AI Incident Log handles React. AI Risk Assessor handles Assess. AI Governance Manager handles Govern. The full SUITE handles Prove across the whole organization.
If you’re trying to figure out where to start, that’s usually the clearest signal: you start where your governance program actually is, not where you wish it were. For most organizations, that’s React — which means your first job is building a disciplined log of what’s already happening in your environment.
That’s not glamorous work. But it’s the foundation everything else depends on.
