AI Consulting Switzerland.

An engagement runs in five steps: map the processes, collect and score the use cases, check the data, define a pilot, do the maths. Every step produces something you can still use without us. That is the test of whether the advice had substance.

• Map how the work runs today. We interview the people who do the work, not just the management. We record the steps a case passes through, how often it comes up, how long it takes, where it stalls and who signs it off. The result is a process map with volumes attached — often the first time anyone in the business sees how much time a side activity eats.
• Collect the use cases. The map produces an unfiltered list. Nothing is discarded at this stage, not even the obviously unrealistic ideas. Scoring comes later, and it holds up better when the weak ideas were weighed openly rather than quietly dropped.
• Check the data. For every serious candidate: what data exists, in what format, how clean, how current, who owns it, where it lives. In practice this step kills more use cases than any technical limit does.
• Define a pilot. One use case, a tightly drawn scope, a success criterion with a number before and a number after, and a stop criterion. Without a stop criterion every pilot turns into a permanent project.
• Do the maths. Build cost, running cost, hours saved, cost of errors, time to payback. Not sold as a forecast, but presented as a calculation with its assumptions on the table so you can redo it yourself.

One thing is deliberately missing from that sequence: a tool recommendation at the start. Start with the tool and you will find a problem to fit it. Tools have their place — after the analysis, not before it.

Ranking runs on two axes: implementation effort and annual value — and it uses numbers from the process map, not gut feel. Value comes from case volume times minutes saved per case times your internal hourly cost, plus errors avoided and response time gained. Effort is the sum of integrating with existing systems, preparing the data, running the thing, checking its output and getting people used to it.

Two axes give you four fields. High value, low effort is where you start — usually text work on existing templates, summaries, pre-sorting. High value, high effort is the second step, after a pilot has worked and with budget freed up by the first one. Low value, low effort is something a team may try on the side, but it does not belong in a project plan. Low value, high effort is where most failed AI projects began. You can spot them by their justification: "we need to do something with AI" rather than a number.

Two further criteria reshuffle the order regularly. The first is tolerance for error. A misrouted email costs thirty seconds to fix; a miscalculated quote costs a client relationship. Use cases with a high tolerance for error belong at the front, because that is where you can learn without paying for it. The second is visibility inside the team. Your first use case should take work off someone who genuinely dislikes that work. That decides whether steps two and three get accepted far more than any figure in the business case does.

Your data carries a use case when the relevant information is machine-readable, complete enough, current and legally usable — and when someone in the building can say which version is the valid one. All four conditions have to hold. The fourth is the one people underestimate.

Machine-readable is not the same as "we have it digitally". A scanned PDF with no text layer is a picture. A spreadsheet where numbers sit in the same cell as their units is a collection of sentences. Both can be cleaned up, but that is project work and belongs in the effort estimate, not in a footnote.

Complete enough is a relative standard. A system that makes documents searchable can live with gaps, because a human reads the result anyway. A system that decides on its own cannot. Current means there is a process that keeps the source material up to date. Without one, the application will confidently answer four-month-old questions after four months — which is worse than no answer at all.

Legally usable concerns personal data, client contracts with confidentiality clauses and third-party copyright. If you hand client documents to an external service, you need a legal basis, a data processing agreement and clarity about whether your input is used for training. The technical background is in our glossary entries on large language models and retrieval augmented generation.

The practical test takes an hour. Take twenty real cases from the last quarter and try to find, by hand, the information a machine would need for each one. If you cannot do it, neither can the machine.

The calculation has five lines: one-off build, monthly running cost, working time saved, the cost of checking the output, and the point at which the thing starts paying for itself. What matters is that the checking cost is in there from the beginning. It is the line missing from optimistic calculations and present in every real project.

An example with invented but ordinary numbers, so the structure is visible. A business writes forty quotes a month, forty-five minutes each. An assistant that drafts from the enquiry, the price list and earlier quotes brings that down to twenty minutes including the check. That is roughly sixteen hours a month. Against it stand the one-off build, the monthly licence and running cost, and the effort of keeping the price lists current. Whether it pays depends entirely on that figure of forty. At eight quotes a month the same calculation goes negative, without anything changing in the technology.

