The most consequential change in AI at work is also the least dramatic. AI is disappearing as a separate tool and turning into a feature of the systems people already use. Nobody wants to open a second application every morning, upload five documents and write a prompt. The useful version is built into the CRM, the service portal, the document management system or an internal application, where the work already happens.
That is the difference between occasional AI use and an AI implementation, and it is most of what AI consulting now consists of.
Start with the process, not the model
The wrong opening question is which AI to use. The better one is which problem you are solving, and whether it needs AI at all. It sounds like a small distinction and it usually decides the project.
The openings worth examining are unglamorous. How many hours does your team spend on recurring emails? How often is information retyped from one system into another? How long does it take to find a document? How many support requests could be categorised or drafted in advance? Which reports get rebuilt every week from the same data?
Swiss SMEs are already concentrated there. In 2025, 34% used AI to automate specific work steps and 32% for data analysis, both up sharply on the previous year. Translation, correspondence and process automation lead the list. These are ordinary tasks, which is exactly why they add up.
A ten-minute task is not a small task
Ten minutes looks like nothing. Multiplied across several people, several cases a day and twelve months, it becomes one of the larger line items in an operations budget. The best automation candidates are usually boring and frequent rather than impressive and rare.
Scoring use cases before choosing technology
A prioritised list beats an ambitious one. Four questions are usually enough to rank candidates honestly.
| Question | What you are testing | Why it decides the outcome |
|---|---|---|
| How often does it occur? | Volume per day or week | Frequency, not novelty, drives the return |
| How much manual effort does it take? | Handling time and rework | Sets the ceiling on what can be saved |
| How available is the data? | Sources, quality, permissions | Poor data caps quality regardless of the model |
| What is the business effect? | Cost, speed, risk or revenue | Decides whether integration and operation are justified |
A process that runs a hundred times a day and consists mostly of standardised information handling is a better candidate than a spectacular idea needed twice a month. So the first step is not "we will build a chatbot". It is showing where time, knowledge or data is being lost today.
Why integration is the hard part
An assistant with no access to company information can only give general answers. An automation with no CRM connection creates extra manual work. An analysis model with no reliable data pipeline eventually serves stale results. This is where AI consulting, software engineering, cloud work and DevOps stop being separate disciplines.
Newer tooling has made the connection part more tractable. The Model Context Protocol is an open standard for connecting AI applications to data sources, tools and workflows under defined permissions. It is the technical basis for assistants and agents that do more than answer, working inside your systems within explicit boundaries.
The model is one component of six. Most of the engineering effort, and most of the risk, sits in the other five.
Data quality deserves particular attention here. In EY's 2026 Swiss survey, insufficient data quality and data silos were the most frequently named obstacle to AI integration at 20%, just ahead of security and data protection concerns at 19%. Before discussing models, it is usually more productive to discuss APIs, data quality and access rights.
Choosing between cloud and private AI
Not every company needs its own language model, and not every use case should be sent to a public AI service. Most of the useful options are in between: a standard SaaS product for general tasks, a secured retrieval system for company knowledge, a private cloud architecture for sensitive information, or self-hosted models for tightly controlled environments.
Decide it on stated criteria rather than preference: business value, data classification, output quality, integration effort, running cost, latency, scalability, vendor dependence, security and regulatory requirements. The Swiss picture suggests companies are already spreading across this range. In the 2026 EY survey, 35% used enterprise licences of specialised AI applications, while roughly a third had built their own solutions on more than one model.
The rules matter as much as the software
A technically excellent system still fails if the people meant to use it do not understand it or do not trust it. Swiss practice shows the gap plainly: although AI use rose sharply, only 34% of surveyed SMEs had clear rules about which data employees may enter into AI tools. Among companies with fewer than ten employees that fell to 23%.
Employees need to know what a system is for, which data may be used, when results must be checked and who is responsible when something goes wrong. Internal rules also have to stay simple enough that people still use the technology. The goal is not to turn everyone into a machine learning engineer. It is for staff to use AI as routinely and as responsibly as any other digital tool.
This is increasingly a regulatory expectation too. In the EU, AI literacy obligations have applied since February 2025. In Switzerland the Data Protection Act already covers AI-supported processing of personal data, and a consultation draft on AI regulation is expected by the end of 2026.
Launch is the start of the measurement
For conventional software, go-live is a milestone. For AI it opens a learning phase. How are people actually using it? Where does it work well? Which inputs produce wrong or incomplete results? Are permissions applied correctly? Are model or infrastructure costs rising? Have the connected systems changed underneath it?
Production AI needs monitoring, logging, tests and regular evaluation for the same reason it needs a data pipeline. Quality drifts quietly, and without measurement the first person to notice is a customer. An AI strategy that ends as a PDF has ended too early.
Successful AI does not have to start big. It has to start on the right problem.
You may not need an agent. You may not need your own LLM cluster. You may need one well-chosen process where AI saves several hours a week, built properly enough that it still works in six months.