AI Pilot Acceptance Testing: A 12-Case Contract Card for Swiss SMEs

Decision in one sentence: hire an AI consultant for a bounded pilot only when the supplier can turn one named business task into a baseline, a testable acceptance rule, a safe data path, a staffed operating handover, and a priced stop/continue decision; otherwise buy discovery or do the process work first.

If you are comparing providers in Ticino, begin with the local context in IAPME Suisse’s guide to AI consultants in Lugano and Ticino. That guide already covers multilingual work, local constraints, human review, and questions to ask. This article adds a buyer-side artifact: a proposal scorecard and twelve synthetic acceptance cases that make the pilot contract testable before you sign. The aim is not to prove that AI is always the answer. It is to make a small decision reversible.

What this guide adds to the existing advice

Search results for “how to choose an AI consultant” commonly recommend defining the business problem, checking references, scoping a pilot, protecting data, measuring value, and planning for handover. The cited IAPME guide also offers a local checklist. Those are sound starting points, but advice such as “define success” is hard to apply when a proposal never says what counts as a successful result, how much human correction is allowed, or who pays to operate the workflow afterward.

The gap is contractual specificity. A polished demo can show that a model produced a plausible answer once. A buyer needs evidence that the whole workflow performs on representative cases, rejects unsafe cases, fits the existing process, and remains usable when the consultant leaves. The acceptance card below converts broad advice into observable evidence, contract deliverables, and a reversible decision.

Evidence boundary: I reviewed the live search-result baseline, Swiss federal SME guidance, a regional university adoption project, a Swiss SME program’s public prototype and case-study page, and one entrepreneur-forum discussion. These sources are different kinds of evidence. A federal page is guidance, an ongoing research project is not a completed outcome study, a program page is a selected cohort, and a forum post is an anecdote. None establishes a success rate for AI consultants in Ticino.

The buyer’s answer: purchase a decision, not a demo

A useful pilot has a clear boundary. It names the process, the people who own it, the records or documents the system may see, the action it may take, and the person who can stop that action. It defines the current way of working before the supplier changes it. It then tests whether a proposed system improves a business-relevant measure without failing a safety or quality condition.

That does not mean every pilot needs a complicated model. A deterministic rule, better form, search index, OCR product, or ordinary workflow automation may be cheaper and easier to maintain. Switzerland’s SME portal advises companies to identify suitable use cases, assess whether data is compatible, establish an internal framework, train employees, and evaluate impact; it also cautions that popular general-purpose tools may not fit every task. Treat this as a sequence of buyer questions, not a recommendation to buy a particular technology. SECO SME Portal: five tips for integrating AI.

The recommendation is conditional: compare a consultant’s proposal with the simplest non-AI alternative. If the supplier cannot explain why AI is needed, cannot define an acceptance test, or will not expose the operating costs and ownership, do not approve production work yet. Commission a short discovery with a fixed deliverable, or pause until your process and data are ready.

Why a pilot can remain a pilot

A pilot often stalls for reasons unrelated to model quality. The work may have no internal owner; legal or brand review may begin only after the demo; source data may be inconsistent; the team may not know what to do when the system is uncertain; or the prototype may depend on an account, connector, or prompt that only the supplier can maintain.

One entrepreneur-forum thread describes this pattern in the author’s own experience: tool seats bought after a compelling demo go unused, customer-facing use gets blocked by compliance or brand concerns, and no employee owns integration or measurement. This is an individual account, not a survey or evidence that the pattern is common. It is useful as a question prompt: who has authority to approve this workflow, and what decision will they need to see before the pilot starts? Fastlane forum discussion.

A ZHAW project with the Winterthur Chamber of Commerce, started in April 2026 and still marked ongoing when reviewed, says firm-level guidance is limited because many available indicators are aggregated nationally or across Europe. Its research asks how technology, organization, and environment relate to adoption and project outcomes. That is a reason to assess your own starting position; it is not a completed finding about the best consultant or a measured regional success rate. ZHAW: Current State of AI Adoption in Swiss SMEs.

The Swiss Data Science Center’s Canton Zurich SME program publicly describes expert-guided prototypes, program requirements, open-source outputs, and two case-study videos: one on forecasting for customer support and another on knowledge retrieval. These examples can help a buyer ask what evidence a real prototype produced. They are selected program cases, not a representative comparison of consulting firms and not a guarantee that a similar result transfers to your business. SDSC and Canton of Zurich SME AI Program.

A practical supplier decision rule

