Fractional Chief AI Officer: the job, and when you need one

A fractional Chief AI Officer, or fractional CAIO, owns your company's AI decisions without being on your payroll full time. Not a strategy deck and not a vendor introduction: a named person who decides what you build, what you buy, what you leave alone and who owns each one afterwards, and who is still there in month six when the first answer turns out to be wrong. This page covers the job, the first thirty days, how you will know it works, what it costs, and the cases where hiring one is the wrong move.

What does a fractional Chief AI Officer actually do?

The honest version of this job is unglamorous, and it is mostly saying no. In a company that has decided AI matters there is never a shortage of things to try. There are vendor demos that looked impressive, a proof of concept somebody's nephew built, three teams each quietly paying for a different model provider, and a board that wants to hear the word on the next call. What is missing is a person whose job is to decide which of those becomes real, in what order, and who is accountable when it ships.

That comes down to four decisions, made over and over.

• What to build. The things that are specific to how your business actually works, where there is no product to buy because the problem only exists inside your company. This list is always shorter than anyone expects.
• What to buy. Everything that is a commodity. Transcription, general document extraction, the model itself. Building these is a way of spending a year to arrive where a subscription would have put you in an afternoon.
• What to leave alone. The largest category and the one nobody writes on a slide. Processes that are already fine, problems that are organizational rather than technical, and the genuinely good ideas that are not this year's.
• Who owns it afterwards. The decision that determines whether any of the others survive. A system nobody inside the company is accountable for goes stale the week the outside help leaves.

Underneath those, the same four questions come up in every company I have worked inside. Where does your data actually live, and what leaves the building when a model touches it. What does a wrong answer cost, and who finds out. What are you already paying for that you have forgotten about. And which of your people can look at the output and say it is wrong, because that person is worth more to an AI program than any tool you will buy.

Fractional, full-time, or hand it to your CTO?

Most companies arrive at this question already shopping for fractional CTO services, because that is the vocabulary they know. Three ways to fill the seat, and companies pick wrong for predictable reasons. The full-time hire is what an anxious board asks for, and it is the most expensive way to discover you did not need one. Handing it to the CTO is what a tight budget asks for, and it is free right until it costs you the rest of the engineering roadmap.

The fourth option, which most companies try first, is a consultancy engagement that produces a strategy document. The ones I have read were usually correct and almost never actionable, because nobody who wrote them was still there when the first integration turned out to be harder than the slide said.

When should you hire a fractional CAIO?

Not by company size, and not by revenue. The signals are symptoms, and they are specific.

• You have more than one pilot and none of them are in production. The most common one by far. Pilots are easy to start and have no owner, so they accumulate. The diagnosis is almost never the model.
• Two teams are solving the same problem with different tools and neither knows about the other.
• Somebody is about to sign a significant contract and nobody in the room can say what happens to your data under it, or what it would cost to leave in two years.
• Your engineers are asking for a decision you cannot make, because it is a business decision wearing technical clothes. Whether a wrong answer is acceptable, and how often, is not an engineering question.
• The board has asked for an AI strategy and the honest answer is that three quarters of what you would put on the slide should not be built.

There is one more, and it is the one nobody writes a page for. Your CTO has just been handed AI on top of everything else, and what they need is not an overseer but a peer who has shipped this before and can be argued with. That is a perfectly good reason to bring someone in, and it is a different engagement from the one a nervous board buys.

If none of those are true, you probably do not need this role yet, and I will say so.

The first thirty days

Most of the market sells this month as an AI readiness assessment. It is a fair name for it, as long as what comes out the other end is a decision with somebody's name against it rather than a maturity score. Every engagement I run starts the same way, whether I am deciding or building: the things that are the owner's to decide get written down first, so they are never argued about again. On one engagement that document had a heading that meant, in so many words, do not relitigate. Under it sat the things nobody would have called engineering questions, all of which would have been fought over in month three: which data source was in and which was out, that nobody would ever be phoned or texted, which customers came first, which channels were allowed and at what budget.

After that the shape changes. A typical month is a half day of review, a half day with the engineers on whatever is genuinely hard, and the rest on the decision currently live. The standing rule is the one I use when building too: something real every week that a person outside the team can look at. Progress nobody can inspect does not count.

Who actually builds it?

Read the other pages selling this role and you will notice the deliverable is always a document. A roadmap, a governance charter, a scorecard, a vendor shortlist. Two of them have a question in their own FAQ that gives it away: does the fractional CAIO actually build the systems, and will this person lead the team day to day. Those questions exist because the answer is no.

That gap is not an oversight, it is the business model, and it has a cost you pay later. Advice written by someone who will not implement it is optimistic in a specific direction. Integration is always harder than the slide said, the data is always dirtier, and the person who wrote the recommendation is not there when that turns out to be true.

I do both. I spend most of my time inside companies writing production code, which is what lets me tell you honestly what the build option really costs, in weeks and in the maintenance nobody budgets for. It cuts both ways. Most people who only advise cannot build, so their recommendation drifts toward buying. Most people who only build cannot afford to say no to a build, so theirs drifts toward building. Being able to do either is what makes it possible to say that the answer here is a subscription and a Tuesday afternoon.

