Choosing AI use cases for a business starts with understanding the work: where it takes too long, what errors cost and which information people need to complete it. A model demonstration can suggest possibilities, but it cannot answer those questions for you.
This guide sets out a practical approach to AI business problem solving. It covers process mapping, data readiness, return on investment and the cost of errors, then brings them together in a scoring method for comparing potential projects.
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.
McKinsey's State of AI 2026 survey found that 37% of respondents attributed an EBIT impact to AI, and about 6% qualified as what McKinsey calls high performers. Roughly 20% said AI-related operating costs were constraining their use. These are different populations and measures from Eurostat's adoption figures, so they do not provide a direct comparison of adoption and financial returns.
Results also vary by task. A field study of 5,172 customer-support agents, published in the Quarterly Journal of Economics, found that a generative AI assistant raised issues resolved per hour by an average of 15%, with the largest gains among less experienced staff (Brynjolfsson, Li and Raymond). A field experiment with 758 consultants found that participants completed 12.2% more tasks and finished 25.1% faster on work within the model's capabilities. On a task outside those capabilities, AI users were 19 percentage points less likely to reach the correct answer (Dell'Acqua and colleagues).
These studies support testing individual tasks before committing to wider automation. For each candidate, ask:
What should improve, how will we measure it, and can we detect and manage the errors AI makes?
Define the business 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 second statement identifies a workflow and its controls. It gives the team something to measure and an owner to involve. A proposal to deploy an LLM or introduce agents needs that level of detail before its cost and value can be assessed.
A workable problem statement includes the current process, a measurable problem and the intended outcome. For example: "Our finance team receives supplier invoices in hundreds of layouts, creating a two-day backlog. We want to reduce handling time and exceptions while keeping the existing financial controls." These are illustrative details; use your own operational figures.
Record the information needed to estimate the project:
- The business objective, process owner and current workflow
- Transaction volume, cycle time, labour cost and rework
- Error rates, the cost of a mistake and the review required
- Source systems, available data, access rights and security classification
- Regulatory constraints and the baseline measures for judging improvement
Map the process before automating it
Map the inputs, activities, decisions, hand-offs, systems, exceptions and outputs. Look for queues, duplicate entry and repeated corrections. Ask which decisions rely on undocumented knowledge and which exceptions take the most time. Include the workarounds staff use when the documented process does not fit.
The task first proposed for automation may be only a small part of the delay.
If an invoice waits three days for five approvals, automatic routing may leave the main delay intact. Copying six fixed fields between systems may need an API integration. An internal assistant using outdated documentation needs better source material. Review these alternatives before assigning model development to the team.
Decide whether the problem needs AI
Use the following categories to choose the first step in an assessment.
| 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 |
Use ordinary software for results that can be specified exactly: calculations, validation, permissions, fixed eligibility rules, database operations, scheduled workflows and pricing formulas. These tasks need reproducible execution.
AI is useful when the input varies too much for a practical set of rules. Candidate tasks include document extraction, language classification, semantic search, prediction and anomaly detection. An invoice workflow, for example, might use AI to extract fields, then code to validate totals, check duplicates and enforce approvals.
Test the individual task on your own data
The consultant experiment illustrates why a department or job title is too broad a unit for evaluation. Two tasks that look equally demanding to a person can produce quite different model results.
Test this task, for these users, on your data, at the required quality and cost. Choose representative cases, including difficult inputs. A useful pilot needs enough volume to measure, accessible source information and a way to check the output. If errors cannot be detected reliably, reconsider the scope or keep the decision with a qualified person.
Check data readiness and access
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, establish whether the data is available, current, representative and lawfully usable. Identify its owner, check whether permissions carry through to search and model context, and confirm that it can support an evaluation set. Budget for any data preparation before estimating model development.
Estimate the return on AI investment
Technical feasibility does not establish a business case. Estimate annual volume, handling time, labour cost, rework, exceptions, error losses and current technology cost. Then identify which costs can fall or which additional work the team can complete.
If an assistant frees ten hours a week, explain how that time will be used. It may help the team process more volume, improve service, reduce overtime or avoid external spend. Those benefits differ from a direct reduction in payroll. Include review time, implementation, model usage, monitoring and maintenance in the ROI calculation.
Account for the cost of errors
Accuracy alone is insufficient. For a system described as 95% accurate, investigate the errors in the remaining 5%: their consequences, how reliably they can be detected, whether they can be reversed and the cost of checking them.
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 interprets inputs; code enforces 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, drafting and 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
Score and prioritise AI use cases
Use consistent criteria to compare candidates across departments. The Alpine Edge AI Opportunity Score below is a planning heuristic. It helps structure an assessment but has not been validated as a predictor of project success.
Check four prerequisites before scoring: a measurable outcome; representative and lawfully usable data; acceptable ways to detect and manage errors; and a credible advantage over simpler software or a process change. A candidate that fails a check needs further work or a different approach.
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
A score of 80 or more indicates a strong pilot candidate. Scores from 65 to 79 suggest testing the largest uncertainty first. From 50 to 64, work on the foundations; below 50, defer the project or consider another approach. These bands guide prioritisation and do not express a probability of success.
For example, an invoice workflow scores 86 if it receives 5 for business value, task fit and frequency; 4 for data readiness, error economics, oversight, regulatory fit, time to value and evaluation readiness; and 3 for integration. It qualifies for a controlled pilot, with integration as a concern to investigate early.
Published examples of business AI use cases
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.
These are company-reported outcomes, so use them to understand the applications and their scale. They are not controlled estimates or forecasts for another organisation. Examine the source data, integration, controls and human responsibilities when considering a similar use case.
Software development shows the limits of transferring results between settings. METR's randomised trial found that early-2025 AI tools made experienced open-source developers 19% slower in the environment tested. In a February 2026 update, METR said newer tools likely offered more acceleration, but selection effects prevented a reliable estimate of the improvement. Test the tools on your own repositories and task mix.
Which problems should not go to AI
Record rejected candidates and the reasons for rejecting them. Common reasons include the following.
A deterministic answer. Tax calculations, permissions, identifiers, interest calculations and fixed business rules need reproducible code.
Low volume or limited value. A task taking fifteen minutes a few times a year is unlikely to justify a custom integration. Check whether an existing tool is sufficient.
An unresolved process problem. Remove unnecessary approvals, duplicate entry and obsolete forms, and resolve unclear ownership before automating the workflow.
No measurable outcome. Goals such as "become AI-first" or "deploy agents" need an operational measure before a pilot can be assessed.
Errors that cannot be checked or contained. AI may help with preparation and research, but full automation needs particular scrutiny when failures can harm people, decisions are irreversible or qualified review is unavailable.
Missing or unreliable data. Outdated documentation, unrecorded outcomes, poor labels and unknown access rights need to be addressed before a dependable system can use them.
Expensive review. Include the time needed to reconstruct or verify an answer. If checking takes as long as the original task, any benefit must come from something other than time saved.
An unclear business case. 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. A functioning prototype still needs an economic and operational case for deployment.
Regulation belongs in discovery
For Swiss and European companies, assess applicable legal obligations during discovery. They can affect data access, the permitted uses of a system and the controls required before launch.
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. Separate dates apply to high-risk systems. 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. Assess the applicable rules during discovery so that they inform the design and deployment plan.
Choose what to buy, customise or build
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.
Many projects combine a purchased model or platform with custom workflow code, integrations, permissions and evaluation. Compare that approach with packaged software before taking on the cost of a fully custom system.
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 |
Deployment location alone does not establish security. Check data classification, residency, retention, processor relationships, encryption and document permissions. Also compare volume, latency, resilience and running cost. Self-hosting gives the team more infrastructure control and responsibility for patching, monitoring, model updates and incident response.
Evaluation does not stop at launch
A demonstration provides limited evidence about everyday use. NIST's AI Risk Management Framework recommends testing before deployment and regularly during operation, because behaviour can change with data and operating conditions.
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
Start with a process that is costly or constrains the team. Record its volume, time, quality and cost, then map the workflow with its exceptions. Compare a process change, conventional automation and AI assistance. Apply the four prerequisites, score viable candidates and test a small complete workflow using representative data and the intended integrations.
Compare the pilot with the baseline before deciding to expand it. A result that rules out deployment is useful if it prevents a larger investment in a poor fit.
At Alpine Edge, a technical assessment produces a prioritised set of use cases, the evidence for testing them, an outline architecture and reasons for rejecting other candidates. We can then take a suitable project through AI development, integration and production operation.
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.