Use three gates before scoring anything. They are not weights that a supplier can average away.

1. Legitimate task: a process owner can explain the task, its pain, the current baseline, and what would change if the pilot works.
2. Safe and lawful path: the data, access, intended action, supplier role, and review controls have an approvable route. If this remains unclear, restrict the pilot to synthetic or properly minimized data.
3. Operable handover: a named employee can own the workflow after the pilot, and the proposal identifies support, dependencies, rollback, and recurring costs.

If any gate fails, classify the offer as not ready. A high weighted score must not compensate for missing permission, unbounded data use, or no owner. If all three pass, score the proposed pilot across the acceptance card below.

The 12-check pilot acceptance card

The card is a reusable original decision asset. It is a constructed procurement tool, not a measured survey of vendors or SMEs. Complete one row for each item using Pass, Needs evidence, or Fail, and paste a link or contract reference in the evidence column. “We discussed it” is not evidence. Evidence can be a signed scope, test fixture, workflow diagram, data-flow statement, sample result, runbook, or priced support schedule.

A supplier can pass the scorecard without agreeing to every proposed number. The important point is that the contract makes disagreements explicit before the test. A proposal that is strong on technical build but weak on ownership or data access is not a balanced offer; it is a partially specified project.

How to make the baseline useful

The baseline should be collected from the process that the pilot will actually touch. If an employee spends time finding a document, measure the time from a defined request to a verified answer, not just model generation time. If the process is invoice classification, record the number of items, the categories, the review rule, and the correction rate. If the task is drafting replies, distinguish draft creation from human review and sending.

Choose a unit that employees can recognize. “Minutes per completed request” is more useful than “tokens per answer” for an operations decision. “Correctly routed case within one working day” may be more useful than raw classification accuracy if delayed routing is what creates cost. Include the quality condition that makes a fast answer unacceptable: wrong customer, missing legal attachment, wrong language, or unsupported commitment.

Write the baseline as a small table with a date range, inclusion rule, excluded cases, and data owner. For example: “For requests received through the shared support mailbox between 3 and 14 November, measure active staff minutes from first review through approved routing; exclude spam, duplicates, and cases requiring a regulated professional decision.” This is a sample specification only. It does not report observed values.

Do not let the vendor measure only the tasks that the tool handles well. Include failed or ambiguous cases and work that the tool sends back to a human. Otherwise the apparent saving may merely shift time from the first employee to the reviewer. Where the data is too sensitive to share during discovery, ask the supplier to design the test on synthetic records or in your controlled environment until the data path is reviewed.

Define acceptance before the build

“Accuracy” is not one metric. It can mean exact match, acceptable category, grounded answer, correct escalation, or a human’s approval. A proposal should state the unit and denominator. If a tool produces a hundred answers but abstains on some, the contract should say whether abstentions count as safe failures, missed opportunities, or both.

Write a one-page acceptance specification: the task; the included population and excluded cases; how test cases are selected; who labels expected behavior; how reviewer disagreement is resolved; the list of critical errors that block acceptance; the metric and formula; the run conditions; and the person who signs pass, redesign, or stop. Record the model or service version where available, configuration, prompt, integration state, data snapshot, and run date. Without those details, a later change can make an apparently identical test incomparable.

A useful two-part rule combines a service measure with safety constraints. For example, a drafting workflow may require that a specified share of eligible drafts needs no material factual correction, while every draft containing a price, eligibility decision, or legal commitment must be held for a human. The share and threshold must come from your risk tolerance and baseline, not a generic industry benchmark.

A 12-case synthetic acceptance fixture

Below is a small test fixture a buyer can adapt before the supplier begins. It contains twelve designed scenarios, not twelve observed model results. Its purpose is to prevent a pilot from testing only normal inputs. Replace each scenario with an approved test case and have a domain owner label the expected behavior before seeing system output.

This fixture tests process behavior, not just generated text. Retain the case identifier, input version, expected result or action, actual output, reviewer decision, model/configuration version, and disposition. Do not put real customer data in an article, shared demo, or unmanaged test workspace. If realistic examples are necessary, build an approved, minimized test set and document who can access it.

A simple scoring model

Use hard gates first, then a weighted score to compare offers that remain eligible. For each of the twelve checks, assign 0 for absent, 1 for partial or unverified, and 2 for documented and testable. Maximum score: 24. Treat 18 as a working shortlist threshold only if every hard gate passed and no critical error remains unresolved. The value 18 is a proposed decision rule in this article, not a statistically validated cutoff or market benchmark. A board or owner may set a higher threshold; a lower total cannot be rescued by a beautiful demo.

