From Demo to Invoice: The Cloud Costs Hiding Behind Your AI Rollout

AI has a lovely habit of arriving as a free trial. A coding assistant appears in your developer tools. A summarisation button turns up in your CRM. A chatbot gets bolted onto the help centre. Everyone has a play with it, the demo looks impressive, and then someone asks the finance director to approve a permanent line item. That is when the cloud bill starts telling a different story.

As of 2026, AI features are being bundled into productivity suites, contact-centre platforms and data tools at a fair clip. For UK teams, the temptation is to treat these features like any other software seat. But AI workloads have their own infrastructure shape: accelerators, inference calls, storage growth, egress and governance controls. The pilot price is rarely the production price.

The pilot price is not the production price

Pilots are designed to be small. You might get a capped number of credits, a limited user group or a fixed monthly allowance. That makes it easy to say yes. It also makes it easy to miss what happens when the cap comes off.

Ask what is actually metered. Is it seats, tokens, API calls, GPU hours, or some combination? A per-seat price for an assistant sounds simple until heavy users start generating long documents or querying large datasets. Suddenly the seat is cheap and the inference is not. If the vendor cannot explain the meter in plain English, treat that as a warning sign rather than a quirk.

GPUs, quotas and the queue you didn’t budget for

AI workloads often need specialised compute. In the cloud, that means GPUs or other accelerators, and they are not infinite. Providers impose quotas, and quotas can be raised—but not always instantly. If your team is planning a customer-facing feature that needs consistent response times, capacity planning matters.

There is also the question of utilisation. A GPU reserved for a pilot that runs two hours a day is an expensive paperweight for the other twenty-two. Some teams are better served by managed AI services where the provider handles the infrastructure. Others need dedicated capacity for latency, cost or data reasons. Neither is automatically right. The mistake is assuming the pilot’s architecture will scale linearly.

Egress, embeddings and the storage that keeps growing

AI features generate data. Prompts, responses, logs, embeddings, model artefacts and evaluation datasets all take up space. Embeddings are particularly sneaky: they are small individually, but if you are indexing documents, support tickets or product catalogues, the storage adds up. Vector databases are not free, and neither are the backups behind them.

Then there is egress. Moving data between regions, services or external systems can attract charges. If your AI workflow pulls data from one cloud, sends it to another service and writes results back, those hops may have a price. UK teams should also check where the processing happens. A UK region for storage does not necessarily mean UK processing for every AI feature. If data protection depends on location, verify the whole path.

Governance is a line item too

Governance features have a habit of being optional extras. Audit logs, data loss prevention, retention controls, regional processing settings and access reviews may sit on a higher tier. For UK organisations subject to UK GDPR, these are not nice-to-haves. They are part of demonstrating accountability.

Before scaling, ask whether the AI feature trains on your data, how you opt out, how long prompts and outputs are retained, and which sub-processors are involved. If you need a DPIA, the vendor should be able to give you enough detail to complete it without guesswork. ‘Trust us, it’s secure’ is not a data protection answer.

Ten questions to ask before you scale

1. What exactly is metered—seats, tokens, API calls, GPU hours or something else?
2. What happens to the price when the pilot allowance ends?
3. Where are prompts, outputs, embeddings and logs stored and processed?
4. How long is that data retained, and can we change the retention period?
5. Does the service train on our data, and how do we opt out?
6. What egress charges apply between services, regions or external systems?
7. Which sub-processors handle AI inference or analytics, and where are they based?
8. Can we restrict processing to the UK or a specific region, and at what cost?
9. Which governance features—audit logs, DLP, access controls—are included and which are extra?
10. What is the exit plan for deleting data and exporting anything we need to keep?

AI can be genuinely useful. It can also be a masterclass in cost drift if nobody owns the meter. The UK teams that get this right tend to do three things: they pilot with a named budget, they map the data path before procurement, and they ask awkward questions early. That is less exciting than a demo, but it is much more relaxing when the invoice arrives.