Shadow AI Is a Process Problem: Why Employees Automate Around the Official Workflow
Shadow AI Is a Process Problem: Why Employees Automate Around the Official Workflow
Two-thirds of office professionals at large enterprises have used AI tools at work that they believed were not permitted. That figure comes from PagerDuty’s 2026 Shadow AI Survey, conducted among 1,250 non-IT office professionals at organisations with $500 million or more in annual revenue across Australia, Japan, the United Kingdom and the United States. Salesforce’s 2026 Workforce AI Survey puts employee AI use at work at 67%, against 18% of organisations holding a formal AI security policy.
The security industry has claimed this topic, and it frames the problem as a data-loss problem answered by detection, blocking and policy. That framing describes the symptom accurately. It describes the cause poorly.
People reach for an unsanctioned tool at the exact points where the official way of working is slow, undocumented, or absent. Shadow AI is the visible residue of a process gap. Treating it purely as a tooling violation moves the behaviour somewhere harder to see.
The scale, and what the numbers actually measure
The research is consistent enough to be treated as settled. Gartner’s November 2025 analysis, based on a survey of 302 cybersecurity leaders, found 69% of organisations already suspect or have evidence that employees use prohibited public generative AI tools, and predicts that by 2030 more than 40% of enterprises will experience a security or compliance incident linked to unauthorised shadow AI. ISACA’s 2026 figures put 25% of organisations at no active AI policy at all.
Gartner also expects 40% of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5% in 2025. That matters for a reason that is easy to miss. As AI capability arrives inside tools the enterprise has already bought, the line between sanctioned and unsanctioned use stops running between applications and starts running inside them. An employee using an approved SaaS product may be using an AI feature nobody assessed, on data nobody classified.
So the honest reading of the numbers is narrower than the headlines. They do not show that employees are reckless. They show that employee adoption moved faster than the organisation’s ability to describe how work should be done.
Blocking moves the behaviour
Enterprises that respond with prohibition tend to get three outcomes in sequence.
Usage moves to personal devices and personal accounts, where the organisation has no telemetry at all. The behaviour continues, and visibility falls.
The people most likely to comply are the people whose work was least affected. The people under the most operational pressure are the ones who find the workaround, which means the exposure concentrates in the busiest and often the most business-critical processes.
The organisation loses the diagnostic signal. A shadow AI incident is unwelcome, and it is also evidence: it tells you exactly which process was slow enough, opaque enough, or manual enough that someone was willing to take a risk to get around it. Prohibition removes the evidence without removing the condition that produced it.
None of this argues against policy. Policy is necessary and it is not sufficient. A rule that tells people what they may not do, in an environment where the sanctioned path remains slower than the shortcut, produces quiet non-compliance.
Where shadow AI starts
Across delivery engagements, the processes that attract unsanctioned automation share a small set of characteristics.
The official process is undocumented. Nobody can point at how the work is supposed to run, so there is no sanctioned path to follow. The employee invents one. When the invented path involves pasting a customer record into a public model, the organisation discovers its process gap through a security alert.
The official process is slower than the deadline. Approval chains designed for a different volume of work, handoffs that sit in inboxes, and steps that exist because of a system limitation that was removed years ago. People do not route around governance because they dislike governance. They route around latency.
The work is judgement-heavy and unsupported. Summarising a long document, classifying an ambiguous case, drafting a first version of something. These are the tasks where a general-purpose model feels immediately useful and where no internal tool was ever provided.
The process spans systems that do not talk to each other. Where the integration is missing, a human becomes the integration layer, and a human with an AI assistant becomes a faster integration layer. This is the same structural gap that produced the RPA bot estates many European enterprises are still maintaining, and the architecture relationship between RPA and BPM applies here without much modification.
Each of these is a process condition with a process remedy. None of them is fixed by a browser extension that blocks a domain.
The cost that is not data leakage
Data exposure is the risk that gets reported. Process divergence is the risk that compounds.
When a meaningful share of a process runs through tools and steps that are not in the process model, the model stops describing reality. The documented process and the executed process drift apart. Everything downstream of the model degrades with it: the training material is wrong, the audit evidence is incomplete, the improvement analysis is built on a flow nobody follows, and the automation project scoped against the documented process automates something that stopped happening two years ago.
This is the same failure pattern that shows up when process mining findings never reach execution. The organisation holds a description of its processes and a separate reality, and the gap between them is invisible until something forces a comparison.
Shadow AI widens that gap faster than manual workarounds did, because the output looks finished. A spreadsheet workaround announces itself as a workaround. A well-formatted AI-generated summary entering a case file does not.
The regulatory position has become specific
Two developments have moved this from good practice to documented obligation for European enterprises.
The EU AI Act’s Article 50 transparency obligations have applied since 2 August 2026, with Article 50(2) for systems already on the market, and the new prohibited practices, applying from 2 December 2026. High-risk obligations for stand-alone Annex III systems follow on 2 December 2027 after the Digital Omnibus deferral. The obligations attach to the enterprise as a deployer regardless of whether the deployment was approved internally. An AI system nobody sanctioned is still an AI system the enterprise is deploying. The deployer obligations and the compliance calendar are worth reading alongside this.
For financial entities, DORA has been directly applicable since January 2025, with MaRisk in German banking, DNB guidelines in the Netherlands, and BCBS 239 sitting above both. Each expects documented, traceable, end-to-end process governance. An organisation that cannot describe how a process runs cannot evidence that it is governed, and unsanctioned AI inside that process makes the description less accurate rather than more.
The practical consequence: the inventory a regulator expects is a process inventory before it is a tool inventory. Knowing which applications are in use answers a narrower question than knowing which processes contain automated decision-making and where a human reviews the output.
What to do at the process layer
The sequence that holds up is unglamorous and it starts before the tooling decision.
Find the processes, not the tools. Network telemetry tells you which applications are being reached. It does not tell you which business process the employee was inside when they reached for one. Ask the second question. The answer identifies the processes carrying the most latency, the least documentation, or the least support.
Treat each finding as a process defect. For every instance of unsanctioned use, establish what the sanctioned path was, how long it took, and why the shortcut was faster. That produces a prioritised list of processes worth fixing, ordered by demonstrated demand rather than by assumption.
Describe the process before automating it. A process that exists only as behaviour cannot be governed, improved, or evidenced. Modelling it in a standard notation is the step organisations defer and the one that determines whether anything else is achievable.
Define where AI is permitted inside the flow, at step level. A blanket organisational policy is too coarse to be useful. The operational version names the step, the permitted tool, the data class allowed at that step, the human review point, and what is retained. This is a process design decision expressed in the model, not a paragraph in a handbook.
Make the sanctioned path faster than the shortcut. This is the part that determines whether any of the preceding work holds. Where the approved route is quicker, better supported and produces a better result, compliance stops requiring enforcement. Where it is slower, the behaviour returns as soon as attention moves elsewhere.
Instrument it. The engine running the process should produce a retained, queryable record of what happened at each step, including which steps involved an automated component. That record is what converts a governance claim into evidence.
Explore our services for how discovery, design and automation delivery sequence in practice.
Where the tooling conversation belongs
Once the process work is done, the platform question becomes answerable, and it is genuinely scenario-dependent.
Enterprises with a mature modelling estate in ARIS or SAP Signavio already hold the description layer, and the gap is usually execution and consumption rather than modelling. Enterprises running Camunda 7 or Camunda 8 hold an execution layer that can carry the governed AI steps once the model defines them. Microsoft-estate organisations frequently find that Power Automate is simultaneously part of the sanctioned toolset and part of the sprawl, which is a governance design question rather than a product criticism. The relationship between AI components and the orchestration layer above them is covered in more depth in where AI agents sit in enterprise BPM.
Concordia BPM is DNA’s open, AI-powered BPM platform, built on open BPMN and DMN standards with a Java, Angular and PostgreSQL stack and a transparent monthly price. AI-guided process design and consumption sits inside the platform rather than beside it, which is the relevant property here: the sanctioned way to get an answer about a process is the same system that runs the process.
The general point holds regardless of platform. Any architecture where the process is described in a standard notation, executed by an engine that logs what it did, and consumable by the people who need answers, gives employees a sanctioned path worth using.
The conclusion the data supports
Shadow AI is widespread, it is growing, and prohibition has a poor record against it. The organisations that will handle the next two years well are the ones that read each incident as a signal about a process rather than a failure of individual judgement.
The question worth putting to an operations or transformation team is narrow. For the processes where unsanctioned AI use has appeared, can the organisation describe how the work is supposed to run, name who owns it, and show that the sanctioned path is faster than the workaround. Where the answer is yes, policy is enforceable. Where it is no, the policy is a statement of intent.
DNA works vendor-neutrally across ARIS, Camunda, ServiceNow, SAP Signavio and Power Automate, and recommends what is best for the client rather than what is licensed.
Book a meeting to discuss where unsanctioned automation is appearing in your process estate.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
Two-thirds of office professionals at large enterprises have used AI tools at work that they believed were not permitted. That figure comes from PagerDuty’s 2026 Shadow AI Survey, conducted among 1,250 non-IT office professionals at organisations with $500 million or more in annual revenue across Australia, Japan, the United Kingdom and the United States. Salesforce’s 2026 Workforce AI Survey puts employee AI use at work at 67%, against 18% of organisations holding a formal AI security policy.
The security industry has claimed this topic, and it frames the problem as a data-loss problem answered by detection, blocking and policy. That framing describes the symptom accurately. It describes the cause poorly.
People reach for an unsanctioned tool at the exact points where the official way of working is slow, undocumented, or absent. Shadow AI is the visible residue of a process gap. Treating it purely as a tooling violation moves the behaviour somewhere harder to see.
The scale, and what the numbers actually measure
The research is consistent enough to be treated as settled. Gartner’s November 2025 analysis, based on a survey of 302 cybersecurity leaders, found 69% of organisations already suspect or have evidence that employees use prohibited public generative AI tools, and predicts that by 2030 more than 40% of enterprises will experience a security or compliance incident linked to unauthorised shadow AI. ISACA’s 2026 figures put 25% of organisations at no active AI policy at all.
Gartner also expects 40% of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5% in 2025. That matters for a reason that is easy to miss. As AI capability arrives inside tools the enterprise has already bought, the line between sanctioned and unsanctioned use stops running between applications and starts running inside them. An employee using an approved SaaS product may be using an AI feature nobody assessed, on data nobody classified.
So the honest reading of the numbers is narrower than the headlines. They do not show that employees are reckless. They show that employee adoption moved faster than the organisation’s ability to describe how work should be done.
Blocking moves the behaviour
Enterprises that respond with prohibition tend to get three outcomes in sequence.
Usage moves to personal devices and personal accounts, where the organisation has no telemetry at all. The behaviour continues, and visibility falls.
The people most likely to comply are the people whose work was least affected. The people under the most operational pressure are the ones who find the workaround, which means the exposure concentrates in the busiest and often the most business-critical processes.
The organisation loses the diagnostic signal. A shadow AI incident is unwelcome, and it is also evidence: it tells you exactly which process was slow enough, opaque enough, or manual enough that someone was willing to take a risk to get around it. Prohibition removes the evidence without removing the condition that produced it.
None of this argues against policy. Policy is necessary and it is not sufficient. A rule that tells people what they may not do, in an environment where the sanctioned path remains slower than the shortcut, produces quiet non-compliance.
Where shadow AI starts
Across delivery engagements, the processes that attract unsanctioned automation share a small set of characteristics.
The official process is undocumented. Nobody can point at how the work is supposed to run, so there is no sanctioned path to follow. The employee invents one. When the invented path involves pasting a customer record into a public model, the organisation discovers its process gap through a security alert.
The official process is slower than the deadline. Approval chains designed for a different volume of work, handoffs that sit in inboxes, and steps that exist because of a system limitation that was removed years ago. People do not route around governance because they dislike governance. They route around latency.
The work is judgement-heavy and unsupported. Summarising a long document, classifying an ambiguous case, drafting a first version of something. These are the tasks where a general-purpose model feels immediately useful and where no internal tool was ever provided.
The process spans systems that do not talk to each other. Where the integration is missing, a human becomes the integration layer, and a human with an AI assistant becomes a faster integration layer. This is the same structural gap that produced the RPA bot estates many European enterprises are still maintaining, and the architecture relationship between RPA and BPM applies here without much modification.
Each of these is a process condition with a process remedy. None of them is fixed by a browser extension that blocks a domain.
The cost that is not data leakage
Data exposure is the risk that gets reported. Process divergence is the risk that compounds.
When a meaningful share of a process runs through tools and steps that are not in the process model, the model stops describing reality. The documented process and the executed process drift apart. Everything downstream of the model degrades with it: the training material is wrong, the audit evidence is incomplete, the improvement analysis is built on a flow nobody follows, and the automation project scoped against the documented process automates something that stopped happening two years ago.
This is the same failure pattern that shows up when process mining findings never reach execution. The organisation holds a description of its processes and a separate reality, and the gap between them is invisible until something forces a comparison.
Shadow AI widens that gap faster than manual workarounds did, because the output looks finished. A spreadsheet workaround announces itself as a workaround. A well-formatted AI-generated summary entering a case file does not.
The regulatory position has become specific
Two developments have moved this from good practice to documented obligation for European enterprises.
The EU AI Act’s Article 50 transparency obligations have applied since 2 August 2026, with Article 50(2) for systems already on the market, and the new prohibited practices, applying from 2 December 2026. High-risk obligations for stand-alone Annex III systems follow on 2 December 2027 after the Digital Omnibus deferral. The obligations attach to the enterprise as a deployer regardless of whether the deployment was approved internally. An AI system nobody sanctioned is still an AI system the enterprise is deploying. The deployer obligations and the compliance calendar are worth reading alongside this.
For financial entities, DORA has been directly applicable since January 2025, with MaRisk in German banking, DNB guidelines in the Netherlands, and BCBS 239 sitting above both. Each expects documented, traceable, end-to-end process governance. An organisation that cannot describe how a process runs cannot evidence that it is governed, and unsanctioned AI inside that process makes the description less accurate rather than more.
The practical consequence: the inventory a regulator expects is a process inventory before it is a tool inventory. Knowing which applications are in use answers a narrower question than knowing which processes contain automated decision-making and where a human reviews the output.
What to do at the process layer
The sequence that holds up is unglamorous and it starts before the tooling decision.
Find the processes, not the tools. Network telemetry tells you which applications are being reached. It does not tell you which business process the employee was inside when they reached for one. Ask the second question. The answer identifies the processes carrying the most latency, the least documentation, or the least support.
Treat each finding as a process defect. For every instance of unsanctioned use, establish what the sanctioned path was, how long it took, and why the shortcut was faster. That produces a prioritised list of processes worth fixing, ordered by demonstrated demand rather than by assumption.
Describe the process before automating it. A process that exists only as behaviour cannot be governed, improved, or evidenced. Modelling it in a standard notation is the step organisations defer and the one that determines whether anything else is achievable.
Define where AI is permitted inside the flow, at step level. A blanket organisational policy is too coarse to be useful. The operational version names the step, the permitted tool, the data class allowed at that step, the human review point, and what is retained. This is a process design decision expressed in the model, not a paragraph in a handbook.
Make the sanctioned path faster than the shortcut. This is the part that determines whether any of the preceding work holds. Where the approved route is quicker, better supported and produces a better result, compliance stops requiring enforcement. Where it is slower, the behaviour returns as soon as attention moves elsewhere.
Instrument it. The engine running the process should produce a retained, queryable record of what happened at each step, including which steps involved an automated component. That record is what converts a governance claim into evidence.
Explore our services for how discovery, design and automation delivery sequence in practice.
Where the tooling conversation belongs
Once the process work is done, the platform question becomes answerable, and it is genuinely scenario-dependent.
Enterprises with a mature modelling estate in ARIS or SAP Signavio already hold the description layer, and the gap is usually execution and consumption rather than modelling. Enterprises running Camunda 7 or Camunda 8 hold an execution layer that can carry the governed AI steps once the model defines them. Microsoft-estate organisations frequently find that Power Automate is simultaneously part of the sanctioned toolset and part of the sprawl, which is a governance design question rather than a product criticism. The relationship between AI components and the orchestration layer above them is covered in more depth in where AI agents sit in enterprise BPM.
Concordia BPM is DNA’s open, AI-powered BPM platform, built on open BPMN and DMN standards with a Java, Angular and PostgreSQL stack and a transparent monthly price. AI-guided process design and consumption sits inside the platform rather than beside it, which is the relevant property here: the sanctioned way to get an answer about a process is the same system that runs the process.
The general point holds regardless of platform. Any architecture where the process is described in a standard notation, executed by an engine that logs what it did, and consumable by the people who need answers, gives employees a sanctioned path worth using.
The conclusion the data supports
Shadow AI is widespread, it is growing, and prohibition has a poor record against it. The organisations that will handle the next two years well are the ones that read each incident as a signal about a process rather than a failure of individual judgement.
The question worth putting to an operations or transformation team is narrow. For the processes where unsanctioned AI use has appeared, can the organisation describe how the work is supposed to run, name who owns it, and show that the sanctioned path is faster than the workaround. Where the answer is yes, policy is enforceable. Where it is no, the policy is a statement of intent.
DNA works vendor-neutrally across ARIS, Camunda, ServiceNow, SAP Signavio and Power Automate, and recommends what is best for the client rather than what is licensed.
Book a meeting to discuss where unsanctioned automation is appearing in your process estate.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
Written by:
Ante Gudelj
Managing Partner
Share with friends:
What is shadow AI?
Shadow AI is the use of AI tools that the organisation has not sanctioned, assessed, or in some cases detected. It covers public generative AI tools accessed through personal accounts, unvetted browser extensions and AI features inside approved software that were never assessed. It is the AI-era successor to shadow IT, with a different risk profile because the tools process and generate from the data rather than only storing or transmitting it.
How common is shadow AI in large enterprises?
PagerDuty’s 2026 Shadow AI Survey of 1,250 office professionals at organisations with $500 million or more in revenue found 66% had used AI tools at work they believed were not permitted. Salesforce’s 2026 Workforce AI Survey found 67% of employees use AI tools at work while 18% of organisations have a formal AI security policy. Gartner’s 2025 survey of 302 cybersecurity leaders found 69% of organisations suspect or have evidence of prohibited public generative AI use.
Does blocking AI tools solve shadow AI?
Rarely on its own. Prohibition tends to move usage to personal devices and personal accounts, where the organisation has less visibility than before. It also removes the diagnostic signal that identifies which processes were slow or undocumented enough to make the workaround worth the risk. Policy is necessary, and it holds only where the sanctioned path is faster than the shortcut.
Is shadow AI a compliance risk under the EU AI Act?
It can be. Deployer obligations under the AI Act attach to the enterprise regardless of whether a deployment was internally approved. Article 50 transparency obligations have applied since 2 August 2026, with further obligations following in December 2026 and December 2027. An enterprise that cannot inventory where automated decision-making sits inside its processes cannot demonstrate that those obligations are met.
Why is shadow AI described as a process problem rather than a security problem?
Because the conditions that produce it are process conditions: undocumented workflows, approval latency, judgement-heavy steps with no supported tool, and missing integration between systems. Security controls detect the behaviour. Process work removes the reason for it. Both are needed, and only one of them addresses the cause.
What is shadow AI?
Shadow AI is the use of AI tools that the organisation has not sanctioned, assessed, or in some cases detected. It covers public generative AI tools accessed through personal accounts, unvetted browser extensions and AI features inside approved software that were never assessed. It is the AI-era successor to shadow IT, with a different risk profile because the tools process and generate from the data rather than only storing or transmitting it.
How common is shadow AI in large enterprises?
PagerDuty’s 2026 Shadow AI Survey of 1,250 office professionals at organisations with $500 million or more in revenue found 66% had used AI tools at work they believed were not permitted. Salesforce’s 2026 Workforce AI Survey found 67% of employees use AI tools at work while 18% of organisations have a formal AI security policy. Gartner’s 2025 survey of 302 cybersecurity leaders found 69% of organisations suspect or have evidence of prohibited public generative AI use.
Does blocking AI tools solve shadow AI?
Rarely on its own. Prohibition tends to move usage to personal devices and personal accounts, where the organisation has less visibility than before. It also removes the diagnostic signal that identifies which processes were slow or undocumented enough to make the workaround worth the risk. Policy is necessary, and it holds only where the sanctioned path is faster than the shortcut.
Is shadow AI a compliance risk under the EU AI Act?
It can be. Deployer obligations under the AI Act attach to the enterprise regardless of whether a deployment was internally approved. Article 50 transparency obligations have applied since 2 August 2026, with further obligations following in December 2026 and December 2027. An enterprise that cannot inventory where automated decision-making sits inside its processes cannot demonstrate that those obligations are met.
Why is shadow AI described as a process problem rather than a security problem?
Because the conditions that produce it are process conditions: undocumented workflows, approval latency, judgement-heavy steps with no supported tool, and missing integration between systems. Security controls detect the behaviour. Process work removes the reason for it. Both are needed, and only one of them addresses the cause.
What is shadow AI?
Shadow AI is the use of AI tools that the organisation has not sanctioned, assessed, or in some cases detected. It covers public generative AI tools accessed through personal accounts, unvetted browser extensions and AI features inside approved software that were never assessed. It is the AI-era successor to shadow IT, with a different risk profile because the tools process and generate from the data rather than only storing or transmitting it.
How common is shadow AI in large enterprises?
PagerDuty’s 2026 Shadow AI Survey of 1,250 office professionals at organisations with $500 million or more in revenue found 66% had used AI tools at work they believed were not permitted. Salesforce’s 2026 Workforce AI Survey found 67% of employees use AI tools at work while 18% of organisations have a formal AI security policy. Gartner’s 2025 survey of 302 cybersecurity leaders found 69% of organisations suspect or have evidence of prohibited public generative AI use.
Does blocking AI tools solve shadow AI?
Rarely on its own. Prohibition tends to move usage to personal devices and personal accounts, where the organisation has less visibility than before. It also removes the diagnostic signal that identifies which processes were slow or undocumented enough to make the workaround worth the risk. Policy is necessary, and it holds only where the sanctioned path is faster than the shortcut.
Is shadow AI a compliance risk under the EU AI Act?
It can be. Deployer obligations under the AI Act attach to the enterprise regardless of whether a deployment was internally approved. Article 50 transparency obligations have applied since 2 August 2026, with further obligations following in December 2026 and December 2027. An enterprise that cannot inventory where automated decision-making sits inside its processes cannot demonstrate that those obligations are met.
Why is shadow AI described as a process problem rather than a security problem?
Because the conditions that produce it are process conditions: undocumented workflows, approval latency, judgement-heavy steps with no supported tool, and missing integration between systems. Security controls detect the behaviour. Process work removes the reason for it. Both are needed, and only one of them addresses the cause.