Most UK organisations now have a small AI pilot somewhere in the business. The sticking point is getting from “a clever demo” to a safe, measurable, supportable service that your colleagues can trust and your finance director can budget for. This article gives a pragmatic 12‑week launch plan aimed at non‑technical leaders in SMEs and charities. You’ll get a week‑by‑week roadmap, a build‑vs‑buy decision tree, procurement questions, a risk/cost table, and a short list of KPIs to decide if you’re ready to go live.
We reference public, vendor‑neutral guidance where helpful, including the UK government’s AI Playbook (2025), the cross‑government Technology Code of Practice, DSIT’s Software Security Code of Practice (2025), the NCSC/CISA Guidelines for Secure AI System Development, and the FinOps Foundation’s work on forecasting AI service costs.
The 12‑week production launch plan
Weeks 0–1: Frame the business outcome and the budget guardrails
- One‑line outcome: What measurable outcome should a director recognise? Examples: “Cut average email response time from 2 days to 4 hours” or “Save 300 hours per quarter on tender reviews.”
- Scope and exclusions: Define top 3 tasks the AI will handle and 3 things it will not. This avoids “AI creep”.
- Budget guardrails: Set a monthly cap and a per‑user or per‑request cap. FinOps guidance recommends unit economics such as cost per 100k words or per resolved ticket; you can adopt these from day one and track weekly. See the FinOps Foundation’s unit‑cost approach.
- Go/No‑Go KPIs (baseline now): Task success rate (% of answers accepted with no edits), cost per outcome (£ per resolved query), median turnaround time, and human review burden (% of items requiring escalation).
Weeks 2–3: Pick the delivery path (build, buy, or “configure and extend”)
Most SMEs don’t need to “build AI”; they need to configure an existing platform and integrate it with their content and workflows. Use this decision tree:
| If… | Then… | Why |
|---|---|---|
| Your use case is common (FAQ/helpdesk, HR policies search, document summarising) and time‑to‑value matters | Buy/configure a proven product; extend with your content | Faster, cheaper, predictable support |
| You need your own data as the source of truth with basic retrieval | Configure a RAG pattern using a managed service | Retain control of content; minimal engineering |
| There’s unique workflow or domain logic and moderate scale | Custom app on a managed AI platform | Balance flexibility and ops simplicity |
| You require bespoke models, offline operation, or strict sovereignty | Specialist build with experienced partners | Only if value clearly outweighs cost/complexity |
Related reads: our 6‑week RAG blueprint and 30‑day AI helpdesk playbook.
Weeks 4–6: Prototype the “happy path” and the guardrails
- Golden tasks: Collect 40–80 real examples the AI must handle. For each, record the ideal answer and acceptance criteria in plain English.
- Human‑in‑the‑loop: Decide which tasks need mandatory review, optional review, or auto‑publish with audit. Keep it simple.
- Safety and privacy defaults: Follow the spirit of the UK government’s playbook: never paste sensitive or personal data into public tools, log usage, and route production traffic through accounts you control. See: AI Playbook.
- Cost controls: Apply request caps, block oversized documents, and prefer smaller/cheaper models if they pass your acceptance criteria. The FinOps community recommends tracking “cost per 100k words” and forecasting weekly. Reference: Forecasting AI costs.
Weeks 7–8: Evaluation harness and pilot in “shadow mode”
- Automate checks: Run your golden tasks daily and chart the four KPIs. Add a tiny set of “red flag” checks to catch obvious errors.
- Shadow mode pilot: Let the AI draft answers but keep humans sending. Measure time saved and edit rate.
- Operational readiness: Draft runbooks: how to roll back, rotate keys, pause spending, update prompts, and handle user feedback.
- Security hygiene: Align with the NCSC/CISA secure AI guidelines: secure design, development, deployment, and operation. See the joint guidance here.
Weeks 9–10: Production‑grade reliability
- SLA you can keep: Define response time targets and support hours you can actually meet. Avoid over‑promising.
- Change control: Treat prompt changes like software changes: review, test against the golden set, then release.
- Telemetry: Capture success/failure, user edits, and costs per request. Retain enough logs to investigate issues without storing unnecessary personal data. The UK Technology Code of Practice stresses making things secure and privacy‑aware by design.
Weeks 11–12: Limited live launch and iterate
- Start narrow: 1–2 teams, one clear use case, a weekly change window, and a visible “feedback” button.
- Weekly ops drumbeat: Review incidents, cost vs. budget, and a small backlog of quality fixes. Celebrate time saved to build confidence.
- Document the steady state: Owner, on‑call rota, how to request new intents, and your stop‑loss rules (see below).
Governance that helps, not hinders
Good governance creates repeatability rather than paperwork. These three artefacts are usually enough for SMEs:
- One‑page Service Charter: what the AI does, who owns it, how you measure it, and what happens if it misbehaves.
- Risk & Controls Register: a short table of the top risks with an owner and a simple control (see template below).
- Change Log: one place to record prompt, model or vendor changes, and their effect on KPIs.
If you need ready‑to‑use wording, our AI Policy Pack (2025) has concise templates for UK organisations.
Stop‑loss rules
Agree these before go‑live; wire them into dashboards so anyone can pause the system if thresholds are breached:
- Quality: Task success rate drops below 85% on the golden set for two consecutive days.
- Safety: Any substantiated safety incident (for example, inappropriate advice) triggers an immediate pause and review.
- Cost: Weekly spend projection exceeds the monthly cap by 20% without an approved business case.
Risk and cost: a compact register you can actually maintain
| Risk | What it looks like | Simple control | Residual cost impact |
|---|---|---|---|
| Data leakage | Colleagues paste sensitive content into public tools | Use enterprise accounts; block public tools on corporate devices; short training | Low–medium (avoidable with training + controls) |
| Hallucinations | AI answers confidently but incorrectly | RAG over your own content; cite sources; human review for risky intents | Medium (drops with golden‑set testing) |
| Vendor change or model drift | Quality shifts after a model update | Daily golden‑set runs; second‑source model ready; change log | Medium (requires monitoring time) |
| Cost runaway | Usage spikes or long documents inflate tokens | Hard caps, rate limits, document size limits, weekly forecasting | Medium (contained with caps & FinOps cadence) |
| Security gaps | Poor key handling, weak isolation, no audit trail | Follow secure‑by‑design practices (NCSC/CISA guidelines); rotate keys; central logging | Low (with basic hygiene) |
For baseline security practices and supplier expectations, see the UK’s Software Security Code of Practice and the NCSC/CISA guidelines for secure AI development referenced above.
KPIs that prove value (and keep you honest)
- Task success rate: % of AI outputs accepted with zero edits.
- Human review burden: % requiring escalation or major edits.
- Turnaround time: median time from request to final answer (including review).
- Cost per outcome: £ per resolved ticket, per approved summary, or per drafted page.
- User satisfaction: 1–5 rating on usefulness and clarity.
Track weekly across pilot and early production. If quality holds and cost per outcome is comfortably below your manual baseline, widen the rollout.
Procurement: questions that separate signal from noise
Use these during demos and commercial negotiations. You’ll avoid expensive surprises:
- Costing and limits
- What are the main cost drivers (tokens, requests, users, throughput)? Do you offer caps and alerts?
- Is provisioned capacity available for predictable throughput, and on what terms? (FinOps notes the trade‑off between lower unit rates and utilisation risk.)
- Quality and change control
- How do you test for regressions when models change? Can we pin versions?
- Can we run our golden set automatically and export results?
- Security and privacy
- Where is data processed and stored? Is training on our data disabled by default?
- Do you follow secure‑by‑design practices consistent with NCSC/CISA guidance?
- Supportability
- What’s your documented SLA and support route? Do you provide a runbook template?
- Can we export our content, prompts, logs and analytics if we leave?
Government buyers are guided to make things secure, accessible and measurable under the Technology Code of Practice; the spirit applies equally to SMEs.
Cost governance in practice (SME‑friendly)
Your 30‑minute FinOps cadence
- Every Monday: Check weekly spend vs. forecast; review top 5 most expensive prompts or intents.
- Every Wednesday: Sample 10 outputs for quality and safety; log edits.
- Every Friday: Decide one small optimisation: shorter context, cheaper model for a subset, or merge duplicate intents.
Adopt the FinOps Foundation’s simple unit metrics (for text use cases: cost per 100k words and cost per resolved item) and a weekly forecasting cycle. Start small; you can mature later. See FinOps’ guidance on AI cost forecasting and cost estimation.
Security and resilience: what boards should ask
Boards do not need to master the technical detail, but they should expect a plan aligned with mainstream good practice:
- Secure by design: clear separation of test and production, managed secrets, restricted admin access, and centralised logging. See DSIT’s Software Security Code of Practice.
- AI‑specific risks covered: prompt injection, model or content drift, and data poisoning mitigated by allow‑listed sources, regular evaluation, and change control. See NCSC/CISA’s secure AI development guidance.
- Operational resilience: documented rollback, second‑source model or vendor if quality shifts, and a pause switch tied to stop‑loss rules.
Rollout patterns that work in SMEs
“Assistant first”
Start with a drafting assistant for internal teams (ops, HR, marketing). Lower risk, quick wins, visible time savings.
“Search first”
Add retrieval over your policies, manuals and service notes. Accuracy rises because the AI cites your content rather than inventing it. If this is your need, see our RAG blueprint.
“Helpdesk first”
Use AI to draft replies and route tickets; keep humans in the loop for final send until quality stabilises. Our helpdesk playbook shows a 30‑day path.
“Document heavy”
If you process long tenders or reports, constrain input sizes and templates; summarise sections then stitch. A case study: 400‑page tenders to 8‑minute briefs.
What “good” looks like after 12 weeks
- You can explain, on one page, what the AI service does, who owns it, and how it’s measured.
- Your golden set runs daily and shows stable or improving quality.
- Cost per outcome is tracked weekly and is lower than manual processing.
- There’s a clear change process and an audit trail for prompts, models and vendors.
- Security basics are covered and match mainstream guidance (NCSC/CISA; DSIT code).
If you’re not there yet, pause, fix the bottleneck, and relaunch the narrowest viable slice. That’s normal.
Next steps with us
We help UK SMEs and charities go from pilot to production with a focus on measurable outcomes, predictable costs and workable guardrails. Typical engagements include a 2‑week readiness audit, a RAG or helpdesk pilot, and a 30/60/90‑day value plan aligned to your sector and budget.