There is a particular kind of overcorrection that shows up almost every time a mid-sized company decides to take a new capability, AI, usually, but not only AI. The instinct isn’t to under-invest, it is to over-build. Before a single use case has run, there’s already a conversation about which platform to license, whether to stand up a lab, and who should sit on the committee.
I think that instinct is understandable, and mostly wrong. It comes from a reasonable place: nobody wants to look back and admit they moved without structure. But structure sized for a scale the company doesn’t have yet isn’t caution, it’s a more expensive way of doing nothing. A platform nobody has tested against a real problem, a lab with no pilot running, a committee reviewing a model that doesn’t exist: none of that reduces risk. It mostly delays the point at which the real risk, running nothing at all, becomes visible.
The alternative isn’t "skip the structure." It’s sizing it to what’s there. Three questions that come up constantly in this conversation, what to build versus buy, how to run a first AI pilot, how to manage the first internal model, sound like separate problems. In practice, they share the same answer.
The Platform You Don’t Need Yet
When a mid-sized company hits a real operational gap, a process that doesn’t fit any of its existing systems, the reflex is often to look for a platform that covers it, plus a dozen adjacent capabilities the company doesn’t currently need. It looks efficient: buy once, cover more ground. In practice it usually means months of implementation for a system sized for a company much bigger than the one buying it, most of that time spent configuring, or working around, capabilities nobody asked for.
The more useful question is narrower: what specific piece is missing? Sometimes that’s not a platform at all, it’s a small, purpose-built component, designed to a clear specification for the one process that doesn’t fit anywhere else. It costs less, it ships faster, and it doesn’t leave the company maintaining a dozen modules it never uses. The platform conversation can happen later, once there’s evidence of what needs to be scaled.
A Pilot Needs an Owner, not a Lab
The equivalent overcorrection with AI specifically is the standing "innovation lab", a function, a budget line, sometimes a hire, built before a single pilot has produced a result worth acting on. For most mid-sized companies, that’s the wrong order. A lab implies a portfolio of experiments running in parallel, with people whose job is exclusively to manage that portfolio. Most companies at this stage don’t have, and don’t need, that volume of experimentation yet.
What they need are two or three well-chosen pilots, narrow enough to finish, tied to a real process, with one person clearly accountable for running them and reporting what happened. Not a lab. An owner. If a standing innovation function is ever justified, it gets built once there’s a track record of pilots that resolved into something real, not in anticipation of one.
"Well-chosen" is doing real work in that sentence. It means a pilot with a clear owner, a defined end date, and a specific question it is meant to answer, not an open-ended exploration of what AI could theoretically do for the business. A pilot that never ends isn’t a pilot. It’s an unstaffed lab with a different name.
Your First Model Needs an Owner, not a committee
The same pattern shows up again once a company builds its first internal model, a credit score, a demand forecast, a fraud flag. The instinct is to reach for the governance apparatus built for institutions running dozens of models across multiple business lines: a model risk committee, a formal validation function, a policy document covering scenarios the company hasn’t encountered yet.
A single model doesn’t need a committee. It needs someone who owns it, who knows what data feeds it, who’s accountable when its performance drifts, and who reviews it on a set cadence, not only when something visibly breaks. That’s a fraction of what a full model risk framework requires, and for a first model, it covers the risk that matters: nobody accountable, and nobody watching.
Sizing the Structure to What Exists
The common thread across all three is worth naming directly: premature structure is its own way of avoiding the real risk, which is running nothing. A platform, a lab, and a committee all sound like diligence. For a company at this stage, what they often are is a reason to keep planning instead of shipping.
My recommendation is to size the structure to what exists today: the specific piece that’s missing, not the platform; the owner of a pilot, not the lab; the owner of a model, not the committee. Scale the structure once there’s a track record that justifies it, not ahead of one.
None of this is an argument against eventually building the platform, the lab, or the committee. Companies that grow into needing all three usually do end up with them. The argument is about sequence: structure that responds to something real is worth the investment. Structure built in anticipation of a problem the company hasn’t had yet is mostly a way of feeling prepared without becoming it.
Rhisco Group designs and builds the specific technology component a critical process is missing (On Demand Development), helps clients run their own AI pilots with the right governance built in (Innovation & AI Lab), and creates the risk models and control artifacts a first model needs to be owned properly (Risk, Models & AI Governance).
This article was co-created with the assistance of artificial intelligence under strict supervision, editing, and verification of our team.