A consultant is preparing a deliverable. The deadline is close, the material is incomplete, and an AI assistant could help structure the work and challenge assumptions. The technical step is easy: open an application and ask a question.
The professional decision is harder. Is this account approved? Is the information suitable for that service? Does the client's permission cover this use? Can the assistant only suggest text, or can it read files and take actions? Who checks the result?
CloudNala's view is that most shadow AI in professional services is a governance design problem before it becomes a disciplinary one. It appears where the organisation expects AI-enabled speed but has not made the permitted route clear, quick or usable, so the person doing the work ends up designing the controls themselves at the moment of delivery. Deliberate misuse still needs consequences. Ambiguous use needs the system repaired.
About the example. Amandla Retail Group is a fictional multi-brand retailer, and the consulting team, people, deadlines and outcomes below are invented teaching scenarios. They are not disguised accounts of any real engagement or anyone's conduct. Claude Code, ChatGPT, GitHub Copilot, Microsoft 365 Copilot, Microsoft Foundry, Amazon Bedrock and LiteLLM are real product names used to make the patterns concrete. Nothing here is a claim about any product's current terms, approval status, configuration or performance; check those against the deployed product and the current agreement.
What shadow AI actually looks like
For this article, shadow AI means work-related generative or agentic AI use where approval, oversight or permitted use is absent, unclear or incomplete. The definition deliberately includes uncertainty. It does not, by itself, establish that a policy was breached.
The usual picture is an employee secretly signing up for a chatbot. In consulting and transformation work, it more often looks like this:
- an approved product used through a personal rather than a managed account;
- an AI feature that appears inside software the organisation already licenses, after an update;
- a coding assistant used on a repository it was never approved for;
- a "generic" description of a client problem that still carries enough detail to identify the engagement;
- an agent given broader tool access than the policy anticipated.
None of these involves hiding anything or bypassing a control. All of them leave a question that nobody has answered. The useful unit of analysis is therefore one specific use. "We use AI for productivity" tells you nothing about the information involved, the alternatives considered or the decision made.
Available, approved and suitable are different decisions
AI governance becomes clearer when three questions are kept apart.
Is the capability available? The person can open it, install it or switch it on.
Is it approved? The accountable organisation has accepted defined uses under stated conditions.
Is it suitable for this task? The specific account, information, tools, permissions, review and evidence meet the needs of this use.
A yes to one does not answer the others. Microsoft 365 Copilot may be approved in a tenant while a particular use is still inappropriate because the user can reach far more files than the task needs. GitHub Copilot may be licensed while generated code still needs testing, security review and licence awareness. Claude Code may be a sensible tool for a clean local prototype and still not be authorised to touch a client's repository. A managed model platform such as Microsoft Foundry or Amazon Bedrock can provide enterprise controls while the agent built on top of it is given unsafe permissions.
Product procurement is one layer of governance. Use-case governance is the layer where the work actually happens.
Approval has eight parts
An organisation can approve a product while restricting a particular account, dataset, integration or action. A consultant can hold their own firm's permission and still need to establish the client's.
| Boundary | Practical question | Example of uncertainty |
|---|---|---|
| Product and feature | Is this application or feature permitted? | A new AI feature appears inside an existing application. |
| Account | Which account and workspace may be used? | A personal subscription is available, but only a managed account has been assessed. |
| Information | What information may enter the service? | A seemingly generic description contains distinctive operational details. |
| Task | What may the assistant help with? | Drafting generic questions is covered; evaluating client documents is not addressed. |
| Access | Which files, repositories or services may it reach? | A connector could expose more content than the immediate task needs. |
| Action | What may it do beyond producing suggestions? | An agent can edit files or open a pull request. |
| Review | Who checks and accepts the result? | A fluent recommendation reaches a workshop without technical validation. |
| Engagement | Whose permission governs this work? | The consulting firm's guidance and the client's instructions differ. |
Each of these needs an answer for the actual use. A familiar brand name cannot supply it.
Case one: a first draft under unclear guidance
The requirement
A small consulting team is helping Amandla Retail Group modernise its digital platforms. Stakeholders have agreed the business outcomes. The delivery team now needs something it can build from: a first-pass architecture description, a component view, implementation tasks, acceptance criteria and a test approach, inside a delivery window shorter than the normal drafting cycle.
The hard part is still human work: deciding what matters, understanding constraints, choosing boundaries and judging risk. Much of the rest is translation of ideas the architect already understands into several formats: a Markdown specification, diagrams as code, a task breakdown and a review checklist. That translation is where an AI assistant looks attractive.
The capability and the uncertainty
The architect has Claude Code on a personal development account. It can read a local folder the architect controls, propose Markdown, generate diagram code, restructure requirements, suggest tests and point out inconsistencies across files.
The client has a clear general rule: confidential information must not go into unapproved external services. It has no accessible guidance on synthetic reconstructions, or on local AI-assisted drafting that never touches client systems. The team is expected to deliver at an "AI-enabled" pace.
At that point the architect knows four things with different levels of confidence:
- Client confidential information, personal information, credentials and production data must not enter an unapproved service. That boundary is clear.
- They are accountable for the deliverable. AI output cannot be treated as authoritative.
- Having access to a tool does not make it approved for client work.
- Whether using the tool on a fully synthetic reconstruction, purely for a private first draft, is inside or outside the applicable policy has no clear answer.
The alternatives
The architect could write everything manually, use standard templates, ask a colleague, ask for more time, wait for written approval, look for an approved enterprise assistant, shrink the first draft, or do the first pass by hand and bring AI in later. None of these is impossible. Each costs time, someone else's capacity or breadth of output.
The sequence
- Identify the decisions and artefacts the team needs.
- Separate the underlying pattern from the client-specific facts.
- Write a synthetic problem statement with fictional names, generic components and invented data. No client documents or code are copied.
- Put only that material in a clean local workspace.
- Ask Claude Code for a draft specification, component view, tasks, risks, acceptance criteria and test ideas.
- Review the result for invented assumptions, insecure patterns, gaps and contradictions.
- Check technical claims against product documentation where needed.
- Discard anything that depends on facts the tool could not know.
- Rebuild the useful structure in the client's approved environment and add the real facts by hand.
- Submit the final artefact through the normal review process as the architect's own work.
The tool never receives credentials, client code, personal information or production data. It does not connect to client systems, open a pull request, send a message or deploy anything.
Why it seemed reasonable
The task was partly generative and repetitive, the input could be made synthetic, and the output was disposable. The architect also believed the risk was reduced by data minimisation, an isolated workspace, no external actions and expert review. Their working rule was narrower than "the tool is allowed": I may use it only if I can remove the client context, constrain the task, prevent external action and verify the result independently.
That is a careful rule. It is also self-authored governance. An individual may not know every contractual, licensing, retention, residency or intellectual property constraint that applies, and good intentions do not replace an organisational decision. Removing the client's name does not necessarily remove what identifies the engagement, either: an unusual combination of systems, volumes or constraints can do that on its own.
What happened
The draft was faster and better structured, and the tool surfaced questions that improved the human review: failure paths, access boundaries, logging, test evidence and rollback. Some suggestions assumed integrations or practices that had not been established and were rejected. No measured time saving is claimed.
No confidentiality or security problem is known to have resulted. That does not show the decision was risk-free, or that the account and use were permitted. The absence of an observed problem and the adequacy of the control are different questions.
The less visible consequence is governance debt. The use was not hidden, but there was also no mechanism to record it, so it never entered any inventory. The organisation could not learn from it, compare it with similar uses or turn it into an approved workflow. A successful unrecorded experiment tends to reinforce shadow use: the person sees the benefit, and the organisation sees neither the benefit nor the residual risk.
What the architect would change
The technical controls were sensible, and the architect would use them again inside a declared, approved sandbox. The governance step is what changes. Before starting, they would record the intended use, information class, account type, tool and output path, and if no rule covered it, ask the accountable owner for a quick decision. They would also keep evidence of the checks made on the output.
Case two: the boundary is visible
Later in the same fictional engagement, the architect needs to analyse an internal design and prepare implementation guidance. This time the work depends on internal system relationships, code and operational detail. Abstracting those away would defeat the purpose, so a synthetic reconstruction is not an option.
The architect does not use a personal or public AI account. The client has approved GitHub Copilot for a defined set of repositories and Microsoft 365 Copilot for documents already governed in its tenant, and the engagement owner has confirmed that this work is in scope. The architect checks that before starting, uses the approved tools only within that scope and does everything outside it manually inside the agreed environment.
The decision felt different because the boundary was visible: the tool, account, data location, access controls and review route were known. The approved route was less flexible than the personal tool, but it removed the uncertainty and left a trail a reviewer could follow. The architect did not have to invent a governance model while trying to meet a deadline.
The output still needed checking against the source material. Approved does not mean correct, secure or fit for purpose. It means the organisation has accepted a defined use under stated controls.
| Dimension | Case one: first draft | Case two: internal design review |
|---|---|---|
| Information | Newly written synthetic reconstruction | Real internal documents and code |
| Tool and account | Claude Code on a personal account | GitHub Copilot and Microsoft 365 Copilot, client-approved |
| Permission | Not resolved before use | Stated scope, checked before use |
| Why AI | Translation between formats, surfacing gaps | Assistance inside work that needs the real context |
| Work outside AI | Final artefact rebuilt by hand in the client environment | Anything outside the approved scope done manually |
| Remaining limitation | Permission and residual identification uncertainty | Output quality still needs checking |
Why careful professionals still choose the ambiguous path
People use shadow AI for reasons that are understandable even when the decision is not approved.
The task is real and immediate. The deadline belongs to the delivery team. Waiting for governance is felt as delivery risk, while platform risk feels distant.
The approved tool does not match the work. An organisation may approve a chat interface while the work needs repository-aware editing, terminal access or structured tool calls. People then compare a governed but limited route with an ungoverned but effective one.
The policy names prohibited data but not permitted work. "Do not upload confidential information" is necessary and incomplete. It does not say whether synthetic examples, public information, boilerplate code, meeting summaries, architecture patterns or generated test data are allowed.
AI arrives embedded. A feature appears in an IDE, CRM, browser, meeting platform or design tool after an update. Nobody experiences that as adopting a new system.
The organisation rewards the output. Leaders celebrate AI-enabled delivery without funding a usable governed platform, and the individual is left to reconcile speed, quality and policy.
The action feels reversible. A draft can be deleted. That may be true for the workflow while retention, telemetry and contractual questions remain.
One test cuts through most of these. Could I explain this method openly to a reviewer, now, before anyone asks? If a use can only continue as long as nobody notices, that is a warning sign. If it could be explained but there is nowhere to record it, that is a gap in the governance system.
The control boundary is the whole system, not the model
The model is one component. The same model is low risk drafting from synthetic data and high risk once it is connected to a customer database, a mailbox or a deployment pipeline. A meaningful review looks at the full path.
| Control area | Questions to answer |
|---|---|
| Identity | Personal or enterprise-managed account? Is use attributable? |
| Information | What classification enters prompts, files, retrieval or memory? Is minimisation applied? |
| Model | Which provider, model and deployment process the request, under which terms? |
| Retrieval | Which repositories, drives, databases or vector stores can be searched? |
| Tools | Can it send email, change code, query a database, create a ticket or deploy infrastructure? |
| Permissions | Does the agent inherit the user's broad access, or get a scoped identity? |
| Memory | What state is kept, for how long, under which user or thread? |
| Output | Is the result advice, a draft, a decision or an executed action? |
| Review | Which steps need a qualified human? What may be auto-approved? |
| Evidence | Are prompts, tool calls, tests, approvals and outcomes recorded proportionately? |
| Operations | How are incidents, drift, cost, abuse and failure detected? |
This view explains how an approved model can still produce shadow behaviour. A team uses the approved model but connects an unapproved MCP server. It builds an agent on a managed platform but gives it an over-privileged identity. It routes every call through a gateway such as LiteLLM and assumes that makes every downstream use approved. It uses GitHub Copilot in an approved repository and merges changes without adequate tests. CloudNala has written separately about why the model gateway is not the AI platform and about the enterprise MCP gateway.
Agents add an action boundary
A conversational assistant produces a suggestion that a person decides whether to use. An agent may also read, change or submit information. Allowing suggestions on synthetic code is a different decision from allowing repository access, file edits or a pull request, and each step changes what needs authorising and reviewing.
Before enabling an agent, settle its objective, information scope, tools, permitted actions and stopping points. Decide which actions need human approval, and how the team will inspect changes and recover from mistakes. Separate read, propose and execute permissions. Agents change the risk boundary goes into this in more depth.
Confidentiality and quality are separate questions
An input can be fine to process while the output is wrong. An output can be useful even though the input should never have gone to that service. Both need an answer.
For architecture work, a practical check is to tie every retained recommendation to a requirement, a source fact or a clearly labelled assumption. A suggestion that depends on an unconfirmed integration becomes a question to investigate, not a statement in the design. Agreement between two AI assistants is not independent proof.
Governance that helps someone decide
A useful operating model lets a practitioner resolve an uncertain case while the work is still in progress. A general warning does not do that. A decision system does.
An approved tool catalogue. For each tool: the approved account type, permitted users and tasks, prohibited tasks, supported information classes, retention position, processing location, and whether it may take external actions.
A use-case decision routine. A handful of questions about the tool, account, information class, client permission, actions and review, ending in one of four answers: proceed, proceed with stated controls, request a decision, or do not proceed.
Guidance for the difficult middle cases. Synthetic and abstracted scenarios, embedded AI, browser extensions, personal accounts, coding assistants, copied logs, meeting transcripts, retrieval, agents, MCP tools and generated intellectual property. Training should use these, not just the obvious prohibitions.
A governed sandbox. An environment where teams can try synthetic and low-risk uses with approved identities, logging, a model gateway, restricted tool access and isolated workspaces.
Fast, accountable approval. A named decision owner and a response time. A synthetic drafting task should not go through the same process as an autonomous production agent handling personal information.
Minimum evidence. A short AI-use record (purpose, tool, information class, model, how the output is used, reviewer, tests and exceptions) kept with the decision record, pull request or work item.
A proportionate way to raise mistakes. Someone who realises a boundary may have been crossed needs a clear, non-punitive route to say so. A time-limited amnesty in which teams declare current AI use is one way to find demand, rationalise tools and close gaps quickly.
These are design proposals for discussion, not a description of any particular organisation's policy.
Match the controls to the level of risk
Not every use needs the same process. A five-level lens keeps light uses light and puts the weight where the consequence is.
| Level | What the AI is doing | Example | Default posture |
|---|---|---|---|
| 1 | Ideation on public or synthetic material | Headings or generic test ideas | Allowed in approved tools with basic training |
| 2 | Drafting from low-sensitivity internal material | Summarising an internal procedure | Enterprise identity, approved platform, human review |
| 3 | Advice using confidential or regulated information | Retrieval assistant over client documents | Use-case approval, permission-aware retrieval, evaluations, monitoring |
| 4 | Proposed action | Agent prepares a code change or customer reply | Strong tests, traceability, scoped tools, explicit approval before action |
| 5 | Autonomous consequential action | Agent changes production or decides eligibility | Exceptional approval, strict technical limits, continuous control, named owner |
Case one sat at level 1 for its information and was ambiguous only on account and task. Under this lens it would have been quick to approve, which is exactly why the lack of a route to ask cost so much.
Human oversight needs the same proportion. Review belongs at consequential decisions, with a reviewer who has the context, authority and time to say no. Asking someone to click "approve" hundreds of times without inspection creates the appearance of accountability, not the substance; human-in-the-loop must show their work.
From shadow use to an approved pathway
Discovered shadow use is information about demand. It says that people have a real job to do and the approved route is missing, slow, unclear or less capable. Treating every instance only as misconduct throws that information away.
- Discover. Invite declaration, review licences and integrations, and look for embedded AI features.
- Classify. Group uses by information sensitivity, autonomy, consequence, user population and external exposure.
- Contain. Stop clearly unsafe access, reduce permissions and move suitable experiments into the sandbox.
- Evaluate. Test quality, security, privacy, cost, failure behaviour and human oversight.
- Approve or retire. Publish the permitted boundary, owner, evidence requirements and review date, or remove the capability.
- Productise. Where the same demand keeps appearing, provide a supported internal capability rather than approving one-off exceptions forever.
The result is a portfolio, not a single AI policy. Drafting tools, coding assistants, retrieval systems and autonomous agents need different controls.
What leaders should measure
Counting licences shows neither usefulness nor governance. A more honest view includes:
- declared and discovered AI use cases, and their status: approved, conditional, experimental or prohibited;
- the share of usage that goes through enterprise-managed identities;
- information-class exceptions;
- evaluation pass rates and recurring failure types;
- human override and rejection rates;
- blocked and failed tool calls;
- incidents and near misses;
- time from a use-case request to a decision;
- adoption of the approved alternative after shadow use is found;
- outcome, quality, cycle time and cost for each material use case.
The measures should not promise certainty. They should make risk, value and behaviour discussable.
A short routine for the practitioner
Until the organisation provides the system above, a consultant can still make a defensible decision:
- Describe the task and why AI would help.
- Identify the exact account, feature and integrations involved.
- Identify the information needed, including context that could identify the engagement even without names.
- Check permission for that combination of task, information and access, in both your own organisation and the client's.
- If permission is uncertain, ask, and record that you asked, or use a confirmed alternative.
- Decide how the output will be checked before relying on it.
- For agents, agree action limits and human approval points before granting access.
The routine should be short enough to use mid-delivery, and it should let you explain the decision afterwards without inventing certainty you did not have at the time.
Accountability does not move to the tool. The provider is responsible for its service commitments, the platform team for the controls it runs, the product owner for the use case, and the practitioner for using the capability within the permitted boundary. Calling the model an assistant changes none of that; see also confidentiality before convenience.
The management question
The useful question is not "how do we eliminate shadow AI?" New features, models and workarounds will keep arriving.
The better question is "how quickly can we turn legitimate demand into a visible, testable and accountable capability?"
An organisation that only blocks will learn slowly and push use out of sight. An organisation that only encourages experimentation will collect unmanaged data, tools and decisions. The workable middle is a governed route that is fast enough for delivery teams and strong enough for clients, regulators and executives.
Shadow AI is evidence of a gap between the work people are expected to do and the systems they are given to do it. Good governance closes the gap, and makes the safe route the usable one.