An AI roadmap for CIOs: your first production project in 90 days

A first AI production project is a system that solves one business problem measurably, is used by real users every day and can be operated by IT. It is not a demo, and it is certainly not a pilot that drags on without an end date. With the right scope, you can reach that goal in 90 days.

From 2012 to 2021 I was Head of IT at Civil Mağazacılık, a Turkish retail chain; in 2021 I founded CX Teknoloji, and in 2022 I served as IT Manager at HD Holding. So I have sat both on the side that approves IT projects and on the side that offers AI solutions. This article is not a case story; it turns the principles I took from both sides into a workable plan. I described the broader journey in the article on moving from enterprise IT to AI entrepreneurship.

Why 90 days?

Ninety days is long enough to put a narrowly scoped job into production and short enough to keep the sponsor’s attention. It matches a quarter, so it lines up with business units’ reporting cycle. Most importantly, it forces scope discipline: if the scope does not fit into 90 days, the problem is the scope, not the timeline.

Step 1: How do you choose the use case?

Score the candidate list separately for value and feasibility. Each criterion can be scored from 1 to 5:

Axis	Criterion	Question to ask
Value	Business impact	If it works, which business metric changes, and by how much?
Value	Frequency	How often is this task or decision repeated?
Value	Ownership	Is there a business manager who wants the result and will measure it?
Feasibility	Data	Does the data exist, is it accessible, is its quality good enough?
Feasibility	Integration	Which system and which screen will the result land in?
Feasibility	Error tolerance	What does a model error cost, and can a person correct it?
Feasibility	Regulation	Is there a high risk under data protection law or the EU AI Act?

The scores place each candidate on a two-axis matrix:

	High feasibility	Low feasibility
High value	First project candidate	Strategic investment: data and infrastructure first
Low value	Quick experiment; weak as a first project	Drop it

The scoring below is purely illustrative; do it with the business owners in your own company:

Candidate use case	Value	Feasibility	Note
IT service desk ticket classification and draft solutions	Medium	High	Data already in the ticketing system; errors are reversible
Document assistant for internal procedures	Medium–high	High	Document ownership is a must
People counting and queue alerts in stores	High	Medium–high	Uses existing cameras; privacy by design from day one
Matching supplier invoices to purchase orders	High	Medium	ERP integration is decisive
Candidate screening in recruitment	Variable	Low	High risk under the EU AI Act; not a first project

If you choose the document assistant, see the enterprise RAG article for the architecture.

Step 2: Five questions on data readiness

1. Where is the data and who owns it? Data without an owner stops projects; name an owner for every data source in week one.
2. Is the definition clear? Does “active customer” or “completed order” mean the same thing to every unit? Agree on definitions before building a model.
3. Is the quality good enough? Measure missing fields, duplicate records and late-arriving data.
4. Is there a legal basis and access? Is personal data really needed, can it be anonymised, and on what legal basis is it processed?
5. How will data flow in production? A one-off export can train a model but cannot run a system; design a data flow that runs continuously.

The second question matters most to me. The Nebim V3 data warehouse and business intelligence work at Civil ran on roughly 4.5 TB of data; even at that scale, in my experience most arguments come from definitions, not technology.

Step 3: Build, buy or partner?

As the founder of a product company, I should say up front that I am not neutral here. Still, these are the criteria I use:

Criterion	Build	Buy (ready product)	Partner (specialist firm)
When?	The capability will be a competitive advantage and you have a team	Standard problem, mature products on the market	Domain expertise needed, data and process specific to you
Speed	Slow	Fast	Medium to fast
Data control	Full	Depends on the vendor	Set by contract
Long-term cost	Internal team and maintenance	Licence or usage fees	Project and maintenance fees
Main risk	Skills and time	Lock-in, limited customisation	No real knowledge transfer

Whichever route you take, the contract should state who owns the data and the trained model, how data is handed back on exit, service levels, data-processor obligations under data protection law (KVKK in Turkey) and, if you sell into the EU, EU AI Act documentation.

Step 4: A 0–30, 30–60, 60–90 day plan

Period	Goal	Main work	Decision gate
Days 0–30	Fix the problem and the baseline	Business owner and product owner appointed; baseline measured; data access opened; preliminary data protection and EU AI Act classification; build-or-buy decision; evaluation set prepared	Is the data accessible and the baseline measured? If not, stop.
Days 30–60	A first version on real data	Integration with one system; measurement on the evaluation set; security and permission review; shadow mode with a small user group	Is quality approaching the target, and are users using it?
Days 60–90	Go live and decide	Monitoring and alerts; runbook; onboarding into the service desk and incident management; training; widening from the pilot group; comparison with the baseline	Scale, improve or stop

