Introducing AI in a business: the first 90 days

AI adoption first needs a responsible owner. This person does not need to understand every model technically. They should bring decisions together, document open questions, and ensure that management, privacy, IT, and affected employees do not work past one another. Without this role, experiments stay private and lessons are lost.

Next, observe where work actually gets stuck today. Which information is transferred more than once? Which answers are repeatedly written from scratch? Where does a process depend on one person? This also includes an inventory: which AI services are already being used, with which accounts and data? The goal is not a long strategy report, but a shared understanding of the starting point.

A good first case occurs frequently, consumes noticeable attention, and has an outcome a person can review. Examples include preparing recurring responses, summarizing approved documents, capturing a request in a structured way, or searching a clearly limited knowledge base. The process should already be understood, even if it is not yet optimal.

For each candidate, document value, data, exceptions, possible errors, and human approvals. A case with high theoretical value may be a poor starting point when errors would have serious consequences or reliable data is missing. The pilot also needs a clear boundary: who tests it, which tasks are included, which are explicitly excluded, and how a useful result will be recognized after several weeks.

Now create the smallest version that can test the central assumption. For response preparation, this may initially be a draft based on fixed source material with human approval. For automation, one workflow covering the most common standard case may be enough. Exceptions are made visible, but not all implemented immediately.

The test belongs in real day-to-day work. The team should document not only time, but also missing information, incorrect outputs, required corrections, and situations that needed a personal decision. A pilot is not a showroom. If difficulties are hidden, the business cannot make a reliable decision or improve the setup later.

At this point, experience should become understandable rules. These include approved accounts, suitable and unsuitable data, required checks, source review, approvals, and a contact for uncertainty. A rule such as 'do not enter sensitive data' is too abstract if nobody knows what that means in their own role. Examples from the pilot make guardrails concrete.

AI literacy does not mean turning every employee into a technical expert. People should understand why the system is used, its limitations, how results are reviewed, and who remains responsible. The European Commission also describes AI literacy as a context-dependent obligation for providers and deployers. Practical guidance does not replace qualified review of individual legal questions.

At the end, compare the starting point with the pilot. Did the workflow become faster or more reliable? How much rework was needed? Which errors occurred, and were they detected in time? Did the team adopt the new step? In addition to time, a clearer status, less searching, or a better handoff may be important outcomes.

There are then three equally valid decisions: continue, change, or stop. Continuing means defining ownership, operations, cost, and regular review. Changing may mean narrowing the use case or improving data and process first. Stopping is useful when effort, risk, or dependency outweighs the benefit. A well-reasoned no is a successful learning result.

The most common mistake is an assignment that is too broad, such as 'we are introducing AI now.' Many topics begin in parallel, but nothing is fully tested under real conditions. A management-only experiment without the people who perform the workflow every day is equally problematic. Their exceptions and practical knowledge will be missing from the solution.

Another mistake is showing only successful outputs. Corrections, stops, and uncertainties are especially valuable for a decision. The tool contract also deserves attention: access rights, data use, retention, export options, and the ability to change providers should match the actual risk of the use case.