How Long Does It Take to Implement AI Automation in a Business?

How long does it take to build a single AI automation?

One process, one or two systems, and a decision that follows rules somebody can explain: that is a build measured in weeks rather than quarters.

Scope	Typical time to live	What it looks like	What sets the clock
A bought tool, configured	Days to two weeks	A product that already does the job, pointed at your data and your inbox	Whether it fits without changing how you work. If it does, buy it rather than build
One process, one system	Two to four weeks	Quote follow-up, review requests, appointment reminders running out of software you already use	Getting the rules right. The build is short, the conversation about the exceptions is the long part
One process, two or three systems	Four to eight weeks	Invoices read from email, coded, written into the ledger and the practice or job management system	Each connection is separate engineering with its own permissions, rate limits and failure modes
Several processes for one team	A quarter, in sequence	A department's document handling, intake and reporting	Sequencing. Built one after another, each one shorter than the last
A model trained on your own history	Three months and up	A model fitted to your data rather than a general one given your documents to read	Assembling and labelling the history. Rarely the right first project, and usually not needed for the result people want from it
Company-wide AI program	Eight months on average	Platform selection, governance, a data warehouse, models trained on your own history	Eight months on average from prototype to production, and under half of projects arrive (Gartner, 2024)

Most builds we do are live within two to four weeks of the audit, because the scope is one workflow rather than a company-wide program. The first system at Universidad Maimonides was live inside the first month and has been running ever since, on our infrastructure. Details of that build are in the Universidad Maimonides case study.

The reason the small version is fast is that almost nothing has to be invented. The document reading is solved. The decision logic already exists in somebody's head. What remains is connecting those to the systems you run and handling the cases where the input is wrong, and that is engineering with a known shape.

Be suspicious of any quote where the timeline does not change when the scope does. A firm that says twelve weeks before it knows which systems it has to write into is describing its capacity, not your project.

How long does it take from the first call to the system being live?

Four to eight weeks from the first conversation to a single workflow running, and deciding what to build takes about as long as building it. An engagement runs Discover, Plan, Build, Improve, with a parallel run sitting between the last two: the system goes live weeks before the manual version stops.

Stage	Elapsed	What happens, and what we need from you
Discover	Week 1 to 2	We map how the work really runs, time a sample of it, and count the volume. We need an hour each with the people who do the task, and read access to the systems it passes through
Plan	Week 2 to 3	The roadmap: what is worth doing, in what order, what each one is worth, and what stays with a person. One decision from you at the end of it, which is the step that slips when the decision needs more than one signature
Build	Week 3 to 6	Our engineering team builds the first workflow and runs it against your historical cases. We need the credentials, and this is where the waiting happens: an API tier to upgrade, a login nobody has, an approval from a vendor
Parallel run	Week 6 to 9	The system and your team both do the work, and we compare the outputs. Disagreements turn into rules. Nothing is switched off yet
Improve	Week 9 onward	The manual version stops, the hours come back, and the system stays on our infrastructure with us operating it. Exceptions found in the first month each get a rule

Those weeks overlap in practice and the only ones with a hard floor are Discover and the parallel run. Discover has a floor because a baseline timed over two normal weeks cannot be collected in three days, and the parallel run has one because the work has to go round its own cycle at least once before anybody trusts the comparison.

The usual cause of a slip is not engineering. It is a decision with more than one signature on it, or access to a system nobody in the room controls, and both of those are faster to start chasing in week one than in week four. If you want to know what the Discover conversation actually covers before committing to one, that is in what an AI audit is, and the roadmap it produces is described in what an AI roadmap should contain.

What makes an AI automation project take longer than planned?

Four things make an AI automation project take longer than planned, and three of them are visible before a line of code is written.

Messy records are the usual culprit. Gartner's July 2024 forecast that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025 named poor data quality first among the causes, ahead of inadequate risk controls, escalating costs and unclear business value. In a smaller company that rarely means a data problem in the technical sense. It means the same customer exists three times in the CRM with different spellings, or the field that was supposed to record job type has been used for notes since 2021.

Access is what causes the quiet weeks in the middle of a build. Somebody has to authorize the connection to the accounting package, and that person is on vacation, or the vendor charges for API access on a tier you are not on, or the login belongs to a bookkeeper who left. None of that is technical and all of it takes calendar time.

