Shadow AI at work: tools, data and practical controls

Shadow AI at work means using AI outside the organisation’s approved systems and processes. Start by finding out which tasks people perform, which accounts they use and where the data goes. Then assign owners, approve appropriate uses and establish a clear route for reporting mistakes. A blanket ban alone cannot provide that visibility.

The UK National Cyber Security Centre (NCSC) uses this definition and recommends understanding staff needs alongside providing secure alternatives. The workflow below is a practical proposal for a small business. Its examples are illustrative.

Understand and simplify the task first

Someone might use a chatbot to shorten a proposal, summarise an email thread or organise meeting notes. Ask where the work gets difficult before choosing a control. Could a shared response template, a current price list or a simpler form solve the problem? Improving the workflow may reduce the information that needs to leave the business.

Explain the purpose of discovery: learning what helps people do their jobs and where safer conditions are needed. Say who can see the answers and how the inventory will be used. Avoid promising anonymity if each entry identifies the person responsible for it. Keep routine discovery separate from the investigation of a specific incident.

An illustrative sales example: an employee pastes a proposal into a personal chatbot account to make it shorter. The document includes customer names, negotiated prices and contract terms. A simplified process gives the employee an approved template without customer details. They add the actual details inside the company system, removing the need to upload the full proposal.

Inventory use cases, accounts and data flows

A list of application names misses important differences. The same product can be used through a personal account, a company workspace or an integration with broader permissions. Record each distinct use case together with its operating conditions.

The NIST AI RMF Playbook, GOVERN 1.6 describes AI system inventories and responsibility for maintaining them. A small business can begin with a shared, access-controlled spreadsheet:

Field	What to record
Task and owner	The purpose and the person accountable for the use case
Tool and account	Provider, plan, personal or company account, administrator
Input data	Data categories and their source, without copying confidential content
Data route	Pasted text, uploaded file, recording, connector or API
Permissions	What the integration can read, change, send or delete
Output and recipient	Where the result goes and who checks it
Provider conditions	Verified retention, training use, subprocessors and deletion options
Decision and review	Approved, conditional or paused, with conditions and a review date

Include browser extensions, meeting bots, writing assistants, AI features within existing software and API-based automations. Check shared accounts and integrations left behind when staff leave. A purchased application can gain new AI functionality without appearing as a new purchase.

Compare staff responses with company purchase records, administrative account lists and access grants that you are authorised to review. Stay within agreed access boundaries and avoid collecting employees’ private conversations. Free tools may never appear in finance records. Manual copying and pasting may never appear in a connector list.

Do not turn the inventory into another store of sensitive information. Keep passwords, API keys, complete prompts and customer documents out of it. Record categories and references to evidence held separately with restricted access.

Approve a specific use under specific conditions

NIST, GOVERN 1.3 supports assigning risk management effort according to the significance of the risk. Apply that principle to the task, account, data and permissions together. Paying for a subscription does not establish that every use of it is suitable.

A simple internal decision route could use these operational categories. They are a suggested working method without legal risk classification status:

• Approved: public or deliberately fictional material, an approved account and a person responsible for checking the output.
• Conditional: internal information or access to company documents. Review provider conditions, access scope and output checks before approval.
• Paused for assessment: unclear conditions, confidential material in a personal account, broad mailbox access or autonomous sending and editing without agreed controls.

Name the person who makes the decision and set a response deadline. When pausing a use case, offer an approved alternative or a manual way to finish the task. The employee still has work to deliver, even while the assessment is underway.

Check the actual plan and configuration: who receives the data, how long it is retained, whether it is used for training and how access can be restricted or removed. NCSC warns that transferring sensitive information to consumer AI services can reduce visibility and control. Conditions established for one product or subscription should not be assumed to apply across a provider’s entire range.

Removing a name does not automatically make a document anonymous. Other details can still identify the person. GDPR Recital 26 explains that pseudonymised information remains information about an identifiable person when additional information can be used to attribute it to them.

Put the resulting rules in one accessible place. Our AI use policy guide provides a starting point for permitted accounts and data, output approval and reporting problems. A written policy should reflect the inventory and the actual work people do.

Prepare an incident route before it is needed

Staff should know where to report an accidental upload, an integration with excessive access or an incorrect message sent by an automation. Internal reporting should start the assessment without requiring the employee to decide whether the event meets a legal definition.

Use a clear sequence:

1. Contain further activity. Pause the data flow, disable public sharing or remove unnecessary permissions. If a secret was exposed, have an authorised person rotate it.
2. Preserve the minimum necessary evidence. Record the time, service, account type, data scope, recipients and actions taken. Avoid forwarding the document again or deleting evidence before assessment.
3. Establish the extent. Check sharing history, connector access and information from the provider. Separate confirmed facts from open questions.
4. Bring in the right owners. Involve the security contact and process owner, plus the person responsible for data protection when personal data is involved.
5. Document the decision and repair. Record provider follow-up, any notifications, conditions for resuming work and changes to the inventory or rules.

Deleting a conversation from the user interface does not demonstrate that every provider-held copy has been removed. Record what was actually confirmed. An empty chat window is insufficient evidence for telling a customer that the matter is resolved.

Where the GDPR applies and a personal data breach has occurred, Article 33 requires the controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to create a risk to individuals’ rights and freedoms. Personal data breaches must be documented. Article 34 provides a separate assessment of communication to affected people where high risk is likely, subject to its stated exceptions. Other jurisdictions may have different requirements.

Using an unapproved tool is not automatically a personal data breach. A suspected disclosure still needs prompt assessment by the responsible people. Avoid making a notification decision solely from the tool’s name or the employee’s description of it as a private account.

Frequently asked questions

Should we ban every personal AI tool? Set explicit boundaries for data and use cases, and provide company-approved alternatives. Immediate restrictions may be appropriate for a risky flow, while lasting rules should follow an assessment of the work and the risk.

Do we need to collect every prompt? Routine discovery usually needs a task description, data categories, account and permissions. Keep incident evidence separately with controlled access and an agreed retention period.

When should an approved use be reviewed again? When the data, subscription plan, integration, permissions or use of the output changes. Also agree a regular review with its owner. Approval to draft a message does not automatically include approval to send it to customers.

Start with one workflow

Choose a workflow where AI is already being used. Map its use cases, accounts and data routes, address urgent risks and name the decision owners. Extend the inventory once that process works. If you need help establishing the current situation and priorities, our AI use review covers use-case inventories, data flows and technical and organisational working rules.