“How long will this take?” is usually the second question asked about an automation project, and it has two honest answers that sound nothing alike. A single workflow can be live in production in eight to twelve weeks. An enterprise AI programme, by published 2026 roadmaps, runs twelve to twenty-four months from kickoff to full operational scale.
The gap is not padding. It is that a programme spends most of its time on things that are not building: deciding what to automate, getting access to data, and persuading someone to accept responsibility for a system acting. This guide sets out where the weeks actually go, so you can plan against something closer to reality than a vendor’s demo schedule.
One Workflow Is Not a Programme
| First workflow | AI programme | |
|---|---|---|
| Scope | One process, one team | Several processes, several departments |
| Time to production | 8–12 weeks | 12–24 months to full scale |
| Biggest time sink | Integration access | Governance and change management |
| Who must agree | One process owner | Security, legal, IT, finance, operations |
| First measurable result | Week 8–12 | Month 6–12 |
| Failure mode | Wrong process picked | Never reaching production at all |
Almost every organisation should start with the first column, even if the second is the eventual ambition. A programme that begins with a platform selection and a governance framework produces its first measurable result in month nine; a programme that begins with one workflow produces one in week ten, and the governance conversation then has evidence attached to it.
Where the Weeks Actually Go
Published implementation frameworks for 2026 break the work into six stages. The durations below are the commonly cited ranges, with a note on what consumes them.
Scoping — 2 to 4 weeks
Mapping candidate processes, scoring them on volume, stability and input consistency, and agreeing a written definition of done with a named owner.
This stage is compressible to days if someone already knows which process hurts and can produce the numbers. It stretches to months when the answer is “automate AI across the business”.
Data readiness — 3 to 6 weeks
Getting access to the systems, the sample documents, the historical records and the credentials. Finding out which fields are reliable and which are filled in differently by every person.
This is the stage that slips most often, and almost never for technical reasons. Access requests sit in queues. Nobody is quite sure who owns the database.
Pilot build — 4 to 8 weeks
Building the workflow, the AI step, the validation rules, the escalation path and the logging. The part everyone pictures when they imagine the project, and rarely the longest.
Build time scales with the number of systems written to, not with how clever the AI is. One system is weeks; four systems with one legacy and no API is a different project.
Governance review — 2 to 4 weeks
Security review, data protection assessment, and agreement on what the system may do unsupervised. Expect this to run in parallel with the build, and start it early.
Projects that leave this until the build is finished routinely lose a quarter here, because the answer arrives after the money has been spent.
Limited rollout — 4 to 8 weeks
Running on real volume with a human approving every action, measuring accuracy against the agreed threshold, and fixing what the real world exposes.
Shortening this stage is the most common and most expensive mistake. It is where the exception rate becomes known, and the exception rate is what the business case rests on.
Scale — ongoing
Removing the approval step where the accuracy record justifies it, extending to adjacent processes, and maintaining the thing as suppliers, systems and rules change.
There is no end date here. Automation is a system you operate, not a project you finish.
Add the midpoints and a first workflow lands around eleven to fourteen weeks, with governance overlapping the build. That is the realistic number to plan against.
Twelve Weeks for a First Workflow
| Weeks | What happens | What must exist at the end |
|---|---|---|
| 1–2 | Process audit and scoring; definition of done agreed | A written success threshold and a named owner |
| 2–5 | System access, sample data, field reliability review | Credentials, a representative data set, a field map |
| 3–6 | Security and data protection review starts in parallel | Agreed limits on what the system may do |
| 4–9 | Build: workflow, AI step, validation, escalation, logging | Working end to end on real data, writing to the real system |
| 8–12 | Limited rollout with human approval on every action | A measured straight-through rate and exception rate |
| 12 | Gate review against the week-1 threshold | A decision: extend, fix, or stop |
The overlaps are deliberate. Data access and governance are the two stages that run on other people’s calendars, so both start before the build and run alongside it.
What Happens at Week Twelve
A common rule in published frameworks is to scale only when the pilot meets at least 70 percent of its defined KPIs, and to iterate rather than scale when it does not. The rule matters less than having one at all, agreed in week one and honoured in week twelve.
Keeping to the Timeline
Frequently Asked Questions
Conclusion
Twelve weeks for a first workflow is achievable, and the plan above is not optimistic — it simply puts the two stages that run on other people’s calendars at the start rather than the end. The projects that overrun are almost never the ones whose build was underestimated.
Start with one process, agree the number it must hit, raise the access requests immediately, and hold the gate at week twelve whatever the answer is. That is the whole method, and it is how we run automation projects.