How to start an AI project, in six steps: define the problem, assess your data, check whether AI is really necessary, write the success criteria up front, start with a small pilot and choose the right partner. Projects that break this order usually fail not for technical reasons but because they started with the wrong question. This guide from Intelligence AI, an enterprise AI company in Istanbul, is written to be useful whichever vendor you work with, in Türkiye or anywhere else.
The most common starting mistake in AI projects is framing the question as “what can we do with AI?”. That question produces a search whose answer keeps changing and never ends.
The right question is: which decision do you want to make faster, more accurately or more cheaply? Your answer automatically determines the project’s scope, success measure and budget.
A well-defined problem statement looks like this:
A poorly defined problem looks like this: “We want to use AI as part of our digital transformation.” That sentence is an intention, not a goal, and no project scope can be derived from an intention.
It is normal not to have mentioned technology at all at this step. If you have written the problem correctly, whether the solution is AI or something simpler will emerge by itself in the next steps.
AI runs on data. At this step you need to answer three questions.
Scattered data is normal; it may be in the ERP, in Excel files, in emails and sometimes only in someone’s head. What matters is whether the data exists at all; bringing it together is a solvable job.
The history needed depends on the problem. For work like document reading you need almost none of your own historical data. For demand forecasting or churn prediction, on the other hand, at least a year of data is usually required so that seasonal effects are visible.
The same customer recorded under three different spellings, optional fields left empty, mixed date formats: these exist in almost every company and can be fixed. But if the data is systematically wrong, for example a field that has been used for a different purpose for years, that needs to be noticed first.
What if you have no data? Postpone the AI project and start accumulating data first. That is not a failure; it is the correct order. Building a data collection infrastructure is far more valuable than trying to train a model on data that does not exist. At this stage a Business Intelligence infrastructure may be the right place to begin.
Skipping this step leads to unnecessary complexity and wasted budget. Not every automation need requires AI.
AI is probably unnecessary when:
AI is the right tool when:
If your need falls into the first group, an honest consultant will not sell you AI. Being able to run this check yourself also helps when choosing the right vendor.
Before the project starts, define in writing what the word “successful” means. When this is not done, the project never ends; it falls into a permanent “let’s improve it a bit more” loop.
A good success criterion is measurable, time-bound and compared against the current state:
One point to watch: define the false alarm rate as well. If you target only the detection rate, you end up with a system that flags everything as suspicious and that nobody trusts. The two measures must be defined together.
Also decide from the start who will measure the criterion and with which data. If the measurement itself becomes contested, the outcome will never be clear.
The most common reason enterprise AI projects fail is that the scope is set too wide at the beginning. When the target is a large system covering every process, the first working output appears months later, and by then the assumptions have turned out to be wrong.
How do you choose a pilot scope? A good pilot has three qualities:
A working prototype can usually be obtained within 2-4 weeks. The prototype should run on your real data and never write to the production system; it should only read and produce results. That way you see whether the approach works without taking any risk.
If the prototype does not meet expectations, stopping there is not a failure but a saving. The real loss is carrying on for months with a project that is clearly not going to work.
We write this section impartially; ask us these questions too.
Most AI projects do not collapse for technical reasons. The five real causes are these.
If the project started with “let’s do something with AI”, the scope grows a little wider at every meeting. It never ends because the finish line was never defined. Fix: a one-sentence problem definition and written success criteria.
At the planning stage the data is assumed to be clean; in practice it turns out not to be. That delays the project by weeks. Fix: look at real data during discovery, not sample files.
AI systems change business processes. If the person who will approve that change is not part of the project, a system that works technically goes unused in the organisation. Fix: the process owner and the decision-maker take an active part in the project.
If AI is expected never to make mistakes, to know every situation or to remove human judgement entirely, disappointment is inevitable. Fix: write down the target accuracy rate and the false alarm tolerance from the start.
The system is built, the vendor leaves the project, and six months later nobody can update it. Models age over time and data sources change. Fix: handover training, documentation and a maintenance plan written into the contract.
Start with the process, not the technology. Identify the repetitive job your team spends the most time on, or the point where mistakes happen most often. If you can write it in one sentence, your starting point is ready. If you are not sure which process is suitable, list a few candidates and compare them by volume, frequency of repetition and cost of error.
Yes, and that is the right approach anyway. In a staged plan, discovery comes first, then a prototype with limited scope. At the prototype stage you see whether the approach works and decide there whether to continue. Be cautious of plans that demand a large commitment up front.
On the company side, two people are usually enough: one who knows the process on the ground and a technical contact who can provide system access. The process owner’s contribution amounts to a few hours in total but is critical to the project; only that person knows what the data fields really mean. You do not need to hire an AI specialist.
Discovery 1-2 weeks, working prototype 2-4 weeks, and 2-3 months in total including the move to production is a typical range. Projects that require integration with many systems, or where the data infrastructure has to be built first, take longer. Be cautious of a plan that does not pin these timings down at the feasibility stage.
If your company has a team with AI experience and the work is a strategic priority, doing it in-house makes sense. If this is your first project, starting with an external partner is usually faster and less risky; your team learns along the way and can run later projects internally. The critical point is that, even with an external partner, the handover plan is discussed from the start.
When you proceed in stages, the loss is limited to the time spent so far and the cost of the prototype. The real risk is carrying on for months with a project whose failure could have been recognised early. That is why a plan that allows you to stop at the end of each stage is safer than a full-scope commitment from the start. Even a failed pilot yields lasting outputs such as data quality improvements and a process map.
If you are stuck at any of the steps above, whether you cannot pin down the problem, do not know if your data is sufficient or are not sure AI is really needed, this call is exactly for that.
We do not make sales pitches: describe your problem and get an honest assessment. If you do not need AI, we will say so.
Related pages: Enterprise AI consulting · AI integration services · AI solutions for business
