Before You Buy AI, Run a Data-Readiness Gate for Your Swiss SME

Posted on Nov 6 • Originally published at iapmesuisse.ch

An AI project brief should start with a decision and a dataset, not a vendor demo. Before spending on a model, workflow, or consultancy, name one repeated business task, identify the records it needs, show who may approve the result, and define how a person will catch a bad answer. If you cannot do those things with real examples, the next step is process and data discovery, not deployment.

This is a practical companion to IAPME Suisse’s guide to AI data analysis for Swiss SMEs. That guide discusses turning business data into decisions; this article supplies a buyer-side readiness instrument: a one-page brief, a 12-case evidence pack, and explicit stop conditions to take into a first internal review or supplier meeting.

The question is not “Are we ready for AI?” as if readiness were a permanent company trait. It is: “Is this particular task safe and measurable enough for a bounded experiment, and what must be fixed before it can touch live work?” A firm may be ready to summarize public product documentation and not ready to classify employee cases. A team may have clean invoices but no lawful, stable way to export them. A process may be suitable for suggestions but not for automatic decisions.

Keep four outcomes available. Proceed means the task, data, owner, baseline, and human control are sufficiently defined for a limited test. Proceed with a constraint means the test can use synthetic, public, or de-identified examples while a named issue is resolved. Do discovery first means the business case is plausible but evidence about process, data, or exceptions is missing. Stop means the proposed use has no accountable owner, no legitimate data path, no viable human review, or no measurable value that justifies the risk.

This gate is deliberately conservative. It does not certify legal compliance, model quality, cybersecurity, or funding eligibility. It catches missing project inputs early enough that the owner can correct them before buying a platform or promising a return.

The Swiss SME Portal reported in July 2026 that an EY survey of 604 employees found AI use widespread but implementation maturity uneven: 55% of surveyed companies had deployed AI strategically in at least one business area, 31% remained in pilot, and 14% had no concrete initiative. The same summary identified data quality and silos, security and data protection, and skills as reported barriers. These are survey findings, not a prediction about an individual firm; the sample and respondents matter, and “daily use” by employees is not equivalent to a controlled business process. SECO’s SME Portal provides the survey summary and links to the underlying EY report.

That distinction matters in a small company. An employee can paste a draft into a consumer tool and get a useful answer while the company still lacks ownership, retention rules, a reliable source dataset, or a way to verify the output. Conversely, a company can have a formal AI strategy and still fail on a mundane issue such as inconsistent customer identifiers or missing dates. Adoption is a state of usage; readiness is specific to a task and its controls.

The evidence base also has limits. The SECO portal’s summary is a secondary account of an EY survey, not a census of all Swiss firms. Percentages should not be added together unless the survey wording says the categories are mutually exclusive. Do not infer that a given share of Swiss SMEs will receive a return, that the same barriers rank identically in every industry, or that a project is viable because national adoption is high. Use the findings as prompts for questions, then measure your own process.

The underlying EY Switzerland survey release provides the consulting-side context for the portal’s summary. The OECD discussion paper on AI adoption by SMEs likewise stresses that firms differ in digital maturity, use-case complexity, and adoption scope. These sources support segmentation of the decision; neither supplies a validated readiness score for one Swiss firm. That is why the score below is explicitly a proposed checklist aid rather than an empirical maturity model.

Complete these fields on one page before a vendor demonstration. Use plain language. If a field cannot be answered, write “unknown,” name who will find out, and set a date. A blank is useful evidence; a polished guess is not.

This format is intentionally more specific than a use-case slogan. “Use AI to improve customer service” is not a testable task. “Draft a response to a warranty question using the current warranty policy and the customer’s order record; a service agent approves before sending” names a bounded job, inputs, output, and authority boundary. It still requires privacy review, data access design, policy version control, and testing, but those questions can now be answered.

Task and user. Observe the task as performed, including handoffs and waiting. Write the trigger, the steps, the systems opened, and the artifact that marks completion. Do not define the task around a tool (“use a chatbot”) or a department-wide aspiration. If two employees describe different workflows, document both; the mismatch may be the first process issue to solve.

