Generative AI for businesses pays off first where a narrow, repeatable task goes to a co-pilot that drafts, summarises or retrieves, and a person checks the output before it goes anywhere. The adoption guidance from FAIGMOE and AWS points the same way: begin with a carefully designed pilot, keep its scope limited, document what success looks like, and scale only after the pilot has been validated, because scaling first risks system failures. The hosted services that organisations have already trialled are the most useful evidence here. They show which tasks a co-pilot speeds up, where it gets things wrong, and what changes in cost and dependency once usage stops being experimental.
The FAIGMOE framework (arXiv, 2025) breaks adoption into four phases: strategic assessment, planning and use-case development, implementation and integration, and operationalisation and optimisation. The rest of this article follows the decisions a team meets inside those phases, in the order it meets them.
Generative AI for businesses: what the services are actually used for
Usage falls into two modes, copilot and workflow agent. A 2025 study of knowledge workers at Argonne National Laboratory defines a copilot as a system that works with a user on a task and responds conversationally, and a workflow agent as an autonomous or semi-autonomous system that carries out complex tasks mostly on its own. Current copilot use in that study centred on writing structured text or code that the user can easily verify, such as emails and reports. Employees wanted to go further and extract insights from unstructured text, but held back because they feared hallucinations.
The government trials show copilot use centred on similar text tasks. In Australia’s whole-of-government Microsoft 365 Copilot trial (Digital Transformation Agency, 2024), Copilot was used mainly to summarise information and rewrite content, and participants estimated savings of up to an hour when summarising, drafting a first version of a document or searching for information. The UK Government Digital Service ran a trial with 20,000 civil servants from September to December 2024; participants reported saving an average of 26 minutes a day, with drafting documents saving 24 minutes.
Sales is another clean example. Microsoft’s MSX Sales Copilot paper (2024) describes a real-time question-answering skill that recommends sales material a seller can share during a customer call, built on a bi-encoder retriever with a cross-encoder re-ranker. In satisfaction surveys over the first two months, sellers rated the skill’s relevance to their daily tasks 4 out of 5 and the relevance of the recommended documents 3.7 out of 5.
Workflow agents are at an earlier stage. Argonne respondents had tried agent-style tasks such as analysing data (43%) and merging, cleaning or formatting data (35%), but the researchers describe generative AI workflow agents as being in the early stages of development and use. Our piece on generative AI across industries goes sector by sector, and the gap between agent demos and production is covered in what agentic AI is actually shipping versus what is still research.
Which uses suit a first co-pilot pilot
| Use | Mode | Fit for a first pilot |
|---|---|---|
| Drafting emails, reports and documents | Co-pilot | Strong: output is easy for the author to verify |
| Summarising and rewriting content | Co-pilot | Strong: the most common use in the Australian trial |
| Finding internal or sales content | Co-pilot with retrieval | Evidence: sellers rated MSX Sales Copilot’s document relevance 3.7 out of 5 |
| Extracting insights from large unstructured text | Co-pilot | Later: users held back over hallucination |
| Multi-step data workflows (analysis, cleaning, formatting) | Workflow agent | Not first: agents are still early stage |
| Nuanced, context-heavy judgement | Human, with co-pilot support | Keep the decision with a person |
Why start with a human in the loop instead of full automation?
A co-pilot is the safer first deployment because it puts a reviewer between the model and anyone who acts on its output, and that reviewer is what turns an unreliable generator into a useful tool. The UK trial found that Copilot, as an assistive tool, still needed human input and decision-making, and that it struggled with nuanced or context-heavy data that calls for human judgement. The Australian evaluation found that Copilot’s inaccuracy reduced the productivity benefit: up to 7% of participants said it added time to their activities, because outputs needed checking and editing. Removing the reviewer does not remove those errors.
The co-pilot framing also brings the feasibility question forward. We hold that the first thing to settle in any generative AI engagement is whether the expected outcome is plausible at current capability: getting a model to take over a repeatable, menial task is a very different proposition from wanting it to be smarter than the people it serves, and only the first reliably has measurable ROI. A co-pilot pilot tests exactly the first kind.
Human review also combines with partial automation. Chrono Innovation describes confidence-based routing in which high-confidence outputs pass straight through, medium-confidence outputs are flagged for asynchronous review, and low-confidence outputs wait until a human approves them. A pilot that logs reviewer decisions is collecting exactly the evidence needed to set those thresholds later. There is an adoption argument too: FAIGMOE notes that solutions augmenting people rather than replacing them win greater acceptance.
Which business function should run the first co-pilot pilot?
Pick the function with the most high-volume, repeatable text work, a named person who can judge the output, and a result you can measure. FAIGMOE recommends ranking candidate use cases on business value, technical feasibility, implementation complexity, resource requirements, risk and strategic fit, and suggests that midsize organisations focus on high-impact departmental applications, run as single-department pilots. Chrono Innovation makes the same point more bluntly: teams that ship start with a specific workflow, a specific user and a specific outcome, and define “good” before writing inference code.
The studies cited here show benefits in three places:
- Administration, HR and policy. The UK trial found Copilot most beneficial for routine administrative work such as scheduling, reporting and documentation drafting, with a strong signal from HR and policy teams.
- Customer support. Brynjolfsson, Li and Raymond (NBER, published in QJE 2025) studied 5,179 support agents and found that a generative AI assistant raised issues resolved per hour by 14% on average, by 34% for novice and low-skilled workers, with minimal effect on experienced workers. Our article on generative AI in customer service covers that function in depth.
- Sales enablement. Content recommendation inside the CRM, as in MSX Sales Copilot.
One finding cuts across functions. In the UK trial, professions with the lowest familiarity and confidence in AI tools saw the smallest time savings. In Australia, 75% of participants who received three or more forms of training were confident using Copilot, 28 percentage points more than those who received one. A function with no appetite for training is a poor first choice, however good its use case looks on paper.
What are the risks of using generative AI services, and how does a co-pilot contain them?
The risks raised most are unreliable output, people trusting it too much, and data privacy and security. Among the Argonne survey respondents, 44% raised reliability concerns, 21% worried about overreliance, and 42% had privacy and security concerns. The researchers called the lack of reliability and the tendency to hallucinate the biggest barrier to adoption. The Australian evaluation adds a quieter risk: Copilot may magnify an organisation’s existing poor data security and information management practices.
| Risk | How it shows up | Containment in a co-pilot pilot |
|---|---|---|
| Hallucination and unreliability | Confident but false output, missing citations | Pick tasks whose output the user can verify; keep a person overseeing the output |
| Overreliance and automation bias | Users stop checking outputs thoroughly | Keep reviewers aware of automation bias and able to disregard, override or reverse the output |
| Data privacy and security | Staff redact sensitive data before using LLMs but disagree on what is acceptable to share | Provide a sanctioned internal or private instance and a clear data policy |
| Exposure through broad permissions | Retrieval surfaces documents a user should not see | Use tools that inherit the user’s permissions, as M365 Copilot does with retrieval-augmented generation |
| Shadow use of better external tools | Employees bypass an internal tool that falls behind | Keep the sanctioned option competitive with commercial alternatives |
Two cautions about the containment column. First, a private instance only helps if people use it: Argonne staff felt safer with their private deployment, but it offered GPT-3.5 while GPT-4 was already available commercially, and the researchers warned the strategy could backfire for that reason. Second, the EU AI Act’s Article 14 requires high-risk AI systems to be designed so that the people overseeing them can understand their limits, stay aware of automation bias, and disregard, override or reverse the output. Those oversight capabilities are a sound design checklist for any co-pilot, high-risk or not. FAIGMOE argues for putting governance in place before wide deployment, scaled to the organisation’s complexity and regulatory exposure. Our article on generative AI security risks and best-practice measures covers the security controls in more detail.
A pilot that leaves usable value behind
A co-pilot pilot should produce working artefacts at every stage, not one verdict at the end. A delivery-oriented AI project needs milestones that deliver tangible, usable results before the final goal is reached, because a project whose only value arrives with a perfect final output loses momentum and tends to fail. For a co-pilot, those artefacts are the evaluation set, the prompts and retrieval configuration, the logged reviewer corrections, and the measured time saving for one team.
Steps for running the pilot
- Define one workflow, one user group and one measurable outcome before choosing a model.
- Build the evaluation suite before the first production deployment, and treat it as the test suite: if it does not exist, the system is not production-ready.
- Do the token arithmetic early: model per-request cost at production volume during design.
- Run a limited-scope pilot and document success metrics and lessons for the next project.
- Train the pilot group in prompting and in the task-specific uses, since prompting and finding relevant use cases were major capability barriers in the Australian trial.
- Before launch, set up dashboards for latency, throughput, error rates and cost per inference, with alerts and cost-allocation tags per use case.
- Scale gradually, with controls and support in place.
The reasons these projects fail early are covered in why generative AI projects fail.
The lack of in-house AI expertise is a significant barrier for midsize organisations. FAIGMOE notes that they often cannot justify hiring specialised AI staff, and Chrono Innovation’s advice is to bring in experienced builders who ship to real users within weeks, before hiring for strategy. If you are weighing outside help, what to expect from a generative AI consultant sets out what that kind of engagement covers.
Hosted service or in-house model as usage grows
Break-even between a hosted service and running an open model yourself varies widely with provider pricing. The answer depends on monthly token volume and which commercial service you compare against. A 2025 cost-benefit analysis of on-premise LLM deployment (arXiv 2509.18101) splits the in-house cost into capital expenditure (GPUs, servers, setup), operating expenditure (electricity, cooling, maintenance, personnel, licences) and the cost of scaling as workloads grow.
Its estimates by scale:
- Under 10M tokens a month, small open models, feasible on consumer GPUs, broke even in 0.3 to 3 months, depending on which commercial service they were compared with.
- At 10M to 50M tokens a month, medium models on dual-A100 hardware broke even in 3.8 to 34 months, and the authors see hybrid setups (sensitive work local, burst traffic to cloud APIs) as the best fit at this tier.
- Above 50M tokens a month, large models broke even in 3.5 to 69.3 months, stretching to 5 to 9 years against aggressively priced providers unless privacy, sovereignty or lock-in outweigh the economics.
Read those figures with their caveats attached. The paper counts open models within 20% of leading commercial models on benchmarks as comparable. Its authors say their total cost of ownership modelling still needs to include staffing, energy, hardware failures and maintenance, and that the projections need validating against real deployments.
For a pilot, the practical sequence is the one AWS recommends: build the proof of concept on a top-tier model to establish business value quickly, then once the use case is proven, evaluate smaller models against your benchmarks to cut production cost. The in-house question becomes a real one only once the cost dashboards from the pilot show sustained volume. Comparing GPUs for that in-house option is a measurement question, and LynxBenchAI’s published results are where we point readers for that.
How can a team pilot a vendor’s generative AI service without getting locked in?
Keep everything you own outside the vendor’s walls, and call the model through an interface you control. Kong, which sells an AI gateway product, defines vendor lock-in as dependence on one vendor’s products, services or proprietary formats deep enough that switching becomes prohibitively expensive or disruptive, whether through proprietary APIs, non-portable data, ecosystem-specific integrations or contract terms. The worry is common: Kong cites a Zapier survey in which 81% of AI users were concerned about depending too heavily on a single AI vendor, and 47% said at least one key business function would malfunction if their primary vendor went offline. Participants in the Australian trial also raised lock-in concerns.
Kong’s recommended pattern is an AI gateway between applications and LLM providers, so that developers code against one consistent interface rather than each provider’s API format. It also argues for setting exit policies before committing: a vendor-agnostic abstraction layer, exportable data formats written into contracts, and regular checks of switching costs. At pilot scale, a commercial gateway is not essential. A thin internal wrapper does the same job at that scale. What matters is that the prompts, the evaluation set, the retrieval index and the logged reviewer decisions are stored in formats you control, because those are what let you test a second provider without rebuilding from scratch.
Portability is worth paying for when there is a measurable reason: a performance ceiling, a deployment-target constraint or a quantified lock-in cost, not portability for its own sake. In a pilot, the abstraction layer is what makes acting on such a trigger cheap.
How far the evidence supports this playbook
The methodology rests on evidence that is suggestive rather than settled, and it helps to know where it is thinnest. FAIGMOE describes itself as a conceptual framework that still needs empirical validation through longitudinal and sector-specific studies. The on-premise break-even figures are projections whose authors call for validation against real deployments and fuller cost models. The UK trial’s 26 minutes a day was reported by users, and the evaluators could not identify how the saved time was spent. The Australian figures are estimates from participants too.
What holds up across all of them is narrower and more useful. Co-pilots help with verifiable, repetitive text work; they need a human checking the output; and benefits were larger where training and familiarity were higher. The question a team still has to answer for itself is whether its own first task has those properties, and a limited-scope pilot with an evaluation set is how to answer it.
