Shadow AI in Procurement and Operations: The Costs Companies Don’t See

You have an AI policy. It’s probably a few pages long, sits in a shared drive nobody opens twice, and was signed off by a committee that has never watched anyone actually do the job.

Meanwhile, right now, a procurement analyst is pasting three supplier bids into a free AI tool to knock out a comparison table before a 3pm deadline. An operations manager is feeding a demand forecast into a different tool because the approved one is slow. A contract specialist just asked an AI assistant to summarise a supplier agreement nobody has time to read line by line.

None of them opened your policy first. None of them think they’re doing anything wrong. They’re just trying to get through their day.

That gap, between what your policy says and what your team is actually pasting into a browser tab at their desk, is Shadow AI. It’s not a hypothetical for the next board deck. It’s already happening, today, inside your procurement and operations functions.

Your organisation may have an AI policy, an approved software list and a procurement process for buying new technology. That does not necessarily mean you know where AI is being used.

But the organisation may now have unknown data exposure, duplicate software spend, unverifiable outputs and no reliable record of how an important business decision was produced. This is the problem with Shadow AI.

It is not simply employees using ChatGPT without permission. It is AI entering business workflows without the visibility, approval, data controls, ownership or monitoring the organisation requires.

For procurement and operations teams, that creates a problem that reaches well beyond cybersecurity. It can affect what the company spends, what information it shares, how decisions are made, how suppliers are managed and how much work is created when somebody eventually has to check what the AI produced.

What is Shadow AI?

A useful working definition is:

That includes more than personal accounts. Shadow AI can take at least four forms:

• Employees using personal accounts with public AI services.
• Unapproved AI applications or browser extensions.
• AI features quietly introduced into software the organisation already approves.
• Suppliers, contractors or service providers using AI as part of delivering a service.

That last category matters particularly to procurement. A company could eliminate every unauthorised chatbot from its employees’ laptops and still have AI operating somewhere in its supply chain.

The real question is therefore not: “Which AI tools did we buy?” It is: “Where is AI participating in our work, and what data and decisions move through it?”

Where Shadow AI appears in procurement and operations

Procurement and operations are particularly susceptible because their teams work across large amounts of information and are constantly under pressure to move faster. Consider where AI might appear.

There is also an important distinction between AI-assisted and AI-decided work.

An AI system might extract information from 50 supplier responses. That does not mean it should decide which supplier wins. It might identify patterns in demand data. That does not mean its recommendation should automatically change inventory levels.

The more consequential the decision, the more important it becomes to define who reviews the output, what evidence they use and who remains accountable for the final decision.

The five hidden costs of Shadow AI

The easiest mistake is to treat Shadow AI as a security problem with a possible financial consequence. The financial consequences can be much broader, and all five trace back to the same root cause: staff who were never trained to use AI safely inside their actual procurement and operations work.

1 Duplicate tool spend

When departments discover AI independently, organisations can end up paying several times for capabilities they could have consolidated.

One team buys an AI meeting assistant. Another buys a writing tool. A third subscribes to an analysis platform. Somewhere else, employees use free versions of similar products.

Each purchase may appear inexpensive. Collectively, they create:

• overlapping licences;
• unused seats;
• fragmented contracts;
• separate data-processing arrangements;
• inconsistent security controls;
• additional vendor-management work.

Then add usage-based charges, API consumption and unused seats. The purpose is not to manufacture an impressive number. It is to discover whether the organisation is paying for AI capabilities it already has elsewhere. Consolidating tools only sticks once staff have been trained well enough on the approved one to stop reaching for a personal alternative — the same pattern behind why an AI investment stops delivering results even after the licences are paid for.

2 Rework and productivity leakage

AI is often introduced because someone wants to save time. But an apparently fast AI workflow can create a second task: checking the output.

That matters when employees have to:

• correct invented supplier information;
• verify every AI-generated comparison;
• reconcile an AI report with ERP records;
• rebuild work in an approved system;
• resolve inconsistent definitions;
• explain an AI recommendation to management or audit.

