AI 智能體還是工作流自動化？瑞士中小企決策測試

AI Agent or Workflow Automation? A Decision Test for Swiss SMEs

Short answer: choose the least autonomous system that can meet the real task. Use deterministic automation when the inputs, rules, and acceptable output are stable; use an AI-assisted workflow when language or classification is uncertain but a person can review the result; consider an agent only when the task genuinely needs flexible multi-step decisions, the available actions are bounded, errors are reversible, and a measured pilot shows better outcomes than the simpler alternatives.

The useful first purchase is often not a model. It is a one-page process description, a small set of real examples, and an acceptance test. This article provides a reusable 10-signal decision matrix, a 12-case test plan, and a worked SME example. Scores are a triage aid designed here, not a validated predictive model or a promise of savings.

Why the decision is harder than “agent versus no agent”

The words automation, AI assistant, and agent are used inconsistently. Some vendors call a fixed prompt followed by a webhook an agent; some teams reserve the term for a system that plans, calls tools, observes results, and chooses the next action. A comparison is useful only after the team writes down what the system may actually do. Does it classify and draft? Does it write to the CRM? Can it send a message, change a record, commit a payment, or make a decision without approval? Those are materially different risk profiles.

The Swiss SME source page, “AI Competitive Advantage for Swiss SMEs” already recommends piloting a high-impact, low-disruption process with measurable outcomes. The missing step is an operational decision rule for separating three options: ordinary rules, AI assistance inside a controlled workflow, and autonomous tool use. That is the reader problem this guide resolves. A recent site-level GSC snapshot also showed the query “agent ia pour pme” at average position 8 with one impression for the site's domain; the monitor does not retain a query-to-landing-page mapping, so this is a weak site-level signal, not proof that the specific source page ranked for that exact query. It is a prioritization hint, not evidence of demand or a ranking promise.

Define the task before selecting the technology

Describe one task as a bounded transformation: when a particular input arrives, which evidence may be read, what decision or artifact must be produced, which changes may be made, and who owns an exception. “Improve customer service” is not testable. “For an incoming email about delivery dates, retrieve the order status, draft a response with the source link, and leave it in a human review queue” is testable.

Keep the workflow small enough to inspect. Split a broad request such as “handle a new customer” into intake validation, eligibility, data entry, price calculation, response drafting, and final approval. Different steps can use different tools. A rule can validate required fields, an AI model can extract the request from prose, and a person can approve a commitment. This hybrid design is not a compromise; it is often the correct architecture when uncertainty exists in one part but not another.

The Gartner research abstract on deterministic and agentic business-process automation explicitly recommends selecting AI selectively and combining it with deterministic approaches for predictable, scalable process automation. The abstract is not the full paid report, so this article does not attribute a detailed scoring framework to Gartner. The decision matrix below is an original operational aid built from the task properties teams can inspect directly.

The three choices in plain language

Deterministic workflow: code or a workflow platform applies explicit conditions. The same accepted inputs follow the same path. Use it for required-field checks, known routing rules, fixed calculations, status transitions, scheduled reminders, and repeatable updates. It is easiest to test and explain when exceptions are limited and rules are current.

AI-assisted workflow: a model extracts, classifies, summarizes, or drafts; ordinary code controls access, validation, routing, persistence, and approval. A human confirms uncertain or consequential outputs. This is a good fit when inputs are varied or language-heavy but actions can remain bounded. The model can propose; the workflow decides what is allowed.

Agentic workflow: a model can choose and sequence tools, inspect intermediate results, and continue toward a goal. That flexibility may help when the path is not fully known in advance. It also adds more states to test: tool selection, arguments, retries, partial completion, permission boundaries, and recovery after an interrupted step. If a fixed sequence already solves the task, granting an agent planning freedom may add cost and failure modes without adding value.

The options can coexist in one process. “Agent or workflow” is often a false dichotomy: a deterministic shell can give an agent one narrow decision and retain control of everything else.

Ten signals for the first decision