The checklist is intentionally equal-weighted. If your workflow creates meaningful personal, financial, employment, health, or safety effects, add risk-weighted review. Do not treat a low-risk price estimate and a high-risk employee decision equally just because they are each one row. A hard fail remains a hard fail even when the total is high.

A compact record can look like this:

Pilot: _________________________________________________
Process owner: __________________  Decision approver: __________________
Baseline window and data source: _______________________________________
Excluded cases: ______________________________________________________
Primary measure and formula: __________________________________________
Critical errors that block acceptance: _________________________________
Test-set custodian and access route: ___________________________________
Supplier/subprocessor and data-flow reference: _________________________
Run conditions (model/version/configuration/date): _____________________
Total score (0–24): ______  Hard gates all pass? yes/no
Decision: stop / redesign / continue  Decision date: ___________________
Handover owner and rollback tested on: _________________________________

This is a buyer-created record. It does not replace a contract, privacy review, security assessment, or professional advice.

Swiss data and supplier responsibility: what belongs in the gate

A Swiss company remains responsible for decisions about its personal-data processing even when work is outsourced. The Federal Data Protection and Information Commissioner says controllers must select processors carefully, instruct them, and monitor them where necessary. The commissioner also explains that a data-protection impact assessment is required where processing is likely to create a high risk to the personality or fundamental rights of data subjects. That does not mean every AI pilot automatically needs a DPIA. It means the buyer must assess the actual data, purpose, scale, circumstances, and risk instead of relying on a vendor’s generic “compliant” label. FDPIC: Outsourcing of data processing and FDPIC: Data protection impact assessment.

For each proposal, ask for a data-flow diagram with the business data source, model or service, logs, backups, support access, subprocessors, retention, deletion, and any transfer route. Clarify whether the supplier uses customer prompts or outputs to improve a service, whether a human operator can inspect them, and what happens after termination. If the supplier cannot answer yet, the scope should say that personal or confidential data will not enter the test until the answer is approved.

The English translation of the Swiss Federal Act on Data Protection on Fedlex is informational and states that the English version has no legal force. The applicable legal text and obligations depend on the specific operation and other rules that may apply. Fedlex: Federal Act on Data Protection, English translation. Cross-border clients or processing may bring other regimes or contractual duties into scope; ask qualified counsel when that question matters.

A useful supplier response is concrete: “Here are the categories we need; here is the service and subprocessor that receives them; here is the retention setting; here is how access is limited; here is the deletion and export procedure; here is the incident contact; here is the decision still requiring your counsel.” A weak response is a broad assurance with no route to inspect or contract the controls. For a supplementary security questionnaire, CISA’s Secure by Design guidance can provide prompts about responsibility, defaults, and secure product behavior; it is a US cybersecurity reference, not Swiss law or an AI certification. CISA Secure by Design.

Decide what the consultant must deliver

A pilot should buy a set of artifacts, not just a build. The statement of work can request:

1. A process map and baseline record approved by the owner.
2. A shortlist of candidate approaches, including a non-AI alternative.
3. A data inventory and flow diagram for the chosen design.
4. A risk and dependency register with named owners and dates.
5. A versioned test fixture, expected behavior, and acceptance report.
6. A human review and escalation design, including who can suspend the workflow.
7. A deployment plan that separates test and production access.
8. A runbook, support route, configuration export, and rollback procedure.
9. Staff training with task-based exercises in the languages the team uses.
10. A closeout decision: stop, redesign, or continue, with known costs and remaining uncertainty.

The supplier should identify which deliverables are included in the fixed fee and which are change requests. Define review windows and what happens if the customer or consultant misses a dependency. Accept the discovery report separately from implementation; you may accept a prototype as a learning result while rejecting it for production.

Price the operating path, not just the pilot

Compare total cost using the same time horizon and scope. Include consulting, licenses, tokens or per-use fees, storage, integrations, data preparation, human review, security assessment, training, support, monitoring, and exit. Ask for a low, expected, and high usage scenario with assumptions. These are scenario estimates, not promises. Keep one-time implementation separate from recurring costs so that a pilot cannot appear inexpensive by leaving production support outside the quote.

The cost of review is often invisible. If an employee must check every answer, include that time in the operating model. If the tool has a human-in-the-loop step, define how long the review takes, when the queue is paused, and who handles a peak volume. If the vendor proposes “autonomous” operation, ask what action is authorized and what makes the system stop. The fastest path is not necessarily the least expensive path when correction, integration, and support are counted.