Decision owner and affected people. The person who funds the experiment may not be the person who can approve an output. Name both. Identify who experiences the consequence of a false positive, a missed case, a delay, or a disclosure. Where a decision concerns an individual, do not bury that fact in a general “customer experience” label. The Swiss FDPIC says the Federal Data Protection Act applies directly to AI-supported personal-data processing and emphasizes transparency, data-subject rights, and impact assessment in high-risk cases. Read the FDPIC’s AI and data protection guidance.

Baseline. Pick one measure tied to the task. A baseline could be elapsed minutes from a complete request to a reviewed draft, the percentage of cases returned for missing information, or the count of corrections per batch. Define what starts and ends the clock. Decide whether holidays, incomplete cases, urgent work, or a system outage are included. Capture the method before the pilot. If staff must reconstruct a baseline from memory, label it an estimate and do not present it as a measured result.

Data sources and boundary. Record the source system for each field, not just the name of a database. A customer ID from the CRM may disagree with an invoice ID; the brief should say how they are joined and who resolves conflicts. State whether the proposed tool receives personal data, confidential business information, credentials, or only public and synthetic examples. “Hosted in Switzerland” is not by itself a complete data assessment: access, subprocessors, retention, transfers, backups, support access, and the purpose of processing still matter. The FDPIC guidance is a starting point, not a substitute for case-specific legal advice.

Data condition and exceptions. Profile a small, explicitly selected sample of records and explain why it is representative enough for discovery. Note missing fields, duplicate identifiers, old policy versions, mixed languages, scanned images, and exceptions staff routinely resolve. Do not clean away the hard cases before the first test. If the records are too sensitive to use, create synthetic cases that preserve the structure of the problem without exposing real people.

Output, human control, and failure response. Specify the output as a form or schema. If the model cannot support a field, it should return “unknown” rather than inventing one. Tell the reviewer what evidence to check and how to reject an answer. A review button that nobody has time to use is not a control. Record who can pause the system, how the team returns to the old workflow, and how affected people are corrected if an error has already been acted on.

Success and cost. Choose one primary outcome and at least two guardrails. For a drafting assistant, a primary outcome might be review time saved; guardrails might be factual correction rate and unresolved cases. Calculate total ownership cost, not only licence price: integration, data preparation, staff training, review, incident response, version changes, and exit all consume resources. Present the inputs and formulas, not a single ROI percentage stripped of assumptions.

The project brief becomes more useful when paired with test cases. Create 12 cases from representative ordinary examples and known edge conditions. This is a designed acceptance pack, not a statistically powered performance study. Twelve is an operational starter set chosen to make a short review manageable; it does not imply a confidence level or prove general accuracy. Record the source of each case, the expected safe behavior, the observed result, and the reviewer’s decision.

The expected result is not “the model gives a plausible answer.” For each case, write the rule that defines passing. A sensitive-data case passes only if the excluded field does not reach the service or its retained logs under the tested configuration. A human-override case passes only if the edited value is what the downstream system uses. A low-confidence case passes only if the user can distinguish it from a verified answer. If the team cannot agree on the rule, that is a discovery task, not a reason to score the model generously.

Imagine a small Swiss distributor receives supplier invoices by email. Staff currently open the email, match the supplier and purchase order, check the amount and VAT fields, and route exceptions to an accountant. The proposed system extracts fields and drafts a routing suggestion. It does not approve payment.

The project brief records the current process and an agreed baseline period. It lists the invoice PDF, supplier master, purchase order, and accounting system as sources. It states that the master record is authoritative for supplier identity, while the purchase order is authoritative for ordered quantity and agreed price. It names accounts payable as the reviewer, the finance lead as the decision owner, and suppliers and employees as affected parties if an incorrect payment or disclosure occurs. The output is a structured draft with a source reference for each field, plus an explicit “manual review required” state.

The team then builds the 12 cases. The ordinary case contains a readable invoice with a matching order. A missing case omits the order number. A conflict case uses a supplier name that differs from the registered entity. A stale case uses an old supplier bank detail. A sensitive case includes a personal note in the email thread that must not be sent to the model. A duplicate case replays the same invoice after a timeout. A failure case makes the accounting API unavailable. The expected behavior for the bank detail conflict is not to “choose the most likely” value: it is to stop and route the case to the existing verification step.

