The Risk of Shadow AI in Organisations: How to Use Public AI More Safely Generative AI tools such as ChatGPT, Grok and Gemini are now part of everyday work. Staff use them to summarise documents, rewrite emails, analyse technical text, draft reports and speed up decisions. The problem is that this often happens outside formal procurement, security review and governance. In many organisations, especially in public sector, government, legal, finance, healthcare and critical infrastructure, employees may paste sensitive data into public AI tools without fully understanding where that data goes, how long it is retained, whether it may be reviewed, or whether it can be used to improve the provider’s services or models. That is one of the core risks behind what many now call shadow AI: the unofficial, uncontrolled use of public AI services inside the organisation. This is not mainly about “other users seeing your chats.” In normal private use, other users do not simply see your conversations. The real issue is different: these are third-party cloud services operating outside your organisation’s own security boundary, contractual controls and internal policies. In some cases, prompts or activity may be retained, reviewed, or used for product improvement depending on account type and settings. OpenAI states that consumer ChatGPT users can stop their chats from being used to train models by turning off the relevant control, while Google explains that Gemini Apps Activity affects whether future activity is used to improve Google AI, and X provides privacy controls for Grok personalization and deletion of Grok conversation history. Sensitive internal data may be exposed beyond approved systems. This can include customer data, internal architecture, source code, vulnerability details, legal drafts, procurement documents, HR material, health-related information, credentials, incident notes, IP ranges, contract discussions, or unpublished strategy. Even when the intent is harmless, a single pasted prompt can move sensitive business information into an external platform outside the company’s approved processing environment. That can create security, confidentiality, compliance and contractual problems, especially under GDPR, trade secret obligations, public-sector records rules and sector-specific controls. The risk grows when staff assume that “private” means “inside the organisation,” which it does not. Another problem is false confidence. Many users assume that if a tool feels professional, it must already be safe for sensitive work. In practice, privacy protections vary by provider, by account type, by admin configuration, and by whether the user is on a consumer plan or an enterprise-grade environment. Google explicitly distinguishes between ordinary Gemini use and work or school accounts with enterprise-grade data protections. This is why AI use in organisations needs the same discipline as any other external cloud service. Convenience is not governance. What organisations should do first A good starting point is simple: Do not paste raw confidential data into public AI tools unless the service has been formally approved for that purpose. Do not enter customer data, vulnerability reports, internal network diagrams, legal drafts, procurement material, personal data, credentials, unpublished financial information, or incident details into consumer AI tools. Use redacted, minimised or synthetic data wherever possible. Prefer enterprise-approved AI environments with contractual controls, auditability and admin governance. Train employees to treat prompts as data disclosure, not as harmless chat. These are basic hygiene measures, but they matter because users often do not realise that a prompt can itself be sensitive. How to make popular public AI tools more private Below is a practical user guide for three widely used public AI platforms. ChatGPT OpenAI’s official help documentation states that signed-in users can turn off “Improve the model for everyone” in Data Controls, and that when this is off, conversations still appear in chat history but are not used to train ChatGPT. OpenAI also states that Temporary Chat starts a blank-slate conversation and is not used to improve models, although retention for certain services may still be affected by legal developments. Recommended privacy steps for ChatGPT:
That is the minimum safer setup for public ChatGPT use. It reduces risk, but it does not make consumer AI suitable for unrestricted handling of highly sensitive organisational data. Grok X’s official Grok help page says users can manage Grok-related privacy controls in Privacy & Safety, under Data sharing and personalization, including Grok & Third-party Collaborators, where users can manage Grok Personalization. X also states that users can delete all Grok conversation history, and that deleted conversations are removed from systems within 30 days unless retention is required for security or legal reasons. Recommended privacy steps for Grok:
This matters especially because Grok lives inside a social platform environment, where users may blur the line between private experimentation and public posting. Google Gemini Google’s official Gemini privacy documentation says users can visit Gemini Apps Activity to review and delete activity, change auto-delete periods, and control whether data is used to improve Google AI. Google also states that turning off Keep Activity stops future chats from being used to improve Google AI. At the same time, Google notes that Gemini Apps Activity settings do not control all anonymized processing used to improve Google services. Google further explains that connected apps and uploaded content can also create privacy exposure if activity retention remains enabled. Recommended privacy steps for Gemini:
Google also states that if you are using Gemini with a work or school account and see enterprise-grade protections, the data handling can differ from ordinary consumer use. That distinction is important for organisations writing policy. What a sensible internal policy should say A strong internal AI policy does not need to ban everything. It should clearly separate low-risk from high-risk use. Low-risk use might include grammar improvement, generic brainstorming, formatting help, public marketing drafts, or summarising text that contains no confidential or personal data. High-risk use includes anything involving customer records, personal data, security incidents, legal analysis tied to real cases, procurement, source code, infrastructure diagrams, vulnerability details, classified material, internal business plans, unreleased products, or sensitive government information. For high-risk categories, the policy should require either an approved enterprise AI environment or no AI use at all. That is the difference between helpful AI adoption and unmanaged shadow AI. Bottom line Public AI can be useful, but it should never be treated as a neutral clipboard for sensitive organisational data. The main danger is not that strangers will read your prompts. The real danger is that staff use external AI services without understanding retention, review, training, connected-app exposure, or whether the service is approved for sensitive work. OpenAI, Google and X all provide privacy controls, but those controls must be actively configured, and they are not a substitute for governance, data classification and staff awareness.
Responsible AI use is now part of modern cyber hygiene. AI Meeting Transcription: Useful, but Often Overlooked as a Privacy RiskAnother growing risk area is the use of AI to transcribe and summarise meetings in platforms such as Zoom, Microsoft Teams and similar services. This is becoming very popular because it saves time, creates notes automatically and helps participants remember decisions and action points. Zoom actively promotes AI note-taking and meeting summaries across Zoom, Microsoft Teams, Google Meet, in-person meetings and other third-party meetings. Microsoft also allows Copilot in Teams meetings to use meeting transcript data, and if transcription is started, Copilot can also include chat data from up to 24 hours before the meeting. The danger is that meetings often contain exactly the kind of information that should be handled with great care: internal strategy, legal issues, customer information, security incidents, procurement discussions, HR matters, financial data, technical architecture and confidential business decisions. Once this is spoken aloud in a meeting and captured by AI transcription or summary tools, that content may be stored in external cloud systems, shared more widely than intended, retained for longer than users realise, or become available to additional AI features depending on configuration and account settings. Zoom states that account owners and administrators can allow audio transcripts generated with AI Companion meeting summaries to be used for other AI Companion features, while Microsoft explains that transcripts and related meeting data can be used by Copilot inside Teams meeting workflows. This is where many organisations make a mistake. Staff may assume that meeting transcription is just a convenience feature, when in reality it is also a data handling decision. It is not only a question of whether the meeting is recorded. It is also a question of where transcripts are stored, who can access them, how long they are kept, whether they are connected to chat history, whether external participants are included, and whether the content may later be reused by other features inside the platform. Microsoft explicitly provides controls over who can access a Teams recording or transcript, and Zoom notes that when content is stored in Zoom Cloud, Zoom has access to that content to provide the service, whereas locally recorded meetings are different. It is also important not to overstate the issue. Not every AI transcription feature automatically trains public foundation models on your meeting content. The risk depends on the vendor, the product tier, the organisation’s settings, and whether the service is a consumer/public environment or an enterprise-controlled one. For example, Microsoft says that prompts, retrieved data and responses in Microsoft 365 Copilot remain within the Microsoft 365 service boundary, and that Microsoft 365 Copilot does not use customer data to train the foundation large language models behind the service. At the same time, Microsoft’s separate Copilot privacy FAQ warns users not to provide confidential or sensitive personal data they would not want Microsoft to use for the purposes described in its privacy documentation. That is exactly why organisations should not rely on assumptions. They should verify the actual privacy model, retention behaviour, admin controls and contractual protections for each meeting AI feature they use. Safer use of AI transcription in meetingsA sensible approach is: Only enable AI transcription and meeting summaries where there is a clear business need. Do not use public or consumer AI meeting tools for meetings involving confidential customer data, legal matters, incident response, internal security discussions, HR cases or sensitive government information. Review who can access transcripts, recordings and summaries. Prefer enterprise-managed environments with admin controls, retention settings and contractual safeguards. Make sure staff know that spoken information can become stored, searchable and reusable data. In other words, AI meeting transcription should be treated as a security and governance matter, not just a productivity feature.
If you want, I can also make this into a slightly shorter section so it matches the tone and length of the rest of your article. |