Sovereign AI: how QVCCS uses AI without handing over customer data

Our work means handling other organisations' data, and AI is only safe for that work when we control where the data goes. On a typical project we see call recordings and transcripts; IVR, routing and journey data; interaction analytics; CRM and case extracts; agent performance and schedules; configuration exports from contact-centre platforms; and design documents full of business rules. Much of it contains personal data, such as names, phone numbers, addresses and account numbers, and some of it is special category data, such as a health insurer's call recordings that mention a customer's condition.

On most projects QVCCS is a processor, acting only on the client's documented instructions. UK GDPR says a processor must not engage another processor without the controller's prior written authorisation, and contracts typically limit which sub-processors may see the data and where it may go. Pasting a transcript into an outside AI service can make that service a new sub-processor and move the data abroad, which the contract may not allow.

We use AI anyway, because it now does real engineering and analysis work: reviewing a large database of interaction records, drafting a low-level design, building and testing an integration. That multiplies what a specialist team can deliver, but only if the AI can see the real data, safely. Our answer is to run the AI where the data already belongs, under our control, rather than send the data to the AI.

Sovereign AI, as we use the term, means that QVCCS controls five things: the data, the models, the machines, the jurisdiction and the operations. If any one of them sits with someone else, the data is only as safe as that party's terms. The table sets out what each control means for Think, and the drawing shows where the boundary falls.

We are clear about the edges. The server is rented from a UK hosting provider rather than housed in our own building, but it is dedicated to QVCCS and run only by our own people. A few optional features, chiefly web search, send search terms to public search engines through our own search service; they never send documents, and Section 7 explains how staff handle that for client work. Everything else, from the question to the answer, stays inside the boundary.

Think is the AI every QVCCS person uses, in the browser and inside engineering tools, and it was built for our work. Everyone uses Think chat in the browser, signed in with their Microsoft account. Engineers also use coding agents in their editor and terminal, pointed at Think rather than at an outside AI service, so the same protections apply however someone works.

We use it for Genesys Cloud design, build and troubleshooting; analysis of large data sets; documents in QVCCS's own templates and brand; research across our SharePoint knowledge; and web pages and illustrations to our web standards. Five design principles shape every decision about it, listed below. When a new feature would weaken one of them, we change the feature, not the principle.

• Private by default: no prompt, document or answer leaves the platform for an AI provider.
• Permission-aware: Think can see only what the person asking could already open.
• Our standards built in: documents, pages and drawings are checked against QVCCS standards automatically.
• Fair capacity for everyone: no one person's work can crowd out anyone else's.
• Observable and auditable: we can show who used what, and when, without reading anyone's prompts.

Think is six layers on one dedicated platform, and every request passes through the same checks before any model sees it. The table describes each layer by its role, and the drawing shows how a request travels through them. We do not publish host names, addresses, product versions or configuration, because they would help an attacker and tell a reader nothing about how the data is protected.

A request, step by step, shows how the layers work together. The numbered list below follows one question from an engineer to its answer. Nothing leaves the platform at any step, no model is reached except through access and the gateway, and the only record the gateway keeps is that the request happened and how large it was.

Think shares one platform fairly between everyone, runs many requests at once and keeps each answer streaming at a comfortable reading speed. When the platform is busy, new work waits briefly rather than slowing everyone down, and long-running background tasks give way to people waiting for an answer.

1. An engineer asks Think chat a design question, signed in with Microsoft 365.
2. The model decides it needs our knowledge and calls the search tool.
3. The search tool checks who is asking, from a signed, short-lived identity token, and searches only documents that person can already open in SharePoint.
4. It returns the most relevant passages; the model answers and cites the documents it used.
5. The gateway records that a request happened and its size, not its content.

Think does the same kinds of work as the public AI services our engineers would otherwise use, on our own data and to our own standards. Reasoning is sized to the task: quick for a simple question, deeper and step by step for a design problem. Coding agents in the editor and terminal read code, run tests and make changes, asking the engineer before each command or edit. For large data sets, agents write and run queries against data that stays where it is, rather than copying records into a chat.

Think builds Word, PowerPoint and Excel documents from QVCCS's official templates and checks them automatically against our brand and document standards before they are handed over; web pages and illustrations are checked against our web standards in the same way. It knows our delivery method, workshops and services, and Genesys Cloud's public documentation and API reference, and it cites the page it used. It also reads screenshots and error dialogs, and turns speech into text.

We say tuned, and we mean it precisely: we do not retrain the model. We tune Think with knowledge, in the form of skills and indexed sources; with standards and the checkers that enforce them; and with settings sized to each kind of work. Background tasks such as naming a chat, for example, run without step-by-step thinking, so they finish at once and leave capacity for people's questions.

Every connection Think makes is one we built, run and can switch off, and none gives the AI more access than the person using it. Sign-in uses Microsoft Entra ID single sign-on, with access granted through app roles: Entra issues a roles claim in the sign-in token for each role a person holds, and Think reads that claim rather than keeping its own list of users. Tools reached through the Model Context Protocol are ours alone; the protocol's specification asks hosts to obtain the user's consent before invoking any tool and to treat tool descriptions from servers they do not trust as untrusted, and we follow both.

