How to Choose an AI Consultant in Switzerland: A Fair Pilot Scorecard

Posted on Oct 24 • Originally published at iapmesuisse.ch

Choosing an AI consultant is not mainly a contest between impressive demos. It is a decision about who can turn one defined business problem into a safe, supportable workflow—and who will still be able to explain the result after the workshop is over. For a Swiss small or medium-sized business, compare a consultant, an agency and a software product against the same work sample, the same access limits and the same acceptance test. Do not ask each bidder to present its best showcase and then compare the presentations as if they were equivalent evidence.

The short recommendation: first decide whether the need is a standard product, a bounded integration or a genuinely bespoke workflow. Then give each serious option the same small, representative test pack. Score evidence, not confidence. Keep a separate set of non-negotiable gates for data access, human approval, operating ownership and exit. A high weighted score cannot compensate for a vendor refusing a basic control.

This article contributes an original buyer-run artifact: a normalized 100-point scorecard, a common test-pack protocol, explicit hard-veto gates and a reusable pilot acceptance record. It is a designed decision aid, not a market survey, benchmark, or claim that any vendor has passed it. Its weights are recommendations. A reader should change them before issuing a request for proposal if its risk profile or business priorities differ.

Search results for Swiss AI consulting usually help with the first shortlist: they describe agencies, independent consultants and SaaS products; they recommend checking references, sector experience, privacy, tool independence, handoff, ongoing costs and whether a pilot has a route to deployment. Those are sensible questions. But most comparison pages are published by providers or intermediaries, so their descriptions are not independent evidence that a specific provider can solve your particular workflow. A service page can tell you what a provider sells; it cannot establish that your case will meet your acceptance criteria.

The source guide linked below is a useful example of the genre and also illustrates why source control matters. The visible page says that a Digital Switzerland 2025 report found that 67% of Swiss SMEs explored an AI tool, but the sentence does not link the exact report or disclose the sample, field date, question wording or exclusions beside the claim. The same page's pricing passages contain the phrase “cadrage personnalisé” where a number or range would normally appear. These observations do not prove the claims false. They mean a buyer should not reuse them as verified statistics or price evidence without finding the underlying source. The page is a shortlist aid, not a data set.

There is also contrary evidence to the reassuring story that “a pilot” is enough. A joint OST / Swiss FinTech Innovations report on the Swiss financial sector says it surveyed 24 institutions in summer 2025 and complemented the survey with selected practitioner interviews. It reports that many initiatives remained upstream, while the headline summary says 65% of production cases met or exceeded expectations. The population is financial institutions, not all Swiss SMEs; the work also involved industry contributors and was not a randomized comparison of consultants. The useful inference is narrower: successful production and stalled pilots can coexist, so a demo or proof of concept is not the same thing as deployability. Read the OST / SFTI study and its method.

The missing practical layer is a buyer-controlled comparison: identical inputs, a declared baseline, visible failure handling, a costed operating path and an exit test. A provider questionnaire can reveal what to ask; the scorecard below gives you a repeatable way to compare answers.

The word “AI consultant” hides several different offers. A strategy adviser may help select use cases and quantify constraints but never build the workflow. An implementation partner may connect a model to an existing CRM or document process. A SaaS provider sells a mostly standardized feature, with configuration rather than custom development. An engineering firm may build and operate a bespoke service. A training provider may raise staff capability without owning a production system. These can all be valuable; they are not interchangeable bids.

Start with the work, not with the label. Write one sentence in this form: “When [specific event] occurs, [named role] needs [decision or output] from [identified information], within [operating constraint], while [human] remains accountable for [consequence].” If you cannot fill those blanks, the first purchase may be discovery or process redesign, not a production AI build.

