Rolling Out AI in 90 Days: A Roadmap for Companies with 20 to 250 Employees

Most AI initiatives don’t fail because of the technology, but because of the sequence. A tool gets procured before it’s clear what for. Training happens before anyone knows which task it’s meant to handle. And the legal questions come up once everyone is already excited.

This roadmap reverses that order. It’s tailored to companies with twenty to two hundred fifty employees and assumes nobody is freed up full-time for it.

Upfront: the three prerequisites

Without these three things, no timeline will work.

A responsible person with time. Not “on top of the day job”, but with a fixed share of time — half a day a week is realistic. This person should come from the department where the first use case lives, not necessarily from IT.

Backing from management. Not as a welcome speech, but as a willingness to decide on process changes.

A budget for the one-time effort. Ongoing license costs are rarely the problem. Integration and preparatory work are the line item where projects get stuck.

Weeks 1 to 2: Finding the use case

Sit down with three to five managers and collect activities that meet four criteria: they occur frequently, they noticeably cost time, they’re based on text or documents, and the people involved dislike doing them.

Rate the list by expected benefit and estimated effort. Choose exactly one case. Not three — one.

Typical result: Drafting proposals, answering recurring customer inquiries, researching internal documents, pre-capturing invoices.

Decision at the end: Which case, which department, who’s responsible.

Weeks 3 to 4: Clarifying the framework

Now come the questions that get expensive later if you skip them.

What data does the case need, and where does it live? Is personal data involved? How are permissions set up in that area? Is there a works council, and does it need to be involved? What requirements does your data protection officer have for processing location and contract?

In parallel: collect twenty to thirty real test questions or test cases from recent weeks — with the known correct answer. This list is your benchmark and the single most important building block of the whole project.

Result: One page with data sources, legal framework, and stakeholders. Plus the test list.

Weeks 5 to 6: Selecting and cleaning up

Only now do you talk to providers. With a use case and test list in hand, conversations become short and concrete: you don’t ask “What can you do?”, but “How do you solve this?” and “How are permissions checked at the time of the request?”

At the same time, the preparatory work at home begins: review the affected storage area, correct permissions, flag or archive outdated documents, and establish one valid version for every important document.

This part is unpopular, and it decides the outcome more than the choice of provider does.

Weeks 7 to 9: Building and testing

Set up the integration, sign-on through your directory, check the permissions logic. Then test — using the test list from week 4 and with the rights of a normal user, not as an administrator.

Also create test accounts for typical roles and deliberately ask uncomfortable questions to check whether the assistant finds things it isn’t supposed to find.

Expect about a third of the test cases not to be answered satisfactorily on the first run. That’s normal. The cause is usually the state of the documents, not the system — and is therefore fixable.

Decision at the end: Does the case hold up? If the hit rate still isn’t convincing after fixes, stopping is the right decision. In that case you’ve invested six weeks, not a year.

Weeks 10 to 11: Rolling out to the team

Now the users come on board. Two hours of hands-on training on real tasks, not examples. A named contact person who’s reachable during the first weeks. A short usage policy: what data may go in, what needs to be checked, who helps with questions.

Document the training — that’s your evidence for the competence requirement under Article 4 of the EU AI Act, in force since February 2025.

Also provide the first templates: five to ten pre-written prompts for the most common tasks. Without them, most people use the tool well below its potential.

Weeks 12 to 13: Measuring and deciding

Compare against the baseline. Useful metrics are processing time per case, number of follow-up questions, and — often the most telling — how many employees actually used the tool in the past week.

At the same time, gather feedback: What was missing? Where were the answers unreliable? Which adjacent task would be the next sensible step?

Decision at the end: expand, refine, or stop. All three are legitimate outcomes.

The most common deviations from the plan

The preparatory work takes longer. That’s the norm, not the exception. If permissions turn out worse than expected, everything shifts by two to four weeks. Better that than skipping the cleanup.

The case grows. During testing, everyone involved thinks of further possibilities. Write them down and don’t act on any of them before week 13.

Enthusiasm outruns scrutiny. Once the first results are good, suddenly everyone wants access. Resist — an untested rollout across four departments is the fastest way to an incident.