The table sets out each integration, how it works and the safeguard that goes with it. Each was built by QVCCS and can be switched off on its own without affecting the rest of the platform. Think does not connect to clients' Genesys Cloud organisations today; engineers work with Genesys Cloud in our own sandbox organisations.

We assessed Think against the OWASP Top 10 for Large Language Model Applications, 2026 edition, and each risk has a named guard-rail and a plain note of what remains. The last column matters most: no platform removes every risk, and saying what is left, and how we handle it, is what lets a client judge the controls for themselves. We also follow the NCSC's guidelines for secure AI system development, which cover secure design, development, deployment, and operation and maintenance, and we use the NIST AI Risk Management Framework's functions of govern, map, measure and manage to review the platform.

Secrets, such as the certificate Think uses for SharePoint, are held only on the platform, rotated, and never placed in prompts, examples or system instructions. Engineers build Genesys Cloud CX integrations in their own development environment, and the client IDs and secrets for that work stay in its local configuration: not even Think, our own AI, has access to them. Availability rests on monitoring, alerts, automatic recovery and a watchdog that restarts a stalled answer. Usage is measured per person for fairness and capacity planning, without anyone reading prompts or answers.

Chats, uploads and everything else Think holds are kept on the platform, never with an AI provider, and only for as long as the second table sets out. Deletion is automatic wherever it can be, and a legal hold, when one is needed, suspends deletion only for the named data and is applied by hand and recorded.

Public AI services can be used safely for a great deal of work, provided you know which terms you are under and what you are putting in. The points below are practical guidance any organisation can use. They come from the vendors' own pages and from the ICO, whose guidance on AI and data protection says that most uses of AI involve processing likely to be high risk, which requires a data protection impact assessment, and that where you decide a use is not high risk you should still document how you reached that view.

Our own rule is one question, shown in the drawing. Does the task involve customer data, personal data, our SharePoint content or a client's platform? If yes, it goes to Think. If no, an approved public AI service on business terms may be used. If in doubt, it is Think.

• Know which service you are using: consumer accounts and business plans usually carry different terms on training, retention and administrator control. Check each vendor's own page for the exact plan, and date the check.
• Training: the major vendors' business and API terms say business data is not used for training by default; consumer settings vary.
• Retention: providers keep prompts for set periods, for example to detect abuse; some offer reduced or zero retention by agreement. Ask before sending sensitive material.
• Location and transfers: know where processing happens. Personal data leaving the UK needs a lawful transfer mechanism under UK GDPR Chapter V.
• Your role and contracts: a processor needs the controller's authorisation to use another processor (UK GDPR Article 28), so adding an AI service to a client project can mean asking the client first.
• Connectors widen access: an assistant linked to mailboxes, drives or CRMs can read more, and content it reads can carry hidden instructions. Connect only what the task needs.
• Give people an approved route: unofficial use of personal AI accounts is best prevented by an approved tool and clear rules.
• Never paste credentials, customers' personal data, recordings or client system configurations into a service not approved for that data by contract.
• Check what comes back: its accuracy, the licensing of generated code, and whether the output itself is confidential.

The leading public AI services are outstanding, and we use them for work that involves no customer or enterprise data. The table gives each a fair summary from the vendor's own pages, checked on 26 October 2026: what it suits, strengths the vendor states, and what to check before using it for anything sensitive. Terms change often, so read the vendor's current page for the plan you are on.

Our approved public AI service is Claude, from Anthropic. We use it for research on public topics, for frontier capability on hard problems that involve no customer data, and for early access to new techniques. What we learn from it often shapes Think: a method that works well on a public service becomes a skill or a checker on our own platform, where it can then be used on real project data.

For sustained, heavy AI work on sensitive data, a dedicated platform gives a fixed, predictable cost and keeps the data in-house, while public services remain the better choice for occasional frontier work. We do not publish prices or estimates, so this section explains the shape of the trade-off rather than the sums.

Agent work is heavy because coding and analysis agents resend their growing working context to the model at every step. In our testing in October 2026, one engineer's agent work on a busy day sent more than 90 million tokens to the model, most of it repeated context. Public services charge by use, so cost rises with every heavy user and every busy month. A dedicated platform costs the same whether it is busy or quiet, up to its capacity.

A dedicated platform costs in other ways too: committed hardware, our own people's time to run and upgrade it, and models that are usually a step behind the newest public ones. In return it gives us the ability to use AI on customer data at all, a predictable cost, capacity shared fairly across the team, and tools and standards built around our work. The balance we strike is Think for everything involving customer or enterprise data, and public services for public research and frontier capability.

As a processor of our clients' data we owe them specific duties under UK GDPR, and Think is designed so that using AI does not weaken any of them. The table maps each duty to what Think does. It describes controls, not badges: we claim no certification on this page.

Contact centres often take payments, and Think is not used to process cardholder data. Good controls also need people who use them well, so we pair Think with staff guidance, approved tools and training, and we encourage everyone to use AI confidently within those rules rather than avoid it. That, more than any single control, is what keeps client data where it belongs.