How long does an AI project take?

The short answer

A functional pilot in four to six weeks. A first use case running in production in eight to sixteen, counted from the same start. The range is wide because it is almost entirely determined by integration depth and compliance, not by anything about the model.

Anyone who quotes a timeline before knowing which systems they have to touch is quoting a hope.

What the first four to six weeks contain

Not building. The first phase is finding the decision worth automating, confirming it can be measured, and proving it can be reached in your environment.

Concretely: mapping where the decision happens today and who makes it, agreeing the number that will move, connecting to at least one real system to discover what that actually involves, and building a narrow working version against production shaped data.

The output is a yes or no with evidence, an integration plan grounded in systems you actually touched, and a production price. A phase that ends in a demo instead of those three has not de-risked anything.

What the production build contains

Eight to sixteen weeks, and the work is mostly not the AI. Real integration with the systems of record. Auth, permissions and audit wired through properly. Evaluation set built and running in CI. Observability. Guardrails. Rollout, monitoring, and the handover so your team can operate it.

If you removed the model entirely, most of this list would still be there, which is why teams who scope AI projects as model work are surprised by the schedule. The engineering around it is the project. That is the same point behind guardrails and observability.

What compresses it

Clean API access to the systems involved. An existing staging environment. A named internal owner with authority. A decision that is already measured. And a narrow scope, one decision rather than a capability.

Teams that have all five routinely land at the fast end. It has very little to do with how sophisticated the AI is.

What stretches it

Integration with systems that have no real API, or only a batch interface. Change approval processes measured in weeks. Data that has to be cleaned or reconciled before it can be used. Compliance review where nobody has done an AI review before, so the process is being invented alongside your project.

And the most common one: unclear ownership. A project waiting on a decision from someone who is not in the room does not move, and that wait is invisible on every plan.

Why pilot based estimates are wrong

A pilot connects to a copy of the data. Production connects to the source, with its permissions, its load, its change process and its undocumented behaviour. Extrapolating from one to the other consistently understates the work by a wide margin, and that gap is the single biggest reason projects stall. We covered the pattern in why pilots fail to reach production.

The correction is to touch at least one real system during the pilot, even narrowly, so the estimate is grounded in something you measured rather than something you assumed.

Sequencing for early value

Do not wait for the full scope to be live to get anything. Pick the narrowest version that reaches a real user, ship that, then widen.

This is not just a delivery preference. A system in front of real users produces information no internal review can: what people actually ask, where it fails, which cases you never imagined. Getting that in week ten rather than week thirty changes what you build next.

What to do while you wait on IT

Access approvals are frequently the long pole and they are rarely on the critical path anyone plans for. Start them on day one, before the design is finished, because the request itself takes longer than the work it unblocks.

Meanwhile, build against a faithful copy with the same shape and the same permission model, so the switch is a configuration change rather than a rewrite. Assume nothing about the real interface until you have called it.

Putting a date in front of a board

Give two dates, not one. The date something is live in front of real users, narrow, and the date the full scope is live. Boards accept staged delivery far better than they accept a single date that slips.

And state the dependency explicitly: this date assumes access to these systems by this day. Naming that upfront turns a future delay into a shared problem instead of your miss. That is how we structure engagements, alongside the cost breakdown in what it costs and the vendor questions in how to choose a partner.