The test could show that extraction is technically useful but that the data join fails on a particular supplier format. That result is valuable. The next step might be a vendor-specific rule, a process change, or no AI at all. The test does not establish a productivity percentage because it uses a small designed set and not a representative sample of the invoice population. A later controlled pilot would need a dated sample plan, a comparison with the current process, reviewer effort, correction categories, and an agreed stop threshold.

Use a small manifest rather than emailing spreadsheets around. The following JSON is a template; values are illustrative placeholders and not measured company data.

{ "project": "invoice-exception-triage", "review_date": "YYYY-MM-DD", "owner_role": "finance lead", "task_boundary": "draft extraction and routing only; no payment approval", "sample_method": "select consecutive eligible cases from a defined period", "sample_size": 12, "excluded_fields": [ "bank credentials", "personal email content" ], "cases": [ { "id": "C01", "condition": "complete invoice and matching purchase order", "expected": "draft fields cite source; human approves", "pass_rule": "no unsupported field; no external action" }, { "id": "C02", "condition": "missing purchase-order reference", "expected": "manual review", "pass_rule": "system does not infer a purchase order" } ], "decision": "proceed | constrain | discover | stop", "open_issues": [], "approver_role": "finance lead" } Enter fullscreen mode Exit fullscreen mode Before testing, freeze the prompt or configuration version, model identifier where exposed, retrieval sources, and integration permissions. Record the date and environment. If any of those change, treat the run as a new configuration; do not merge results across versions as if the system were unchanged.

Use synthetic identifiers in the evidence pack. Keep the case ledger access-controlled and delete working copies according to the company’s retention policy.

For every case, the reviewer records expected behavior before seeing the output. Then a second person, if available, checks whether the expected rule is clear and consistent. Only after that does the operator run the case and record output, actual behavior, error category, reviewer action, and whether an external action occurred. This order reduces hindsight bias: teams are less likely to excuse an unsafe answer after seeing a fluent response.

Use gates before points. A single critical failure can block a pilot regardless of the aggregate score. For example, if personal data that the brief explicitly excludes is transmitted, the result is stop and investigate, not “11 out of 12 passed.” Likewise, if an output can trigger payment or send a binding customer commitment without the named reviewer, the control boundary has failed.

For non-critical readiness items, score each as 0 = absent, 1 = partly evidenced, 2 = evidenced and owned. Suggested items are: task boundary, owner, baseline, source-of-truth map, data quality, sensitive-data boundary, exception list, output contract, reviewer capacity, success measure, rollback, and exit plan. Sum is at most 24, but the number is a management aid created for this article, not a validated maturity scale. A low score does not mean “bad company”; it identifies work to do. A high score does not prove the model works.

These ranges are proposed decision thresholds for this instrument only. They have not been empirically calibrated. A company should change them to fit its risk appetite and document why. Do not report the score as a benchmark, compare it across companies, or claim a particular score predicts return.

The FDPIC states that Switzerland’s Federal Data Protection Act applies directly to AI-supported processing. It highlights transparency about purpose, functionality, and data sources, and says a data-protection impact assessment is required in high-risk cases. See the FDPIC guidance. This means the project brief should reveal what data is processed and what effect the result may have on people. It does not mean every AI experiment requires the same assessment, or that a one-page brief itself satisfies the law.

If a project handles personal data, the responsible company must assess its actual purpose, roles, access, retention, transfers, safeguards, and the rights of affected people. The tool’s location alone does not answer these questions. A Swiss server may be relevant to the decision, but a complete data map must also consider support access, subprocessors, logs, backups, and onward transfers. Seek qualified Swiss legal and security advice where the processing is sensitive, high impact, or unclear.

For projects involving customers or workers in the European Union, also determine whether the EU AI Act’s territorial and use-case rules apply. The European Commission describes its risk-based obligations and specified high-risk areas such as employment management; this is EU legislation, not a substitute for Swiss legal analysis. Use the Commission’s AI Act overview to identify the EU questions that require a specialist review.

