Almost every Swiss company we speak to has run an AI pilot, from 15-person software startups to 200-person manufacturers. Very few have one in production carrying real volume. The gap is rarely a modelling gap, because the pilots usually work. A pilot proves that a model can produce an output. Production requires a company to accept that output as part of a decision, every day, with someone answerable when it is wrong.

Those are different problems, and only the first one is technical. The second is about ownership, data that keeps arriving after the demo, a route for the wrong answer and a checked legal position. None of it needs a data science team. All of it needs a named person with a few protected hours a week.

Why do most AI pilots never reach production?

Because a pilot is scoped to answer whether a model can do the task, while production depends on four things a pilot rarely tests: a named owner for the decision the model informs, a route for catching and correcting wrong answers, data that arrives on a schedule rather than as a one-off extract, and a legal position someone has checked. The model is usually the part that works.

Where AI pilots stall, in the order the blockers appearProcess in 4 steps: 1. No decision owner (The output has nowhere to go); 2. No wrong-answer path (The first visible error ends it); 3. Pilot-only data (A hand-made extract, never repeated); 4. Unchecked legal footing (Found at deployment, not at design).01No decisionownerThe output hasnowhere to go02Nowrong-answerpathThe firstvisible errorends it03Pilot-onlydataA hand-madeextract, neverrepeated04UncheckedlegalfootingFound atdeployment, notat designWhere AI pilots stall, in the order the blockers appearProcess in 4 steps: 1. No decision owner (The output has nowhere to go); 2. No wrong-answer path (The first visible error ends it); 3. Pilot-only data (A hand-made extract, never repeated); 4. Unchecked legal footing (Found at deployment, not at design).01No decision ownerThe output has nowhere to go02No wrong-answer pathThe first visible error ends it03Pilot-only dataA hand-made extract, never repeated04Unchecked legal footingFound at deployment, not at design
Figure 1 Where AI pilots stall, in the order the blockers appear. Each blocker surfaces later than the one before it, and each is cheaper to remove before the pilot starts than after it succeeds. Source: TechPulse engagement practice

No owner for the decision. The model recommends; someone must decide. If no named person owns the decision the model informs, the output has nowhere to go. In a 60-person company that owner is whoever runs the team doing the work today, not whoever built the pilot. It is the most common blocker and the least technical.

No path for the wrong answer. Every model is wrong sometimes. Without a route for a person to catch, correct and feed back an error, the first visible failure ends the programme. Design the exception path before the happy path.

Data that only existed for the pilot. The pilot ran on an extract someone made by hand. Production needs it every day, with checks and an owner: a small data project nobody funded. The foundations are set out in is your data ready for AI?

Unclear legal footing. Under the revised Federal Act on Data Protection, a decision based solely on automated processing that has a legal consequence or a considerable adverse effect on a person triggers a duty to inform and a right to human review. Discovering this at deployment stops the programme; designing for it costs almost nothing. The wider obligations are in what Swiss companies actually have to do under the revised FADP.

Supervisors see the same pattern. FINMA's guidance on AI governance and risk management notes that data quality is often more important than the choice of model, and that responsibility for AI applications was often scattered, in organisations far larger than a 60-person company.

How common is AI in companies of this size?

Less common than the headlines suggest, and strongly tied to size. In 2025, 17% of EU enterprises with 10 to 49 employees used at least one AI technology, against 30% of those with 50 to 249 employees and 55% of those with 250 or more. Switzerland is not covered by that survey, but its economy is dominated by small firms in the same way.

The Eurostat survey puts the EU average at 20% of enterprises with ten or more employees, up 6.5 percentage points on 2024, so the direction is clear even if the level is modest. In Switzerland, the Federal Statistical Office counts more than 99% of market enterprises as SMEs, employing roughly two thirds of the people who work in them. The typical Swiss company weighing AI is a firm of 20 to 200 people where the person sponsoring the pilot also runs a department.

The more useful figure is why companies that considered AI did not go ahead.

Why EU companies that considered AI did not use it, 2025Bar chart: Lack of expertise, 70.9%; Unclear legal consequences, 52.5%; Data protection concerns, 48.8%; Not seen as useful, 20.7%. Source: [Eurostat, Use of artificial intelligence in enterprises](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises).Lack of expertise70.9%Unclear legal consequences52.5%Data protection concerns48.8%Not seen as useful20.7%Why EU companies that considered AI did not use it, 2025Bar chart: Lack of expertise, 70.9%; Unclear legal consequences, 52.5%; Data protection concerns, 48.8%; Not seen as useful, 20.7%. Source: [Eurostat, Use of artificial intelligence in enterprises](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises).Lack of expertise70.9%Unclear legal consequences52.5%Data protection concerns48.8%Not seen as useful20.7%
Figure 2 Why EU companies that considered AI did not use it, 2025. Share of enterprises that had considered AI but did not use it, by reason. Shares add up to more than 100% because firms could give several reasons. Source: Eurostat, Use of artificial intelligence in enterprises

