"Shadow AI" is the LLM version of shadow IT: employees using AI tools through personal accounts, browser tabs, and unofficial scripts, outside any corporate visibility. It happens for the most ordinary reason imaginable: the tools help people do their jobs faster, and the official alternative is either missing or worse. Treating this purely as a discipline problem misreads it. It is a demand signal, and the organizations that handle it best respond with supply.
Why bans fail
A blanket ban has a poor track record for one structural reason: the banned behavior is invisible. Pasting a paragraph into a personal AI account leaves no trace in your systems. You cannot audit what you cannot see, so a ban converts visible, governable usage into invisible, ungovernable usage while leaving the underlying demand untouched. Worse, bans push usage toward the least controlled tools, since an employee already breaking policy has no reason to prefer a reputable service over whichever free tool ranks first in search results.
The real risks of shadow AI are concrete: sensitive text pasted into consumer tools with unknown retention, no record of what left the building, work quality dependent on unvetted outputs, and contractual or regulatory exposure nobody assessed. Notice that every one of these risks comes from the path, not from the underlying models. The same task, run through a sanctioned deployment inside your cloud with logging and access control, is a normal governed workload.
Make the sanctioned path the easy path
People switch when the approved option is at least as good as the workaround. For enterprises already on AWS, Google Cloud, or Azure, this is more attainable than it sounds, because Claude is available through all of them: Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and the Anthropic-operated Claude Platform on AWS. Procurement can run through the existing cloud relationship, identity and access ride on IAM roles, service accounts, or resource keys you already manage, and usage lands in audit logs your security team already watches.
A common rollout pattern has three tiers. First, an internal assistant: a simple chat interface backed by Claude on your cloud, available to every employee, so the general-purpose demand has a safe home. Second, an internal gateway for builders: one API door through which team applications call the model, giving you central logging, cost attribution, and a kill switch. Third, embedded use cases: the specific high-value workflows (support drafting, document summarization) built properly with review gates. The first tier is what actually drains the shadow usage; ship it early even if it is plain.
Pair the carrot with clear, narrow rules
A sanctioned path still needs a policy, but keep it short and specific. State what is allowed by default (most everyday text work through the approved tools), what needs review (customer personal data, regulated content), and the small set of things that are prohibited anywhere. Explain the why in one sentence per rule; people comply with rules they understand. Then say plainly that past shadow usage is amnestied, because a policy that starts by threatening retroactive punishment guarantees nobody tells you what tools they were using, and that inventory of existing shadow usage is the most valuable input to your rollout plan.
Enforcement, where you need it, should be mostly technical and mostly gentle: network controls that redirect known consumer AI endpoints to a page pointing at the internal tool work better than disciplinary memos, and they double as a discovery mechanism for demand you have not met yet.
A realistic 90-day arc
Month one: inventory demand (survey teams, check egress logs), pick your platform based on the cloud you already run, and stand up the internal assistant for a pilot group. Month two: open it to everyone, publish the one-page policy, and launch the gateway for builder teams. Month three: review what people actually use it for, promote the top two or three workflows into properly built features, and report conversion metrics to leadership. None of this requires ML specialists; it requires the same IT, security, and change-management muscles you already have.
Where to go next
The policy piece is covered in detail in Writing an Internal Acceptable-Use Policy for Claude, and the gateway pattern in The Internal AI Gateway Pattern. For picking the platform, start from the platforms overview.