Is your IT provider feeding your data into cloud AI?

Possibly, and quite plausibly without anyone at your organisation making a decision about it. Your managed service provider holds administrative access across your estate: support tickets full of screenshots and credential context, exported configuration files, mailbox access for migrations, and log archives. Helpdesk and remote-monitoring tooling is racing to add AI summarisation and troubleshooting copilots, and MSP technicians are under the same productivity pressure as everyone else, so your data can start flowing into cloud AI through your supplier's tooling before you have ever been asked.

The question matters because supply-chain AI exposure is invisible from the client side by design: the client sees a ticket resolved faster, not the AI feature that resolved it, and the first sign of a problem is often a data protection or contractual issue rather than a security alert.

How would AI actually enter your data through an MSP?

Through the everyday tools the MSP already uses to support you. A professional services automation platform, a remote monitoring and management console, or a ticketing system may enable an AI feature, sometimes on by default with a new release, that summarises ticket content, drafts responses, or triages issues using a cloud AI model. Ticket content routinely includes screenshots of your systems, extracts of configuration, and sometimes direct pastes of data your technician was trying to fix.

Why is this an Article 28 problem, not just a security question?

Because under UK GDPR your MSP is typically a data processor acting under your instructions, and engaging a new sub-processor, which is what a cloud AI feature effectively is once it starts processing your data, requires prior authorisation under Article 28. An MSP that enables an AI feature across its whole tooling estate without checking client contracts is very likely creating unauthorised sub-processing at scale, even where no individual technician intended anything improper.

Do NIS2 and DORA make this worse?

They raise the stakes without changing the underlying mechanism. Both regimes push supply-chain and third-party risk onto the buyer: NIS2 requires essential and important entities to manage security risk in their supply chains, and DORA imposes ICT third-party risk management duties on in-scope financial entities. Neither regime is covered in depth here, but both mean that an MSP's undisclosed AI feature is not merely a data protection gap for firms in scope of either regime, it is a supply-chain control failure they are specifically required to manage.

What should you ask your MSP in writing?

Six direct questions, and insist on written answers rather than a verbal reassurance:

• Which AI features are currently enabled in the PSA, RMM or ticketing tools used to support our account?
• Is any of our data used as input to those features, including screenshots, logs, configuration exports or ticket text?
• Which AI sub-processors are involved, and where are they located?
• Can those AI features be disabled specifically for our tenant if we require it?
• What does our contract currently say about sub-processor authorisation, and does it cover this scenario?
• What audit rights do we already hold, and have we ever exercised them?

What do most existing MSP contracts actually say?

Often less than clients assume. Many managed service agreements were negotiated before generative AI existed as a mainstream feature of support tooling, and general sub-processor clauses may not have been drafted with an AI feature toggle in mind. Checking the existing audit rights clause, and actually using it, is usually more productive in the short term than waiting for a contract renewal to fix the gap.

Where does keeping data inside your own boundary help even when support is outsourced?

It separates who provides the support from where the data and the AI actually sit. Support can still be outsourced to a trusted MSP while the data and any AI processing of it remain inside infrastructure the client controls, with the MSP's own actions on that infrastructure landing in the same sealed record as everything else. That converts is our supplier feeding our data into cloud AI from an open question the client cannot answer into a boundary the client enforces by design.

“An MSP does not need to act improperly for your data to reach cloud AI, it only needs a tooling update you were never told about.”

How support can stay outsourced while data and AI processing remain inside a boundary the client controls, with every action sealed to a record, is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Is my MSP breaking the law if its helpdesk tool has an AI feature enabled?

Not automatically, but if that AI feature processes your data through a cloud AI model it has not been authorised for under your contract, the MSP is very likely engaging an unauthorised sub-processor under UK GDPR Article 28, which is a breach of the processing agreement regardless of intent.

How would we even know if our MSP's tools had AI features turned on?

In practice, only by asking directly and in writing, since these features are frequently enabled at the vendor's platform level and may not be individually announced to every downstream client. The six-question checklist above is designed to surface exactly this.

Does our contract already give us the right to ask these questions?

Most professional services and MSP agreements include audit rights and sub-processor notification clauses, though the strength and specificity of those clauses varies considerably. Reviewing the actual wording, rather than assuming a standard protection exists, is the necessary first step.

Does NIS2 apply to every business using an MSP?

No, NIS2 applies to organisations classified as essential or important entities under the Directive within scope member states, not to every business, and the UK sits outside NIS2 entirely. Where it does apply, supply-chain risk management duties reach exactly this kind of exposure.

Can we simply require our MSP to disable all AI features for our account?

You can ask, and many MSPs can accommodate a per-tenant configuration change, but this depends on the specific platform's capabilities and your MSP's willingness and technical ability to segment it, which is precisely why asking the question directly and in writing matters.