So we run every line with your numbers and put the assumptions on the table, rather than importing a percentage from someone else's study. Two things we deliberately keep out of the benefit side: hypothetical extra revenue and "strategic value". Neither can be measured or disproved, and both make any calculation say whatever you want. For the cost side of an actual delivery project, the project calculator gives you a range in three minutes.

AI is the wrong answer when the process is unclear, when the data will not carry it, when the volume is too small, or when the real problem is organisational rather than technical. We say so inside the engagement, even when it argues against the follow-on work — and in roughly one first conversation in three, that is the core of the answer.

• Nobody can describe the process. If three people solve the same task three different ways and nobody can say which one is right, you would be automating a disagreement. Decide the process first, then support it.
• The volume is too small. At five cases a month, build and maintenance permanently outweigh the benefit. A good template and a text snippet are the better investment here — unglamorous, but effective immediately.
• The output has to be right and nobody checks it. Language models produce fluent, convincing answers when they are wrong, too. Without a named person doing the checking, that is a risk rather than a tool.
• The problem is organisational. If enquiries sit unanswered because nobody knows who owns them, no assistant fixes that. It only speeds up the journey to the point where things get stuck.
• The data cannot leave where it has to stay. With professional secrecy, health data or contracts carrying strict confidentiality clauses, self-hosting may be the only permissible route — and that rarely adds up for a small business.

A no for one of these reasons is not a lost engagement. It is the outcome you pay for advice to reach. The most expensive mistake in this field is not the investment you called off; it is the eighteen-month project that never went live.

Consulting ends with documents and a decision. Delivery starts with software and operational responsibility. We separate the two contractually and in time, so that the analysis does not quietly become a sales preparation. Advice whose conclusion is fixed in advance is not advice.

At the end of an engagement you receive: the process map with volumes, the scored list of use cases with the reasoning behind each position, the data verdict per candidate, the pilot definition with its success and stop criteria, the business case with its assumptions disclosed, and an assessment of the legal position. These documents are yours, and they are written so that any delivery partner can work from them.

For delivery you then have three routes: in house, with another supplier, or with us. If we build, our published anchors apply — a prototype that validates an idea from CHF 10,000, a website or web application between CHF 3,000 and CHF 25,000. What a delivery project involves technically is described under AI Development; how to decide cleanly between agency, freelancer and in-house team is covered in Choosing a Digital Agency in Switzerland.

As of August 2026 Switzerland has no overarching AI act. What governs the field is the revised Federal Act on Data Protection, sector-specific law and — if you do business with the EU — the EU AI Act. This is not a legal vacuum. It is existing law, written technology-neutrally, and therefore applicable to AI-assisted processing.

In practice that means three things for an SME. First, transparency: the people concerned must be able to see that their data is processed and for what. Second, documentation: AI-assisted processing of personal data belongs in the register of processing activities, with purpose, data categories, recipients and retention period. Third, a data protection impact assessment where the processing can create a high risk for the people concerned — extensive profiling, for instance, or particularly sensitive data.

The legislative picture is moving. Switzerland has signed the Council of Europe framework convention on artificial intelligence, human rights, democracy and the rule of law, and the federal administration is preparing a consultation draft that is expected to address transparency, data protection, non-discrimination and supervision. Anyone placing AI output on the market in the EU or using it there also falls under the EU AI Act, whose obligations for high-risk systems were pushed back in May 2026. This picture changes continuously. We reflect it inside an engagement as a risk assessment, and it explicitly does not replace legal advice.

We are a small digital agency with our own development team in Zollikon near Zurich, and we have no published AI project in our portfolio that we could hold up as a reference here. Our work comes from hospitality, fashion, delivery services, stationery, kitchen fitting, house clearance and pipe renovation; the technically most demanding piece is a web application for tax returns. We write that down because this field is full of suppliers quoting case numbers nobody can verify.

What we bring instead: we have been building software and websites since 2022, we know the state of real company data from projects rather than from slide decks, and we use the same tools in our own operation, from research through to development. In this field the value of advice does not come from industry benchmarks. It comes from being able to read a process map and recognise an unrealistic use case before it gets a budget.

An engagement starts with a free sixty-minute conversation. In it we work out whether there is anything to advise on at all — and in a good share of cases the honest answer is that a template, a tidy filing structure or a clear line of responsibility will do more than any model. After that we propose a scope with a budget range and a ceiling. For the content side of the same question, our guide to AI content strategy for Swiss SMEs is the right place to start.