And when the answer is build, I can go and do it. Some engagements are designed that way: a month of deciding, then a build inside the company with its real data, then a handover written as a contract. Keeping both halves in one pair of hands closes the gap where a strategy document gets handed to a team that was not in the room when the tradeoffs were made.

The record behind that is public rather than asserted. In the twelve months to 14 September 2026 I recorded 8,202 contributions across unrelated domains: a retail operating platform, a trading system, on-chain settlement, security tooling, a video product, robotics and inference research. The bio page lists them and the homepage pulls the number live. I led the architecture of an operating platform for nineteen months with a team of seven across more than forty-five domain modules, where the call that mattered most was separating the transactional path from the analytics path so reporting could never slow the tills. Nobody would file that under AI. It is exactly the decision that looks obvious in hindsight and costs a fortune when it is made late.

How will you know the thing actually works?

This is the question underneath all the governance language, and almost nobody selling this role answers it. Not "is the strategy sound" but: when the model is in front of a customer, how do you know it has not started being wrong, and who finds out first.

The answer is that a system without a way to measure its own output is a prototype, whatever it is running in. Before anything goes near a customer there has to be a set of examples with known right answers, a score, and a threshold below which the thing does not ship. That suite is what lets you change a model provider later without holding your breath, and standing one up is usually days rather than weeks. It is the cheapest insurance in the entire program and it is the first thing cut when nobody senior is watching.

I hold my own work to that. On a workshop I ran, an 8-billion-parameter model went from 30 percent to 95 percent on a scored task after an optimizer rewrote its prompt from the model's own recorded failures, while a model thirty times its size scored 45 percent on the hand-written prompt. That result only exists because there was a score in the first place. The deck and the runnable notebook are published, so you can check the claim rather than take it.

The same habit applies to the hardware question, which is where a great deal of money gets spent on assumptions. I put a 26-billion-parameter model on a desktop with no graphics card and published every number, including the dead ends. When I tell you a small model on your own hardware will do a job, that is not a position I hold. It is something I measured, with the workings in public.

What does a fractional Chief AI Officer cost?

The published rates for this role run from roughly $4,000 to $80,000 a month, which is a twenty-fold spread with very little explanation attached to it. So the useful thing to write down is not a number, it is what moves it.

• How much of the month you need. Two days a month to own a small set of decisions is a different job from two days a week embedded with your teams.
• Whether it includes building. Deciding is priced as a retainer. A build inside your company is a different arrangement, and it should be quoted as one.
• How many teams the decisions cover. One product with one engineering team is straightforward. Four business units that each bought their own tool is a different scope, and most of the extra work is organizational rather than technical.

I price it as a monthly retainer for an agreed number of days, not by the hour and not as a share of what gets built, and I quote a fixed figure after the first conversation once I know which of those three you actually need. There is no ladder of packages on this page, because I have never seen one survive contact with a real company.

The comparison that matters is not against a day rate anyway. It is against two costs you are already carrying. The first is a full-time executive hire: published salary ranges for a Chief AI Officer sit somewhere between $250,000 and $400,000 before equity, and that figure does not include the months of recruiting before anybody does any work. The second is quieter and usually larger: pilots that never ship, duplicate subscriptions across teams, and a contract signed on terms nobody read. Stopping two of those tends to cover the arrangement by itself.

When you should not hire one

Four cases where this is the wrong call, and I would rather write them here than discover them with you in month two.

• Your problem is not an AI problem. A large share of what arrives described as AI work is a reporting problem, a data quality problem, or two departments that do not talk to each other. Putting a model on top of any of those makes the underlying fault harder to see, not easier.
• Nobody inside will own the outcome. If there is no person who will be accountable after I leave, the engagement produces a document and nothing else. That wastes your money and my time.
• You want a name on a slide. If the goal is to tell a board or an investor that you have AI leadership, hire someone cheaper. I will not be useful and the arrangement will end awkwardly.
• You already have the person. If someone in your company has shipped machine learning into production and has the authority to make these calls, give them the room and the budget instead. The best outcome of an early conversation with me is sometimes that you promote somebody.

The same logic applies to the technology. On more than one engagement the right recommendation was that a piece of work did not need a model at all. Rules a person can read, and argue with, beat a model on any problem where the answer is genuinely deterministic. Saying that out loud is part of the job.

What you own at the end

The deliverable is the decision record, and it is written so that it works without me. Each entry carries the decision, the reasoning that produced it, a named owner, and the date it gets read against a number chosen in advance. That last part is what stops an AI program from drifting. The question is never "is this going well", it is "it is week twelve, here is the number we agreed to read, and the options we named in advance were double down, change direction, or stop honestly."

If the engagement included building, you also get the system itself, inside the tools your staff already use, and a handover written as a contract: what shipped, what was deliberately left out and why, the activation order with your own steps named, and an acceptance list you can check without me.

Either way, the test of this role is what happens after it ends. If your team cannot make the next decision without calling me, I did the job badly.

Common questions