Innosuisse’s public criteria for innovation projects are a useful contrast, not a general AI procurement checklist. Its page describes support for research projects with high innovation potential and says applications are assessed for innovation, value creation, methodological quality, partner expertise, and sustainable contribution. It also states that the offer is for research partners and that feasibility studies, prototypes, and testing facilities can be supported in that scheme. Review Innosuisse’s eligibility and evaluation details before assuming an SME implementation project qualifies.

Funding eligibility, legal compliance, and operational readiness are separate decisions. A project can be fundable but not ready for production. It can be lawful but commercially pointless. It can show time saved but still fail a privacy or security gate. The brief keeps those decisions visible instead of letting one positive result stand in for all the others.

The source article linked above discusses AI and data analysis for Swiss SMEs. Treat its business framing as a starting point for questions, not as independent evidence that a particular implementation will pay off. The linked SECO portal presents survey results about adoption and reported barriers, while the FDPIC describes an applicable legal framework. Those sources answer different questions: survey respondents describe reported company practice; the authority explains data-protection expectations. Neither establishes the likely outcome of your own project.

There is also a tension between “start small” and “do enough work before starting.” Both can be right. A small experiment reduces exposure only if it is genuinely bounded: synthetic data, no external action, known reviewer, and a stop switch. A nominally small pilot can still create material risk if it uses live employee records, sends customer responses, or makes a consequential decision. The size of the software bill is not the same as the magnitude of the impact.

Another tension concerns data preparation. Better data can improve evaluation, but collecting more data may expand privacy and security exposure. The right move is not “collect everything”; it is to identify the minimum fields and records needed for the defined task. If one variable cannot be justified, exclude it. If the task cannot work without a sensitive field, document why and bring the relevant privacy and security reviewers into the decision before a vendor receives access.

Finally, there is a tension between a numeric score and expert judgment. Scores make assumptions visible and help compare project briefs over time. They also invite false precision. The critical-failure gates therefore override the sum, and the score’s proposed thresholds are disclosed as unvalidated. If the score disagrees with the lived risk described by the process owner, investigate the disagreement rather than averaging it away.

A demo uses clean data that production does not have. Ask for a case from the ordinary workflow and one from the exception set. If the provider cannot show how the system identifies missing or stale data, keep the experiment offline.

The owner is actually a vendor. A supplier can operate a service, but the SME still needs an internal role accountable for decisions, access, incident handling, and service continuity. Name a deputy for holidays and departures.

Review becomes rubber-stamping. Measure reviewer time and correction behavior. If staff are pressured to accept every answer or cannot inspect evidence, the human-in-the-loop label is cosmetic. Reduce automation authority or stop.

The pilot quietly becomes production. Set a date, data boundary, user list, and expiry for access. Any expansion in users, records, integrations, or external actions requires a new approval.

The baseline changes after results are visible. Freeze definitions before the test. If seasonality or policy changes make comparison unfair, explain the change and rerun rather than reporting a convenient denominator.

The team treats a vendor statement as a control. “We are secure,” “we do not train on your data,” or “we are compliant” is not enough. Record the contractual commitment, configuration, evidence, scope, and exceptions; have the responsible reviewer verify the exact service and plan.

A fluent answer hides an unsupported fact. Require citations to approved sources or field-level provenance where feasible. Test whether the system declines when the evidence is absent, not only whether it succeeds when everything is present.

The integration duplicates or loses work. Test retries, duplicate events, partial writes, and timeouts. A good answer displayed twice may still create two invoices, tickets, or customer messages.

Staff work around the approved route. If the sanctioned tool is too slow or restrictive, employees may use personal accounts. Gather workflow feedback and provide a safe route. Do not assume a written policy changes behavior by itself.

The exit plan is theoretical. Before contracting, ask for export formats, deletion process, retained logs, configuration ownership, notice periods, and the effort required to return to the existing workflow. A pilot should be reversible in practice.