Score each signal as 0, 1, or 2 for the specific task. Zero means the deterministic option is favored; one means uncertainty or a mixed case; two means an agent may have a real reason to exist. The scores are ordinal prompts for a review meeting, not probabilities. Do not sum them and treat the result as a universal truth. A single hard-stop condition—such as irreversible financial action with no review—can outweigh a high total.

Interpret the table in two stages. First, inspect the “error impact” and “reversibility” rows as safety constraints. A high-impact process should not become autonomous merely because its inputs are messy. Second, inspect variation, branching, and tool selection. These are the places where an agent might have an advantage over fixed rules. If only language variation is high while steps are predictable, use AI for extraction or drafting inside a deterministic workflow instead of granting broad tool autonomy.

A decision rule that stops teams buying autonomy by default

Apply this sequence to one task, not to an entire department:

1. If rules are stable, inputs structured, and exceptions rare, implement or retain a deterministic workflow.
2. If input language varies but the allowed steps are stable, add AI extraction or drafting; keep validation, routing, and permissions in ordinary code.
3. If the system must choose among several tools or steps based on results, test an agent against a fixed-workflow baseline using the same cases.
4. If the wrong action can create a legal, financial, privacy, safety, or serious customer consequence, require approval or remove that action from the agent’s permissions.
5. If the benefit cannot be measured against current work, do not expand autonomy. First instrument the baseline.

This is a conservative recommendation, not a law of nature. There are narrow environments where an agent can safely operate with high autonomy—for example, a sandbox that edits disposable test files and has a deterministic evaluator. That does not imply an agent should independently send an offer, change an accounting record, or decide customer eligibility. The consequences and undo path differ.

Original asset: the SME automation decision worksheet

Use this template in a short process workshop. Fill in a single task and retain the completed worksheet as the decision record. “Unknown” is a valid answer and should trigger measurement, not an invented estimate.

TASK
  Trigger and input:
  Intended user/customer outcome:
  Systems the task may read:
  Systems/actions it may change:
  Named process owner:

BASELINE (observe before the pilot)
  Number of eligible cases in the observation window:
  Median and range of handling time:
  Rework / correction reasons:
  Customer or business impact of a wrong result:
  Current exception rate and how it was counted:

CHOICE
  Deterministic steps:
  AI-only assistance (if any):
  Agent tool permissions (if any):
  Human approval point:
  Hard-stop conditions:
  Rollback / manual fallback:

PILOT GATE
  Primary outcome and denominator:
  Safety guardrail:
  Minimum evidence to continue:
  Stop condition:
  Review date and accountable owner:

This worksheet produces no benchmark statistics. Its purpose is to stop a pilot from beginning with an undefined “efficiency” claim. A completed form should reveal whether the team lacks a process description, a measurable baseline, an exception taxonomy, or an owner. Those are project risks even if the eventual tool is excellent.

Worked example: incoming supplier invoices

Imagine a small Swiss service company receives supplier invoices as PDFs and email attachments. The goal is not “automate accounting.” The bounded task is: capture supplier name, invoice date, amount, currency, reference, and due date; check required fields; match the supplier to an approved list; flag possible duplicates; prepare a draft accounting entry; and route uncertain or high-impact cases to the bookkeeper. Payment approval remains outside the automation.

The input layout varies, so a pure fixed parser may struggle. But arithmetic, vendor allowlisting, required fields, currency rules, and final approval are deterministic. A sensible first design uses OCR or a language model to extract candidate values, validates the values with code, compares them with existing records, and shows the source page or bounding box to a person. An agent may be useful later for resolving multi-document exceptions, but only if it has read-only access first and cannot release payment.

The acceptance outcome is not “the model extracted the invoice.” It is a pair of measures: the share of cases that become correct draft entries under the agreed rubric, and the correction burden per eligible case. Count a result as correct only when the required fields match the source, duplicate detection is correct, and the record routes to the correct approver. A fast extraction that creates more review work is not an improvement.

For the first pilot, sample consecutively received invoices over a declared observation period; include routine invoices and separately label credit notes, foreign currency, missing references, and ambiguous tax treatment. Do not quietly remove the difficult cases. If they are excluded, state that the tool is only being assessed on the remainder. Keep a human reviewer blinded to which system produced the draft where practical, and record disagreements. This is a test design, not a claim about expected extraction accuracy.