A useful economic test is a break-even equation, not an ROI promise:

Net period value = (baseline labor cost avoided or capacity redeployed)
                   - recurring software and hosting
                   - human review and exception handling
                   - support and maintenance
                   - amortized implementation and exit costs

Use values your finance or process owner can defend. If time is freed but not redeployed, describe that as capacity released, not cash saved. If error reduction is the purpose, calculate the cost of errors and the cost of catching them. If a small volume makes the fixed integration expensive, the correct answer may be a manual process or standard software.

Make handover and exit acceptance criteria

At the end of a pilot, an employee who did not build the workflow should be able to explain its inputs, output, exceptions, and failure route. They should be able to run the test fixture, inspect logs permitted by policy, update an approved configuration, and disable the workflow. The consultant should leave documentation in a format the company can access and reuse.

Ask who owns source code, prompts, schemas, evaluation data, and custom connectors; who can reuse generic components; what third-party licenses restrict; and how customer data is returned or deleted. The contract should distinguish intellectual-property ownership from operational access. You do not need to own a vendor’s entire platform to retain an exportable business process, tested requirements, and the ability to migrate.

A rollback is more than a sentence. Define the trigger, person authorized to execute it, maximum tolerated data loss, treatment of queued work, and route back to the previous process. Test this in a non-production environment. The pilot is not reversible if the company cannot identify the version to restore or if a connector has already changed live records without an audit trail.

Compare proposals without being dazzled by demos

Ask each finalist to fill the same one-page response. Score evidence, not charisma. A demonstration is useful for understanding interaction design; it is weak evidence for data quality, reliability, review burden, privacy, maintainability, or total cost.

A smaller supplier may be better than a large one for a bounded job, and a large systems integrator may be needed for complex integration or regulated operations. Gartner’s capital-allocation guidance discusses staged learning and reassessment as alternatives to treating every investment as a one-shot hurdle decision. Apply that as a general investment-management lens, not as an AI-vendor benchmark or an SME-specific result. Gartner: Building an Effective Capital Allocation Strategy for CFOs. Brand size alone does not establish delivery fit. Ask for references in a similar workflow and ask the reference what had to be done internally after the vendor left. Treat marketing case studies as examples, not independent evaluation.

How to interpret survey and program evidence

The SECO SME Portal article reports findings from an EY survey of 604 employees and summarizes company-stage and reported-barrier percentages. The population named by the page is employees; it is not a census of Ticino SMEs, a randomized comparison of consultants, or evidence that a particular pilot will succeed. The page says 31% of respondents’ companies were still in pilot phase and lists data, security, and skills as reported barriers. Use those figures only to understand the distinction between adoption and broad transformation, and verify the underlying EY report before using them in a business case. SECO SME Portal summary, published 15 July 2026.

The OECD report on generative AI and the SME workforce is a broader research source for workplace adoption questions, not a consultant evaluation and not a Ticino-specific estimate. Keep its population and research method separate from the ZHAW project and from selected implementation cases. OECD: Generative AI and the SME Workforce.

Likewise, the Swiss SME program page lists a selected cohort and public prototypes. Its 2025 RAG work may show what a collaborative research-to-prototype activity can produce, and its video case pages can help a buyer ask about test conditions and handover. It cannot tell you the average result of all consultants. Read the underlying reports and ask what the prototype did not cover before treating it as a model for your project. A program can be excellent and still have a different selection process, funding structure, and support horizon than a private engagement.

These limitations matter because several evidence types get blurred in sales conversations: adoption surveys measure reported use; vendor cases illustrate selected deployments; a prototype demonstrates feasibility under specified conditions; a production service must also meet reliability, governance, integration, and support needs. Do not combine them into one “AI works” statistic.

Failure modes to design out

