What a programme for 100 small companies demonstrates

AI pilots in small businesses often begin with a model choice or a software subscription. That reverses the decision order: the team has not defined the process, data, or value metric, yet it is already discussing technology. A few weeks later, the demos may look impressive while management still cannot say what became faster, cheaper, or more reliable.

AI Sweden describes a different route. Through the AI Change Agent West project, it supported 100 small and medium-sized enterprises in western Sweden as they began their data and AI maturity journey. The offer was a 6–8 week project with introductory sessions, an AI maturity assessment, and an ideation workshop for identifying practical use cases with tangible business benefits. The supporting material emphasises domain knowledge, data quality, and the principle of starting small while keeping a larger ambition.

This is not evidence that all 100 companies achieved the same return: the published page does not provide comparable economic outcomes for every participant. Its value is the pilot structure. Readiness and use-case selection come first; technology follows. The framework below adapts that route for an SME while adding explicit quality, security, and economics gates.

Week 0: record the process without AI

Before the first model call, capture a baseline. Select one repeated process: triaging inbound leads, drafting a customer reply, searching policies, extracting document fields, or classifying service requests.

Record at least:

  • weekly operation volume;
  • median and peak handling time;
  • employee minutes per operation;
  • rework, return, and escalation rates;
  • the cost of an error and acceptable delay;
  • who makes the final decision today.

“Help the sales team” is too broad. A usable definition is: “create a reply draft from a CRM lead using the approved catalogue and customer history; a manager reviews and sends it.” Inputs, outputs, ownership, and the responsibility boundary are now visible.

Week 1: assess readiness, not enthusiasm

The OECD pilot SME AI Readiness Tool examines digital foundations, skills, data practices, current AI use, internal rules, risk assessment, and adoption barriers. The important part for a company outside the tool’s country scope is not the resulting label but the questions.

Run a short inventory:

  • where the source of truth lives: CRM, ERP, files, email, or a knowledge base;
  • whether a data owner and correction process exist;
  • whether data can be obtained through an API or a controlled export;
  • which fields contain personal, commercial, or contractual information;
  • who can maintain the integration after the pilot;
  • which decisions must never be delegated to a model.

If inputs are unprocessed scans, document versions are mixed, and access rights exist only by convention, narrow the pilot. Sometimes the best first-week result is a normalised reference list, a document template, or an access procedure rather than a model.

Week 2: select one use case with four criteria

List five to seven candidates and score each from 1 to 5:

1. **Frequency and effort.** The process must repeat often enough to measure a change.
2. **Data readiness.** Legally usable examples of inputs and correct outcomes must be available.
3. **Error cost.** A first pilot should favour a task where a person can review a draft cheaply.
4. **Integration simplicity.** One source and one destination are better than a chain of five systems.

Do not select a use case for spectacle alone. Autonomous email, price changes, or payments add risk and make measurement harder. Drafting, policy retrieval, or record completion creates a cleaner experiment.

The week should end with a one-page charter: process owner, user, input, expected output, prohibited actions, metrics, evaluation set, and stop condition.

Week 3: choose the minimum architecture

Architecture follows the task.

**Conventional automation without an LLM** is appropriate when rules are stable and formulas, regular expressions, or lookup tables can produce the result. A text field does not automatically justify AI.

**An external model API** enables a fast test on non-sensitive or properly de-identified data. Check contractual terms, processing location, logging, and whether data can be excluded from service improvement.

**A local model** is appropriate when documents cannot leave a controlled environment, predictable cost matters under steady load, or the business needs independence from an external service. Local deployment still requires access control, updates, monitoring, and quality evaluation.

**RAG** is needed when answers must rely on changing internal documents. The project then includes extraction, cleaning, chunking, metadata, permission filters, retrieval, and citations—not only an LLM.

**An agent** is justified for a multi-step process with tools. During the first pilot, let it read and draft. Writing to CRM, sending a message, or changing an order should require explicit human approval.

A minimum system usually contains an adapter to one source, a sensitive-data cleaning layer, the model or RAG service, an output validator, an event log, and an approval interface. Do not build a universal platform before one process proves value.

Week 4: build a shadow mode

The system processes copied or live tasks but does not change production data or contact customers by itself. Users see the model’s proposal next to the actual decision and label the outcome.

Log necessary events rather than every confidential payload:

  • use-case identifier and configuration version;
  • time spent by each stage;
  • sources used and permission checks applied;
  • automated validation result;
  • accepted, edited, or rejected proposal;
  • human review minutes;
  • escalation reason.

For RAG, store the index version and passage references. For an agent, record each tool call, requested permission, and human approval. For extraction, validate the output schema: required fields, types, ranges, and document checksums.

Week 5: test quality and risk

Build a golden set of real examples that are sanitised and authorised for testing. Include routine cases, rare formats, missing information, and adversarial requests. Separate tuning and final evaluation sets so the team does not silently optimise for known answers.

The NIST AI Risk Management Framework treats trustworthiness as part of AI design, use, and evaluation. A small pilot can translate this into a practical map:

  • what harm an incorrect output could cause;
  • who can catch the error before an action;
  • what data the model must not receive;
  • what happens when the service is unavailable;
  • how a configuration is rolled back;
  • what events stop the pilot.

Measure accepted outcomes, review time, rework, citation correctness, invalid actions, and cost per accepted operation—not general satisfaction with the response. High-risk routes should retain 100% human approval.

Week 6: decide through explicit gates

The final meeting should produce one of three decisions: stop, repeat a constrained test, or enter controlled operation.

Continue only when all conditions hold:

  • quality exceeds the predefined threshold on a held-out set;
  • total employee time falls after review is included;
  • critical errors do not pass the control barrier;
  • the process owner accepts responsibility for the operating procedure;
  • monthly model, infrastructure, data, and support costs are understood;
  • someone other than the prototype author can maintain the integration.

Economics must be measured against the baseline:

**period benefit = labour hours saved + losses avoided − all pilot and operating costs.**

Show one-time integration costs separately. For local infrastructure, include servers, redundancy, energy, administration, and realised utilisation. For APIs, include tokens, rate limits, log retention, and manual retries. The cheapest model can be expensive when employees rewrite every second answer.

What management should prepare

The starting package is not a platform specification. It is:

  • a charter for one process;
  • two to four weeks of baseline metrics;
  • 50–200 authorised evaluation examples;
  • a process owner and a data owner;
  • prohibited actions and sensitive fields;
  • a budget and team-time cap;
  • a fixed go/no-go date.

A six-week format does not guarantee deployment. It limits the cost of uncertainty. If a company cannot gather examples, name an owner, or define a useful outcome, that becomes visible before it buys hardware and licences.

Management takeaway

Start an AI initiative with one process and a baseline, not with a model. Six weeks is enough to test data readiness, choose a minimum architecture, run in shadow mode, and calculate the cost of an accepted result. A local model, RAG, or an agent should appear only when the task requires it.

The first practical step is to name the process owner and collect 50 real examples with actual handling time. If those two items do not exist after a week, it is too early to buy a platform.