This routing is an inference from delivery shape, not a statement about the quality of any category. A small firm can have excellent engineering; a large consultancy can be wrong for a narrow task. The point is to compare the actual scope and risk transfer. Do not pay a bespoke-project price merely because a supplier calls a standard connector “custom AI.” Conversely, do not force a generic SaaS package onto a process where its data boundary, exception rate or audit needs do not fit.

Score each dimension from zero to five, then multiply by its weight divided by five. A zero means no credible evidence or an unacceptable answer. A three means the bidder meets the written requirement with evidence that is relevant but incomplete. A five means the bidder demonstrates the requirement on the common test pack, explains limitations, and supplies an artifact your team can retain. Scores one, two and four are intermediate. Record “not tested” separately; never convert missing evidence into a neutral three.

The weight design gives a combined 40 points to problem fit and data/security because a technically elegant answer to the wrong task, or one that crosses an unacceptable data boundary, should not win by presentation quality. Reliability and production operation receive 30 points together because outcomes must survive the happy path. Commercial and people/exit dimensions account for the remaining 30. This weighting is a normative starting point, not empirically optimized. A healthcare provider, a bank, a one-person consultancy or a public body may reasonably move weight toward safety, regulation, continuity or procurement assurance.

For each dimension, retain four columns: score, artifact reviewed, unresolved assumption, and owner/date for checking it. Example formula: weighted_points = weight * score / 5. If a bidder receives 4 for problem fit, the contribution is 20 * 4 / 5 = 16 points. This arithmetic only standardizes your own comparison; it does not mean the bidder has a 80% probability of success.

Use bands only to structure discussion, not as universal truth. A buyer may choose “advance” at 75 points, “clarify” between 60 and 74, and “do not advance” below 60 as an internal procurement rule. Those values are suggested thresholds for a first screen, not industry norms and not output from the OST/SFTI survey. More importantly, a bidder fails regardless of total if it fails a hard gate below. Set the threshold before receiving bids, keep it stable during the comparison, and record who approved any exception.

Use vetoes for minimum safe conditions. A zero on one of these gates means no pilot with real business data until the issue is resolved in writing. Depending on the use case, the remedy may be a synthetic-data test, a restricted environment, a different supplier or a no-build decision. A vendor’s willingness to discuss the issue is not itself proof that it is controlled.

The official EU AI Act overview is relevant only where its scope applies—for example, systems placed on the EU market or systems whose outputs are used in the EU. It is not a blanket statement that every Swiss SME is subject to the same obligations. The specific role, system, intended use and territorial facts matter; get qualified legal advice for a real classification. The Act's risk-based structure is still a useful prompt for asking what the system does, who uses it and what consequences follow. European Commission: regulatory framework for AI.

For tool-using generative systems, ask how permissions and actions are constrained. OWASP's LLM application risks describe “excessive agency” as a risk associated with excessive functionality, permissions or autonomy. That gives the buyer a practical test: can the supplier demonstrate a least-privilege configuration and show that a model suggestion cannot turn into an external side effect without the defined control? OWASP Top 10 for LLM Applications.

The same-input test is the core of fair comparison. Pick a small set of examples that represents normal work, edge cases and deliberate traps. Make the pack large enough to expose different behavior but small enough that your reviewers can inspect every result. Do not upload live confidential records to a bidder just to make the test feel realistic; use approved redacted, synthetic or specifically authorized samples.

For a document workflow, a pack could contain: a straightforward in-scope document; a document with a missing field; a contradictory pair of documents; an out-of-scope request; a prompt containing instructions that should be treated as untrusted content; and a case where the right answer is to abstain or ask a person. The exact cases should come from your process owner and risk reviewer. Record why each case exists, expected acceptable behavior, unacceptable behavior and who adjudicates disagreement.

Before the demonstration, freeze the test pack version, output format, time allowance, tool access and evaluation rubric. Require each bidder to state what they changed from its default product or demo configuration. Do not let one bidder use a hand-picked golden example while another sees a difficult case. If a provider cannot run your exact test due to a legitimate product constraint, mark the case “not comparable” and document the limitation; do not award a pass by assumption.

