Four AI decisions that do not require a forecast

Elon Musk expects an age of abundance in which work becomes optional. Dario Amodei considers very fast economic growth, high underemployment and high inequality possible at the same time. European institutions are investing in diffusion, infrastructure and a common regulatory framework. Switzerland is testing openness and technological sovereignty through infrastructure such as Apertus.

These positions do not describe one shared future. They differ on speed, distribution, risk and the role of institutions. They also come from actors with different interests.

An SME cannot wait until this debate is settled. It has to invest, learn and set limits now. The useful question is therefore not which forecast will win. It is which decisions remain sensible if several forecasts prove partly wrong.

Four decisions meet that test.

1. Build a task portfolio, not a tool list

Many AI programmes begin with products: licences are bought, workshops are held and teams are invited to experiment. Activity grows, but management still cannot say which part of the operating system should improve.

Start with recurring work instead. A suitable first task has a visible input, a visible output and a named owner. Its current cycle time, error rate or rework can be measured. The boundary between assistance, automation and a decision that must remain human can be stated before the pilot begins.

A task portfolio also prevents one model from becoming the strategy. Different tasks may need different models, interfaces and risk controls. The durable asset is the description of the work and its evaluation contract.

For one candidate process, write down:

• the event that starts the work;
• the result that marks it complete;
• the knowledge and permissions required;
• the person responsible for release;
• the current time, errors and rework.

If these points are unclear, the organisation is not yet evaluating AI. It is evaluating a demonstration.

2. Make private knowledge usable

General models know a great deal. They do not automatically know which version of an internal document is authoritative, who may see it or what a colleague learnt from a failed project five years ago.

For an SME, that private context is often more valuable than another increment in model capability. It contains customer history, product judgement, exceptions, local regulation and the reasons behind decisions.

Making it usable requires more than uploading a folder. Sources need owners. Permissions need to survive retrieval. Answers need citations. Important passages need human review. Corrections need to improve the next answer.

This creates an asset which can outlast a provider. The model may change; the structure of approved knowledge, access rules and feedback should not.

3. Install an evaluation loop before scaling

The European Investment Bank analysed matched data from more than 12,000 non-financial firms in the EU and the US. Its estimate associated AI adoption with a four per cent increase in labour productivity and no significant short-term job losses. The gains were concentrated in medium-sized and large firms and were supported by complementary investment in software, data and workforce training.

The four per cent is an estimated average effect, not a promise. The more useful finding is organisational: value appeared with the working system around the tool.

Define the measures before the pilot. For many administrative processes, four are enough:

• cycle time;
• error or exception rate;
• rework;
• escalation to a qualified person.

Add cost if it can be measured without distorting behaviour. Add quality only if the team can define it consistently. Compare a bounded period before and after the change.

A pilot without a baseline can still produce enthusiasm. It cannot produce reliable evidence.

4. Set governance and an exit route together

Governance is often treated as the part that slows adoption down. In practice, a short set of rules can make experimentation easier: people know which data may enter which system, where human review is mandatory and who may approve a new use case.

The same architecture should preserve an exit route. Keep source documents outside the model provider. Store important prompts, tests and workflow definitions in portable formats. Separate the user interface from the model where the cost is justified. Record which provider processed which data.

An exit route is not a prediction that a provider will fail. It is protection against price changes, discontinued features, regulatory constraints and a better model appearing elsewhere.

Open infrastructure can help, but openness alone does not create portability. The team still needs documented data flows, permissions and tests.

A one-hour management exercise

Use one leadership meeting and one real process.

First 15 minutes — task. Choose a recurring process with a visible beginning and end. Name its owner and the human decision that cannot be delegated.

Second 15 minutes — knowledge. List the authoritative sources, their owners and who may access them. Mark what is missing or outdated.

Third 15 minutes — evidence. Choose three before-and-after measures. Record the baseline before changing the process.

Final 15 minutes — limits and exit. Define prohibited data, the escalation point and how the workflow could move to another model or provider.

The output is one testable operating decision. It is not another technology roadmap.

What this framework does not claim

It does not predict model capability, regulation or labour-market effects. It does not show that every firm will gain four per cent productivity. It does not make high-risk applications safe through a checklist.

It reduces avoidable dependency and makes learning observable while the larger questions remain open.

Forecasts can guide attention. They should not replace operating decisions.