Renato Salvadori, CISSP, shares his views on why artificial intelligence (AI) acceptable use policies and awareness alone are not sufficient to address shadow AI, and how organizations can connect governance, data classification, technical controls, monitoring and secure alternatives to turn AI awareness into operational security.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
In recent years, a question has started to appear frequently in the security assessments I conduct for clients: "Do you have any policies for the use of generative AI?" In an even more worrying scenario, it is the clients themselves who ask me: "How are other companies facing this challenge?"
The situation changes from organization to organization – some already have an AI Acceptable Use Policy, others don't even know that employees already use ChatGPT and Copilot on a daily basis. But there is a pattern that catches my attention: when the policy exists, it is easy to confuse its existence with actual control. The document is published, the “I read and agree” has been recorded and the AI risk appears as addressed in a compliance spreadsheet. But what happens when someone pastes a contract into a public AI tool to “quickly summarize”?
Enter Shadow AI
That's where shadow AI comes in: the use of AI tools (in the browser, in extensions, embedded in SaaS, in APIs) without the knowledge or visibility of those responsible for governance and security. Unlike what we traditionally teach in awareness programs, there is no need for a malicious agent on the other side: there is no phishing or social engineering. The user, solving a legitimate task, creates a flow of data outside the controlled environment. The behavior seems perfectly normal to those who practice it: the analyst does not believe he is leaking data; he is summarizing a contract.
Why Awareness Alone Isn't Enough
Therefore, treating shadow AI only as an awareness problem is insufficient. We are not trying to prevent a malicious action, but to control the risk of a legitimate use, in an environment where the organization does not yet see this use.
The most common policy guidance seems reasonable: "do not send confidential information to unapproved AI tools." The problem lies in the assumptions necessary for it to function as a control: first, that the user recognizes the classification of the information when he shares it; second, more seriously, that there is some control capable of detecting or preventing the action if he does not recognize the risk – or decides to proceed anyway.
In most environments, policy ends right where the mouse click begins – and the organization has shifted all responsibility for a flow of data that should be part of its security architecture to a human decision.
This does not take away the responsibility of the user. It recognizes only a basic security premise: people make mistakes and tend to choose the fastest way. An AI acceptable use policy should be understood, then, as a layer of control – not as the only control. If it is only a layer, the question ceases to be "do we have an AI policy?" and becomes: “what technically happens when this policy is not followed?”
The Temptation to Block
There's a natural temptation, after describing this picture, to close with the most obvious recipe: blocking. Restricting access to unapproved AI tools, blocking access through the proxy, removing extensions, treating the problem as if it were phishing – something to be eliminated from the environment. I've seen organizations make exactly this decision and the result is usually predictable: usage doesn't disappear, it just loses visibility.
If an analyst has a task to complete by the end of the day and the approved enterprise tool doesn't exist, is slow, or requires a request process that takes weeks, they're not going to stop using AI. They're going to use their personal phone, a personal account, a network other than their corporate one. The behavior isn't eliminated – it's shifted beyond the reach of any control the organization has built. Blocking without providing an alternative doesn't solve the risk, it just makes it invisible again – the same condition that created shadow AI in the first place.
From Saying No to Offering a Path
This changes the question that security needs to ask. It’s not "how do we prevent the use of AI," but "what are we offering to those who need AI to do the job." If the answer is "nothing," or "an approval process that no one follows," the policy won’t compete with the convenience of a browser tab opened in seconds.
A secure alternative doesn't have to be sophisticated to work – it needs to be good enough to make it worth using rather than bypassing control. And let's face it, avoiding workarounds is already a familiar difficulty for security teams. That could mean an enterprise AI environment with contractual guarantees on data usage. Or, a gateway that brokers access to public models by applying classification and masking before submission. It could simply be a clear, up-to-date list of approved tools by data type, with a quick path to request evaluation of a new one. The specific solution matters less than when it arrives: it needs to exist before the organization tightens control, not after.
In fact, this is also a change in posture for those who work with security. Restricting is usually among the first responses to a new risk. Let's make this mea culpa here. With generative AI, this logic needs to be reversed, that is, the sooner security is positioned as part of the solution – offering a path, not just a barrier – the less pressure users will feel to find a workaround on their own. Security that only says no is not reducing risk; it is just postponing the moment when it appears in a less visible way, those familiar workarounds, created by users themselves.
Connecting the Layers
The way, then, is not to choose between awareness and technical control – it is to connect the two. The two actions need to go together, pari passu. That is, policies, standards and procedures translate expected behavior into applicable guidelines; governance establishes which uses are acceptable; classification determines what information can be processed and under what conditions; technical controls apply these decisions in the environment; monitoring allows you to see if what is happening in practice corresponds to what has been defined.
However, as a consequence, this also means abandoning the idea of controlling AI through a simple list of allowed or prohibited tools. The same tool can pose completely different risks depending on the use case, the type of information involved, the account used, and the conditions under which the data is processed. The goal is not to govern tools — it is to govern how AI is used and what data can be part of that process.
When these layers work together, awareness is no longer the only line of defense. The user remains an essential part of the security model, but their eventual error is no longer the only barrier between sensitive information and an external service or context.
The Real Test
In the end, perhaps the simplest test to know if an organization has transformed awareness into operational security is to go back to the example from the beginning. When an employee needs to summarize that contract, the answer should not depend only on him remembering a rule saying where he cannot put it. Perhaps the correct question is another: does he know where he can perform the task and what information he can use to do so? And, on the other hand, does the organization have controls capable of keeping him on this path, without reducing his operational capacity?
Therefore, policies for the acceptable use of AI are still necessary, without a doubt. And not policies alone: standards and operating procedures are also necessary. Awareness, ditto. But none of them should carry the responsibility alone for decisions that happen hundreds or thousands of times in the environment every day.
The policy tells users what they should do. Operational security is what the organization is prepared to do when they do something else.
Renato Salvadori, CISSP, is a cybersecurity consultant and professor specializing in security assessments, governance, and data privacy.
.png?h=420&iar=0&w=420)