For each case, capture at least: expected user outcome, actual output, factual or procedural errors, whether a citation or source is present when required, whether the system recognizes missing information, whether a human checkpoint triggers, time spent correcting the output, and any data or permission boundary crossed. The correction burden matters. A fluent answer that requires the employee to verify every sentence may not save work compared with the existing process.

Keep an untouched baseline. Run the existing workflow on the same cases, under the same definition of “complete.” The baseline might be a manual process, a rules-based system or a current product. Measure wall-clock time and active correction time separately. If the old process includes queueing or waiting, report that separately from staff effort. This avoids crediting the AI for delays it did not remove or comparing a polished model answer with an unfinished manual case.

Design the pilot as a bounded decision experiment. Define a start and end, business owner, technical owner, security reviewer, user group, environment, allowed data and stop route. The length should be long enough to include representative work and operational support but not chosen to make a desired outcome inevitable. There is no universal “two-week” or “one-month” duration; derive it from task volume, review capacity, change windows and the need to observe exceptions.

Write acceptance criteria before the first run. Examples include: the workflow reduces the median active handling time without worsening the error rate beyond an approved tolerance; every external action stays behind an approval; unsupported cases route to a person; logs can be reconciled; and the service can be switched off without losing the source records. Do not invent a target percentage simply because the provider has used it in another customer case. Have the process owner choose the smallest measurable improvement that would justify operating cost and change burden.

Pre-register the measurement method in plain language. State the unit of analysis (case, document, call or transaction), inclusion and exclusion rules, how incomplete cases are treated, who labels quality, and how disagreement is resolved. If results will be compared before and after, document what else changed during the period. A change in staffing, volume, templates or seasonality can make a simple before/after result misleading. When random assignment is impractical, label the result as an operational comparison, not a causal estimate.

Track a small set of outcomes rather than every available dashboard metric: completion quality; active correction time; exception and abstention handling; user adoption; reliability and incident burden; and total cost to operate. For each metric, define numerator, denominator, time window and source system. “Accuracy improved” is not a metric until the team says which outputs count, who verified them, what error severity means and what happened to unreviewed outputs.

The pilot should contain a rollback rehearsal. Disable the AI path for a controlled test case, confirm the manual route works, and verify the record needed to continue the workflow remains accessible. If your plan assumes the model will always respond, the pilot has not tested the system that the business would actually operate.

Do not compare a consultant’s day rate with a SaaS subscription as if they buy the same thing. Build a total-cost worksheet with separate rows for discovery, configuration, custom development, integration, data preparation, security/legal review, licences, model usage, monitoring, support, retraining or content updates, internal staff time, change management, and exit. Ask which amounts are fixed, usage-based, pass-through or conditional. Record what causes a change request and who approves it.

Use a transparent planning formula rather than a single headline quote:

period_cost = setup + integration + internal_time + (subscription * periods) + measured_usage_cost + support_and_monitoring + change_budget + exit_or_transition_cost Enter fullscreen mode Exit fullscreen mode This is a checklist formula, not an ROI forecast. Fill each term from a quote, an internal estimate or a marked unknown. Do not silently replace unknowns with zero. For usage-based services, record the unit charged (request, token, minute, seat, document or workflow run) and use an observed pilot sample only if it is representative enough for the intended scenario. Report low, expected and high-volume cases with the assumptions visible. If you do not yet know volume, treat it as a sensitivity variable rather than inventing a forecast.

Ask the supplier to separate one-time delivery from recurring responsibilities. Who updates prompts, test cases, connectors and business rules when the process changes? Who investigates a regression? What is included in support, and what is a billable change? Which party carries the operational pager? A low initial quote can conceal a high internal support burden; an apparently expensive partner may include controls and training that you would otherwise have to buy separately.

