The company assistant cannot analyse a supplier’s spreadsheet. An employee has a deadline, opens a personal AI account and uploads it there. The answer is useful. The company now needs to understand where the spreadsheet went.
This is one form of Shadow AI: work carried out through AI tools, accounts or connections outside the organisation’s approved arrangements. It can involve a familiar provider, a personal paid subscription or a browser extension that sits between the employee and the model.
For a manager, the immediate question is which route received which data. A promise that a provider does not train on company data addresses one use of the information. It does not, by itself, settle retention, connected services, shared links or malicious access.
Why employees reach for a personal AI account
An employee may be trying to finish an ordinary task: compare quotes, summarise a contract or extract figures from a document. If the approved tool lacks a file format, connector or usable workflow, a personal account can look like a practical workaround.
That explanation needs checking in the actual team. An AMCIS conference paper reports a survey of 340 full-time employees examining perceived corporate AI inadequacy and Shadow AI use. Its abstract describes two countervailing emotional effects: more frustration with internal AI tools, but less fear of missing out on AI. It does not support a simple rule that inadequate corporate tools cause unapproved use. This summary relies on the abstract only.
Ask what failed before buying a replacement: the model’s answer, access to a document, an unavailable feature, response time or the approval process. Each points to a different repair. Giving everyone another subscription will not necessarily fix a connector that exposes too much information.
Advice we argue with: “ban personal AI accounts and the problem goes away.” Without an approved tool that can finish the task, a ban moves the same work somewhere less visible. We would fix the failed task first, then set which data may go where.
What the OpenAI and Anthropic promises cover
“They do not use our data” is too broad to guide a decision. Check the account and service actually used, then the relevant settings and exceptions.
| Route | What the provider currently says about training | What still needs checking |
|---|---|---|
| Standard personal ChatGPT workspace | Training sharing is on by default; the user can turn it off. | History, sharing, feedback and separate product settings. |
| ChatGPT Business/Enterprise and OpenAI API | No training by default; explicit sharing arrangements can differ. | Actual workspace, service terms, retention and external recipients. |
| Consumer Claude account | Model-improvement permission matters; safety and feedback contexts have additional terms. | Settings, conversation history and connected services. |
| Commercial Claude services | No model training by default, with explicit permission/feedback exceptions. | Service, model, retention terms and enabled integrations. |
Sources: OpenAI data controls, OpenAI API data controls, ChatGPT Business, Enterprise and Edu security, Claude consumer policy and Claude commercial policy. These are provider statements, checked on 10 November 2026. They are not an independent audit of implementation. Special programmes, feedback and other product settings can affect the general rules; the account label alone is insufficient.
Training and retention are separate decisions. For example, Claude consumer chats stay in the history until the user deletes them; deleted chats leave back-end storage within 30 days, but data used for model improvement, flagged chats and feedback are kept longer (up to 5, 2 and 5 years). Commercial retention differs by service, and for designated covered models Anthropic requires 30-day retention, with exceptions, from organisations that otherwise use zero data retention. There is no safe universal reading of “nothing is stored after 30 days”. Check the consumer retention rules, commercial rules and covered-model terms.
On a call with a manager, we put it this way: “Turning training off decides one thing: whether the provider learns from those chats. It does not decide who can open a shared link, what an extension reads, or who keeps the history when the employee leaves.”
Who gets the data, and when is it theft?
There are several distinct routes. Calling every transfer “theft” obscures which action could close it.
The provider processes the request. OpenAI describes limited access by authorised personnel and trusted service providers for specified purposes, including security and support. It also states that it does not sell user data or share chat content for marketing or advertising purposes. That is different from a malicious party copying a chat. Read its consumer-data explanation; do not substitute an unsupported allegation about either provider.
A connected service receives part of the input. A custom GPT can call an outside service through an app or an action. OpenAI says relevant parts of the input may then be sent to that third-party service. A GPT builder does not automatically see individual conversations merely because they built it; a service endpoint invoked by it is a separate recipient. The GPT documentation makes that distinction. OpenAI is moving custom GPTs to plugins before retiring them; the same check applies to the plugin or app that replaces one. Check the recipient’s terms and the connection’s permissions.
An extension makes another copy. In March 2026, Microsoft Defender researchers described malicious AI-assistant extensions collecting chat content and sending it to operator-controlled infrastructure. This is observed malicious collection outside the model provider. The report does not establish who ultimately bought the information or that it was used against a particular company.
A person shares the conversation. In a personal ChatGPT account, anyone with the shared link can view the shared snapshot. Eligible managed-workspace audiences differ. A training opt-out does not revoke that link. The sharing rules need their own check. For what a company should control, see An AI share link is not private.
“Who steals it?” therefore has a bounded answer: researchers have documented malicious extensions collecting and exfiltrating conversations. That does not identify the people controlling them. Other recipients may receive data through an enabled integration or a deliberate share. These are different mechanisms, with different evidence. We cannot name an unknown ultimate buyer or claim that a competitor obtained a company’s documents without proof.
Follow one task through the whole route
Consider an illustrative purchasing task, not an IZZY client case. A buyer needs to compare three supplier quotes. The approved assistant cannot read the workbook. It contains named contacts, proposed prices and internal negotiation notes.
The buyer opens a personal account, installs an AI sidebar to help with the file and shares the resulting conversation with a colleague. This creates several decisions:
| Point in the task | Question that changes the decision |
|---|---|
| Workbook input | Could a reduced table answer the question without contact details and negotiation notes? |
| Personal account | Is this exact account and data use authorised, under the relevant controls? |
| Sidebar or converter | Does it read the page, receive the file or contact its own backend? Has that recipient been reviewed? |
| Output sharing | Who can open the link, and does the answer repeat confidential input? |
Turning training off in the personal account addresses neither the sidebar’s copy nor the link audience. A personal paid subscription also does not establish that the company has approved the route.
The same reasoning applies to secrets. In an analysis of selected high-risk extensions, Unit 42 reported an AI job-application assistant extension forwarding user-entered AI-provider API keys to its developer’s backend. That selected sample does not describe every extension. It does show why a familiar provider’s name on the settings screen is insufficient evidence about the destination of a key.
Could exposed information be used against the company? Negotiation notes could inform a targeted impersonation attempt; a valid key could enable unauthorised use within its permissions. These are possible consequences, dependent on the information and access involved. They are not documented outcomes of the fictional purchasing example or proof of downstream exploitation in the cited extension cases.
What worries us first is control after departure: the files and chat history stay in an account the company cannot see or close.
Give the task an approved route
Start with this one workflow. Use a synthetic workbook or public material to reproduce the limitation before putting confidential information into a new service.
The team responsible for the task and the people responsible for security and data should agree:
- The permitted input. Specify the necessary fields and prohibited material. “Remove sensitive data” is less useful than “retain product references and quantities; exclude names, contract identifiers and internal negotiation notes”. A small remaining dataset may still be identifying or confidential.
- The complete route. Name the account, provider, connected apps and output destination. Review access and retention for those recipients, rather than approving a brand in isolation.
- The accepted result. Test whether the approved route can actually compare the quotes accurately. For this example, check currencies, units, missing rows and invented totals against the safe source file. A permitted tool that cannot finish the task leaves the original problem unresolved.
- The fallback. If there is no suitable approved route, keep the task in an authorised manual or existing process while the gap is assessed. Make the escalation contact and next decision clear.
This follows the direction of CNIL’s generative-AI usage guidance (in French): define uses and data boundaries, explain them to staff and check practice. A generic prohibition does not describe how this buyer should finish this spreadsheet.
Autonomous agents that can act across files, a browser and other tools need a separate decision. CERT-FR’s April 2026 bulletin (in French) covers those powers and their risks, including prompt injection, and recommends against deploying such assistants on workstations or in production for now, limiting them to isolated test environments without sensitive data. Do not treat permission to analyse a table as permission to browse an entire drive or send email.
If confidential material has already gone to an unapproved recipient, involve the company’s security/privacy process with the known account, file, recipient and time. Preserve the information needed to assess the event. The responsible team can decide on revoking a connection or link, requesting deletion and rotating an exposed credential. Do not assume one deletion removes every copy or decide notification duties from a generic article.
Find the approved route with us
If the gap lies in an approved AI workflow or product integration, IZZY’s AI Agents & LLM Products service is a relevant starting point for a scoped discussion. Bring the task, permitted data and a safe example of the failure. For the adjacent question of continuity when a provider changes access or terms, see AI model-provider dependency.
Frequently asked questions
No. Price alone does not determine organisational approval, contract or controls. OpenAI distinguishes managed and personal accounts, with configuration and account-claim exceptions. Verify the actual workspace rather than inferring it from the employee’s email address.
It addresses a specified training use. You still need permission to submit that data, an acceptable recipient and retention arrangement, and control over integrations and sharing. An opt-out does not retrospectively withdraw another recipient’s copy.
First reproduce the failed task safely. A missing connector, poor document preparation and a model capability limit require different interventions. Replacement is one possible decision, not an automatic consequence of discovering Shadow AI.