Why benchmark results help—and where they do not transfer

The GTA benchmark paper evaluates general tool agents using 229 human-designed tasks, executable tool chains, and multimodal inputs. It reports that GPT-4 completed fewer than half of those tasks and most evaluated models completed fewer than a quarter. That is evidence that realistic tool use can be difficult in the benchmark’s setting, not a failure rate for Swiss SME processes. The benchmark’s authors also note a limitation: all its queries are in English. Its tasks and tools are not invoices, local accounting rules, or your organization’s real CRM.

The practical lesson is methodological: test complete tasks with real tools and real context, not just isolated model answers. NIST’s ARIA Evaluation Planning Manual describes a holistic evaluation approach using model testing, red teaming, and user testing. NIST’s agentic AI evaluation-probes project emphasizes visibility into tool use and evidence, including machine-readable audit trails. These are evaluation resources, not a certification that a system is safe. An SME can scale down the method while retaining the principle: test normal examples, adversarial or unusual cases, and the user’s ability to detect and correct errors.

The twelve-case pilot test plan

Use these cases as a minimum scenario library for any AI-assisted or agentic workflow. They are author-created test cases, not observations from customer traffic. Write one expected outcome per case before running the system. For every run, save the input fixture ID, tool calls, output, reviewer result, time to complete, and whether an unsafe action was attempted.

The count “twelve” is the number of rows in this designed test plan, dated 25 October 2026. It is not an empirical sample size and should not be reported as a measured performance result. For a real pilot, set the sample from business volume, risk, and the precision needed for the decision. A dozen synthetic cases can expose obvious design faults; it cannot establish a dependable error rate for a low-frequency, high-impact event.

Score outcomes, not demonstrations

Before the pilot, choose a primary outcome and a small set of guardrails. The primary measure might be correct completed cases per eligible case, or median human handling time for cases that passed quality review. A guardrail might be incorrect customer communication, unauthorized record changes, missed escalation, or privacy leakage. Define the denominator before you observe the result. “Time saved in a demo” is not the same as time saved per accepted production case.

Keep separate columns for model quality, process quality, and business outcome. A model can extract values accurately while the workflow routes a record to the wrong person. A workflow can route correctly while reviewers spend longer correcting drafts than they did before. Revenue or customer satisfaction may change for reasons unrelated to the pilot. For a small sample, report the case counts and uncertainty plainly; avoid percentages with false precision.

Use a comparison baseline. Run the current process and the proposed system on matched or consecutive cases with the same eligibility rules. If the automation is tested only on easy historical examples while the human baseline includes all cases, the comparison is biased. If you change the process during the test, record that change. If staff know which result came from AI, their review behavior may change; acknowledge that limitation rather than claiming a blinded study when it was not.

Keep a deterministic shell around probabilistic components

Treat the model as a component with an input contract and output contract. The application should decide what the model is allowed to see, constrain the output schema, validate the returned values, and determine whether an action is permitted. A model-generated approved: true field is not authorization. A policy engine or human approval should make that decision.

Use explicit tools with narrow scopes. A draft-generation component may need read access to a customer record but no permission to send email. An invoice extractor can propose a supplier ID from an allowlist but should not create a new vendor. A planning agent can request an action, but a separate authorization layer should check the user, record, amount, state, and approval token. Keep side effects idempotent and logged with a correlation ID so a retry does not create a second payment or customer message.

If a task has a stable sequence, write that sequence as code and call AI only for the uncertain step. If the next step truly depends on the result, expose a short list of permitted next actions and require machine-checkable preconditions. An agent should not have broad shell, email, finance, or CRM access simply because its prompt says to be careful. Permissions are stronger than wording.

Swiss regulatory context: useful caution, not a shortcut to legal advice

