Start with the workflow, not the model

Most small businesses do not have a separate team that can spend months building a data platform. So the first question is not “which model should we buy?” It is “which recurring decision or operation consumes time, and how will we know that an assistant improved it?”

The OECD’s 2026 paper on SME digitalisation and AI draws on a survey of more than 2,000 small and medium-sized enterprises in 12 countries. The authors explicitly say the sample is not representative of all businesses. Respondents cited maintenance costs, lack of time for training and hardware costs among the obstacles to digital adoption. This is a useful guide to the kinds of problems companies face, but it is neither a statistic for the Russian market nor a guarantee that the same barriers rank the same way in any one company.

The practical point is simple: a pilot must test the whole workflow—people, data, integrations and controls—not just a model’s answers to a few cherry-picked examples.

Choose a narrow task

A good first task is repetitive, has a clear input and output, and does not trigger an irreversible action when it fails. For example, a system might classify incoming enquiries, draft a reply, extract fields from an order or help an employee find an instruction. Contract approval, price changes and payments should remain with a person and verifiable rules.

Score candidate tasks from 1 to 5 on five dimensions:

  • frequency and total staff time spent on the operation;
  • how standardised the incoming material is;
  • how many exceptions and manual corrections occur;
  • availability and quality of the required data;
  • cost of an error and whether the result can safely be sent for review.

Do not deploy a complex model where a template, search or ordinary automation is enough. AI is useful when the inputs contain variable text, images or ambiguity that simple rules handle poorly. Even then, use the model for a draft, candidate extraction or routing; leave critical checks to ordinary code and an accountable employee.

Record the baseline first

Before the pilot, collect a small sample of real examples with unnecessary personal and commercial data removed. Record how the task is performed today and note common exceptions. For each example, capture four things: the input, the expected result, what counts as an acceptable error, and who makes the final decision.

A minimal baseline can include:

  • weekly operation volume and median time per operation;
  • the share of operations that need correction or escalation;
  • common causes of rework and repeated data entry;
  • waiting time between steps and the share of overdue operations;
  • variable processing cost, if it is charged separately.

Do not substitute “model accuracy” for the business metric. A high share of correctly filled fields is not useful if an employee still checks every field and the workflow has not become faster or more reliable. Measure first-pass acceptance, review minutes per operation, serious-error frequency and cost per completed outcome. The process owner must set the acceptance threshold before testing—not the vendor after a demo.

Prepare the data and access boundaries

A pilot does not require a perfect company-wide database. It does require one agreed source of truth for the selected workflow and clarity about who may see it. Check which file versions are current, how fields differ between CRM or ERP records, and what a blank value means. If document retrieval is involved, enforce user permissions before sending retrieved passages to the model.

Put data into three groups: what may be sent to an external service; what may stay inside the company; and what must be removed, masked or excluded altogether. Before connecting a model, establish retention terms, administrator access, processing region, deletion periods and whether customer data is excluded from training. If these cannot be confirmed, use synthetic examples or a closed local environment.

Also define an input/output contract. For example, the input may be an email and an order record; the output may be JSON with the order number, item, quantity, confidence and a note about fields that could not be recognised. Validate the schema and ranges with ordinary code. If information is missing, the model should return “clarification required” rather than inventing a value.

A minimal pilot architecture

For a task such as enquiry triage, a small workflow is enough:

1. A service receives a request from email, CRM or a test folder and checks its type and access rights.
2. Rules remove disallowed fields, add an operation ID and select approved data sources.
3. A model classifies the request or creates a structured draft; if needed, RAG retrieves only documents the employee is allowed to access.
4. A validator checks the schema, required fields and allowed values.
5. An employee approves, corrects or rejects the result. Data is written to the CRM only after approval.
6. A log records the model and prompt version, source ID, validator outcome and human action, but not unnecessary customer text.

For a local model, do not stop at parameter counts or a laptop demo: test concurrent requests, latency, backups, model updates and server access. For a cloud service, check actual-volume cost, network failures and contractual data-processing terms. In a small pilot, compare both options on the same de-identified sample.

Run the pilot in four weeks

**Week 1 — observe.** The process owner maps the current workflow, collects examples and measures baseline time. IT records source systems, permissions, fields and data constraints.

**Week 2 — create a test set.** An experienced employee prepares control examples and expected answers. Include normal cases, rare formats, incomplete documents, conflicting values and examples that cannot be resolved. Mark the signals that require human escalation.

**Week 3 — shadow mode.** The AI produces results but does not change the production system. The team compares outputs with real decisions, groups errors by cause and changes only one or two settings per iteration. Do not exclude difficult cases from evaluation.

**Week 4 — limited rollout.** If the test meets the pre-agreed thresholds, enable the assistant for a small employee group. Writes remain reviewable, manual bypass remains available, and a manager can quickly disable the integration. Compare outcomes with the baseline and include support, review and correction costs.

Calculate the economics without magic

Measure the cost of an accepted operation, not the price of a model call. Include setup, integration, compute, storage, support, training, review time and error correction. A rough monthly benefit can be modelled as operation volume multiplied by genuinely saved minutes and the employee-hour cost, minus support and review expenses. This is an illustrative calculation: take its inputs from your own systems, not a sales deck.

If savings exist only under the assumption that nobody checks the output, the case has not yet been proven. If the system reduces re-entry, speeds up sorting or prevents missed enquiries, measure those outcomes instead. Avoided losses, reliable turnaround and owner time may matter to a small business too, but describe them separately rather than inventing revenue.

When not to scale

Pause if data cannot be used on a clear and lawful basis, outputs cannot be checked, no one owns errors, or review consumes all of the benefit. Stop as well if important customer or order groups experience systematic failures, even when an average metric looks acceptable.

NIST’s Generative AI Profile recommends stronger review, tracking and documentation as application risk increases. For a small business, that does not mean creating a compliance department. It means naming a process owner, allowed data, test scenarios, change log and shutdown plan.

What to do this week

Pick one workflow and ask two employees to show five ordinary and five difficult examples. Record the time, exceptions, data sources and any decision that must not be delegated without approval. That will clarify whether the problem needs generative AI, a local environment, RAG or ordinary automation. A short audit like this can save more than an early GPU purchase or a pilot on data nobody has checked.