Days 1–3: observe and bound. Interview the person doing the task, the owner, and the people affected. Gather ordinary and exception examples. Draw the workflow from trigger through final action. Record where a human judgment is essential. Do not choose a model yet.

Days 4–7: establish baseline and data map. Define the outcome measure, baseline sample, and counting rules. Map each field to its source of truth and owner. Label personal, confidential, public, and synthetic data. Identify what cannot leave the current environment. Ask IT or the provider to confirm access, logging, retention, and data-flow details.

Days 8–12: define the test pack. Prepare the 12 cases, write expected behavior before running them, and agree critical stop conditions. Remove direct identifiers. Keep a versioned copy of prompts, configuration, retrieval sources, and tool permissions. A small firm can do this in a spreadsheet or a structured JSON file; the critical feature is reproducibility, not software sophistication.

Days 13–18: run offline. Execute only on approved sample data or synthetic cases. Record every case outcome, correction, refusal, latency issue, and integration failure. Include at least one case where the system should say “I do not know.” Do not permit automatic customer communication, payment, hiring, or eligibility decisions during this phase.

Days 19–22: review harms and operating cost. Ask the process owner what the system changed, the reviewer what evidence was usable, and the privacy or security contact what remains unresolved. Calculate cost using observed effort and the intended service terms. Keep the pilot cost separate from future scaling assumptions.

Days 23–26: decide. Use the four outcomes: proceed, constrained experiment, discovery, or stop. Name the approver, conditions, next date, and evidence required. If proceeding, define the limited user group, duration, data boundary, support channel, rollback, and expiry. If stopping, preserve the reason and the conditions under which the question may be reopened.

Days 27–30: prepare the next evidence cycle. If the offline gate passes, design a monitored pilot that compares the AI-assisted workflow with the current method using a defined period and sample. Pre-register metrics and exclusions. Decide how errors are triaged and who sees them. A pilot result should be reported with the sample, dates, system version, reviewer process, and limitations. Do not claim causal savings from an uncontrolled before-and-after comparison when workload, staff, or policy also changed.

flowchart TD A[Name one repeated task] --> B{Owner, baseline, data source known?} B -- No --> C[Discovery: map workflow and data] B -- Yes --> D{Sensitive data or consequential effect?} D -- Yes --> E[Privacy, security, and human review before live data] D -- No --> F[Build synthetic or low-risk 12-case pack] E --> G{Critical gate passes?} F --> G G -- No --> H[Stop or constrain; resolve named issue] G -- Yes --> I[Time-boxed pilot with baseline and stop thresholds] I --> J{Value and guardrails both pass?} J -- No --> K[Rollback and document learning] J -- Yes --> L[Separate approval for wider deployment] The diagram is a decision aid, not a compliance workflow. If an emergency, regulated process, or high-impact decision is involved, bring the relevant specialists in before the offline test. If the work requires a formal assessment, the diagram does not replace it.

If any answer is no, write the smallest next action and owner. For example: “Finance lead will sample 20 consecutive invoice cases and measure missing PO references by 18 November” is actionable. “Improve data quality” is not.

A Swiss SME does not need a grand AI strategy document to make a responsible first decision. It needs a precise task, a defensible data boundary, a baseline, named ownership, tests for the cases most likely to break, and a human who can stop the workflow. The 15-field brief and 12-case pack above turn those requirements into evidence a team can review together.

The original score and thresholds here are a proposed operating aid, not a measured benchmark. The 12 cases are a starter acceptance set, not a statistical sample. The survey percentages describe respondents, not the likely success of your project. The legal sources summarize general requirements; apply them to the actual processing and seek specialist advice where the risks or interpretation are material. A project should advance only when the evidence supports that specific next step—and should remain small until a monitored pilot shows value without breaching its guardrails.

Method note (6 November 2026): the original asset is a desk-designed 15-field brief, a 12-case synthetic acceptance pack, and an unvalidated 0–24 prioritization aid. No company dataset or live model was tested; no original performance statistic is claimed. The examples are illustrative. The sample size of 12 is a usability-sized starter set, not a statistical sample. Excluded from this article are vendor comparisons, legal opinions, funding advice, and claims that the proposed thresholds predict ROI.