• The wrong problem is automated. The process has avoidable steps, unclear policy, or duplicate data. The model can accelerate the wrong work. Map and simplify first.
• The baseline is invented after the demo. The vendor compares pilot results with memory or a different period. Freeze the measurement rule before testing.
• Only easy cases are tested. The model looks strong while ambiguous, multilingual, or exception cases are hidden. Include a case taxonomy and hard failures.
• A single average conceals a dangerous tail. A high mean can coexist with a rare but unacceptable error. Track critical errors individually and fail closed where consequences require it.
• Review becomes unpaid operations. “Human review” sounds free until someone must check every item. Measure reviewer time and queue effects.
• Data approval comes too late. A demo uses realistic customer records before access and retention are approved. Use synthetic or minimized data until the route is accepted.
• A named model changes. A provider updates a model or settings and the output changes. Record version/configuration where available and run regression tests before release.
• Permissions exceed the task. A connector can read or modify more than necessary. Limit access and test denied actions.
• The consultant retains the only knowledge. The system works during the engagement but no employee can diagnose or pause it. Make handover a paid, accepted deliverable.
• Savings are counted twice. Released capacity is counted as both cash reduction and new capacity. Separate cost avoided from capacity redeployed.
• The exit is theoretical. No data export, queued-work plan, or rollback has been tested. Rehearse it before production.
• Pilot success is confused with authorization. Passing a technical test does not approve customer-facing, employee-impacting, or regulated use. Keep technical acceptance and organizational approval distinct.

A Mermaid decision path

flowchart TD
    A[Name one process and owner] --> B{Baseline and task evidence available?}
    B -- No --> C[Discovery or process cleanup]
    B -- Yes --> D{Data and action path approved?}
    D -- No --> E[Use synthetic or minimized data; resolve review]
    D -- Yes --> F{Simpler non-AI option adequate?}
    F -- Yes --> G[Use simpler option and measure]
    F -- No --> H[Agree acceptance card and test cases]
    H --> I{Hard gates and critical errors pass?}
    I -- No --> J[Stop or redesign]
    I -- Yes --> K{Owner, support, cost, exit accepted?}
    K -- No --> J
    K -- Yes --> L[Bounded pilot]
    L --> M{Evidence supports the agreed use?}
    M -- No --> J
    M -- Yes --> N[Separate approval for controlled operation]

The diagram separates a pilot from production. Passing a pilot acceptance test means the agreed test passed under recorded conditions. It does not prove performance on every future case, certify legal compliance, or authorize every user and data category.

A copy-ready acceptance clause

Adapt this only with your lawyer and process owner; it is a drafting aid, not legal advice:

The pilot is limited to [named workflow], [user group], and [approved data categories]. Before development, the parties will approve the baseline window, test-set sampling rule, critical-error list, metric formula, and run conditions in Appendix A. The supplier will provide the process map, data-flow statement, test results, configuration/version record, runbook, training, and rollback procedure listed in Appendix B. No production action or new data category is permitted without written approval by [customer role]. Acceptance of the prototype is limited to the test conditions in Appendix A and does not constitute authorization for broader use. At closeout, the customer will choose stop, redesign, or continue by [date]; no automatic extension applies. Data return/deletion, access removal, export, and support fees at termination are set out in Appendix C.

The clause needs tailoring to the actual service, contracts, and applicable law. It should not replace a data-processing agreement, security terms, or sector-specific review. Its value is that it makes the decision packet visible before the vendor starts building.

When hiring a consultant is the wrong next step

Do not hire a build team yet if the task is too rare to justify integration, no one owns the process, the source data is inaccessible, policy is unsettled, or the business cannot define an acceptable error. A short internal workshop can be more valuable than a prototype when employees disagree about what “done” means.

Do not use a general-purpose assistant for a task that requires authoritative source-of-truth updates unless the workflow constrains retrieval and writes, logs the action, and provides a tested correction path. Do not put confidential records into a public tool simply because a colleague already uses a personal account. Do not infer that a service is suitable from its Swiss office address or a “Swiss AI” label; examine the actual provider, subprocessor, data flows, access, and contractual terms.

If there is a plausible task but insufficient evidence, buy a discovery phase with a concrete exit artifact: baseline, data map, alternatives, acceptance fixture, and a go/no-go recommendation. If the consultant says discovery is unnecessary, ask how they know the workflow, exceptions, data rights, and approval path before seeing the environment.

How to run the first buyer meeting

Send the same brief to each candidate. Include one workflow, an example input with sensitive details removed, the current path, a rough volume range if known, the owner, the business consequence of delay or error, and constraints such as language, system, and data handling. Ask the supplier to return its assumptions, five unanswered questions, the simplest alternative, the smallest safe pilot, a list of dependencies, and what would cause it to recommend against building.

During the meeting, ask the supplier to walk one normal case and one failure case. Notice whether it identifies uncertainty, source evidence, and a human decision point. Ask who will write integration code and attend acceptance review. Ask whether the person in the call will do the implementation or hand off to another team. Request a named delivery role, not only an organization chart.