This is one reason measuring AI productivity requires more than asking employees whether a tool saved them time. The apparent saving may disappear when verification and correction are included. Teams trained to prompt, verify and integrate AI output correctly generate far less of this rework in the first place — it’s part of what AI high performers do differently when they convert AI usage into measurable value instead of hidden overhead.

For a deeper look at this problem, see our guide to The AI Productivity Audit.

3 Commercial and data exposure

Procurement teams handle information that can be commercially sensitive even when it is not classified as highly regulated personal data. That can include:

• supplier price lists;
• negotiated discounts;
• pricing floors;
• tender responses;
• contract drafts;
• statements of work;
• payment information;
• supplier performance data;
• demand forecasts;
• inventory levels;
• production constraints;
• sourcing strategies;
• negotiation positions;
• internal approval notes;
• expansion or restructuring plans.

Imagine a category manager uploading three supplier proposals to an unapproved AI service and asking it to rank them. The data may reveal not just who the suppliers are, but how the organisation negotiates, what it values, where it has weaknesses and what prices it is prepared to accept.

There may also be uncertainty about how the AI service handles the information. Where is it stored? Who can access it? Is it retained? Is it used for product improvement? Are subprocessors involved? What happens if the provider changes its terms?

Even where no breach occurs, an organisation that cannot answer these questions has a visibility problem. In most cases, that gap exists because the people uploading the data were never told, in concrete terms, which categories of procurement information are safe to paste into which tools.

4 Poor decisions and operational disruption

The danger is not limited to confidential information leaving the organisation. AI output can also be wrong.

A supplier ranking might rely on an inappropriate criterion. A forecast might ignore lead times. An inventory recommendation might overlook minimum order quantities. A contract summary might omit an important qualification. An AI-generated report might use definitions that differ from those in the organisation’s ERP.

The problem becomes more serious when nobody records how the result was generated. What model was used? What data went into it? What assumptions were made? Who reviewed the output? What did the final decision-maker change?

Without those answers, an organisation can struggle to reproduce or defend an AI-assisted decision. Reducing this cost means training reviewers to interrogate an AI output before accepting it, not banning the output altogether.

5 Audit and vendor-management costs

Shadow AI creates another problem that may not appear until much later. Someone eventually asks:

• Which AI tools are being used?
• What information do they process?
• Who approved them?
• Which supplier terms apply?
• Was human review required?
• Who made the final decision?
• Can the result be reproduced?
• Has the supplier introduced a new AI feature?
• Are subprocessors involved?

If nobody knows, the organisation has to reconstruct the answers. That work consumes procurement, IT, security, legal, compliance, operations and audit resources.

The cost is often delayed rather than immediate. It appears during a customer questionnaire, internal audit, supplier review, contract renewal, incident investigation or regulatory enquiry.

An audit trail is only as reliable as the judgment of the people who created the record it depends on. Training that judgment upfront is consistently cheaper than reconstructing it after the fact, and that holds for all five of these costs.

The supplier problem companies often miss

There is a third door through which Shadow AI enters an organisation. The supplier.

An employee may never use an unauthorised AI tool. The company can still be exposed if a supplier, contractor or service provider uses AI behind the scenes. For example, a supplier might use AI to:

• analyse customer support interactions;
• summarise documents;
• forecast demand;
• process recruitment information;
• review contracts;
• classify incidents;
• generate reports;
• provide analytics.

From the buying organisation’s perspective, the service may look unchanged. The technology underneath it may not be.

That means procurement’s AI inventory cannot stop at software purchased directly by the organisation. Supplier due diligence needs to ask where AI is used in service delivery and what controls apply. Useful questions include:

• Where is AI used in delivering the service?
• Which models and subprocessors are involved?
• Is customer data used for training, tuning or product improvement?
• How is customer information separated from other customers?
• What are the retention and deletion periods?
• Are prompts and outputs logged?
• How are material model or subprocessor changes communicated?
• What human review exists for consequential decisions?
• How are model failures handled?
• What audit evidence can the supplier provide?
• What happens to data when the contract ends?
• Can the organisation opt out of newly introduced AI features?

