How long does an AI integration actually take?
A focused first version is usually a few weeks of engineering, and the projects that take nine months rarely spent nine months building. They spent them waiting: for access to a system, for a security review nobody scheduled, for a decision about which team owns the output. If you want a realistic date, the questions to ask are mostly about your own organisation rather than about the technology.
What actually takes the time?
Access, decisions and integration surface, in that order. The model work is generally the smallest and most predictable part, because calling a capable model is now a solved problem and the interesting engineering is everything around it.
Access means credentials to the systems the feature reads from and writes to, in an environment that resembles production. This is routinely the longest single delay and it is almost never on the plan, because everyone assumes it is administrative. A two-week wait for a read-only database user is common and it stops all meaningful progress.
Decisions means the questions that surface once something works: what happens when the model is unsure, who reviews the output, whether it writes to the record automatically or proposes a change. These are business decisions, they cannot be made by the supplier, and they tend to require someone senior who was not in the kick-off.
| Phase | Typical share of elapsed time | Who controls it |
|---|---|---|
| Getting system access | Often the largest | You |
| Building the integration | Moderate and predictable | The supplier |
| Model and prompt work | Smaller than expected | The supplier |
| Evaluation and tuning | Moderate | Both |
| Business decisions on edge cases | Frequently underestimated | You |
| Security and privacy review | Large if left until the end | You |
What does a realistic first version look like?
One workflow, one team, and a human between the model and anything consequential. That scope is achievable in weeks rather than quarters, and it produces the thing that actually accelerates a project: evidence that changes the conversation from speculative to specific.
The reason to keep a person in the loop initially is not caution for its own sake. It is that their corrections are the most valuable dataset the project will generate, and collecting them from day one gives you both a safety net and the evidence needed to justify removing it later.
Scope that resists this usually contains an unstated assumption, most often that the feature must launch to everyone at once because of how it was announced internally. That is worth surfacing early, because it changes the timeline far more than any technical choice.
Which approvals decide the date?
Four, and each can add weeks if it arrives late. Whether company data may be sent to an external provider, and under what agreement. Who owns the output when the model is wrong. Whether the feature may write to a system of record or only propose. And who signs off that it is ready for real users.
None of these are technical and all of them are commonly discovered in week six. Answering them in week one costs an afternoon; answering them in week six costs the difference between the two dates plus whatever gets rebuilt.
The security and privacy review is the one most likely to force rework rather than merely delay, because its answers determine architecture. A team that learns in month two that data cannot leave the network has to revisit decisions made in month one.
How can you tell an optimistic plan from a deliverable one?
A deliverable plan names your dependencies with dates against them. If a proposal contains no line requiring anything from you, it is not a plan, it is a quote with a timeline attached, and it will slip on the first access request.
It also states what the first version deliberately excludes. A supplier who scopes everything you mentioned has not prioritised, which means the sequencing decisions get made later under time pressure by whoever is closest to the deadline.
And it says how the thing will be judged before it is built. A plan that reaches a launch date without ever defining what an acceptable output rate looks like is one where the argument about whether it works happens after the money is spent.
Why do pilots stall before production?
Because the pilot was built to demonstrate rather than to run, and the two are different engineering. A demonstration needs to work on chosen examples in front of an audience; a production feature needs to handle the input nobody anticipated, at three in the morning, without a person watching.
The gap is mostly unglamorous: error handling, retries, cost controls, logging, permissions, and a defined behaviour for the cases where the model is not confident. None of it is difficult and all of it is invisible in a demo, which is why pilots that impressed everyone can sit unlaunched for months.
Building the first version as a small production feature rather than as a prototype avoids the second project entirely. It feels slower in week two and is reliably faster by week eight.
What can you do now to shorten it?
Start the access request today, before choosing a supplier. It is the longest-lead item, it is independent of who does the work, and it is the one thing you can advance while still deciding.
Put the security and privacy questions to whoever will review them, in writing, before the design is fixed. Their answers are architectural inputs, and getting them early converts the review from a gate into a constraint you designed around.
Name the person who will decide the edge cases and make sure they know they are in the project. More AI integrations are delayed by an unavailable decision-maker than by an unavailable engineer.
Common questions
- How long does an AI integration take to build?
- A focused first version covering one workflow for one team is usually a few weeks of engineering. Projects that run to many months rarely spend that time building; they spend it waiting for system access, for business decisions about edge cases, and for a security review scheduled too late. The technical work is the smallest and most predictable part.
- What causes AI projects to be delayed?
- Getting credentials to the systems the feature must read and write is routinely the longest single delay and is almost never on the plan. After that, business decisions that only surface once something works, such as what happens when the model is unsure and who reviews the output, and a security review left until the end, which can force rework rather than simply delay.
- Why do AI pilots never reach production?
- Because a pilot is built to demonstrate and a production feature is built to run unattended, and the difference is error handling, retries, cost controls, logging, permissions and defined behaviour for low-confidence cases. None of that appears in a demo, so an impressive pilot can require a second project to become usable. Building the first version as a small production feature avoids that entirely.
- What should be in the first version of an AI feature?
- One workflow, one team, and a person between the model and any consequential action. That reaches evidence in weeks rather than quarters, and the corrections that person makes become both the safety net and the dataset that justifies automating further later.
- How can we speed up an AI integration?
- Start the system access request before you have chosen a supplier, since it is the longest-lead item and is independent of who does the work. Put the security and privacy questions in writing to whoever reviews them before the design is fixed, so their answers become design inputs rather than a late gate. And name the person who will decide edge cases, because an unavailable decision-maker delays more projects than an unavailable engineer.
