Shadow AI The New Baseline Gap How to Close It Before It Costs 670K
A team does not need to approve an AI tool for it to enter the company. One employee can paste a customer email into a public chatbot. Another can upload a contract to summarise it. A developer can test code in a coding assistant using a personal account. None of this needs a purchase order, a security review, or a formal rollout.
That is why shadow AI has become a baseline control problem.
The issue is not that employees are careless. In most cases, they are trying to work faster, write clearer, analyse more data, or remove repetitive tasks. The problem is that adoption is moving faster than policy, access controls, and data rules. When that happens, sensitive data can leave approved systems before anyone in security, IT, or leadership knows the tool exists.
IBM’s 2025 breach reporting puts a hard number on the risk. According to IBM, the use of unsanctioned AI can add approximately USD 670,000 to the cost of a breach. The same reporting also found that 63% of breached organisations lacked AI governance policies. That is not a future problem. It is a current gap in basic security hygiene.
Why employees adopt AI before the organisation is ready
AI tools spread quickly because they solve real daily problems. They can summarise long documents, write first drafts, explain code, turn notes into plans, and help with research. For a busy engineering team or a founder-led company, that speed feels useful from day one.
The usual approval path is much slower. A new tool may need a security check, a data processing review, budget approval, legal input, and configuration. That can take weeks or months. By then, employees may already have found a free tool that works well enough.
This creates a gap between how work is done and how work is governed.
Common examples include:
A salesperson pastes prospect notes into a public AI writing tool to draft a follow-up email.
A product manager uploads customer feedback to summarise themes.
An engineer uses a personal AI coding assistant with internal code snippets.
A finance employee asks an AI tool to explain a spreadsheet containing supplier details.
A support agent uses a chatbot to rewrite a customer complaint that includes personal data.
Each action may look small. Together, they create a map of sensitive company information outside approved systems.
The real risk is data leaving your control
The main concern with unsanctioned AI is not only the tool itself. It is the loss of visibility and control.
When an employee uses an approved system, the organisation can usually answer basic questions:
Who has access?
What data is stored?
Where is the data processed?
Can access be removed when someone leaves?
Are logs available after an incident?
Does the supplier contract include data protection terms?
With unsanctioned AI, many of those answers are unknown.
That matters because prompts and uploaded files can contain valuable information. Customer records, source code, pricing models, contracts, incident reports, internal strategies, credentials, and personal data can all appear in AI prompts. Even if an employee only intends to “clean up the wording”, they may expose more information than they realise.
This is where generative AI data leakage becomes a practical security issue. Data does not need to be stolen by an attacker to become exposed. It can be copied into a tool that the organisation has not reviewed, cannot monitor, and cannot remove data from with confidence.
That creates several risks at once.
Sensitive information may be retained outside approved systems
Different AI providers have different data retention rules. Some business plans provide stronger controls than free plans. Some tools allow the use of prompts for service improvement unless settings or contracts say otherwise. Some browser extensions and plug-ins may collect more information than users expect.
Without an approved list and clear rules, employees may choose based on convenience rather than data handling.
Security teams lose audit trails
After a security incident, logs matter. They help show what happened, which accounts were used, what data moved, and when access changed. If staff use personal AI accounts, there may be no usable audit trail for the organisation.
That makes investigations slower and more expensive. It can also make regulatory reporting harder, especially where personal data is involved.
Access continues after people leave
If an employee signs up to an AI tool with a personal email address or a local password, the organisation may not be able to shut off access when that person leaves. This is a basic identity control gap.
Single Sign-On, often shortened to SSO, helps solve this. It lets employees access approved tools using their company login. When a person leaves, the company disables one account and cuts access to connected systems.
AI output can create hidden quality and compliance issues
Not every risk is a data leak. AI-generated output can be wrong, biased, incomplete, or based on outdated information. If employees use AI for customer replies, code changes, policy documents, or legal summaries without review, quality risk enters the process.
That is why an AI acceptable use policy should cover both input and output. It should tell staff what they can put into tools and when human review is required.
IBM’s 2025 findings show why this belongs in the baseline
Security baselines exist because some controls are too important to leave to chance. Endpoint protection, password rules, access reviews, backups, and patching are baseline topics because they reduce common risks across the whole company.
AI now belongs on that list.
IBM’s 2025 findings make the point clearly. If unsanctioned AI can add approximately USD 670,000 to breach costs, it is no longer a side issue. It is part of breach readiness, access control, supplier risk, and data protection.
The 63% figure is just as important. If most breached organisations in IBM’s reporting lacked AI governance policies, then many companies are still treating AI use as informal experimentation. That approach does not match current risk.
If employees are already using AI, the baseline is not “no AI”. The baseline is governed AI.
For smaller and mid-sized organisations, this does not need to start with a large governance programme. AI governance for SMBs can begin with a few practical controls that are easy to explain and enforce.
The EU AI Act has raised the governance bar
The regulatory pressure is also increasing. Under the EU AI Act, general-purpose AI obligations began on 2 August 2025. These obligations apply especially to providers of general-purpose AI models and include requirements linked to transparency, documentation, and risk management.
For companies using AI tools, the message is still relevant. Even when the main legal obligations sit with model providers, organisations need to know which AI tools are in use, what data is being shared, and whether vendors can support compliance expectations.
This is especially important for companies operating in or serving the EU. If teams use AI tools without review, it becomes much harder to show that data, risk, and supplier controls are in place.
The EU AI Act does not mean every company must stop using AI. It does mean informal use is becoming harder to defend.
The three baseline controls that close the gap
The fastest way to reduce risk is to treat AI like any other business technology. Start with basic controls that set boundaries without blocking useful work.
Baseline control | What it does | What good looks like |
Approved tool list | Gives employees clear options | Staff know which AI tools they can use for work |
Single Sign-On | Links tool access to company identity | Access starts and ends with the company account |
Data-handling rules | Defines what can and cannot be entered | Staff know when data must stay out of AI tools |
Build an approved AI tool list that people will use
An approved tool list should not be a long legal document. It should answer a simple question: “Which AI tools are safe enough for which tasks?”
Start by sorting tools into clear categories.
Approved for general business use
These tools are allowed for normal work, within defined rules. They may cover drafting, summarising non-sensitive content, brainstorming, translation, or internal productivity.
Approved for restricted use
These tools may be allowed for certain teams, data types, or use cases. For example, a coding assistant may be approved only when connected to company accounts and configured not to train on private code.
Not approved for company data
These tools may be allowed only for personal learning or public information. They must not receive customer data, source code, confidential plans, contracts, or personal data.
The list should include the tool name, approved use, data limits, owner, and review date. Keep it short enough that employees can scan it in under two minutes.
A useful approved list also gives alternatives. If employees are already using an unapproved tool, banning it without offering a safe option often pushes use further underground.
Require Single Sign-On for approved AI tools
Single Sign-On is one of the most effective baseline controls because it ties AI access to company-managed identity.
Without it, employees may create separate accounts with weak passwords, personal email addresses, or payment cards. Security teams then lose control over access, logs, and offboarding.
With SSO, the company can usually:
Enforce stronger login checks.
Remove access when someone leaves.
See which employees use the tool.
Apply access groups by team or role.
Reduce the number of standalone passwords.
For founders and IT managers, this is a practical rule: if an AI tool will handle company data, it should support company-managed access. If it cannot, it needs a clear risk decision before use.
This is also where procurement and engineering should work together. A tool may look excellent in testing, but if it cannot meet basic access controls, it may not belong in production use.
Write data-handling rules that fit daily work
Many AI policies fail because they speak in broad warnings. “Do not share confidential data” sounds clear until someone asks whether a customer complaint, log file, product roadmap, or code snippet counts.
Data-handling rules need to be specific.
A simple model can work well:
Green data
Public information that can be used in approved tools. Examples include published website copy, public documentation, public job descriptions, or generic text with no sensitive details.
Amber data
Internal information that may be used only in approved company AI tools, and only when needed. Examples include internal process notes, non-sensitive project summaries, or draft internal communications.
Red data
Information that must not be entered into AI tools unless a specific approved process exists. Examples include customer personal data, secrets, access keys, unpublished financials, sensitive contracts, regulated data, and private source code.
This structure helps employees make faster decisions. It also gives managers a common language when reviewing incidents or approving new use cases.
For engineering teams, include exact rules for code. For example, decide whether developers can paste code into AI tools, what repositories are allowed, and whether security findings or access tokens must be removed first. Do not assume every engineer will interpret “confidential” the same way.
Turn the baseline into a 30-day plan
A good baseline does not require a year-long project. Most organisations can make meaningful progress in 30 days.
Week 1. Find current AI use
Ask teams what tools they use and for what tasks. Make the survey non-punitive. The goal is visibility, not blame.
Check browser extensions, expense claims, identity logs, and team subscriptions where available. Look for tools used with personal accounts or shared logins.
Week 2. Classify the main tools
Decide which tools are approved, restricted, or not approved for company data. Focus first on tools already in use.
For each approved tool, confirm basic facts:
Does it support company login?
Can data use for training be controlled?
Where can administrators review usage?
What data types are allowed?
Who owns the tool internally?
Week 3. Publish the rules
Release a short AI use policy with plain examples. Keep it practical. Tell staff what they can use, what they cannot use, and where to ask questions.
The policy should include:
Approved tools.
Data categories.
Human review requirements.
Rules for customer data.
Rules for source code.
How to request a new tool.
Week 4. Enforce the basics
Turn on SSO for approved tools where possible. Remove shared accounts. Block or warn on clearly unsafe tools if your systems allow it. Add AI tool checks to onboarding, offboarding, and supplier review.
This is where the baseline becomes real. A policy without access control is a suggestion. Access control without clear rules creates confusion. You need both.
What success looks like
A closed baseline gap does not mean every AI risk disappears. It means the organisation can answer the basic questions that matter.
Which AI tools are in use? Who approved them? What data may be entered? How is access controlled? What happens when someone leaves? Who reviews new tools? What must employees avoid?
Those answers reduce guesswork during an incident. They also make it easier to adopt AI safely, because teams know the rules before they experiment.
The companies that handle this well will not be the ones that ban every AI tool. They will be the ones that make safe use easier than unsafe use.
If shadow AI is already part of your company’s day-to-day, a Security Baseline can help you put sensible guardrails in place without slowing anyone down.
The cost of waiting is no longer theoretical. IBM’s 2025 reporting points to a clear financial impact, regulators are raising expectations, and employees are already moving. Close the baseline gap before an unapproved prompt becomes a breach record.
