The risky moment rarely looks dramatic. It looks like an employee trying to be useful. A customer email needs a calmer reply. A contract needs summarising before a meeting. A spreadsheet contains hundreds of rows that someone wants converted into a management narrative. A developer wants an unfamiliar error explained. The employee opens the easiest generative AI tool available, pastes the material, receives a useful answer, and gets back to work.
From the employee’s perspective, this is productivity. From the organisation’s perspective, it may be an unrecorded transfer of information into a service whose retention, training, access, contractual protection, and geographic processing terms have never been assessed. Both views can be true at the same time.
This is why a prohibition-only response usually fails. It describes the risk accurately but ignores the demand. If the approved route remains slower, less capable, or poorly explained, employees will continue to find their own route. The practical question is not whether people will use generative AI. It is whether the organisation can give them a safe path that is easier to follow than the unsafe one.
The phrase “once it is online, it is there forever” is useful—but imprecise
It is reasonable to warn employees that information entered into an external service may be difficult to retrieve or control. But governance should be based on the actual service terms and architecture, not a slogan. Different AI products have different contractual commitments, retention periods, training settings, administrative controls, and enterprise protections. A consumer account and an enterprise tenant may present very different risks.
The stronger principle is this: once data crosses a boundary you do not govern, your ability to prove what happened to it becomes weaker. You may not know who can access the prompt, whether it is retained for abuse monitoring, whether a user enabled history, whether a plugin received part of the content, or whether the output will later be copied into another system. Even when a provider contractually excludes customer content from model training, the organisation still needs to consider identity, authorisation, logging, retention, residency, legal privilege, and the sensitivity of connected data.
NIST’s Generative AI Profile treats risk management as a lifecycle activity organised around governing, mapping, measuring, and managing risk—not as a one-time tool approval. The UK Information Commissioner’s Office similarly frames AI governance around established data-protection principles including purpose limitation, data minimisation, security, and accountability. Those principles turn an abstract concern into concrete questions: Why is this information needed? Is all of it needed? Who is accountable? Where is it processed? How will the organisation demonstrate compliance?
A plausible Tuesday morning
09:08 — A salesperson pastes a prospective customer’s security questionnaire into a public AI assistant and asks it to draft answers.
09:23 — A finance analyst uploads a workbook to explain a variance. Hidden tabs contain employee and supplier information.
10:11 — An engineer pastes a log excerpt containing an internal hostname, a user identifier, and part of a connection string.
11:40 — None of these actions appear in the approved application inventory. No one intended harm. Each person was rewarded by speed.
What actually travels with a prompt
Leaders often imagine a prompt as a sentence. In practice, a prompt can be a bundle: typed instructions, attached files, copied email chains, screenshots, browser context, retrieved documents, plugin calls, conversation history, and the model’s generated response. When an assistant is connected to enterprise search, collaboration platforms, or agents, the relevant boundary expands again. The system may be able to retrieve information the user did not consciously paste at all.
OWASP’s guidance on sensitive information disclosure highlights personal data, financial information, health records, confidential business information, credentials, and legal documents as material exposure categories. It also warns that prompt-only restrictions are not a sufficient security boundary. An instruction telling a model not to reveal sensitive information can be bypassed or simply fail. Deterministic controls—access management, data minimisation, filtering, isolation, and validation—remain necessary.
Not every prompt carries the same risk
A workable policy distinguishes use cases instead of treating all AI activity as equally dangerous. Asking an approved assistant to improve the grammar of a public job advertisement is not equivalent to uploading an unredacted acquisition document. The classification should consider both the data and the action being requested.
| Prompt pattern | Example | Primary concern | Default handling |
|---|---|---|---|
| Lower | Rewrite already-public marketing copy. | Accuracy, tone, copyright, and brand review. | Approved tool; normal human review. |
| Controlled | Summarise an internal procedure with no personal or regulated data. | Confidentiality, retention, and output accuracy. | Enterprise-approved environment; logging and clear ownership. |
| Restricted | Analyse customer records, employee information, source code, legal advice, credentials, or incident evidence. | Privacy, privilege, intellectual property, security, regulatory obligations. | Prohibit in general-purpose tools; require an assessed use case and protected architecture. |
| High impact | Allow an AI agent to change access, send messages, approve transactions, or update production systems. | Excessive agency, authorisation failure, cascading effects, auditability. | Explicit approval, least privilege, deterministic validation, human checkpoints, rollback. |
Why awareness training is necessary—and insufficient
Training matters because many employees do not recognise that a prompt can be a disclosure. They may know not to email a customer database to a stranger while failing to see an AI upload as the same kind of boundary crossing. Clear examples improve judgment.
But training cannot compensate for an unusable operating model. People forget. New tools appear. Browser extensions are installed. Personal accounts coexist with corporate identities. Vendors embed assistants into products already in use. A policy that depends entirely on every employee making a perfect decision in every prompt is not a control system; it is a hope.
The organisation therefore needs layered controls. The purpose is not to monitor curiosity or punish experimentation. It is to make safe behaviour the path of least resistance and to create evidence when risk decisions need review.
Discover actual usage
Build visibility into approved and unapproved AI services, identities, browser access, integrations, and high-level activity patterns. Start with discovery; do not pretend the application register reflects reality.
Classify data and use cases
Translate existing information-classification rules into prompt-sized examples. Employees need to recognise the difference between public, internal, confidential, privileged, personal, regulated, and credential material.
Provide an approved lane
Select enterprise services with suitable identity, contractual, retention, administration, and data-protection controls. An approved tool must also be useful enough to compete with consumer alternatives.
Enforce at the data boundary
Apply least privilege, information protection, data-loss prevention, redaction, application controls, and restrictions on connectors. Microsoft’s current Purview guidance, for example, describes discovering AI activity and applying DLP controls to prompts in supported environments.
Validate outputs and actions
Treat generated content as untrusted until checked. Code, legal text, financial interpretation, security changes, and agent actions need review proportional to their impact. Human oversight must be designed, not merely mentioned.
Measure and improve
Track adoption of the approved route, blocked high-risk events, recurring user questions, false positives, exceptions, incident signals, and business value. Governance should learn as quickly as the tools change.
The questions an executive team should ask before buying another AI licence
Procurement conversations often begin with model capability and price. A stronger conversation begins with the operating boundary. Which identities will use the service? Which repositories can it search? What information classes may enter prompts? What happens to uploaded files? Which administrators can investigate an incident? Can the organisation export logs? Which regions process data? Are plugins or third-party models involved? What happens when a user leaves?
There is also a less technical question: who owns the decision? Security can define controls, privacy can interpret personal-data obligations, legal can assess contracts, IT can operate identity and endpoints, and business leaders can sponsor use cases. None of them can govern enterprise AI alone. If accountability remains distributed without a decision forum, exceptions will accumulate faster than standards.
Microsoft’s guidance on securing generative AI emphasises applying ordinary enterprise controls—identity governance, Conditional Access, privileged access, and data protection—to AI applications. That is an important corrective to the belief that AI requires an entirely separate control universe. The technology is new; many of the disciplines are not.
What not to promise
Do not promise that a single enterprise licence eliminates leakage. It may improve contractual and administrative protection, but users can still paste data into the wrong place, grant an unsafe connector, expose excessive permissions, or rely on an inaccurate output. Do not promise that blocking public tools eliminates shadow AI; employees may shift to personal devices or embedded assistants. Do not promise that a policy written this quarter will remain adequate next year.
Most importantly, do not promise that an AI governance committee can approve its way to safety. Governance has to appear in architecture, identity, product configuration, data handling, logging, support, education, and day-to-day management. A committee can assign accountability. It cannot substitute for controls.
A practical first 30 days
- Name an accountable executive sponsor and a small cross-functional working group.
- Identify the AI services employees already use and the business problems they are solving.
- Publish a one-page interim rule with concrete examples of data that must not enter unapproved tools.
- Offer at least one approved route for low-risk productivity use.
- Review identity, retention, contractual terms, logging, connectors, and data-protection controls for that route.
- Create a lightweight assessment path for higher-risk use cases instead of forcing them underground.
- Define how suspected prompt exposure will be reported and investigated.
The test of good governance
A mature programme is not the one that produces the longest policy. It is the one in which an employee can answer three questions before pressing Enter: Am I allowed to use this tool? Am I allowed to use this information? Who remains accountable for the result?
If those answers require searching an intranet, interpreting legal language, and waiting a week for approval, the control will lose to convenience. If the approved environment is visible, capable, and supported—and if restricted cases have a credible route—the organisation can preserve the productivity employees are seeking without pretending information risk has disappeared.
The goal is not to make people afraid of AI. It is to ensure that speed does not quietly remove the organisation’s ability to govern its own data.
Sources and further reading
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, published 26 July 2024. Cross-sector risk-management guidance organised around govern, map, measure, and manage.
- UK Information Commissioner’s Office, Guidance on AI and data protection. Regulatory guidance covering accountability, data minimisation, security, transparency, and risk to individual rights.
- OWASP GenAI Security Project, LLM02:2025 Sensitive Information Disclosure. Security risk description and mitigation guidance for sensitive data in model inputs, application context, and outputs.
- Microsoft Learn, Manage generative AI apps for your organization. Official product documentation covering AI activity discovery and supported data-loss-prevention controls.
- Microsoft Learn, Secure Generative AI with Microsoft Entra. Official architecture guidance connecting generative AI to identity governance, Conditional Access, privileged access, and data security.
Vikaas H Shah
Vikaas writes about the point where technology architecture, managed services, governance, and human behaviour meet. This article reflects his interest in making enterprise controls practical enough to survive real working habits—not merely look complete in policy documents.
More about Vikash →