Make procurement compare equal scope. If one proposal includes production monitoring and another ends at a demo, label the difference in the decision memo. Do not “normalize” them by assuming missing services are free or automatic. Request an option price for each stage—discovery, controlled pilot, deployment readiness and operations—so the buyer can stop at a natural gate without being forced into a large commitment.

Portability is not just a line in a contract. Ask the delivery team to show, during the evaluation, what the buyer receives at handover: process map, architecture and data-flow diagram, configuration, code or scripts where applicable, test pack, evaluation results, deployment instructions, access inventory, operating runbook, known limitations, and incident or rollback procedure. If the vendor uses proprietary components, ask what can be exported and what must be rebuilt.

Give the bidder a small transition exercise: explain the system to an internal engineer or a second supplier who did not attend the sales meeting. Can that person identify the source data, permissions, failure route, owner and deployment procedure from the retained artifacts? This does not prove a smooth exit under all conditions, but it surfaces undocumented dependencies while the relationship is still optional.

Review credential ownership. The buyer should know who owns cloud accounts, API keys, domain names, storage, model accounts and billing. Avoid shared personal accounts. Define how access is granted, reviewed and revoked, and how secrets are rotated when a contractor leaves. Confirm that disabling the supplier’s access does not disable the business’s only copy of critical data or its ability to operate the workflow.

Ask how the provider handles model or vendor changes. A cloud model may change behavior, price or availability. A local or open model may reduce some dependencies while increasing operational responsibilities. Neither route is inherently safer or cheaper in every case. Require a change notice, regression test and approval process proportionate to the workflow. Preserve the option to fall back to a deterministic or human process if a new version fails your acceptance pack.

The consulting dimension of the scorecard is not a substitute for independent validation. A firm’s governance framework can be useful as a source of questions and implementation patterns, but its own publication is not evidence that a proposed configuration meets your control requirements. For example, KPMG’s trusted-AI governance overview can inform a discussion about roles and controls; the buyer must still verify the actual contract, configuration and operational evidence.

Imagine a fictional Swiss distributor comparing a configured document SaaS product, an independent integration consultant and a multi-disciplinary agency for extracting fields from supplier documents into a finance system. The scenario is illustrative; no real vendors were tested, no client result is being reported, and the score values below are placeholders to demonstrate the arithmetic. Replace them with your own test results.

Suppose the product receives a strong initial fit score but cannot show a required export path. The consultant demonstrates the common test pack and clean rollback but has limited support coverage. The agency provides a named operations team and a more complete handover but scores lower on cost clarity because usage and change terms remain uncertain. A weighted result may help explain trade-offs, yet the product still fails the exit hard gate until export is shown, and the agency should not be treated as production-ready until its pricing uncertainty is resolved. The right decision may be to ask both for a narrow clarification rather than selecting the current numerical leader.

Here is a worked sample for one fictional bidder: problem fit 4/5 contributes 16 of 20; data/security 3/5 contributes 12 of 20; reliability 3/5 contributes 9 of 15; operations 2/5 contributes 6 of 15; commercial clarity 4/5 contributes 8 of 10; team evidence 4/5 contributes 8 of 10; portability 2/5 contributes 4 of 10. Total: 63/100. The arithmetic is exact; the underlying scores are invented placeholders. The outcome should therefore read “clarify,” not “63% likely to succeed.” If a hard gate fails, write “blocked pending evidence” even if the numerical total is higher.

To prevent false precision, the proposed model was designed on 24 October 2026 by mapping common buyer decisions to seven evidence dimensions and allocating a 100-point total as a transparent recommendation. It has no empirical validation sample (N=0 vendor pilots), excludes vendor performance benchmarking, and does not estimate expected ROI or probability of success. It should be adapted and locally tested. The OST/SFTI report’s sample of 24 Swiss financial institutions is separately sourced evidence about that sector; it was not the sample used to create these weights.