The Swiss Federal Chancellery’s AI regulation page says there is not yet overarching Swiss legislation specifically addressing AI and describes a consultation draft planned by the end of 2026. The official SME Portal page, dated 23 September 2026, instead says a consultation draft will be prepared in spring 2027. These are two official pages with different timetable wording. The discrepancy should be checked with the responsible federal office; neither date should be converted into a legal deadline for an individual SME.

Both sources state that AI is not operating in a legal vacuum: existing rules continue to apply, including data protection and sector-specific requirements. This article is not legal advice and does not decide whether a particular business use is compliant. Before processing personal, employment, health, financial, or cross-border data, identify the controller, purpose, access, retention, vendors, and affected jurisdictions with competent counsel or a data-protection professional. “Human in the loop” is not a substitute for a lawful purpose, access control, or meaningful ability to challenge a decision.

Questions from business users and what they reveal

A public small-business discussion asked whether AI agents were saving time or were still mostly hype. The search result included reports of context loss, stale or timed-out APIs, brittle multi-step automation, and a preference for smaller guarded workflows. This is anecdotal, self-selected discussion—not a survey and not evidence of prevalence. Its value is that it names failure patterns an SME can turn into tests: lost context, stale evidence, partial completion, and action without enough guardrails.

The thread also includes promotional or self-interested replies, a common limitation of open forums. Do not copy a claimed percentage of time saved or treat a vendor’s personal success story as a controlled comparison. Ask instead: what process was tested, what was the baseline, what counted as completion, which failures were excluded, and who verified the result? When a commenter says “it works,” the next useful question is “what happens on the exception case?”

NIST’s evaluation material leads to a complementary user question: can the person responsible inspect the evidence and correct an output? That matters more than whether the UI feels conversational. A workflow should show the source record, proposed action, confidence or uncertainty where meaningful, and a clear rejection or escalation route. If a person cannot tell what the system did or undo the relevant action, nominal oversight may be ceremonial.

Failure modes and their design response

Automating a bad process. If the existing workflow has unclear ownership or duplicate handoffs, adding an agent can reproduce the confusion faster. Map the process and remove unnecessary steps before selecting the technology.

Choosing autonomy because a demo looked impressive. A scripted happy path hides tool errors and edge cases. Use the twelve-case suite and compare it with the current process.

Treating a model score as a business KPI. A high benchmark or exact-match score may not reduce rework or improve customer outcomes. Measure accepted end-to-end cases and guardrails.

One agent receives broad permissions. Prompt instructions cannot replace access controls. Begin read-only, add one action at a time, and bind each side effect to a policy check and audit trail.

A human is “in the loop” but cannot intervene. If alerts arrive too late, reasons are hidden, or the queue is too large, oversight is not effective. Give reviewers time, context, authority to stop, and a fallback.

Silent failure after a tool timeout. A model may continue with stale or partial evidence. Require explicit tool-result validation and stop when a required source is missing.

Retries repeat side effects. Use idempotency keys or an action ledger, and test the crash window after an external action but before local completion is recorded.

The evaluation excludes hard cases. Report exclusions and run a separate exception cohort. Do not generalize a pilot over only routine inputs to all customers.

What to ask a vendor or internal builder

Ask for the exact action list, not a product label. What data can the system read? Can it write, send, approve, delete, or change access? Which actions require a separate human token? Can it show a replayable record of evidence and tool calls? What happens if one tool returns stale data, a permission error, or an ambiguous result? How are retries prevented from repeating side effects? Can you export the inbox, evaluation set, audit trail, and configuration if you switch vendors?

Ask for a demonstration on your own redacted examples, including at least one contradictory record and one missing field. Keep the current human process as a baseline. Require the vendor to distinguish model-generated text from verified facts and to explain what happens when the system abstains. If the vendor shows only a flawless demo, ask to see the failure path and the reset procedure.

For a Swiss SME, also ask where data is processed and stored, which subprocessors are involved, whether prompts or outputs are retained for model training, and how deletion and access requests are handled. These questions do not establish compliance by themselves; they create the facts a responsible internal review needs. Avoid sending sensitive real customer data to a trial environment until those facts are known.

Pilot gates and rollout stages

