Large language models in business: a guide for leaders

Large language models (LLMs) take the grind out of document work and speed up the decisions sitting behind it. The best first move is small. Run a focused RAG (retrieval-augmented generation) pilot on one document-heavy process you already own.

Here is what a small pilot usually delivers:

• Hours saved quickly. Document summarisation, contract review, and knowledge search are measurable within weeks.
• Better customer response times. LLM-backed support tools reduce average handle time on routine queries.
• One risk to watch from day one. Hallucination, where the model states something confidently but incorrectly. Ground every output in your own documents using RAG, and keep a human in the review loop.

PwC's 2026 AI Performance study finds that about 74% of AI's economic gains land with just 20% of companies. Those leaders redesign the workflow and chase growth. They do not only cut costs. And before anything goes live with real data, the ICO sets the compliance bar your pilot has to clear.

---

What is a large language model, and how does it work?

An LLM is a type of AI trained on vast amounts of text. It learns patterns in language well enough to read, write, summarise, translate, and answer questions.

Think of it like hiring a very well-read assistant. They have read millions of books, reports, and websites. You give them a task (a "prompt"), and they produce a response based on everything they have absorbed. They do not look things up in real time. They draw on what they learned during training.

Here are the core terms you will encounter:

• LLM (large language model): An AI model trained on large text datasets to understand and generate human language. GPT-4, Claude, and Gemini are all LLMs.
• Prompt: The instruction or question you give the model. Better prompts produce better outputs.
• RAG (retrieval-augmented generation): A technique that connects the LLM to your own documents before it answers. Instead of relying only on training data, it retrieves relevant content from your files first. This is the most practical way to get accurate, grounded answers from company data.
• Fine-tuning: Retraining a model on your specific data so it learns your domain's language and style. More expensive and slower than RAG, but necessary for highly specialist tasks.
• Hallucination: When the model produces a confident-sounding answer that is factually wrong. A known risk in every LLM.

Why RAG matters most for business accuracy. Without RAG, an LLM answers from general training data. With RAG, it answers from your contracts, policies, and knowledge base. That distinction is what makes LLMs usable in regulated, high-stakes environments. MIT Sloan's framework confirms this sequencing: start with prompting, add RAG for accuracy, and only invest in fine-tuning when RAG is not enough.

---

How businesses use large language models: the proven use cases

The role of large language models in business spans nearly every function. The use cases below have demonstrated measurable outcomes in UK and global organisations.

• Document processing. Summarising contracts, extracting clauses, reviewing policies. Typically owned by legal, compliance, or operations. Outcome: hours of manual review reduced to minutes.
• Enterprise knowledge search. Employees ask questions and get answers drawn from internal wikis, handbooks, and past projects. Owned by IT or knowledge management. Outcome: faster onboarding and fewer repeated questions to senior staff.
• Customer operations. LLM-backed chat and email tools handle routine queries, draft replies, and escalate the hard cases. Owned by customer success or support. Outcome: lower average handle time and higher first-contact resolution. See how AI cuts customer support costs in practice.
• Marketing and content. Drafting briefs, first-cut copy, and repurposing long-form work into social posts or email. Owned by marketing. Outcome: faster content cycles without adding headcount.
• Code assistance. Generating boilerplate code, writing tests, and explaining legacy code. Owned by engineering. Outcome: faster development cycles and easier onboarding for new developers.
• Data analysis and reporting. Translating natural language questions into SQL queries, summarising dashboards, and drafting board reports. Owned by finance or data teams.
• HR and admin. Drafting job descriptions, summarising CVs, answering policy questions from staff. Owned by HR. Outcome: reduced admin load on HR business partners.
• Compliance monitoring. Scanning documents for regulatory language, flagging deviations, and summarising changes in regulation. Owned by compliance or legal.

Pro Tip: Document processing and customer operations are the fastest use cases to pilot in UK businesses. Both have clear inputs, measurable outputs, and existing workflows you can compare against a baseline. Start there before moving to more complex use cases like code assistance or compliance monitoring.

Plan the integration points early. Your CRM for customer ops. Your document store for knowledge search. Your ticketing platform for support.

---

What to expect: benefits, quick wins, and realistic timing

LLMs deliver four headline benefits when deployed well.