Keep the record short enough that a procurement lead can complete it after each comparable test. A blank field is a result: it tells you what still needs to be verified. Do not let a sales presentation replace the evidence item.

decision_id: " AI-PILOT-YYYY-NNN" decision_date: " YYYY-MM-DD" process_owner: " role, not only a person" workflow_sentence: " event -> decision/output -> accountable role" baseline_version: " manual or current-system procedure" test_pack_version: " filename and checksum" supplier_and_offer_type: " SaaS | consultant | agency | engineering partner" data_classes_allowed: [ " synthetic", " approved-redacted" ] hard_gates: data_boundary: " pass | fail | pending + evidence link" least_privilege: " pass | fail | pending + evidence link" human_owner: " pass | fail | pending + role" audit_and_fallback: " pass | fail | pending + test record" exit_and_export: " pass | fail | pending + contract/artifact" scores: problem_fit: { weight: 20, score_0_to_5: null, evidence: " " } data_security: { weight: 20, score_0_to_5: null, evidence: " " } reliability: { weight: 15, score_0_to_5: null, evidence: " " } operations: { weight: 15, score_0_to_5: null, evidence: " " } commercial: { weight: 10, score_0_to_5: null, evidence: " " } team: { weight: 10, score_0_to_5: null, evidence: " " } portability: { weight: 10, score_0_to_5: null, evidence: " " } weighted_total: null unknowns_and_owner: [] pilot_exit_rule: " continue | redesign | stop, based on prewritten criteria" approver: " role and date" Enter fullscreen mode Exit fullscreen mode Keep the evidence linked to the exact test, contract clause or configuration version. If the supplier changes the model, access scope or workflow, the record should point to the new revision. This makes the scorecard auditable without pretending it is a certification.

Comparing unrelated demos. One supplier shows a polished chatbot; another answers a messy real document question. The result reflects the demo design, not the provider. Use the same pack or mark the comparison invalid.

Scoring confidence. A persuasive presenter earns a high capability score despite no artifact. Require a concrete item for every score: a test output, relevant reference, named team, diagram, contract term or written limitation.

Treating source content as verified fact. Provider guides may contain claims without a traceable report or complete pricing. Trace a statistic to its original publisher, sample, date and question before using it. When the trace is missing, omit the number or label it unverified.

Averages hiding a veto. A weighted total can let excellent price and presentation obscure unsafe data use. Apply hard gates before ranking, and keep the fail reason visible in the decision memo.

No baseline. Without measuring the present workflow, the buyer cannot tell whether the new system improved anything. Capture normal cases and correction work before the pilot, using the same unit and definition of completion.

Success defined as model output. A generated answer is not necessarily a completed business task. Measure whether the approved record changed correctly, whether a person had to fix it, and whether unsupported cases were routed safely.

A pilot without an exit decision. A demo may continue indefinitely because nobody defined what would justify production or a stop. Write thresholds, owners and review date before starting; include a stop option that does not depend on vendor goodwill.

Legal generalization. A supplier may say “Swiss compliant” or “EU AI Act ready” without describing the actual data flow, role or use. Treat slogans as claims to verify, not legal conclusions. Obtain qualified advice for material regulatory questions.

Overweighting only the model. A better model cannot compensate for unusable data, a broken connector, unclear ownership or absent monitoring. Test the end-to-end workflow and its operating path, not just the response quality.

Ignoring adoption and incentives. Staff may bypass a tool that adds review work or makes accountability unclear. Include intended users in test design, observe correction burden, and ask what changes to role, training or sign-off are required. Adoption is not just a launch email.