Only one in five of those firms said AI was not useful. The rest stopped at expertise, legal clarity or data protection, exactly what a pilot does not test. Expertise here means someone who can turn a demo into a supported process with an owner and a fallback. Legal clarity mostly comes from the law that already applies, summarised below.

How do you choose a first AI use case?

Pick a decision a person already makes repeatedly, with a known cost of being wrong. That combination gives you a baseline to beat, an owner who cares about the result, and a tolerance for error, which are the three things a pilot usually lacks.

Good first candidates in Swiss SMEs: invoice coding and matching, demand forecasting for a constrained product line, triage and routing of inbound requests, and anomaly detection in operational data. Each has an existing manual process to measure against. The drafting and extraction tasks that pay back fastest are compared in generative AI use cases for small businesses, and the forecasting case in demand forecasting without a data science team.

Bad first candidates: anything that must be flawless in front of customers, anything needing training data created from scratch, and anything whose sponsor cannot say what a wrong answer costs.

Before any money is spent, ask the sponsor to answer four questions in writing: which decision changes, who owns it, what it costs today, and what a wrong answer costs. A blank answer is the first piece of work, and far cheaper on paper than in week ten. If the use case connects to nothing in your plan for the year, check it against a one-page digital strategy.

What does it cost to put an AI use case into production?

More than the model, and mostly in people's time. In the projects we have seen, modelling is roughly a sixth of the effort, building a reliable data path about two fifths, fitting the output into the daily workflow about a quarter, and monitoring, review and training the remainder. These shares are typical observations, not a quote, and they shift with how clean your data already is.

Budgets that assume the reverse stall with a working notebook and nothing in production. For a company of 40 to 150 people, the largest cost is internal: the process owner's hours in design and shadow mode, IT time on the data path, and a reviewer's weekly sample once live. Usage fees are usually small next to that, but they scale with volume. Agree a stop point in advance. A stopped project costs a quarter; a project that drifts costs the year. The business case structure is in how to measure ROI on a digital transformation.

Where the model is the product, public co-funding exists for genuine innovation, not for deploying a bought tool. Innosuisse's start-up innovation projects can cover up to 70% of direct project costs for Swiss start-ups under five years old and under 50 full-time equivalents. Established companies can run an innovation project with a Swiss research partner, covering 40 to 60% of total project costs themselves. Check current conditions before planning around them.

Build, buy, or use an API?

Use an API for general capabilities such as extraction, transcription, classification and drafting. Buy when a vendor owns domain data you cannot obtain. Build only when the model encodes something proprietary, such as your pricing behaviour or your process physics. For most companies of 10 to 200 people, the first production use case is an API or a bought tool, and building comes later, if at all.

RouteWhen it fitsTypical first useMain risk
Use an APIThe capability is general: language, extraction, transcriptionInvoice field extraction, email triageWhere data is processed, and on what terms
Buy a productA vendor has domain data you cannot obtainSector-specific forecasting or document checksLock-in, and limited insight into how it decides
BuildThe model encodes something proprietaryPricing behaviour, process physics, your customer graphCost and maintenance stay with you

Building general language or transcription capability yourself in 2026 is almost always a mistake, and hosted inference in Swiss or EU regions has removed most of the residency arguments for doing so. Building is right where the model is your defensible value, a narrower set than most roadmaps assume. For a startup that may be the core of the company, which raises the question of who leads the technical work, covered in fractional CTO, consultant or first technical hire.

What do Swiss and EU rules require before an AI system goes live?

Switzerland has no AI-specific law yet, and the revised Federal Act on Data Protection applies directly to AI. A company must be transparent about purpose and data sources, inform people about decisions based solely on automated processing that significantly affect them, offer those people a human review, and run a data protection impact assessment beforehand where processing is likely to be high risk.

The Federal Data Protection and Information Commissioner has stated that the Act is directly applicable to AI-supported processing, and Articles 21 and 22 of the Federal Act on Data Protection set out the automated-decision duty and the impact assessment. The Act does not require data to stay in Switzerland, but a client contract may, which narrows the provider shortlist, so decide early.