1. Efficiency gains. Repetitive, text-heavy tasks complete faster. Staff spend time on decisions, not drafting.
2. Faster decision-making. Summarised data and instant knowledge retrieval means leaders get to the point quicker.
3. Improved customer satisfaction. Faster, more consistent responses improve NPS and reduce escalations.
4. Support for growth, not just cost cutting. The biggest financial wins come from using AI to pursue new revenue, not only from removing headcount.

PwC's 2026 study found that about 74% of AI's economic gains are captured by just 20% of companies. Those top performers use AI to redesign workflows and pursue growth. McKinsey's 2025 survey found that while 88% of organisations use AI in at least one function, enterprise-wide financial impact remains rare. The gap between widespread use and meaningful return is a management and workflow problem, not a technology problem.

Typical KPIs to track in a pilot:

• Hours saved per week on target process
• Average handle time (customer ops)
• Accuracy rate versus human baseline
• Escalation rate
• Number of tasks automated per month

One timing caveat. An NBER working paper documents a productivity paradox: executives report larger perceived gains from AI than are immediately visible in measured financials. Productivity improvements show up before revenue impact. Plan for a lag of several months between a successful pilot and a measurable EBIT effect. Set expectations accordingly with your board.

---

The main risks: what can go wrong and how to manage it

Three things break LLM deployments more often than anything else: integration, governance, and hallucination. Here is what to watch for.

Major risks:

• Hallucination. The model generates a plausible but incorrect answer. In a contract review context, this could mean a fabricated clause presented as real. Mitigation: use RAG to ground answers in source documents, and require human sign-off on any output used in a decision.
• Data leakage. Sending sensitive data to a third-party API without proper controls. Mitigation: review vendor data use clauses, confirm data is not used for model training, and consider private hosting for sensitive workloads.
• Bias. Models trained on historical data can reproduce historical biases in hiring, credit, or customer communications. Mitigation: test outputs across demographic groups before deployment.
• Regulatory exposure. Using personal data in LLM workflows without a lawful basis under UK GDPR. Mitigation: complete a DPIA (data protection impact assessment) before any live deployment.
• Model drift. Model behaviour changes over time as providers update base models. Mitigation: log outputs and run regression tests after any model version change.
• Vendor lock-in. Building workflows tightly around one provider's API makes migration costly. Mitigation: use abstraction layers and document your prompts and logic independently of any single vendor.

A concrete example. A legal team uses an LLM to review supplier contracts. Without RAG, the model hallucinates a liability cap that does not exist in the document. The fix: connect the model to the actual contract via RAG, add a human review step before any clause is acted on, and log every output for audit. See the most common AI implementation mistakes to avoid repeating them.

---

Your 90-day pilot playbook: pick, prove, protect, then scale

This is a practical checklist you can hand to a supplier or run yourself. The AI implementation phases for service businesses follow a similar shape, and DevWiz covers the same staged path from the build side in enterprise AI adoption: a practical path.

Step 1: Scope the pilot (Week 1–2)

• Pick one process with clear inputs, outputs, and a measurable baseline.
• Define success criteria: target accuracy, time saved, and a breakeven point.
• Identify the data sources the model will need to access.
• Confirm data classification (personal, confidential, public).

Step 2: Prepare data (Week 2–3)

• Clean and organise documents for the RAG knowledge base.
• Apply data minimisation: only include data the model genuinely needs.
• Use synthetic data (realistic but non-personal test data) for initial testing where possible.

Step 3: Set up RAG (Week 3–5)

• Choose a deployment option (see Section 9).
• Connect the model to your document store via a RAG pipeline.
• Write and test prompts against your baseline.

Step 4: Evaluate (Week 5–8)

• Run outputs against a human baseline on 50–100 real examples.
• Measure accuracy, hallucination rate, and time saved.
• Identify edge cases and failure modes.

Step 5: Human review and governance (Week 8–10)

• Define which outputs require human sign-off before use.
• Complete a DPIA if personal data is involved.
• Document the workflow and log outputs.

Step 6: Launch and iterate (Week 10–12)

• Release to a small user group.
• Collect feedback weekly.
• Set a 90-day review date with the original success criteria.

Pilot success criteria template:

• Accuracy: target 90%+ versus human baseline on the scoped task.
• Time saved: at least 30% reduction in process time.
• ROI breakeven: calculate based on staff hours saved versus tool cost.

Pro Tip: Do not start fine-tuning until RAG is stable and holding its accuracy. Fine-tuning is expensive and slow, and most business use cases never need it.