In shadow mode the system produces its suggestion but a person still decides; you compare the suggestion with the actual decision. This stage measures quality and lets users build trust in the system. A decision to stop is also a successful outcome: you learned in 90 days and protected the budget.

Success metrics

Layer	Metric	Example
Business outcome	Time, cost, errors, revenue	Ticket resolution time, queue waiting time
Usage	Active users, suggestion acceptance rate	What share of suggestions is accepted unchanged?
Model quality	Accuracy, precision, recall, faithfulness	Accuracy measured on the evaluation set
Operations	Availability, latency, unit cost	Cost per request, response time

Model accuracy is not a business metric. In our people counting product, for example, field accuracy of up to 96.2% is a model metric; the retailer’s real question is how much that number improves staff planning. Agree on one primary metric with the business owner and take the baseline in the first 30 days.

Governance: connecting to COBIT and ITIL

Do not build a separate bureaucracy for AI; add AI-specific controls to your existing IT governance. As someone certified in COBIT 5 and ITIL, this is the mapping I recommend:

AI need	COBIT 2019 objective	ITIL 4 practice
Policy, roles, decision rights	EDM01 – Ensured governance framework setting and maintenance	—
Use-case portfolio and prioritisation	APO05 – Managed portfolio	Portfolio management
Bias, error and regulatory risk	APO12 – Managed risk	Risk management
Data ownership and quality	APO14 – Managed data	—
User adoption	BAI05 – Managed organizational change	Organizational change management
Project delivery	BAI11 – Managed projects	Project management
Model and prompt changes, live operation	—	Change enablement, incident management, monitoring and event management, service level management

For AI-specific risk language, NIST’s AI Risk Management Framework, released on 26 January 2023 for voluntary use (four functions: Govern, Map, Measure, Manage), and the AI management system standard ISO/IEC 42001:2023 are good references. If you offer products or services in the EU, tie the checklist in the EU AI Act guide to the same inventory.

Change management

The first question users ask is “will this system take my job?” The design should answer it: in the first version the system suggests and a person decides. Bring key users into the project from day one, prioritise features that solve their problems, and explain in training what the system does not do.

We saw at Civil that adoption depends more on need than on technology. We started trialling contactless QR-code payment with Nebim V3 fastPay in pilot stores in 2019. According to financial institutions’ analyses, one in ten sales was contactless that year; during the pandemic it became one in two, and we quickly rolled the integration out to more than 400 payment points across all stores. The technology was the same; what changed was the user’s need. In an AI project, do not expect adoption until users can see it solves a problem they face every day.

Budget lines

Line	Content	Often missed
Model/API or licence	Token usage, per-user licences	Cost that grows linearly with usage
Infrastructure	GPU servers, cloud, storage	Separate test and production environments
Data preparation	Cleaning, labelling, definition work	Often the largest work item
Integration	Connections to ERP, CRM and other systems	Time of the source-system team
Security and compliance	Data protection, EU AI Act, penetration testing	Time needed for legal review
People	Product owner, data engineer, business unit time	The cost of time taken from the business
Change and training	Training, communication, key users	Usually budgeted at zero
Operations	Monitoring, model updates, support	The years after go-live

My advice: plan the first 90 days as a project budget and what follows as a separate operating budget, and set a “stop threshold” from the start.

Typical mistakes

• Starting with technology: “We need a large language model too” is not a problem statement.
• Skipping the baseline: you will not be able to prove success later.
• Running the pilot in a demo environment without real data and real users.
• Starting an IT project that has no business owner.
• Opening many pilots at once and taking none to production.
• Leaving legal and security to the last week.
• Leaving the system without an owner after go-live: as data changes, model quality degrades over time, so monitoring and retraining need a named owner from the start.

Checklist

• A business owner and a product owner are appointed.
• The use case was chosen with the value × feasibility matrix.
• The baseline is measured; one primary metric is agreed.
• Data owner, definitions and legal basis are clear.
• The build-buy-partner decision and contract terms are written down.
• The day-30, day-60 and day-90 decision gates are in the calendar.
• Governance is tied to existing COBIT and ITIL processes.
• An operating budget and a stop threshold are defined.