What is coming in Switzerland. In February 2025 the Federal Council chose to incorporate the Council of Europe's AI Convention into Swiss law, with amendments kept sector-specific as far as possible. According to the Federal Office of Communications, a consultation draft is due by the end of 2026. Until it is published, designing for its content is speculation.

What applies from the EU. A Swiss startup selling into the EU can be in scope of the EU AI Act without an EU office, because Article 2 covers providers and deployers in third countries where their system's output is used in the Union. The European Commission's AI Act page currently gives 2 December 2027 for high-risk uses such as recruitment and credit scoring, and 2 August 2028 for AI built into regulated products. Those dates have already moved once, so check them before relying on them. None of this is legal advice.

A twelve-week path to something real

Twelve weeks is enough to move one use case from a working pilot to shadow mode in production, if the first two are spent on questions rather than the model.

From named decision to shadow mode in twelve weeksTimeline in 5 phases: Weeks 1–2: Name the decision, owner, baseline and error cost; Weeks 3–5: Build the scheduled data path with checks; Weeks 6–8: Model, tested against the human baseline; Weeks 9–10: Exception path, monitoring, human review route; Weeks 11–12: Shadow mode: the model runs, people decide.Weeks 1–2Name thedecision, owner,baseline anderror costWeeks 3–5Build thescheduled datapath with checksWeeks 6–8Model, testedagainst thehuman baselineWeeks 9–10Exception path,monitoring,human reviewrouteWeeks 11–12Shadow mode: themodel runs,people decideFrom named decision to shadow mode in twelve weeksTimeline in 5 phases: Weeks 1–2: Name the decision, owner, baseline and error cost; Weeks 3–5: Build the scheduled data path with checks; Weeks 6–8: Model, tested against the human baseline; Weeks 9–10: Exception path, monitoring, human review route; Weeks 11–12: Shadow mode: the model runs, people decide.Weeks 1–2Name the decision, owner, baseline anderror costWeeks 3–5Build the scheduled data path withchecksWeeks 6–8Model, tested against the humanbaselineWeeks 9–10Exception path, monitoring, humanreview routeWeeks 11–12Shadow mode: the model runs, peopledecide
Figure 3 From named decision to shadow mode in twelve weeks. The data path comes before the model, and the model runs alongside people before it replaces any step. Source: TechPulse engagement practice

If any of the four items in the first fortnight is missing, stop there, because that is the work. The data path comes before the model, so the model sees in week eleven what it will see in production, and it is judged on the number the owner cares about, not on accuracy alone.

In shadow mode the model runs, people decide, and you measure the disagreement. Ship when the disagreement rate is understood, not when it is zero. It is the step most often skipped and the one that most reliably prevents an embarrassing first week.

What changes between a 15-person startup and a 200-person company?

The blockers are the same, but who removes them changes. In a 15-person startup the founder usually owns the decision and the data, so the risk is moving fast without a review route. In a 200-person company the owner is a department head, the data sits in several systems, and the risk is that nobody has the time to own it.

At 15 people. Most technology startups we meet use AI inside their product as well as in their own operations. The product case weighs more, because customers and investors will ask how the system is tested and what happens when it is wrong. Writing down the evaluation method and the human fallback early answers most due diligence questions in advance.

At 60 people. One named owner, a few protected hours a week, and one process per quarter, as in the first 90 days of a digital transformation. The trap is running three pilots at once because each department wants one, and finishing none.

At 200 people. The data path is the long pole, because customer, product and order data sit in systems that disagree. Get the process owner, the data owner and whoever signs the budget in one room before the pilot starts, not after it succeeds.

What separates a pilot from something in production

PilotIn production
OwnerThe person who built itThe person whose work it changes
DataA clean extractThe live source, with its faults
FailureNobody noticesSomeone is blocked, and says so
MeasureModel accuracyThe business number it was meant to move
FundingInnovation budgetThe operating line of the function using it

Every row is an organisational change, not a technical one. That is why so many capable pilots never cross: the modelling was never the hard part.

The free, voluntary NIST AI Risk Management Framework is organised around govern, map, measure and manage. A 50-person company can use those four words as headings on a one-page record per use case.

Where to start

Pick one decision, name its owner, measure today's baseline, and run the twelve weeks above against it. Once one use case is in production, the second is far quicker, because the data path, the review route and the legal position are reusable.

When the question becomes whether a system should act on its own, the controls are in what AI agents can realistically automate in an SME. In healthcare the same logic applies with stricter data rules, as in AI in Swiss healthcare. Our AI and machine learning practice usually starts with the four written questions above.

Sources

Working on this right now?

Tell us where you are in two questions. A consulting partner reviews every enquiry within 2 business days.