---

UK governance: GDPR, DPIAs, and what to put in supplier contracts

Before any LLM goes live with real data, UK businesses must satisfy a minimum governance checklist. The ICO (Information Commissioner's Office) is the UK's data protection regulator and has published specific guidance on AI and automated decision-making.

Compliance checklist:

• Complete a DPIA for any processing that is likely to result in high risk to individuals.
• Establish a lawful basis for processing personal data (legitimate interests, contract, or consent).
• Map data flows: what data enters the LLM, where it is processed, and where outputs are stored.
• Confirm the model provider does not use your data to train their models (check the contract).

Contractual clauses to require from any LLM supplier:

• Data retention limits: how long does the provider store your inputs and outputs?
• Deletion rights: can you request deletion of your data on demand?
• Purpose limitation: confirm data is used only for your specified purpose, not for model improvement.
• Subprocessing disclosure: which third parties does the provider share data with?
• Audit rights: can you request evidence of compliance?

When to choose private or on-premises hosting. If your data includes patient records, financial data subject to FCA rules, or legally privileged material, a cloud API may not be appropriate. Private deployment (running an open-source model on your own infrastructure) keeps data within your control. The cost is higher, but for some regulated sectors it is the only compliant option.

The ICO's guidance on AI and data protection is the primary reference for UK businesses. Read it before you brief any supplier.

---

How to measure success: metrics, timescales, and common traps

Good measurement starts before the pilot goes live. Set a baseline first, then compare.

Metrics to track:

• Process time: average minutes per task before and after.
• Error rate: percentage of outputs requiring correction.
• Escalation rate: percentage of cases passed to a human.
• Customer NPS: for customer-facing deployments.
• Cost per ticket or cost per task: total cost divided by volume.
• Revenue per user: for growth-oriented deployments.

How to interpret results over time. Efficiency gains appear within weeks. Financial returns take longer. The NBER productivity paradox is real: the gap between perceived improvement and measured EBIT can span several quarters, particularly in service businesses. Build this lag into your reporting cadence. For a practical framework on turning LLM outputs into growth signals, the data for insights guide is worth reading alongside your measurement plan.

Common measurement traps:

• No control group. Without a comparison group running the old process, you cannot attribute improvement to the LLM.
• Conflating productivity feeling with financial return. Staff feeling faster is not the same as measurable cost reduction. Track both separately.
• Attribution lag. Revenue impact from a support improvement may not show in NPS for 60–90 days. Do not close the measurement window too early.
• Baseline drift. If the old process was already improving before the pilot, the LLM's contribution is overstated. Measure the baseline for at least four weeks before launch.

---

Choosing the right technology: APIs, RAG, and private models

The main deployment options sit on a spectrum from fast and cheap to private and controlled.

Cloud API models (such as OpenAI's GPT-4 via the Azure OpenAI Service, Anthropic's Claude, or Google Vertex AI / PaLM) are the fastest route to a working pilot. You send a prompt via an API (application programming interface, a connection between your system and the model), and the model returns a response. No infrastructure to manage. Cost is based on usage (tokens processed). The trade-off is that data leaves your premises.

Managed enterprise platforms (such as Microsoft Azure OpenAI Service, IBM watsonx, or Google Vertex AI) add enterprise controls: data residency options, audit logging, role-based access, and SLA guarantees. These sit between raw API access and full private deployment. Suitable for most UK businesses handling moderately sensitive data.

Open-source and private models (such as those available via Hugging Face, including BERT-based models and larger open-weight models) run on your own infrastructure. Data never leaves your environment. BERT (Bidirectional Encoder Representations from Transformers) is a foundational model architecture that underpins many enterprise NLP (natural language processing) tools, particularly for classification and search tasks. Fine-tuning open-source models is more expensive in engineering time but gives full control.

Deployment decision: cloud API vs private

Consideration	Cloud API	Private / on-premises
Speed to pilot	Fast (days)	Slow (weeks to months)
Data control	Limited	Full
Cost structure	Pay-per-use	High upfront, lower marginal
Compliance fit	Moderate	High (regulated sectors)
Engineering effort	Low	High
Fine-tuning flexibility	Limited	Full

Cost structure to budget for:

• Subscription or inference costs (per token or per API call).
• Infrastructure costs for private deployments (compute, storage, maintenance).
• Engineering effort for integration with existing systems (CRM, document store, ticketing).
• Fine-tuning costs if specialist domain adaptation is required.
• Ongoing prompt maintenance and model version management.

For most UK businesses starting out, a managed enterprise platform with RAG is the right balance of speed, control, and compliance.

---

People and change management: the roles you actually need

Technology is the easy part. Getting people to trust and use it consistently is harder.

Roles required for a production LLM deployment:

• Product owner. Defines the use case, owns success criteria, and prioritises the backlog.
• Prompt engineer / trainer. Writes, tests, and iterates prompts. Can be a trained non-developer in many cases.
• Data steward. Manages the knowledge base, ensures data quality, and enforces access controls.
• Operations lead. Owns the day-to-day workflow, trains staff, and manages the human review process.
• Governance lead. Owns the DPIA, vendor contracts, and compliance documentation.

Adoption checklist:

• Run a half-day training session before launch, focused on what the tool does and does not do.
• Write a one-page playbook for each use case: when to use the tool, when to escalate, and how to flag errors.
• Define human review rules in writing before go-live.
• Create a simple feedback channel so staff can report errors without friction.

On cultural change. The biggest adoption barrier is not scepticism about AI. It is fear of being replaced. Address this directly. Frame the tool as handling the drafting and searching so staff can focus on judgement and relationships. Scaling output without hiring is the goal, not reducing headcount. Staff who validate and improve AI outputs become more valuable, not less.

---

A worked example: The AI Orchestrators' 90-day program

A pilot proves one process works. The next question is what to do with the rest of the business. Here is how a knowledge business moves from problem to measurable outcome in 90 days with us.

The problem. A founder-led consulting business turning over £1M or more. The founder is the bottleneck. Every client question, every piece of content, every delivery decision routes through one person. The team cannot move without them, so growth is capped by one calendar.

The frame. A single chatbot does not fix that. What does is an AI Operating System: a coordinated set of AI employees that carry the founder's judgement across delivery, content, and admin. We build them with Claude Code, which is what puts a working system in a non-technical founder's hands in weeks rather than quarters.

90-day activities:

• Weeks 1–3: Map the founder's intellectual property (IP). Find the decisions, frameworks, and knowledge that only exist in their head, and turn it into a structured knowledge architecture the models can actually use.
• Weeks 4–6: Build RAG-backed AI employees that answer client questions, support onboarding, and run routine delivery using the founder's documented method.
• Weeks 7–9: Prototype content and admin workflows. Test outputs against the founder's own standards. Iterate prompts and knowledge base entries.
• Weeks 10–12: Hand workflows to the team. Train staff on validation and escalation. Set up feedback loops and governance documentation.

Sample outcomes after 90 days:

• Founder hours on routine delivery reduced significantly.
• Team able to handle onboarding and support queries without founder input.
• First ROI signals visible in reduced delivery cost per client.
• Governance documentation and DPIA in place for UK compliance.

The AI Orchestrators' program differs from coaching-only offers because it builds the actual system, not just the strategy. Clients leave with working AI agents, documented workflows, and a team trained to run them. For high-ticket service delivery, see how AI integrates into that model.

---

The honest truth about where LLMs fall short

LLMs are not a silver bullet. They need clean data, clear governance, and a workflow that is designed around them, not bolted onto an old one.

The businesses that get the most from LLMs do not just add a chatbot to an existing process. They redesign the process. The ones who only use it to cut costs capture a fraction of the value.

Start small. Pick one process. Measure it honestly. Then scale what works.

---

The AI Orchestrators: built for founders who are ready to scale

You run a consulting or education business past £1M. Your growth is capped by your own hours. That is the situation our 90-day program is built for.

We map your IP. We build AI employees across content, delivery, operations, and support. Then we hand your team a system they can run without you in every conversation. It is done-with-you, not advice. You finish with working software, not a slide deck.

This is not general AI guidance. It is a structured build for founder-led businesses with a proven program and a method worth encoding. If that is you, start with the assessment and find out which part of your delivery is ready to hand over first.

---

Sources

• Three-quarters of AI’s economic gains are being captured by just 20% of companies – PwC 2026 AI Performance study
• The State of AI: Global Survey 2025 | McKinsey
• NBER working paper: The effects of AI on productivity and the workforce
• 3 ways businesses can use large language models | MIT Sloan

---