This changes the procurement question from: “Does this supplier use AI?” to: “Where does AI participate in the service we are buying, and what controls govern that use?” Asking that question well is itself a trained skill. Procurement staff need to know which of these questions matter for a given contract and how to read the answer.

Three ways Shadow AI can appear in everyday work

Scenario 1: The AI-drafted RFP

A procurement employee asks a public AI tool to turn internal requirements into an RFP. The resulting document looks excellent.

But the prompt contained the project’s budget assumptions, technical requirements, timeline and internal evaluation criteria. The organisation has potentially exposed commercially sensitive information while losing control over the generation process.

A trained employee would use an approved enterprise environment, defined data rules, an approved template and human review before the document is released, not because a policy says so, but because they know why each step matters.

Scenario 2: The AI-ranked suppliers

A category manager uploads supplier responses and asks an AI system to rank them. The tool produces a neat table and a clear winner.

But the model may have interpreted the scoring criteria incorrectly, relied on incomplete information, introduced an undocumented weighting, overlooked a qualification, or reproduced bias in the underlying material.

A trained category manager uses AI to support extraction and comparison while keeping the scoring framework, validation and final recommendation under human control, because they have been shown exactly where AI output tends to go wrong in a supplier ranking.

Scenario 3: The AI forecast

An operations manager exports historical demand data and asks a consumer AI service to generate an inventory forecast. The forecast is then copied into the ERP. Nobody records the assumptions behind it.

The model may not understand seasonal patterns, supplier lead times, minimum order quantities or operational constraints. If the forecast goes wrong, the organisation may not even be able to reconstruct why.

A trained operations manager defines the data pipeline, assumptions, exception thresholds, human approval and monitoring before the output influences material inventory decisions, because they have practiced that workflow before it mattered.

All three scenarios share the same failure point: the employee had access to an AI tool but no training on how to use it inside that specific workflow. General AI awareness would not have prevented any of them. What would have is training built around your organisation’s actual RFP process, actual scoring criteria and actual forecasting inputs.

Why banning AI does not solve the problem

A prohibition can be appropriate for particular data, tools or high-risk uses. But a blanket ban does not necessarily remove the underlying work problem.

Consider what happens when:

1. An employee has a genuine productivity problem.
2. The approved route is slow, unclear or unavailable.
3. The employee discovers a faster AI tool.
4. The organisation bans that tool.
5. The underlying task remains.
6. The employee finds another route.

The organisation may have removed the visible tool without removing the use case. In some cases, it may also have made the use harder to discover.

A better approach starts with four questions:

• Is the work problem real?
• Is the approved tool usable?
• Does the employee understand which data can be used?
• Is there a fast process for requesting an exception or new AI use case?

If the answer to these questions is consistently no, uncontrolled adoption should not be surprising.

The practical alternative: controlled enablement

The answer is not “let everyone use whatever they want.” It is also not “ban AI.” It is controlled enablement. That means:

• discover current AI use;
• classify use cases by risk;
• provide approved tools;
• define clear data boundaries;
• create a usable exception process;
• train people on their actual workflows;
• require meaningful human review where decisions have material consequences;
• monitor adoption and incidents;
• revise controls as technology and workflows change.

This is where policy and training have to work together.

Build an approved tool list

An organisation can classify tools as: approved for specific tasks and data; approved with restrictions; pilot-only; prohibited for particular data; or under review.

Approval should not be treated as permanent. Tools change. Features change. Suppliers change. Data-processing terms change. The organisation therefore needs an owner and review process for material AI tools.

Define data boundaries

Employees need more than a statement saying “do not upload confidential information.” They need practical examples. For example:

• Public: information already approved for public release.
• Internal: ordinary operational information not intended for external sharing.
• Confidential: supplier pricing, contracts, forecasts and commercially sensitive information.
• Restricted: personal, regulated, privileged or strategically sensitive information.

Then tell employees what AI use is permitted for each category.

Create a usable exception process