After the 90 days

If the first case holds up, the second is markedly cheaper: integration, sign-on, permissions logic, contract, training concept, and operating model are already in place. What remains is the subject-matter work on the new case.

That’s the real payoff of this first quarter — not the hours saved in the pilot area, but the fact that your company now knows how something like this works at your organization.

Who plays which role in the project

A project of this size needs four roles. In smaller companies, two of them can be combined in one person — but each should be named explicitly.

Sponsor from management: decides on budget, process changes, and ultimately on expanding or stopping. Time required: one hour a month.

Project lead from the department involved: runs the project, selects test cases, gathers feedback. Time required: half a day a week.

IT contact: Integration, sign-on, permissions, operations. Time required: sporadic, markedly higher in weeks 5 to 9.

Data protection and employee representation: involved early, not just for sign-off at the end. Time required: two to three meetings.

The test list: the most important working tool

If there’s one thing from this roadmap to take especially seriously, it’s the twenty to thirty real test cases from week 4. They’re the benchmark for provider selection, for acceptance, and for every later expansion.

Make sure the list includes the awkward cases: the special cases, the poorly scanned documents, the ambiguous wording. A list of twenty friendly cases only confirms what you already hoped.

Frequently asked questions

What if we have several good use cases?

Write them all down and choose just one anyway. The others will be markedly faster and cheaper to implement after the first round, because the groundwork will already be in place.

Can we do the preparatory work in parallel with the selection?

Yes, and it’s even advisable. Permissions and storage need to be put in order independently of the provider.

What if the test disappoints?

First look at the causes. Very often it’s the state of the documents, not the system — that’s fixable. If the hit rate still isn’t convincing after fixes, stopping is the right decision, not a failure.

How do we keep the momentum after week 13?

With a defined next case and the same process. Experience shows the second round takes six to eight weeks instead of thirteen.

What happens in weeks 14 to 26

The roadmap doesn’t end with the decision in week 13. That said, setting up the second case just as carefully as the first wastes time — the groundwork is already in place.

Weeks 14 to 16 – Refine instead of expand. Work through the feedback from the first rollout: add missing documents, correct permissions, expand templates. These three weeks regularly get skipped because everyone already wants to move to the next case — and they’re the reason the first case holds up long-term, or doesn’t.

Weeks 17 to 20 – Second case. Selection, clarifying data sources, building the test list. Markedly faster than the first time, because the legal framework, contract, sign-on, and operating model are already in place.

Weeks 21 to 24 – Build, test, rollout of the second case, following the same pattern.

Weeks 25 to 26 – Interim review of both cases. Now, for the first time, you can judge whether a pattern is emerging: which type of use case works for you, which doesn’t, and why. That insight is more valuable than any single case.

Typical pitfalls by phase

In the selection phase the most common mistake is choosing the case based on people’s enthusiasm rather than how often the process occurs. An exciting case that comes up twelve times a year won’t create a routine, and therefore no habit.

In the clarification phase data protection often gets pushed to later because “we’re just testing for now”. As soon as real data is involved, it’s no longer a test in the legal sense.

In the cleanup phase the scope tends to expand. “We’re sorting the proposals folder” turns into a filing concept for the whole company. Set a hard boundary: only the area this case actually needs.

In the testing phase everyone tests with administrator rights and friendly questions. Both skew the result in the same direction — too optimistic.

In the rollout phase the contact person is missing. If nobody is reachable to help with problems in the first two weeks, half the users quietly decide against the tool — and that decision is rarely reversed later.

In the evaluation phase the baseline numbers are missing because nobody collected them before the start. All that’s left then is a gut feeling, and gut feelings follow expectations.

If it needs to go faster

Thirteen weeks is a realistic duration, not a minimum. It can mainly be shortened in two places: if your permissions are already in good shape, a large part of weeks 5 to 6 falls away. And if the use case doesn’t touch personal data, the clarification phase shortens considerably.

What you shouldn’t shorten is the test with real cases and the refinement phase. Both feel like lost time, and they’re the difference between a tool that’s still being used after a year and one that fizzles out after six weeks.