What the role actually owns
The title varies: Chief AI Officer, Head of AI, or simply the CTO with a new line in the job description. The accountability is the same. You own the answer to four questions the board will ask: What AI are we using? Is it safe and compliant? What has it delivered? What should we do next?
You do not own every AI project. You own the conditions under which projects can succeed: data access, a secure path to models, evaluation discipline, governance and a credible roadmap. Teams that confuse the two end up either bottlenecking everything or sponsoring a dozen pilots that never ship.
The plan below assumes a mid-sized organisation with some experimentation already happening, some shadow usage of public tools, and no clear picture of either. If that is you, the first month is mostly listening.
The 90-day plan at a glance
Days 1–30: find out what is true
Resist announcing anything. Spend the first month building an accurate picture and putting the minimum safe path in place.
Inventory
List every AI system in use or in flight: official projects, vendor features switched on inside SaaS products, and the public tools people use quietly. For each, record the owner, the purpose, the data it touches and who it affects. You will find more than anyone expected. This inventory is also the first step of EU AI Act readiness, so do it once, properly.
Risk triage
Sort the inventory by exposure: customer data in public tools, decisions about people, anything customer-facing without review. Stop the dangerous ones, quietly and with an alternative in hand. Do not stop the harmless ones; shadow usage is demand data.
Listening
Talk to the heads of the functions that generate the most repetitive knowledge work: support, finance, sales operations, legal, HR. Ask what takes their teams' time, not what they think AI could do. The best first project is usually in this list and not on anyone's innovation slide.
Day 30 output
A one-page inventory and risk summary, a shortlist of three candidate first projects with the business owner named, and a sanctioned way for staff to use a capable model safely. That last item matters: an approved tool with sensible data rules removes most of the shadow usage overnight.
Days 15–50: guard-rails before scale
Guard-rails are the policies and technical controls that make it safe to say yes. Put them in before the first project needs them, and keep them light enough that people use the sanctioned path rather than route around it.
- An acceptable-use policy that says which data may go to which tools, in one page.
- A model gateway or approved provider accounts with logging, so usage and cost are visible.
- A review step for anything customer-facing or involving decisions about people.
- Security requirements for LLM applications, which you can take from our LLM security checklist.
- A named owner for AI governance, even if it is you for now.
If the organisation is regulated, or operates in the EU, this is the moment to map obligations. Our AI governance service sets up exactly this layer, typically in a few weeks.
Days 31–60: one production win
Pick one of the three candidates and ship it to real users within thirty days. The choice matters more than the execution. The right first project has a clear owner who wants it, a measurable baseline, data you can already access, and a failure mode that is embarrassing rather than dangerous. A support knowledge assistant over existing documentation, an internal copilot for a specific team or a document-processing step in finance all qualify. A customer-facing agent with write access does not.
Scope it ruthlessly. One user group, one data source, one job. Build an evaluation set in week one, as described in evaluating LLM outputs, so "it works" has a number. Measure the baseline before launch, or you will never be able to show the improvement. The full phase structure is in our AI project roadmap.
The win is not the demo. The win is a system in production with a measured result that the business owner will stand behind in front of the board. Everything that went wrong on the way, from data access to approvals to security sign-off, is your to-do list for the platform.
Days 61–90: platform, evaluation, team
With one system live, you know what the organisation actually needs to ship the next five. Build that, not a generic "AI platform".
Platform. Typically: the model gateway from the guard-rails phase, a shared retrieval service if the first project used RAG, an evaluation harness, logging and cost attribution, and a template for the security review. See LLMOps and monitoring for what this looks like in practice.
Evaluation discipline. Make the evaluation set a deliverable of every project, reviewed at every gate. It is the single practice that separates teams that improve from teams that argue.
Team and vendors. Decide what you will build, what you will buy and where you need senior help, using the framework in build vs buy AI. Most organisations need one or two experienced AI engineers and a lot of upskilled existing developers, not a new department.
Reporting to the board
Report at days 30, 60 and 90, briefly, in the same format each time so progress is visible. Avoid vision decks; the board has seen them.
| Day | What the board hears | What you ask for |
|---|---|---|
| 30 | Inventory, risk profile, what was stopped and why, the three candidates | Endorsement of the acceptable-use policy and the first project |
| 60 | Guard-rails in place, first system in production, early numbers against baseline | Nothing; show that promises were kept |
| 90 | Measured result, platform status, compliance position, costed two-quarter plan | Budget and headcount for the plan, and a governance mandate |
Attach a number to the result using the method in measuring AI ROI. A modest, honest figure with a baseline behind it earns more trust than a large projected one.
Hire, upskill or bring in a fractional CTO
| Option | Strength | Risk | Fits when |
|---|---|---|---|
| Hire a senior AI lead | Permanent capability and ownership | Slow to find; expensive if the role is not yet defined | AI is central to the product and the budget is committed |
| Upskill existing engineers | They know your systems and data | Nobody has shipped an LLM system before; slow first project | Strong engineering culture, paired with outside senior help |
| Fractional AI CTO | Senior judgement from day one, no long hire | Must transfer knowledge, not create dependence | The first year, while the role and the roadmap take shape |
Most organisations combine the last two. Our fractional AI CTO engagement is built around this 90-day plan and our engagement models explain how it is scoped.
Traps
Announcing a strategy in week two. Before the inventory, any strategy is fiction. Listen first.
Many pilots, no production. Pilots are cheap and unthreatening, which is why nothing ships. Pick one and push it live.
Governance as a gate, not a path. If the sanctioned route is slower than the shadow route, people take the shadow route.
Choosing the first project for impressiveness. The best first project is boring, measurable and wanted by its owner.
No baseline. Without a before, there is no after, and the board will notice.
Key takeaways
- You own the conditions for success, not every project.
- Spend the first month on inventory, risk and listening; announce nothing.
- Put light guard-rails and a sanctioned model path in before the first project needs them.
- Ship one boring, measurable system to production by day 60.
- Build the platform from what the first project needed, not from a reference architecture.
- Report in the same format at days 30, 60 and 90, with a baseline and a number.
- Combine upskilling with senior help for the first year.
Related services
Fractional AI CTO
Senior AI leadership on a part-time basis, running this 90-day plan with your team and handing it over.
ExploreAI strategy & consulting
Use-case selection, roadmap and ROI model, built from your inventory rather than a template.
ExploreAI implementation
From pilot to production: the first win, delivered with evaluation and security built in.
Explore