If an employee discovers a valuable AI use case that is not currently approved, there should be a route to test it. The request can capture:

• the business problem;
• proposed tool;
• data involved;
• expected benefit;
• human-review point;
• relevant security, privacy and procurement checks;
• decision owner;
• review or expiry date.

The process needs to be practical enough that employees actually use it.

Train people on real workflows

This is where generic AI literacy reaches its limit. A procurement employee does not primarily need a lecture on every new AI model. They need to know how to use approved AI safely when drafting an RFP, analysing supplier responses, preparing for a negotiation or reviewing supplier performance.

An operations employee needs guidance on forecasting, reporting, inventory planning, incident analysis, workflow automation and exception handling. For organisations operating in or selling into the EU, this is no longer optional best practice: Article 4 of the EU AI Act now requires a baseline level of AI literacy training for staff who use AI systems at work.

A practical Shadow AI discovery checklist

Organisations trying to understand their actual exposure can start here:

• Ask employees which AI tools they use for work.
• Ask which browser extensions and AI features they have enabled.
• Review software, expense, browser, identity and network records where lawful and proportionate.
• Ask major suppliers where AI is used in service delivery.
• Map AI use by workflow, not only by department.
• Record what data is entered and what output is produced.
• Identify who reviews the output.
• Identify which business decision the output affects.
• Identify personal-account usage.
• Identify duplicate tools and overlapping licences.
• Flag workflows involving contracts, supplier pricing, personal data or forecasts.
• Assign an owner to every material AI use case.

The objective is not surveillance for its own sake. It is to replace assumptions with an actual picture of how AI is entering the organisation.

The discovery step matters even more where AI adoption is outpacing formal governance. KPMG’s 2025 Africa CEO Outlook survey found that integrating AI into core operations is now one of the top three challenges cited by African CEOs, named by 32% of respondents, ahead of most other operational pressures. Procurement and operations teams in these markets are frequently the ones absorbing that gap in practice, long before a governance policy catches up.

Calculate the cost instead of guessing it

A simple internal worksheet can expose where the problem is concentrated.

Frequently asked questions

What is the difference between Shadow AI and Shadow IT?

Shadow IT refers to unapproved software or hardware in general. Shadow AI is the specific case of AI tools, features, agents or AI-enabled supplier services operating without organisational visibility, approval or monitoring. It is harder to detect than Shadow IT because AI often lives inside a browser tab, a plugin, or a feature quietly added to software the organisation already approves.

How do I find out if my procurement or operations team is using unapproved AI tools?

Start with the discovery checklist above: ask employees directly which tools they use, review expense and browser data where lawful, and ask key suppliers where AI participates in service delivery. Most organisations find usage is broader than expected once they ask by workflow rather than by department.

Should we just ban AI tools in procurement to reduce risk?

A blanket ban rarely removes the underlying work problem, it just removes visibility into how employees solve it. A better approach is controlled enablement: approved tools, clear data boundaries, a fast exception process, and training staff on how to use AI safely inside their actual tasks.

What should procurement and operations staff never paste into a public AI tool?

Anything classified as confidential or restricted: supplier pricing, contract drafts, demand forecasts, negotiation positions, or personal data. Employees need concrete examples of what falls into each category, not just a generic instruction not to share confidential information.

How is Shadow AI risk different for African businesses?

The underlying risk is the same everywhere, but African organisations are frequently adopting AI faster than they are building governance around it. KPMG’s 2025 Africa CEO Outlook found that integrating AI into core operations is already a top-three challenge for African CEOs, which means procurement and operations teams are often the ones absorbing that gap in daily practice.

Can training actually reduce Shadow AI use, or does it just create awareness?

Training that focuses on real workflows, rather than generic AI literacy, is what changes behaviour. Employees adopt unapproved tools when the approved route is slow or the AI use case is unclear. Training that shows staff how to complete their actual tasks, such as drafting an RFP or reconciling a forecast, inside approved tools and data boundaries removes the reason to go around them.

Close the Shadow AI gap with trained teams, not just policy