A three week AI deployment is the delivery of a working, governed AI capability inside a company's own environment in about 15 working days, and it is achievable now for one reason: nobody is building the intelligence any more.

The models exist. The orchestration exists. What remains is deciding what problem to solve, getting access to the data, agreeing what acceptable output looks like, and putting boundaries around what the system may do unattended. ChatFuse quotes 2 to 3 weeks because that is how long those four things take when someone pushes them.

Three week AI deployment Where the time actually goes.
Access and permissions most
Agreeing what good looks like high
Configuration and connectors medium
Anything resembling model work low
Compiled by ChatFuse from how deployment time actually distributes.

The first bar is why timelines slip, and it is almost never a technical constraint. It is a person who has to approve something and has other priorities.

What happens in week 1?

Scoping and access, in that order, and access is started on day 1 rather than when it is needed. One business problem gets chosen, one measure of success gets written down, and one person is named as the owner of the result.

The scoping conversation is short if the company knows what it wants and long if AI arrived as a mandate rather than a need. A deployment that begins with "we should be using AI" takes a week longer than one that begins with "our proposals take 4 days and should take 1".

ChatFuse pushes hard on that second framing, sometimes to the point of being annoying about it, because a vague scope does not become clearer during the build. It becomes an argument in week 3 about whether the thing that was delivered is the thing anybody wanted.

What happens in week 2?

The system gets built against real data with real permissions, and the first output goes in front of the people who will actually use it. This is deliberately early, because the fastest way to discover that the output is subtly wrong is to show it to somebody who does the job.

The three weeks What gets decided, and by whom.
1
Week 1: scope, access, owner One problem, one measure, one name. Access requests go in on day 1 because they are the long pole.
2
Week 2: build against real data Real permissions from the start, output in front of real users, boundaries set on what runs unattended.
3
Week 3: harden and hand over Controls, audit trail, failure behaviour, and training the owner to run it without us.
Handover is a week's work, not an afternoon, and skipping it is why deployments decay.

Week 2 is also when the boundaries get set: what the system may do on its own and what always waits for a person. The rule ChatFuse applies is that anything leaving the company or moving money needs a human, regardless of how reliable the output has been.

That rule is about reversibility rather than trust, and stating it that way avoids a tedious conversation about how good the model is. A wrong internal draft costs somebody a rewrite. A wrong outbound message has already arrived.

What happens in week 3?

Hardening and handover. ChatFuse narrows access controls to what the job actually needs, an audit trail that will still be useful in 6 months, sensible behaviour when a connected system is unavailable, and the owner trained well enough to run it without us.

Handover is the part most often cut when a timeline slips, and cutting it is how a deployment stops working 3 months later without anyone deciding to abandon it. A system nobody inside the company can adjust ages badly the first time a process changes, and processes change constantly.

The handover that works is not a document. It is the owner making a real change to the system while somebody watches, so that the first time they have to do it alone is not also the first time they have tried.

Why is it not faster?

Because approvals take the time they take. The engineering could be done in days, and frequently is, then waits on a data owner who is on holiday or a security review with a queue. Compressing that is a matter of starting it earlier rather than working harder.

We are also deliberately unhurried about one thing: agreeing what acceptable output means before anything ships. Skipping that is the single most common reason a deployment stalls after the build, which we covered in why AI pilots fail.

What makes a deployment slip past 3 weeks?

Four things, and only one is technical. Nobody empowered to make decisions in the room. Data access that requires a review nobody started. A process that turns out to be broken and needs redesigning rather than automating. And scope that grew during the build because the demo was interesting.

The last one is the most pleasant way to fail. A team sees the first output, imagines 5 more things, and the original measurable problem quietly becomes one of six unmeasured ones. The discipline that holds a ChatFuse timeline is writing those 5 ideas down as a second phase rather than absorbing them into the first.

What does the customer own afterward?

Everything that matters. In a ChatFuse deployment the context and memory live in the customer's own account, the workflows are theirs, and the models underneath are routed across more than 100 options from OpenAI, Anthropic, Google and Meta rather than fixed to one provider. If a model retires, that is a routing change rather than a rebuild, for the reasons in own your AI context.

Frequently asked questions

How long does an AI deployment take?

Two to three weeks for a scoped business capability, assuming decisions can be made quickly and data access is started immediately. The engineering is rarely the constraint. Approvals and agreeing what acceptable output looks like are what set the timeline.

Why can AI deployments be so much faster than traditional software?

Because the hardest components already exist and are rented rather than built. The work is configuration, integration, controls and agreement, not construction, which removes most of what made comparable projects take months.

What slows an AI deployment down most?

Data access approvals. They are a queue somebody else controls, they are frequently started too late, and no amount of engineering effort shortens them. Starting them on the first day changes the timeline more than any other scheduling decision.

Do you need to prepare your data first?

Less than people expect for most use cases, since modern models handle messy inputs well. What matters more is knowing who owns the data and whether they will approve access, which is an organisational question rather than a technical one.

What happens after the three weeks?

The named owner runs it, with the audit trail and controls handed over. Ongoing work is maintenance rather than development, mostly revalidating when a model is retired and adjusting as the process changes. See who owns AI in your company for what that role involves.

Three weeks is realistic because almost nothing is being invented. Treat it as a decision making exercise with a build attached rather than a software project with some decisions in it, and the timeline holds. Treat it the other way around and the build finishes on time while the decisions take another month.

Start free with ChatFuse, or see how deployments are scoped on the business page.

Back to Blog

Written by Nico

Share

Comments

Loading commentsโ€ฆ

Secure signup continues in a new tab.