Adopting AI in your company: how to find and assess use cases and put them into operation

Distinguish three AI effects: efficiency, process, business model

If you want to adopt AI in your company, first be clear about the effect you are after. “We need to do something with AI” often ends with a tool in search of a problem. A better question is where work today is manual, slow or knowledge-heavy. Every use case you find this way belongs to one of three effects, and they differ in effort, risk and how much leadership has to decide.

• Efficiency. Individual employees work faster, for example when writing, researching and summarising. Effort and the need for decisions are low, and so is the risk, as long as it is clear which data may go into which tool. In a field study in customer service, employees with an AI assistant resolved 15% more customer issues per hour on average (Brynjolfsson, Li and Raymond). Less experienced staff benefited most; for the most experienced, quality fell slightly.
• Process. A workflow spanning several steps changes, for example from the arrival of a request to its entry in the core system. The risk is medium, because an error runs through the whole process. The effort lies in data, interfaces and the approval path.
• Business model. AI becomes part of what customers buy, for example as a new service. The risk is high, because brand, intellectual property and customer relationships are directly affected. This is a decision for leadership itself.

Where the effort really lies: in front of the core system

In our experience, the biggest efficiency losses in mid-sized companies arise not in the core system but in front of it. Requests arrive by email, as PDFs, spreadsheets or free text, and are retyped and passed on. This is exactly where you see whether an AI implementation holds up. RAND interviewed 65 experienced data science and engineering professionals about failed AI projects (Ryseff, De Bruhl and Newberry). Among other causes, the report names a misunderstood problem, missing data, putting technology before purpose and missing infrastructure. In our view, four topics are decisive, not the model:

• Data. Are the master data reliable, and are there real sample documents against which the result can be checked?
• Permissions. Which data may go into which system, and who may see which results?
• Target process. Should the AI prepare entries or write directly to the core system, and who checks and approves?
• Operation. Who runs the solution after the project, and what running costs are acceptable?

Collect and assess use cases: profile, score, four quadrants

You will not find good AI use cases in lists of tools, but by asking leadership a few questions. Where do you want to become faster, better or closer to your customers? Where is value being lost, and what must stay protected? Each candidate gets a one-page profile covering benefit, feasibility, data, risks and MVP scope. A simple way to a score: award 1 to 5 points per criterion and add them up. Feasibility, data availability and risk together make up ease of implementation; set against impact, it gives four quadrants.

• Quick wins (high impact, easy to implement) go into a sprint first.
• Strategic bets (high impact, hard to implement) need groundwork on data or process and a decision by leadership.
• Efficiency plays (lower impact, easy to implement) can often be covered by standard features of existing software.
• Later/monitor (lower impact, hard to implement): these cases stay on the list until technology, data or priorities change.

Start small: an MVP sprint, not a major project

The assessment is followed not by a major project but by a controlled MVP (minimum viable product): the smallest solution that can be used in day-to-day work. The principle: the AI does the groundwork, a person decides, and the core system remains the system of record. There is no autopilot, only a handover that can be checked; gaps are flagged, not papered over. For incoming email, a typical target process has six steps:

1. Consolidate. Incoming items arrive in one defined channel.
2. Extract. The AI transfers data from the email text and attachments into a fixed schema.
3. Match. The data are compared with the master data.
4. Check. Mandatory fields for each case type show whether a case is complete; open points go to the relevant department as a task marked “pending clarification”.
5. Present. Every proposal carries a traffic light: “confident”, “check” or “query”. Questions to customers are only ever created as drafts.
6. Approve. A person approves; only then is the case entered in the core system.

The traffic light is not excessive caution: false confidence on the AI’s part would be riskier than one query too many. In a field experiment with 758 employees of a management consultancy, participants using AI worked faster and better on tasks within the AI’s capability frontier. On a task beyond that frontier, they reached the correct solution less often than without AI (Dell’Acqua et al.). An MVP sprint typically takes two to four weeks. It ends with a final demo on real or anonymised cases and a decision on the next sprint.

Settle data, permissions and licences

Staying pragmatic does not mean allowing everything: sensitive customer and company data do not belong in uncontrolled AI tools. Data protection is an architecture decision, not a reason not to start. In practice, this means that before any AI request, the data are classified by how much protection they need. If a provider processes personal data on your behalf, you need a data processing agreement under Art. 28 GDPR. Input, data and model are logged, and the contract rules out training on your data.

• No private or free accounts. Use enterprise licences, central sign-in (single sign-on) and logging.
• Operating model by sensitivity. The more sensitive the data, the more isolated the operation: from EU hosting in a private environment through hybrid solutions to installation on your own premises.
• Mirror permissions. A defined group of users with role-based permissions ensures that the AI shows no more than employees are allowed to see today.
• Licences as needed. Not everyone needs an AI licence straight away: for a process-related use case, a few experienced users (key users) are often enough. Check your existing licences first.
• Involve the works council early. Where there is one, it must be informed in good time about planned uses of AI in work processes (§ 90 BetrVG). Tools that log inputs or usage per person can be subject to co-determination (§ 87(1) no. 6 BetrVG).

Roles and guardrails: product owner, champions, permitted, approved or prohibited

Why does a company need AI governance? So that it is clear who may do what with which data, who decides and what happens when the AI is wrong. The AI Risk Management Framework of the US federal agency NIST, built around the functions Govern, Map, Measure and Manage, works as an organising framework, not as a checklist (see NIST). The real work lies in applying such frameworks to your own use cases: with a few roles, an approval rule and clear guardrails.

• AI product owner. One person is responsible for the programme, roadmap and platform. They lead across organisational boundaries; where they lack formal authority, lateral leadership is a core part of the job.
• AI champions and process owners. In each area, a contact person collects use cases and shares success stories; process owners decide on changes to the target process.
• Steering committee. Here, leadership, business units, IT and legal decide together on priorities and guardrails.
• Training by role. Champions need different knowledge from occasional users; shared success stories carry the learning culture.

Every use case is classified as permitted (within the guidelines, with no further review), approved (after review of purpose, user group and data) or prohibited. Guardrails come on top. For prices, contracts and complaints, a person always checks, and the AI does not act without approval. There is an escalation path for incorrect outputs and data incidents. Employees and customers know where AI is involved.

Expand where the benefit is proven: five levels of automation

Expand only where the MVP proves the need: no architecture built just in case. The levels describe reach across the whole company; a single MVP can try out level 3 on a small scale earlier. The timings in the table are typical ranges, not commitments. Whether level 5 is your goal at all is a question of strategy, not technology. There is more on this in our article on strategy development.

The first 90 days

An AI strategy and a first MVP do not contradict each other: the strategy sets the framework and guardrails, and impact comes from controlled MVPs. So leadership’s first decision can be to approve an MVP rather than wait for a long strategy paper. How we support companies with this: AI strategy and AI consulting for mid-sized companies. For the first 90 days, three phases of about 30 days each work well. That is a rhythm, not a promise:

1. Days 1–30: set-up. Approve an AI tool with an enterprise licence, define guidelines and roles, involve the works council, collect use cases and decide on the metrics you will measure against later.
2. Days 31–60: quick-win pilots. The top-scoring use cases run as MVP sprints, each with human approval and a decision at the end.
3. Days 61–90: impact and scaling. Measure speed, quality, usage rate and user feedback. At the end come a few leadership decisions: make the guidelines binding, fill the roles, expand what has been proven. The AI prepares; people make the judgements.