AI automation for Swiss organizations that must work

Swiss context

Design for the organization that exists, not a generic jurisdiction

Switzerland’s current AI approach is evolving. Official federal information states that there is not yet one overarching AI-specific law and describes ongoing work toward a consultation draft, while existing data protection and sector rules continue to matter. For a business, the practical conclusion is not to wait for a single AI label or assume that no rules apply. Identify the actual use, data, affected people, sector, contractual promises and markets, then obtain qualified assessment. A Swiss company serving European customers may also face requirements that arise from those activities.

Operational fit includes language and federal structure as well as law. A workflow may receive contracts in German, customer messages in French and technical evidence in English. An automation that performs well in one language cannot be presumed equivalent in another. Entities and business units may use different systems or approval rules. Build the process map at the level where work, authority and data actually differ. This page supports discovery and vendor evaluation; it does not provide legal conclusions.

• Assess the concrete use case instead of relying on a generic AI classification.
• Keep current official and sector sources in the governance review.
• Test task behavior separately in each material operating language.
• Map the legal entity and system owner behind every action.
• Record cross-border customers, suppliers and processing paths.

Opportunity selection

Rank workflows by evidence, not executive enthusiasm

Begin with a portfolio, not a promise to automate a department. For each candidate, measure arrival volume, touch time, queue delay, rework, error impact, variation and system boundaries. Interview the people who create the input, do the work and consume the result. Process documents often omit the very exceptions that determine whether automation is feasible. A few days of evidence can disqualify a glamorous use case and reveal a smaller one with a much cleaner return.

Score value alongside readiness and consequence. High volume does not help if inputs are inaccessible or every case requires novel legal judgment. A strong first workflow has a stable trigger, repeatable evidence, a verifiable output, reachable integrations and an obvious escalation owner. Choose a slice that removes a handoff, not one that merely generates content for someone to paste. Preserve a manual path while the pilot proves quality and capacity.

Solution design

Evaluate the complete operating chain, not the model demonstration

An automation vendor should demonstrate the team’s workflow on safely representative cases. Ask how inputs are classified, which sources support a result, how access is applied, where a model is used, what code validates the output and how an exception reaches a person. Include an ambiguous case, a missing document, a conflicting source and an unavailable downstream system. The way the solution fails reveals more than a perfect happy-path run.

Inspect the full data and dependency chain. Hosting is one node. Files may be copied into extraction services, model endpoints, vector stores, observability platforms, backups and support systems. Record retention and deletion for derived data as well as originals. Require an export and exit path for workflow state, evaluation cases and operational records. The buyer needs enough documentation to operate and audit the solution even if a model or supplier changes.

• Use identical representative cases across shortlisted providers.
• Require source provenance and access checks in the live trial.
• Test exceptions, dependency failure and correction workflow.
• Map every processor, subprocessor, store and support path.
• Assess portability of state, data, evaluations and integrations.

Scale

Scale the operating controls before scaling the use cases

Production ownership needs more than a project team. Assign a business outcome owner, workflow operator, technical service owner, data and security contacts, and accountable approvers for material decisions. Define support, incident, change and retirement paths. Users must see what the automation did, what remains pending and how to correct it. Exceptions should carry the original evidence and machine reasoning needed for a person to resolve them efficiently.

Expand when the first workflow remains stable under representative volume and change. Version models, prompts, rules, integrations and evaluation sets. Test a proposed change offline, canary it on limited traffic and preserve rollback. Compare business capacity and quality, not only model accuracy. If downstream queues grow or operators repeatedly override one category, stop and redesign that boundary. Responsible scale is a sequence of proven workflow families, not a rising count of connected agents.

• Name business, technical, data and approval ownership.
• Expose pending, failed and human-review states to users.
• Carry evidence and context into every exception.
• Canary changes and preserve a tested rollback.
• Stop expansion when correction or queue metrics deteriorate.