Undocumented rules are the third. The person who does the task can do it but cannot fully explain it, because a decade of exceptions live in their judgment. Getting those out is the real design work, and it happens in conversation, not in a spreadsheet of requirements.

Scope growth is the fourth and the most expensive. A build that starts as invoice coding acquires purchase order matching, then supplier onboarding, then a dashboard. Each addition is reasonable and the project never ships. The discipline is to launch the first one and add the rest afterwards, against something already running.

A firm that asks about all four before quoting is scoping. A firm that does not will discover them in week three and tell you then.

Why do enterprise AI projects take eight months when one workflow takes weeks?

Enterprise programs buy capability first and use cases second, which inverts the order that produces a working system quickly.

Gartner's May 2024 survey of organizations deploying AI put the average at eight months from prototype to production, with only 48% of projects reaching production at all. That is not incompetence. A company-wide program has to select a platform, satisfy security and legal review, build the data foundation, define governance, and get agreement between departments who each want something different. All of that is real work and most of it happens before anyone automates a task.

A single-workflow build skips the entire sequence because it makes no company-wide commitments. It touches one process, uses the software already in place, and either works or does not within a month. If it does not work, you have lost a month rather than a budget cycle.

The counterpoint is worth stating: the enterprise approach is right for enterprises. Gartner reported in June 2025 that 45% of organizations with high AI maturity keep their AI projects running for at least three years, against a much shorter life at lower maturity, which says the foundations do pay off at scale. If you have a data team, a governance function and a multi-year plan, build the platform.

If you are an owner with a process eating fifteen hours a week, you do not need a platform. You need that process gone by next month. We wrote about why the bigger version so often stalls in why do most AI automation projects fail.

How long does it take to roll the same automation out to more locations or business units?

Rolling the same automation out to more locations or business units takes roughly half as long per site as the first build did, and what sets the clock is how much the sites differ rather than how many there are. Where every branch runs the same software the same way, each one after the first is days of configuration. Where each branch runs its own, each one is close to a fresh build.

What carries over is most of the engineering: the connections, the decision rules, the monitoring and the monthly report. What does not carry over is the part nobody budgets for. Credentials are per site. Local exceptions are per site, and they are discovered in conversation rather than read off a system. So is the question of who approves what, which in a multi-unit company is the item that actually sets the date.

Rollout shape	Typical time per site after the first one is live	What sets the clock
Same software, same process, more branches	Days to two weeks	Credentials and local sign-off. The build is already done
Same software, local variations in how the work is done	Two to four weeks	Getting each local exception written down, which is a conversation rather than engineering
Different software at each site	Four to eight weeks	Every connection is separate engineering again, with its own permissions and failure modes
One process across several brands	Two to four weeks per brand	Whether the differences between brands live in the templates or in the rules. Templates are quick, rules are not
Several business units with their own approvals and budgets	A quarter per unit, and the limit is not technical	Agreement. Each unit has to accept a process it did not design, and that negotiation is the project

Most organizations do not finish this. Deloitte surveyed 3,235 business and IT leaders across 24 countries in August and September 2025 and published the result on 21 January 2026 as The State of AI in the Enterprise: The Untapped Edge, finding that "only 25% of respondents have moved 40% or more of their AI pilots into production". The release adds that 54% expect to reach that level within the next three to six months, without making clear which group that share is drawn from, so it is worth reading as intent rather than as a forecast. Either way the gap between a pilot that works and a process running everywhere is mostly organizational, which is the argument for rolling out in sequence instead of announcing a program.

In sequence means something specific. Do the first site properly, including the parallel run. Take the site most like it second, because that one proves the pattern and pays for the next. Leave the awkward site, the one with its own software and its own way of doing things, until last, since nothing you learn there transfers. The multi-brand version of this goes wrong most quietly: from head office the brands look like one process with different logos, and inside them every template, tone and approval differs.

How long should a new automation run alongside the manual process?

A new automation should run alongside the manual process until the outputs match for a full cycle of the work, which is usually two to four weeks.

