Most AI projects are scoped backwards. A model or an agent framework arrives first, and the search for somewhere to put it starts afterwards. The order is comfortable, because a capability is easy to demonstrate and a business problem is not.
It also explains why the published evidence looks contradictory. AI adoption is rising much faster than measured financial impact, and the same technology produces large gains on one task and worse answers on the next. Neither of those findings is a verdict on AI. They are both statements about fit.
Adoption is running ahead of impact
In 2025, 20% of EU enterprises with at least 10 employees used AI technologies, up from 13.5% a year earlier, according to Eurostat. Analysis of written language was the most common category of use.
Enterprise financial impact has not kept pace. McKinsey's State of AI 2026 survey found that 37% of respondents attributed any EBIT impact at all to AI, and about 6% qualified as what McKinsey calls high performers. Roughly 20% said AI-related operating costs were already constraining how much they could use it.
At task level the picture is just as split. A field study of 5,172 customer-support agents, published in the Quarterly Journal of Economics, found that access to a generative AI assistant raised issues resolved per hour by an average of 15%, with the largest gains going to less experienced staff (Brynjolfsson, Li and Raymond). A field experiment with 758 consultants, published in Organization Science, found that on tasks inside the model's capability frontier participants completed 12.2% more work and finished 25.1% faster, while on a task deliberately chosen to sit outside that frontier they were 19% less likely to reach the correct answer (Dell'Acqua and colleagues).
Read together, those numbers say something more useful than either one alone.
Which of our problems create enough measurable value, have the right task characteristics and data, and can tolerate a probabilistic answer better than ordinary software can?
A capability is not a use case
"Summarisation" is a capability. "Cut the time account managers spend turning customer meetings into CRM records, while keeping the mandatory fields and an approval before submission" is a use case.
The difference is that the second one can be analysed. It has a process, a volume, a cost, an owner and a definition of done. "Deploy an LLM", "use agents" and "introduce generative AI across the company" have none of those, which is why they cannot be evaluated, funded or refused on evidence.
A workable problem statement carries four things: the current state, a measurable pain, the process it sits in, and the outcome you want instead. Something like this: our finance team processes supplier invoices arriving in hundreds of layouts, which creates a two-day backlog and heavy exception handling, and we want to cut processing time and manual intervention without weakening financial control.
Before any technology discussion, write down the business objective, the process owner, the current workflow, transaction volume and frequency, cycle time, loaded labour cost, rework and error rates, the cost of a mistake, the systems involved, what data exists, its security classification, the regulatory constraints, the judgement the work genuinely requires, and the baseline KPIs. That list is the AI business context, and it is what turns an initiative into something an engineer can size.
Map the process before automating it
A large share of failed projects automate the visible task without examining the process around it. Map the work as input, activity, decision, hand-off, system, exception, output. Then look for where work queues, which steps create rework, where information is entered twice, which decisions depend on knowledge nobody wrote down, where people move data between systems by hand, which approvals add no control, and which exceptions absorb most of the effort.
What that usually surfaces is that the automation candidate is not the bottleneck.
If an invoice waits three days because it needs five approvals, routing it automatically through the same five approvals moves the queue rather than removing it. If people copy six known fields between two systems, an API integration is more dependable than an agent. If an internal assistant cannot answer questions because the documentation is out of date, a better model will not fix the documentation. Sometimes the highest-value AI project turns out to be a process change with no AI in it.
Four situations that look identical
Requests that sound the same at the steering committee are usually one of four different problems, and each has a different correct first move.
| Situation | Typical symptom | First response |
|---|---|---|
| A solution looking for a problem | "We have the platform. What can we use it for?" | Go back to business objectives |
| A problem suited to AI | Important work turns on variable language, classification or prediction | Evaluate AI properly |
| A conventional automation problem | Inputs, decisions and outputs can be written as stable rules | Software, APIs, workflow tooling or RPA |
| A process problem | Duplicate work, unnecessary approvals, unclear ownership, poor master data | Redesign the process first |
Ordinary software should stay the default whenever the correct answer can be specified exactly: calculations, deterministic validation, permissions, eligibility rules, database operations, scheduled workflows, state transitions, tax and pricing formulas. If an engineer can define the right result in code, a probabilistic model mostly adds uncertainty.
AI earns its place when variability is the hard part. Unstructured documents, natural language, speech and images, classification, extraction, semantic search, prediction, anomaly detection, recommendation, generation, inconsistent inputs, and workflows with too many variations to express as a rule tree. Even then the whole process rarely needs it. The architecture that holds up is usually AI for the ambiguous step and deterministic software for the controlled ones.
The frontier runs through your own work
The 758-consultant experiment is the most practically useful result in this area, because of what it says about granularity. Two activities can look equally demanding to a person and be entirely different for a model. That jagged edge does not follow job titles, seniority or department. It runs through individual tasks.
So the question to ask is whether AI can do this specific task, for these users, on our data, at an acceptable quality and cost. Not whether the newest model is capable in general. A task worth testing is frequent enough for gains to compound, expensive enough to matter, measurable, variable enough that rules struggle, supported by information the system can reach, and produces output somebody can check. If a mistake cannot be detected, the last condition fails and the rest does not matter.
Data readiness is the usual constraint
Gartner surveyed 1,203 data-management leaders and found 63% either did not have the right data-management practices for AI or were unsure whether they did. Gartner also forecasts that through 2026 organisations will abandon 60% of AI projects that are not supported by AI-ready data. That second figure is an analyst forecast rather than an observed rate, and it should be read as a statement about the dependency rather than a measured failure percentage.
What readiness means changes with the use case. A predictive model needs historical observations, representative outcomes, reliable labels, enough examples of rare events, and some stability between past and future conditions. Document processing needs representative documents, the expected fields, the edge cases, a known output structure and validation rules. A retrieval assistant needs authoritative sources, permissions that hold, useful metadata, update and deletion processes, and a set of evaluation questions. An agent needs more than documents: dependable access to CRM, ERP, ticketing, databases, identity, internal APIs and the business rules themselves.
For each candidate, answer whether the data is available, current, representative and lawfully usable, who owns it, whether access permissions survive the integration, and whether an evaluation set can be built from it. Where the answers are missing, the first investment is data engineering, not AI.
Hours saved are not savings
A technically feasible problem can still be economically pointless. Estimate annual volume, average handling time, loaded labour cost, rework, exception handling, error losses, delay cost, lost revenue and current technology cost, and only then work out how much value is actually recoverable.
One error recurs often enough to name. Saved hours are not money. If an assistant frees ten hours a week and that capacity is neither removed nor redeployed, the organisation has created slack, not cash. Value appears when the capacity processes more volume, improves service, removes overtime, eliminates external spend, shortens revenue cycles or moves people onto higher-value work. Decide which of those it will be before anyone writes an ROI figure into a business case.
What it costs to be wrong
Average accuracy is a weak decision metric on its own. A system described as 95% accurate can be excellent or unusable depending entirely on the remaining 5%. Four questions settle it: what happens when it is wrong, can the error be detected, can it be reversed, and what does verification cost?
A wrong internal draft that someone reads before sending is a different category from rejecting a job candidate, executing a payment, stopping a production line or making a clinical recommendation. Human oversight should be proportional to uncertainty and consequence, which is not the same as approving everything.
Automate
Bounded, high-volume work where a mistake surfaces quickly and costs little to undo.
- AI absorbs the variability, code enforces the rules
- Errors are detectable and reversible
- Representative test cases can be assembled
Augment
Work where AI can do the preparation but a named professional stays accountable.
- Reviewing costs less than doing it unaided
- Consequential steps keep an approval gate
- Contract analysis, diagnosis, drafting, research
Keep human-led
Work where judgement is the value, or where a wrong answer cannot be caught.
- Decisions are irreversible or can harm people
- Outputs cannot be meaningfully verified
- No competent reviewer exists
An opportunity score you can run
To make prioritisation repeatable rather than political, score every candidate against the same criteria. The framework below is ours, built for practical triage across departments. It is a heuristic for comparing opportunities, not a validated predictor of project success.
Four gates come first, and a candidate that fails one is not scored, it is fixed. Is there a measurable outcome? Can representative, reliable and lawful data be reached? Can errors be detected, reviewed, contained or reversed to an acceptable degree? And does AI offer a real advantage over simpler software or a process change?
Candidates that clear the gates are scored 1 to 5 on ten dimensions, each carrying a different weight. The score out of 100 is the sum of score ÷ 5 × weight.
Reading the score
Above 80 is a strong pilot candidate. Between 65 and 79 is promising once the largest uncertainty has been tested. Between 50 and 64 means the foundations need work first, and below 50 should be deferred or solved another way. Those bands are prioritisation thresholds, not probabilities of success.
A variable-format invoice workflow scoring 5 on business value, task fit and frequency, 4 on data readiness, error economics, oversight, regulatory fit, time to value and evaluation readiness, and 3 on integration, comes out at 86. That is a strong candidate for a controlled pilot, and it is worth noting how much of the score comes from things that have nothing to do with the model.
Where this pattern has held up
Published results fall into two categories that should not be mixed: independent research, and figures a company reports about itself.
Microsoft describes a document-processing workflow at Concentrix handling roughly 100,000 invoices a month across more than 300 layouts, with extraction accuracy above 96% and reaching 99% in January 2026. Morgan Stanley says its internal AI Assistant reached 98% adoption among Financial Advisor teams, and that its Debrief system produces meeting summaries and action items from authorised client meetings. Siemens reports that Industrial Copilot maintenance pilots cut reactive-maintenance time by an average of 25%. DBS reported more than 2,000 AI and ML models across over 430 use cases in its 2025 annual reporting, with about SGD 1 billion of annual economic value attributed to data analytics and AI.
All four are company-reported. None is a controlled estimate, and none is a forecast for a different organisation. What transfers is the architecture rather than the percentage: AI absorbs the variability, deterministic logic controls the business process, and a named person stays accountable for consequential steps.
Software development shows why borrowed numbers are dangerous. METR's randomised trial found that early-2025 AI tools made experienced open-source developers 19% slower in the environment tested. In February 2026 METR reported that newer tools probably provide more acceleration than the ones it tested first, while explaining that selection effects in the newer experiment made the size of that improvement impossible to estimate reliably. Two credible results, a year apart, pointing different directions. Benchmark your own engineers, repositories and task mix instead.
Which problems should not go to AI
This decision deserves the same rigour as finding candidates, and it is where an assessment earns most of its money.
Problems with a deterministic answer. Do not use a language model to calculate tax, enforce permissions, validate identifiers, compute interest or execute fixed business logic. Use code. AI is valuable precisely where deterministic logic stops being practical.
Low-volume, low-value work. A task that happens a few times a year and takes fifteen minutes does not justify an integrated system, however good the architecture.
Broken processes. Unnecessary approvals, duplicate entry that should be deleted, unclear ownership, obsolete forms and bad master data all get worse when automated, because automation makes them permanent.
Problems without a measurable outcome. "Become AI-first" is not an outcome. Neither is "deploy agents" or "improve innovation". Without an operational or economic variable, the project cannot be shown to have worked, which usually means it will not be stopped either.
Tasks where errors are expensive and cannot be verified. AI can still help with preparation and research in high-consequence settings. Full automation is hard to defend where decisions are irreversible, failures can harm people, the evidence cannot be reconstructed, the model cannot reliably tell when it is wrong, or no competent reviewer exists.
Problems where the data does not exist. A model cannot repair a missing business reality. Obsolete documentation, outcomes that were never recorded, unreliable labels and unknown access permissions are all prerequisites, not implementation details.
Tasks where checking takes as long as doing. Human-in-the-loop only creates value when review is cheaper than the unaided work. If someone has to reconstruct every answer to know whether it is right, the work has moved rather than gone.
AI for its own sake. Gartner reported in January 2026 that at least 50% of generative AI projects had been abandoned after proof of concept by the end of 2025, citing poor data, weak risk controls, rising costs and unclear business value. The technology can work while the project still fails.
Regulation belongs in discovery
For Swiss and European companies, legal classification is part of opportunity assessment. Discovering it late is how a working prototype becomes unusable.
Switzerland has no general AI statute yet. The Federal Council has instructed federal authorities to prepare legislation implementing the Council of Europe AI Convention, with a consultation draft expected by the end of 2026 (Federal Chancellery). That is not the same as AI being unregulated. The revised Federal Act on Data Protection has applied since 1 September 2023, and the FDPIC states that the FADP applies to AI-supported processing of personal data, with particular emphasis on transparency and on automated individual decisions. Where an automated individual decision falls within the scope of Article 21 FADP, the controller must inform the data subject and provide the ability to state a position and request human review, subject to the statutory exceptions (FDPIC).
In the EU, the AI Act became generally applicable on 2 August 2026, and the timetable then changed. The AI Omnibus entered into force on 27 July 2026 and extended the application dates for the main high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for high-risk AI embedded in Annex I regulated products (Regulation (EU) 2026/1744, and the European Commission's implementation pages). Some transparency rules already apply from August 2026. Swiss organisations should read Article 2 on territorial scope carefully, since it covers certain providers and deployers in third countries where the output is used in the Union. Where GDPR applies, Article 22 also gives a right not to be subject to certain decisions based solely on automated processing. None of this is legal advice, and the practical consequence is only that classification is cheap during discovery and expensive after build.
Buy the model, build the workflow
Once a use case survives prioritisation, decide how much of it you actually need to build. Buy when the problem is commodity, mature software already handles it, integration is light, differentiation is minimal and the vendor's security and data-processing model is acceptable. Build or customise when proprietary workflow or data is central, deep ERP or CRM integration is required, permissions are specialised, auditability requirements are unusual, or the available software does not fit the process.
For most companies this is not binary. The common architecture is to buy the model or platform and build the workflow, integration, permissions, evaluation and governance around it. Owning a foundation model is rarely the differentiator. Owning the process around it frequently is.
Deployment follows the same logic.
| Approach | Main benefit | Main trade-off |
|---|---|---|
| Managed AI API | Fast access to current models | External dependency and usage cost |
| Private or hybrid managed AI | Stronger control boundaries | More architectural complexity |
| Self-hosted, open-weight models | Full runtime and infrastructure control | GPUs, scaling, patching and operations become yours |
The framing to avoid is that cloud is insecure and self-hosting is safe. A self-hosted retrieval system with the wrong document permissions will leak confidential material perfectly well. What matters is data classification, residency, retention, processor relationships, encryption, identity and permissions, volume, latency, resilience, cost, monitoring, model lifecycle, incident response and who owns the system at 3am. Self-hosting buys control and transfers responsibility in the same movement.
Evaluation does not stop at launch
A convincing demonstration is not evidence. NIST's AI Risk Management Framework recommends testing AI systems before deployment and regularly while they run, and treats production monitoring as part of risk management, because behaviour changes as data and operating conditions do.
Two layers are needed. System quality covers accuracy, precision and recall, extraction error, unsupported-answer rate, retrieval relevance, tool-call success, escalation and edit rates, latency, cost per successful task and failure recovery. Business quality measures the outcome the project existed for: throughput, cost, cycle time, backlog, SLA performance, error cost, revenue, conversion, downtime or user satisfaction. The operating cycle is evaluate, deploy, monitor, collect feedback, regression-test, update. An AI system is running software, not a finished innovation project.
Where to start
You do not need a six-month strategy exercise to find the first candidate. Identify the processes that are expensive or constrained. Record the baseline: volume, time, quality, cost. Map the real workflow, exceptions and workarounds included. Remove what should not exist. Then compare solution classes in order, from process redesign through software and APIs and workflow automation to AI augmentation and only then AI automation. Apply the four gates, score what survives, and build the smallest complete workflow using representative data and real integration points, because a chatbot disconnected from the systems proves almost nothing.
Then compare against the baseline, and be willing to stop. A pilot that shows AI should not be deployed has produced a useful result and saved the production budget.
At Alpine Edge we treat opportunity discovery as business analysis and engineering before it is an AI exercise. The output we aim for is not a long list of possible applications. It is a shorter list of problems worth solving, the evidence for why AI suits them, an architecture that fits the organisation, and explicit reasons for rejecting the rest. If that is the stage you are at, a focused technical assessment is usually a better first step than committing to a programme, and we can take the ones that survive from discovery through architecture and integration into dependable production.
Where these numbers come from
- Eurostat, AI use in EU enterprises. 2025 adoption figures.
- McKinsey, The State of AI 2026. EBIT impact, high performers and operating-cost constraints.
- Brynjolfsson, Li and Raymond, Generative AI at Work. Quarterly Journal of Economics; 5,172 support agents.
- Dell'Acqua et al., Navigating the Jagged Technological Frontier. Organization Science; 758 consultants.
- Gartner, lack of AI-ready data puts AI projects at risk. Survey of 1,203 data-management leaders, and the AI-ready-data forecast.
- Gartner, why half of GenAI projects fail. January 2026 analysis of abandoned proofs of concept.
- METR, early-2025 developer productivity study. Randomised trial with experienced developers.
- METR, February 2026 update. Why the newer result cannot be sized reliably.
- Microsoft, Concentrix document processing. Company-reported volume and accuracy.
- Morgan Stanley, AI Assistant and Debrief. Company-reported adoption.
- Siemens, Industrial Copilot maintenance. Vendor-reported pilot result.
- DBS, 2025 annual report. Company-reported AI portfolio and attributed value.
- European Commission, regulatory framework for AI. AI Act application dates.
- EUR-Lex, Regulation (EU) 2026/1744. The AI Omnibus and the revised high-risk dates.
- EUR-Lex, EU AI Act. Official text, including Article 2 on territorial scope.
- EUR-Lex, GDPR. Article 22 on automated individual decision-making.
- Swiss FDPIC, AI and data protection. FADP applicability to AI processing.
- Swiss FDPIC, duty to provide information. Article 21 FADP and automated individual decisions.
- Swiss Federal Chancellery, regulation of AI. Status of Swiss AI legislation and the planned consultation.
- NIST, AI Risk Management Framework. Pre-deployment testing and production monitoring.