Stealth AI: The AI Risk Category Your Governance Framework Does Not Cover

Most organisations now have a Shadow AI policy. Very few have anything covering the second category, which arrives through the front door with your signature already on the paperwork.

Stealth AI is AI capability entering an organisation through existing, approved supplier relationships without triggering security review, governance assessment or change management controls. Your people did not introduce it. Your suppliers did, in a routine product update. No control in your framework was designed to catch it.

The distinction matters because the two problems have different causes, different owners and different fixes. Treating Stealth AI as a variant of Shadow AI produces awareness campaigns and acceptable-use policies aimed at staff who did nothing wrong.

Shadow AI is a people problem. Stealth AI is a process problem

Shadow AI is user-initiated. Someone in finance pastes a management account into a free chatbot because it saves them an hour. The tool was never approved, never assessed and never appeared in your asset inventory. Your controls miss it because the user routed around them.

Stealth AI is supplier-initiated. A platform you procured three years ago, assessed properly, contracted carefully and onboarded through change control gains an AI assistant in version 4.2. The feature is enabled by default. Data flows to a third-party model provider that was not part of the original data processing agreement. Nobody circumvented a control; the control simply never fired.

	Shadow AI	Stealth AI
Who initiates	Employees and teams	Approved suppliers and platform providers
How it enters	Unapproved tools adopted directly by users	Product updates to software already in your estate
Which control fails	Acceptable use policy, egress monitoring, asset inventory	Change management, third-party risk assessment, DPIA review, contract change control
Who is accountable	Ambiguous; often the individual user by default	Clearly the organisation; the supplier acted within contract

That final row is where the risk concentrates. With Shadow AI you can point to a policy breach. With Stealth AI, the supplier has usually done nothing wrong. Their terms permitted feature changes, their release notes documented the addition and their contract allowed it. The exposure sits entirely with you.

Why change management does not catch this

Change management assumes you are the one making the change. Every mature process, from approval through to release scheduling, is built around a request that originates inside your organisation and moves through assessment towards deployment.

SaaS inverts that flow. The change originates with the supplier, deploys to their infrastructure and appears in your environment without a ticket. Your change register records nothing because, from a process perspective, nothing changed on your side.

Third-party risk assessment has the same blind spot. Most organisations assess a supplier at procurement, then reassess annually or at renewal. A capability change shipping in month four of a three-year contract falls into a gap between assessments. The supplier is still the supplier you approved. The software is not the software you approved.

The pattern we see repeatedly

The sequence tends to look like this.

A document management or service desk platform announces an AI summarisation feature. It ships enabled, because suppliers optimise for adoption. Content that users upload is now processed by a large language model, frequently hosted by a different company under a sub-processor arrangement.

No updated Data Protection Impact Assessment exists, because no one inside the organisation registered a new processing activity. No contract amendment was negotiated, because the supplier’s terms already permitted feature evolution. No security review occurred, because nothing in the review trigger list mentions supplier feature releases.

Six months later, someone asks which AI systems process personal data. The honest answer is that nobody knows, and the inventory that should answer the question was built from procurement records rather than current capability.

Under the EU AI Act, the substantive deployer obligations attach primarily to high-risk AI systems, with narrower transparency duties applying to certain other systems. Those duties apply whether or not you chose to acquire the capability deliberately. The ICO’s expectations on transparency and lawful basis will generally apply to processing you did not consciously authorise. Regulators assess what your systems do, not what you intended them to do. This piece is general commentary on governance practice rather than legal advice.

What a proportionate response looks like

None of this requires treating suppliers as adversaries. It requires a small number of controls that assume capability change is continuous rather than event-driven.

Build an AI capability inventory separate from your software asset register. The question is not which products you own. It is which AI functions are active in your estate, which data they touch and which sub-processors sit behind them.
Add a supplier feature-change trigger to your risk assessment process. Release notes and product roadmaps become monitoring inputs rather than marketing material. For your highest-risk platforms, that means someone reads them.
Negotiate notification obligations at renewal. A clause requiring advance notice of material AI capability changes, with the option to disable features pending assessment, costs nothing to request. It shifts the burden to the party that holds the information.
Review default settings on existing platforms now. Features enabled by default are the ones you never decided to accept.

Most organisations discover, when they run this exercise properly, that the gap is not one missing control. It is a mismatch between a framework designed for the software estate of 2019 and the supplier behaviour of 2026.

Key questions on Stealth AI

Who should own Stealth AI in our organisation?

Ownership sits most naturally with whoever owns third-party risk, usually within the security or compliance function, working alongside procurement. The failure mode is assigning it to the AI governance group in isolation, because the controls that need changing are supplier assessment and change management processes rather than AI-specific policy.

Does an AI acceptable use policy help here?

Only indirectly. Acceptable use policies govern employee behaviour, which addresses Shadow AI. Stealth AI enters through supplier decisions, so the effective controls are contractual notification clauses, feature-change monitoring and an accurate AI capability inventory. A policy aimed at staff will not detect a supplier enabling a copilot by default.

How do we find Stealth AI already in our estate?

Start with your ten highest-risk SaaS platforms and audit current AI features against your original procurement documentation. Review admin console settings for AI functions enabled by default, then check whether sub-processor lists have changed since contract signature. This surfaces most material exposure without a full estate review.

Should we ask suppliers directly?

Yes, and most respond willingly. A short standard enquiry covering active AI features, underlying model providers, data retention and default settings gives you documented answers for your inventory. Suppliers are rarely evasive about this. The information exists and simply was never requested.

Where to begin

If you cannot currently name every AI capability active across your supplier estate, that is the gap worth closing first. Our AI Security Gap Analysis assesses your existing governance framework against how AI actually arrives in a modern organisation, and identifies which controls need to change to cover supplier-initiated capability.