Gate 0 — Process clarity. The owner can describe trigger, inputs, allowed actions, success state, exception route, and manual fallback. If not, map the work before automating it.

Gate 1 — Baseline. The team has counted eligible cases and measured handling effort and correction reasons over a declared period. It knows which categories are excluded and why.

Gate 2 — Offline evaluation. A frozen set of representative and adversarial examples passes the expected-output rubric. Failures are categorized; the team has not tuned and tested on the exact same cases without a holdout.

Gate 3 — Shadow mode. The system proposes outputs but does not change customer-facing or financial records. Reviewers compare proposals with normal work and identify missing cases.

Gate 4 — Bounded live pilot. Only low-impact, reversible actions are enabled. A named owner monitors safety guardrails, has a stop switch, and can revert to the prior workflow.

Gate 5 — Expansion decision. Continue only if measured business outcomes improve without unacceptable safety, privacy, or correction costs. Expand permissions in small increments and rerun affected tests after model, prompt, tool, or policy changes.

This staged plan is a recommendation. The right sample size and test duration depend on case volume, impact, and the variation that matters. A low-volume process may require a longer observation window or a parallel simulation. A high-impact process may remain human-approved even after a good pilot.

Method, sample, and limitations for the original asset

The 10-signal worksheet and 12-case suite were authored on 25 October 2026 for this article. Their “sample size” is the designed library of one worksheet and twelve scenarios; no real SME transaction data were collected, no agent was benchmarked, and no time-saving result was measured. The examples are illustrative. The worksheet excludes legal risk scoring, detailed threat modeling, and vendor-specific technical validation; those require a separate review appropriate to the process.

The research snapshot included the Swiss source page baseline, Google Search Console site-level query history, NIST evaluation material, a 2024 arXiv benchmark, a Gartner abstract, official Swiss regulatory pages, and an open small-business forum discussion. The site-level GSC aggregate showed “agent ia pour pme” at position 8 with one impression in its 19 October weekly record; the aggregate does not identify the landing URL. The source page was reachable with HTTP 200, self-referential canonical, and index, follow; that confirms technical indexability, not actual Google indexing or a query-to-page match.

The forum post could not be retrieved in full by the research fetcher, so its search-result excerpt is used only as a qualitative lead and is not treated as a representative dataset. The full Gartner research is paywalled; only its public abstract is cited. The GTA paper is a controlled benchmark with English queries and does not measure SME productivity. The Swiss regulatory timetable differs across two official pages. These limits reduce confidence in any broad prediction about agent reliability or regulation, but do not undermine the practical recommendation to compare an agent with a simpler baseline using your own process cases.

Decision table for the owner

Final checklist

• [ ] Is the task written as one bounded input-to-outcome transformation?
• [ ] Did we split fixed rules from language-heavy or context-dependent steps?
• [ ] Is an agent needed to choose the next step, or would AI-assisted drafting suffice?
• [ ] Are data access and tool permissions narrower than the user’s full account?
• [ ] Are high-impact actions separately authorized by a person or policy engine?
• [ ] Do the twelve cases include missing, contradictory, stale, duplicate, and adversarial inputs?
• [ ] Is the baseline measured with the same eligibility and outcome definition?
• [ ] Are exclusions, sample size, and uncertainty recorded?
• [ ] Can the owner inspect evidence, stop the system, and return to manual work?
• [ ] Did we re-check current Swiss and cross-border requirements with qualified counsel where needed?

Bottom line

An AI agent is justified only when flexible tool selection solves a real part of the task that fixed automation or a reviewed AI step cannot solve as well. Start with a measurable workflow, keep deterministic controls around probabilistic components, and grant autonomy gradually. If the task needs one correct answer, creates an irreversible side effect, or cannot be evaluated with real examples, keep a human approval gate or choose a simpler system.

The 10-signal matrix and 12-case suite are reusable starting assets—not validated thresholds. Use them to make assumptions explicit, test the failure paths, and learn whether an agent earns a larger role in your specific process. Do not generalize the benchmark, forum anecdotes, or GSC impressions into a promise of business results or search rankings.