Strategy Journal / 18
AI strategy: choose the task before automating it
Topic retrospective: 2026-02-09 · Published and updated: October 10, 2026. Written now; not an archived historical publication.
An AI strategy connects a suitable task with verifiable quality, data access and accountability. It does not begin with a list of models. The question is whether an application helps under real conditions, makes errors detectable and preserves human decisions where consequences or uncertainty require them.
By Bernd Best · Original editorial analysis · Approximately 8 minutes
The decision
Automation can make a poor workflow faster. Compare a pilot with the existing task, including review, correction and exceptions. Faster first drafts do not necessarily save time across the whole process. Privacy, security and applicable obligations belong in the initial selection.
Working through the choice
Define the complete task
Describe inputs, required outputs, acceptable errors and review responsibility. An internal summary has different consequences from a binding customer response. Start with work whose quality can be assessed. If nobody can recognize a good result, the pilot is missing its most important prerequisite.
Review data and access
Determine which information may be used, who can access it and how long it is needed. Confidential information should not enter an arbitrary system without suitable review. Provider selection, contracts and technical safeguards depend on the use case. A generic promise of safe AI cannot replace that assessment.
Test difficult cases
Build a suitable small evaluation set with ordinary and challenging cases. Assess factual mistakes, omissions and unwarranted confidence separately. Include human review time. One impressive example justifies testing; it does not establish dependable operating performance.
Organize ownership and fallback
Name the person responsible for approvals and changes. Keep a manual fallback and document when to use it. Deployments in the EU, UK or US need assessment under the relevant local requirements. The EU AI Act is not a globally identical framework.
Illustrative case
Illustrative case: a team tests internal meeting summaries using permitted test data. It compares completeness, mistakes and total review time with the old workflow. Customers continue to receive human-reviewed statements. Evidence determines whether the team expands, changes or stops the use case.
A practical review
Starting measure: Reviewed quality and total time. Specify the unit, source, observation window and owner. Use comparable cases and keep exceptions visible.
| Period | Task | Evidence |
|---|---|---|
| Days 1 to 7 | Clarify task through one specific case. | A documented observation, not merely agreement. |
| Days 8 to 14 | Examine data with the responsible people. | An assumption and the evidence still missing. |
| Days 15 to 23 | Test evaluation within an agreed limit. | Recorded effects, workload and exceptions. |
| Days 24 to 30 | Decide the next step concerning ownership. | An owner, a date and a stopping rule. |
Use the timetable as a discussion aid and adjust it to the actual decision cycle. A manufacturing investment, a family handover and a short service test do not run on identical clocks. Do not infer improvement from completing tasks alone: check whether the decision became clearer and whether the effect appears in ordinary work. Keep a contrary observation in the review even when it complicates the original story.
US, UK, EU and DACH perspectives
The US, UK and EU take different regulatory approaches, and US states may add relevant requirements. In the EU, assess the particular use under the AI Act and applicable privacy rules. Switzerland and the UK are not EU members. The practical task is similar across markets: permitted data, testable quality and clear accountability. The legal assessment cannot be replaced by one global standard answer. Official sources below offer a starting point rather than a complete assessment of a specific deployment.
Frequently asked questions
How should I examine task?
Describe inputs, required outputs, acceptable errors and review responsibility. An internal summary has different consequences from a binding customer response.
How should I examine data?
Determine which information may be used, who can access it and how long it is needed. Confidential information should not enter an arbitrary system without suitable review.
How should I examine evaluation?
Build a suitable small evaluation set with ordinary and challenging cases. Assess factual mistakes, omissions and unwarranted confidence separately.
How should I examine ownership?
Name the person responsible for approvals and changes. Keep a manual fallback and document when to use it.
Which measure belongs in the review?
Begin with reviewed quality and total time. Define the observation window, data source and owner before measuring. Compare similar cases, record exceptions and assess effects on customers and workload. The metric is a local learning aid, not a benchmark or guarantee.
When is this approach unsuitable?
Do not use this framework as a substitute for missing facts, a resolved mandate or required specialist review. Begin with one bounded decision. If the work cannot change a next action, narrow the question or choose a more suitable method.
Further reading
These primary sources provide background. The argument, working plan, illustrations and hypothetical case above are original editorial work. Sources checked October 10, 2026.
If a decision in your business still feels unclear, the short strategy check offers a starting point for a conversation. Open the strategy check.