Most small and midsize organizations are already using AI. Not by decision — by accumulation. Someone in marketing subscribed to a writing tool, someone in support started summarizing tickets, someone in finance is pasting figures into a chatbot. It works well enough that it spreads, and nobody has been asked to look at the whole picture.
The Virtual CIO’s job is to turn that into something deliberate. Our Virtual CIO guide covers why this landed on the technology leadership desk. This is the practical sequence: what actually happens, in what order, and what decision comes out of each step.
Where an advisor actually adds value
It is worth being precise, because the common assumption is wrong. The value is not in knowing which model is best — that changes every few months, and vendors will tell you at length. It is in the four things that do not change:
- Deciding which problems are worth solving this way at all.
- Establishing whether the organization can actually support the solution.
- Deciding who is accountable for the output before it reaches anyone.
- Defining, in advance, what would count as it having worked.
An organization that gets those four right will do fine with an average platform. One that gets them wrong will not be rescued by an excellent one. Written down and agreed, those decisions are what an AI strategy should contain.
Step 1 — Start with processes, not tools
The first conversation should contain no product names. It is a review of how work actually gets done, looking for processes with a particular profile: high volume, repetitive, largely text- or document-based, and tolerant of a review step before the output matters.
In a typical smaller organization the candidates are unglamorous and much the same across industries — responding to routine customer enquiries, extracting data from invoices or forms, drafting first versions of recurring documents, summarizing long threads, finding the right answer in scattered internal documentation.
What gets decided: a shortlist of three to five candidate processes, ranked by how much time they consume and how tolerable an error would be. Processes that are low-volume, highly variable, or carry a consequence nobody can review in time come off the list here — and saying so early is one of the more valuable things an advisor does.
Step 2 — Test each candidate against reality
A promising use case is a hypothesis. This step tries to falsify it, across three dimensions, before any money is committed.
Data
Nearly every disappointing AI result in a smaller organization is a data problem wearing a model problem’s clothes. The questions are basic and often uncomfortable: does the information this depends on exist in a system rather than in someone’s head, is it current, is it consistent, and is there one authoritative version? An assistant answering customer questions from documentation last reviewed three years ago will answer confidently and wrongly, and the confidence is the dangerous part.
Infrastructure
What the workload needs, what integration it requires with the systems that hold the data, and — the part most often skipped — what it costs to run once the pilot budget is gone. Usage-based pricing that is trivial for five users can be significant at eighty.
Security
What information the system would need access to, whether that access can be scoped narrowly, what the vendor does with the data, and whether any of it is subject to a regulatory or contractual obligation. A system that can see almost nothing is safe and not much use; one that can see everything is useful and very hard to defend. Where the line falls is a decision someone has to make on purpose.
What gets decided: which candidates survive, and what must be fixed first for the ones that do not. It is normal and correct for this step to conclude that the real project is cleaning up a document library, not deploying anything. Run at full depth across all eight dimensions, this step is what a readiness assessment covers.
Step 3 — Decide the governance before the pilot, not after
This is the step most often deferred, and deferring it is expensive. Governance is not a policy document; it is a small set of decisions about authority:
- Which tools are approved, and who approves a new one.
- What information may be put into them, and what may not.
- Who reviews output before it reaches a customer, a regulator, or a decision.
- Who is accountable when the output is wrong.
- What is recorded, so that in six months you can answer what was used, by whom, on what.
For a smaller organization this is genuinely a couple of pages, not a framework. What matters is that it exists before people are using the system, because retrofitting a rule onto an established habit is far harder than setting it at the start.
What gets decided: an acceptable-use position, a named owner for each approved tool, and a review step for any output that leaves the organization. The full set of controls, and what to leave out at this scale, is in governance for a smaller organization.
Step 4 — Choose a platform you could leave
Platform selection matters less than the previous three steps and gets most of the attention anyway. The criteria that hold up over time are unexciting: does it integrate with the systems you already run, what are the data-handling terms, what does it cost at realistic usage rather than pilot usage, and what would it take to move off it.
That last question is the one to press. Build processes around a vendor’s proprietary behaviour and you have bought a dependency, not a capability. The reasonable test is whether you could replace the underlying platform in a year without redesigning the work.
What gets decided: a platform, and an honest note of what switching would cost.
Step 5 — Run a pilot designed so it can be stopped
A pilot exists to produce evidence, which means it has to be capable of producing negative evidence. Two conditions make that possible: a fixed scope with a real end date, and a success criterion written down before it starts.
Pick one process, one team, and a defined period — six to twelve weeks is usually enough. Keep the manual path available. Measure the current state before switching anything on, because a great many pilots are judged against a baseline nobody actually recorded, which makes the result unarguable in both directions.
What gets decided: whether this works here. A pilot that ends with “people seemed to like it” has not decided anything.
Step 6 — Measure what you said you would measure
The measurement has to be agreed in advance, or it becomes an argument. Useful measures are concrete: time to complete a task, volume handled without escalation, error rate at review, cost per transaction including the platform fee.
Two adjustments are worth insisting on. Count the review time — output that needs heavy correction has moved effort rather than removed it. And count the running cost at full usage, not pilot usage.
What gets decided: scale, adjust, or stop. All three are legitimate outcomes, and an advisor who has never recommended the third is not giving you much.
Step 7 — Scale deliberately, or stop cleanly
Scaling introduces problems the pilot did not have: more users, broader data access, integration with systems that were out of scope, and training for people who were not volunteers. This is where the governance decided in step three earns its keep.
Stopping is equally a decision, and it should be done properly — cancel the subscription, revoke the access, and record why, so the same idea does not return in nine months without the evidence attached.
Three ways this goes wrong
The failure patterns are consistent enough to name, and all three are avoidable at the point they start.
The pilot that cannot fail. No baseline was recorded, no success criterion was agreed, and the people running it are the ones who proposed it. It concludes positively, scales, and the promised saving never appears in any budget line. The fix is the discipline in step five, and it costs nothing to apply.
The tool that spread before anyone looked. A department adopts something useful, it works, and by the time it reaches technology leadership forty people depend on it, sensitive information has been going into it for months, and the vendor terms have never been read. Withdrawing it now is disruptive, so it usually gets ratified rather than assessed. This is the case for deciding governance early: it is much easier to say what is approved than to un-approve something people rely on.
The data problem sold as a model problem. Results are poor, so the response is to try a different platform. The second platform performs about the same, because the constraint was never the model — it was documentation nobody had maintained. Considerable budget can be spent cycling through vendors before anyone tests that hypothesis, which step two exists to do first.
What this looks like on a calendar
For a typical smaller organization, steps one to three take a few weeks of elapsed time and a modest amount of anyone’s attention. Steps four and five run about a quarter. Step six is a fortnight of honest analysis. So from first conversation to a defensible decision on the first use case is roughly four to six months — slower than a vendor demo suggests, considerably faster than the eighteen months organizations lose to pilots that were never designed to conclude.
The second use case is faster, because the governance, the platform decision, and the measurement habit already exist. That compounding is most of the argument for doing the first one properly — and once there is more than one initiative in flight, sequencing them is a job of its own, covered in phasing the work into a roadmap.
When to bring in outside help
None of this requires an outside advisor in principle. It requires someone with the authority to decide across business, data, security, and budget, and the time to do it. Where that person exists internally, the sequence above is a checklist you can run yourself.
Where technology decisions are already being deferred for want of someone to own them, adding AI to the queue will not improve matters — and that is the situation a Virtual CIO engagement is for. Our wider view of how the advisory relationship is changing is in IT consulting in the era of AI, and the difference between retaining an advisor and commissioning a project is covered separately.
Two related capabilities are worth knowing about when the use case is more specific: AI-powered content management when the target is documentation, search, and institutional knowledge, and AI Solutions for custom models, data engineering, and automation.
Working out where AI fits in your organization? Schedule an AI & Technology Readiness Assessment — it works through steps one to three and produces a roadmap you keep.