Parallel running is the part people want to skip and the part that makes the difference. The system processes everything, a person processes the same items the way they always have, and you compare. Where the two disagree, you find out why. Most disagreements turn out to be a rule nobody stated rather than a mistake by the system.

How long depends on the cycle of the work rather than the calendar. A daily process shows you its variety inside two weeks. A monthly close has to run twice before you have seen it behave, because the second month is the first one that includes the things the first month missed. A seasonal process needs a judgment call: run it in parallel through the busiest two weeks rather than the quietest one, because quiet weeks prove nothing.

After the parallel period the work shifts from checking every item to reading a report. That is the point where the hours actually come back, and it is worth being honest that until then the process costs slightly more, not less. Every system we build sends a monthly report of what it handled, what it escalated and what it produced, so the check stays a five minute read rather than a habit of spot-checking that never quite stops.

Pick the switchover date in advance and write it down. Parallel running with no end date turns into permanent double-handling, which is the most expensive outcome available.

How long before you get the time back?

The hours come back the week the manual process stops, not the week the system goes live, and those are different weeks.

Three things sit between launch and time returned. Parallel running, which is two to four weeks of deliberate double-handling. Exception handling, where the first month surfaces the cases the design missed and each one gets a rule. And habit, which sounds soft and is not: people keep checking a system they do not yet trust, and that checking is the last of the manual work to disappear.

The saving ramps over those same months rather than arriving whole, and we have set the shape of that ramp out month by month in how long it takes before AI automation actually saves anything. Plan for the first month to feel like more work and the second to feel like less. In our experience the compounding happens after that, because the second automation for the same team is faster to build than the first. The connections exist, the rules have been written down once, and the argument about what the process actually is has already happened.

What makes the difference is that somebody keeps it running. Systems break for boring reasons: a supplier changes an invoice layout, a vendor updates an API, a form gains a field. We host what we build and operate it from there, so the fix is ours rather than a question of who on your team notices. If you want to know what a scoping conversation actually covers before committing to one, that is in what is an AI audit.

Frequently asked questions

How much does it cost to implement AI automation, and does a longer build cost more?

Cost tracks scope rather than calendar time, and the two move together. What drives both is the number of systems the automation has to write into, how much variation is in the inputs, how much has to run without a person checking each item, and who operates it afterwards. A build that takes three times as long usually does so because it touches three times as much, not because anyone worked slowly. The figure worth establishing before any quote is what the manual process currently costs you per year in hours.

How long does it take to see results from AI automation?

Weeks for a single workflow, and the honest sequence is: live in two to four weeks from scoping, parallel running for two to four weeks after that, then the hours come back as the manual version stops. For a company-wide program the picture is different. Gartner's May 2024 survey found an average of eight months from prototype to production and only 48% of AI projects reaching production at all.

Is it faster to use an off-the-shelf tool than to have something built?

Off-the-shelf is faster to switch on and slower to fit. A tool that does exactly what you need is the right answer and you should buy it. The reason contractors and practices end up with a build is that the process crosses several systems, or the rules are specific to how they work, and configuring a generic tool into that shape takes longer than building the narrow thing. The test is whether you would change how you work to suit the tool. If yes, buy the tool.

Can a process be automated quickly if our data is a mess?

Yes, more often than people expect, because an AI system reads content rather than requiring a clean schema. Duplicate customer records, inconsistent naming and free text in the wrong field are all things a system can be taught to handle. What genuinely slows a build is missing data rather than messy data. If the information needed to make the decision was never recorded anywhere, no system can recover it, and that gets found in the first week rather than the eighth.

How long does it take to add a second location or business unit?

Days to two weeks where the second site runs the same software the same way, because the connections, the rules and the monitoring already exist and only the credentials and the local sign-off are new. Four to eight weeks where that site runs its own software, at which point each connection is separate engineering and the timeline starts to look like the first build again. What sets it is how much the two sites differ, not how far apart they are, and in a company with separate budgets and approvals per unit the agreement takes longer than the work.

What happens if it takes longer than quoted?

Ask before you sign. The useful question is not whether a firm has ever overrun, since everyone has, but what the first thing to be cut is when a build runs long. The answer should be scope, never the parallel running period, because launching an unverified system on schedule is worse than launching a verified one late.