Shadow AI and third-party risk: approve the data flow

Consider an analyst reviewing a supplier’s SOC 2 report. The document is long, the assessment is due, and an AI assistant can summarize it in seconds. The analyst uploads it through a personal account. No software is purchased. No vendor request is raised. Yet the report has reached a provider the company has not reviewed.

That is the gap shadow AI creates in third-party risk management (TPRM). Shadow AI is the use of AI tools or features outside an organization’s approved processes. When those tools receive company data, a review process triggered only by purchases will miss part of the company’s exposure.

Our view is that an AI review should follow the data: which service receives it, under which account and terms, and what that service can do with it. Approval needs to identify the account, use case, and data involved.

Illustrative onboarding paths. The controls and subprocessor obligations that apply depend on the data and processing arrangement.

The account changes the risk

An approved enterprise account and a personal account can display the same product name while operating under different terms and settings. Approval for one does not settle the review for the other. The same is true of a new AI feature inside software the company already uses.

Netskope’s Cloud and Threat Report 2026 analyzes activity observed in 2025 and reports that 47% of generative AI users in its customer environment used personal AI apps, down from 78% a year earlier. Some used both personal and managed accounts. These figures are not a survey of all employees or proof that every personal-account use violated policy. They show why an enterprise license alone does not establish which account received an upload.

For the analyst’s upload, establish the workspace or account, its administrator, the information shared, and the agreement and settings that applied at the time. A later move to an enterprise plan does not establish what happened to the earlier file. If the account or data cannot be confirmed, preserve that uncertainty and assign an owner to investigate it.

When does an AI provider become a subprocessor?

An AI provider is not automatically a subprocessor. The ICO’s glossary defines a subprocessor as a processor engaged by another processor to perform specified processing for a controller. The role depends on personal data, the parties’ responsibilities and the actual arrangement.

If your company processes a customer’s personal data and sends it to an AI provider for the same work, that provider may become part of the subprocessor chain. Legal needs to assess the arrangement against the customer agreement, including any authorization or notification requirements. If the upload contains only proprietary source code, the issue may instead be confidentiality and intellectual property. It still needs a review.

This distinction changes what you do. A supplier inventory records the services the business uses. A subprocessor list serves a more specific purpose. Finding an unapproved AI tool should start an investigation into its use, rather than an automatic addition to every customer-facing list.

Source: IBM’s 2025 Cost of a Data Breach study of 600 breached organizations. The cost difference compares cohorts with high shadow-AI use against those with low or none. It is not a fixed charge per incident or evidence that shadow AI caused the entire difference.

An approved vendor can introduce a new data flow

Now consider an AI summary feature added to an existing support platform. The company approved the platform to store tickets. The new feature may send ticket content to a model provider, create a separate copy of the output, or allow an agent to act on the result. Whether it does any of those things has to be established from the feature’s architecture and terms.

The original review may already cover the feature. It may also predate it. Check which data leaves the application, which providers receive it, where processing happens, and whether administrators can control access. A new model provider, broader permissions, or different retention terms can justify a fresh review even when the vendor and contract renewal date stay the same.

This is why an AI inventory needs to record the use case and account alongside the product. “Approved for drafting with public information” is a different decision from “approved to process customer support tickets.” The record should make that boundary understandable to the person using the tool.

An example of a change that can require review. Establish the actual downstream providers and contractual roles before changing a subprocessor list.

Turn discovery into a review decision

Start with the evidence available through your authorized browser, network, identity, and SaaS administration tools. Combine it with employee reporting and the AI features enabled in existing applications. Our guide to finding unapproved AI use covers discovery in more detail. Here, the aim is to turn each finding into a decision someone owns.

For each use case, record the business owner, account type, data involved, and access granted. Prioritize the cases where customer information, credentials, confidential documents, or write access are involved. A tool used to brainstorm public marketing ideas does not need the same response as an agent connected to a customer database.

Review the terms for the exact service and plan. Separate training from retention: OpenAI’s API documentation distinguishes model-training policy, abuse-monitoring logs and application state. The relevant controls and exceptions depend on the feature and account. Follow each copy in your own workflow: the uploaded report, generated summary and operational logs may have different retention and deletion paths. Review the DPA and downstream providers where they apply.

The outcome should be usable: approve a defined use, approve it with conditions, move the work to a managed account, or stop it. For example, an analyst might be permitted to summarize designated supplier reports in a managed workspace, with external connectors disabled. Record the permitted data, owner, conditions and review trigger. Tell the employee what work can continue and through which account.

Give useful work an approved route

In the analyst’s case, blocking the upload may be necessary. It does not remove the assessment deadline. The team also needs an approved way to summarize the report, with the right account, data permissions, and handling terms. Otherwise, the reason for the shortcut remains.

Revisit the decision when the tool adds a recipient, gains another permission, or moves from drafting an answer to taking an action. An AI vendor assessment can supply evidence about the provider; agent governance addresses the authority granted to the running workflow. Keep both decisions attached to the use case so approval of the brand is not mistaken for approval of every account or integration.

Explore Zania’s third-party risk management or watch our discussion on third-party risk in the agentic era.