Most enterprises are running multiple AI models without a clear plan for who decides which one handles what. Jeanine L. Charlton, Merchants Fleet chief technology officer, explains how a different kind of governance council–one that fast-tracks low-risk tools, slows down for high-stakes ones, and doesn’t re-review what's already approved–answers that question without slowing everything down.
Most governance councils are rooms where ideas go to get approved or rejected. That's the default model at most companies, and it's exactly what slows AI adoption down.
We started down that road ourselves. Merchants Fleet began exploring AI formally in 2023, building out acceptable-use guidance, security review, and data protection the way most companies do. It didn't take long to hit the ceiling on that approach. Policy alone doesn't tell a team which platform fits which job, and every idea, whether low-risk or entirely new, had to fight through the same review process.
So, we built something different: our Artificial Intelligence Readiness Council.
This council runs on three principles: enable rather than gatekeep, register rather than repeatedly re-review, and apply scrutiny in proportion to risk. The discipline is applying those principles the same way on every use case, rather than relitigating them each time. The headline at Merchants Fleet isn't that we run more than one AI model. More and more companies do. Rather, it's how the discipline provided by our readiness council lets us decide which AI tools are ready to use and where, quickly and responsibly, without governance becoming an obstacle.
Two Use Cases, One Approach
Those three principles aren't slogans. Here's what they look like on two real use cases.
Microsoft Copilot is our standard enterprise productivity platform, and we rolled it out quickly because it operates within our established enterprise environment and security framework. We didn't need to re-evaluate the platform itself for every use case. We could spend our energy identifying the right users, clarifying acceptable-use boundaries, running training, and reinforcing human accountability. That's what enabling looks like in practice.
Contrast that with our evaluation of AI-enabled listening and interaction-capture tools—the kind that record and summarize conversations. That capability raised questions our Copilot rollout never had to answer about consent, multi-channel data capture, summary accuracy, integration, contracting, and how the resulting information gets used downstream. We ran it through defined requirements, weighted scoring, live demonstrations, reference checks, and clear go/no-go criteria before it went anywhere near production.
The difference between those two paths came down to the nature of the data involved, the consequences of an inaccurate output, and how directly the capability could affect employees, clients, or business decisions. That's what applying risk-appropriate scrutiny actually means: oversight rightsized to what's actually at stake.
The third principle, registering rather than repeatedly re-reviewing, is what keeps governance from becoming friction on every routine case. Our AI inventory gives our AI Readiness Council a persistent record of each tool, including the business owner, the intended use, the data involved, and the approved boundaries. Once a platform and its approved-use parameters are established, we don't force every team pursuing a routine, in-bounds use case to restart that same review. The question shifts from "May I use AI?" to "Does this sit inside an already-approved pattern, or does it introduce something genuinely new?"
A Successful Pilot Is Not a Green Light
The tension we run into most often is speed to impact versus data and operational readiness. People assume technical feasibility means production readiness. It doesn't. An AI use case can be compelling and technically feasible and still not be ready. If the underlying data is fragmented or there's no accountable business owner, moving fast automates an unstable process faster.
Our answer was to separate those questions: "Can the technology create value?" and "Is the organization ready to run it in production?" We'll run a pilot to answer the first question. But we don't treat a successful experiment as evidence that we've answered the second. Before we scale anything, we need trusted data, integration into the actual workflow and system of record, an adoption plan, measurable outcomes, and a business owner accountable for the result. A pilot that works and a capability that's ready to scale are two different things, and conflating them is one of the more expensive mistakes I see other organizations make.
Why Policy Isn’t Enough
When we first started, we assumed policy alone would drive responsible adoption. We discovered that was necessary, but not sufficient.
People also needed practical clarity on which tools are approved, what they're allowed to do with them, where to bring a new idea, and how that idea gets decided. So, we expanded the AI Readiness Council into something broader than a policy review body. It now also covers strategic direction, portfolio visibility, tooling, and education. We also stopped treating communications and training as things that happen after governance is designed. They're part of the process from day one.
One thing we haven't done yet is outright retire a model or vendor in production. We're building portability and lifecycle review into the operating model now, before we need it, so a future change doesn't mean abandoning the underlying business capability along with the vendor. The discipline is knowing in advance what would justify a change: a material shift in security, performance, cost, or a demonstrably better option. That's different from chasing every new release.
Designing for Yes
For any technology leader looking to stand up something like the AI Readiness Council, the first step is to establish business ownership and decision rights before designing any process. Technology can own standards, architecture, security, and integration. It cannot own the business outcome, the workflow change, or the value commitment. Governance has to connect those pieces.
A common mistake is designing the council primarily as an approval body. If every interaction with an AI council starts from "no" or makes a team defend its use case before it can proceed, people will either stop innovating or start working around the system. The council's job is to build a safe path to “yes.”
AI governance helps the organization make more good decisions, faster, without losing accountability for any of them. Controlling technology was never really the point.