flowchart TD A[Describe one workflow and baseline] --> B{Standard capability or unique need?} B -->|Mostly standard| C[Compare SaaS configuration and export] B -->|Integration needed| D[Compare implementation scopes] B -->|Need unclear| E[Buy bounded discovery, not a large build] C --> F[Freeze common test pack] D --> F E --> F F --> G[Run same inputs and capture evidence] G --> H{Any hard gate failed?} H -->|Yes| I[Stop, restrict data, or request specific remedy] H -->|No| J[Score seven dimensions and cost scenarios] J --> K[Review uncertainty and production owner] K --> L{Prewritten acceptance criteria met?} L -->|No| M[Redesign once or stop with record] L -->|Yes| N[Approve bounded deployment with monitoring and rollback] The flow intentionally allows “stop” as a successful procurement outcome. If a test shows that a standard product already meets the need, a bespoke engagement may not be warranted. If no provider can meet a hard gate, the evidence has prevented a risky commitment.

The value of a comparison is not that it always produces a winner; it is that it makes uncertainty and trade-offs explicit before an irreversible decision.

The decision should state whether the recommendation is to proceed, clarify, redesign or stop. It should name the process owner, technical owner, data/security reviewer and person authorized to accept residual risk. It should list the evidence reviewed, unknowns, assumptions, contract conditions and review date. Keep “vendor said” separate from “buyer tested.” If a statement is contractual, record the clause; if it is a demo observation, retain the test output; if it is an inference, identify the reasoning.

The source guide's useful role is to help buyers notice categories they might otherwise forget: references, data handling, fit and ongoing cost. The operational scorecard adds a way to test those categories without relying on provider claims alone. For the local Swiss SME framing and the original comparison guide, see the French guide to selecting an AI partner for Swiss SMEs. Read it as a starting point, then trace any statistical, legal or pricing claim to its primary evidence before putting it into your own business case.

The scorecard and test protocol in this article were authored on 24 October 2026 from a structured review of the linked Swiss SME guide, the official European Commission overview of the AI Act, OWASP's LLM application risk material, the KPMG trusted-AI overview, and the OST/SFTI report. The review compared the source guide's stated selection criteria with the buyer decision points, then organized them into seven evidence dimensions and six fail-closed gates. It did not survey buyers, interview vendors, run a client pilot, compare market prices, or independently test any software.

The model's empirical sample size is therefore N=0 vendors and N=0 client deployments. The 100-point total and example values are original design choices, not observations. The illustrative fictional case is not evidence of supplier performance.

The source guide is written by a consulting organization and includes claims that could not be verified from the linked sentence alone in the visible page. Its headline 67% figure is not repeated here as an established Swiss SME adoption estimate. A reader who wants to use it should locate the named Digital Switzerland report and verify field dates, population, denominator and exact question. Its pricing copy is incomplete in the observed page text, so no pricing range is repeated. The guide can still be useful as a list of issues to ask about; marketing authorship does not make every point wrong, but it changes the level of independent verification available.

The OST/SFTI paper is more method-transparent: it describes a summer 2025 structured survey of 24 Swiss financial institutions and selected practitioner interviews. That sample and sector scope limit generalization to Swiss SMEs as a whole. The study also acknowledges institutional and industry contribution, including ELCA Advisory support, which readers should consider when interpreting its framing. Its percentages are reported as the study's findings, not as universal rates or a causal estimate of what a consultant will achieve. The paper is useful evidence that financial-sector projects face a transition from pilots to production; it does not validate this article's weights.

The EU Act and OWASP sources support narrowly stated governance and security prompts, not a legal opinion or guarantee of safety. KPMG is a consulting source, so its governance overview is treated as a perspective to inspect, not independent proof that any particular proposal complies. Laws, guidance, products and terms can change. Check the current source and obtain legal or security advice where the consequences justify it. No ranking, ROI or citation outcome is promised.

The practical recommendation is deliberately modest: decide the task; freeze common inputs; compare evidence; apply minimum gates; price full ownership; and preserve an exit route. If that process ends with “not yet,” the procurement has still produced a useful result. A careful buyer should be able to explain not just which provider scored highest, but what was tested, what remains unknown, who owns the risk and what new evidence would change the decision.