After the meeting, compare answers against the acceptance card. Record unknowns instead of filling them with favorable assumptions. Give every “Needs evidence” item an owner and due date. If a supplier cannot provide evidence until after signing, decide whether you are willing to pay for that uncertainty and constrain what data or action the pilot may use.

Checklist before signature

• [ ] One process, owner, user group, trigger, output, and excluded task are named.
• [ ] A baseline and measurement window are written down.
• [ ] A non-AI or simpler alternative has been considered.
• [ ] Test cases include difficult, incomplete, conflicting, and out-of-scope inputs.
• [ ] The acceptance metric has a denominator and a reviewer.
• [ ] Critical errors and safe fallback behavior are explicit.
• [ ] Data categories, access, service, subprocessors, retention, and deletion are documented.
• [ ] Privacy, security, and any sector review have an owner and decision date.
• [ ] The actual delivery people, support path, and escalation contact are identified.
• [ ] Cost includes licenses, usage, integrations, review, support, maintenance, and exit.
• [ ] Training and operating ownership are included in the scope.
• [ ] Configuration, test results, runbook, export, and rollback are deliverables.
• [ ] Production approval is separate from prototype acceptance.
• [ ] Stop, redesign, and continue each have a trigger, approver, and date.
• [ ] No automatic renewal or undocumented credential dependency remains.

Method, sample, and limits of the original asset

The acceptance card and twelve-case fixture were authored for this article on 3 November 2026. The fixture contains 12 designed scenarios; it is not a sample of vendors, customer records, model outputs, or measured production incidents. The 0–2 score and suggested shortlist line of 18/24 are proposed decision aids, not statistically validated thresholds. The scorecard excludes sector-specific requirements and should be extended where financial, health, employment, safety, or regulated decisions are involved. No performance statistics are claimed from this constructed material.

The research cutoff is 3 November 2026. The source review included the primary Ticino guide linked above; current Swiss federal SME guidance; the FDPIC’s outsourcing and DPIA guidance; Fedlex’s English informational translation; the ZHAW project page; the Canton of Zurich/SDSC program and its linked video case-study descriptions; a SECO SME Portal survey summary; and one public entrepreneur-forum discussion. The forum was used only as an anecdotal question signal. I did not treat selected program cases, a single thread, or the survey summary as representative of Ticino firms or consulting performance.

The decision rule is an inference from the practical need to align task, evidence, risk, and operations. The recommendation is to use the scorecard to make a proposal auditable and a pilot reversible. It is not a guarantee of financial return, compliance, model accuracy, or search ranking.

Annotated sources

• IAPME Suisse — AI Consultant Lugano: Ticino SME Guide 2026: local context, multilingual workflows, consultant questions, and a pre-existing buyer checklist; this article adds a contract acceptance card.
• Swiss Federal SME Portal — Five tips for effectively integrating AI: use-case selection, data compatibility, internal framework, staff training, and impact evaluation.
• Swiss Federal SME Portal — Support to the digitization of SMEs: identifies universities, professional networks, chambers, economic promotion offices, and consulting firms as possible support routes; its source was reread in August 2019, so treat it as a directory rather than a current program inventory.
• FDPIC — Outsourcing of data processing: controller duties when a processor is used, including careful selection, instructions, and monitoring where necessary.
• FDPIC — Data protection impact assessment: high-risk trigger and risk-based purpose of a DPIA; not a claim that every AI pilot needs one.
• Fedlex — Federal Act on Data Protection, English translation: statutory text; the site says the English translation is informational and has no legal force.
• ZHAW — Current State of AI Adoption in Swiss SMEs: ongoing regional project begun in April 2026 and its stated research question; no outcome claims are inferred from an ongoing project.
• Swiss Data Science Center and Canton of Zurich — SME AI Program: program requirements, selected participants, published outputs, and listed case-study recordings on customer-support forecasting and knowledge retrieval.
• SECO SME Portal — AI is becoming widespread in Swiss companies: summary of an EY survey of 604 employees, used with explicit population limitations.
• CISA — Secure by Design: supplementary security-design prompts; not Swiss legal guidance.
• OECD — Generative AI and the SME Workforce: broader workforce research, distinct from local or vendor-performance measurement.
• Gartner — Building an Effective Capital Allocation Strategy for CFOs: a general staged-investment lens, not an AI consultant benchmark.
• The Fastlane forum — AI business discussion: one contributor’s concerns about unused seats, approval barriers, absent process ownership, and pilots that do not reach production; anecdotal only.