How can organisations reduce the risk of querying public AI services?

Reducing exposure when staff use public AI services

Risk reduction starts with deciding which prompts may leave your environment at all. Public AI services are fine for low-sensitivity work, but they should be blocked or tightly brokered for workflows that touch customer data, secrets, incident handling, regulated data, source code, or privileged operations. The practical control objective is to keep sensitive context out of external prompts, not to trust users to self-censor perfectly.

Approved gateways help because they create a policy enforcement point before data reaches the model. They can filter prompt content, enforce tenant and account rules, log usage, and make it easier to distinguish sanctioned model access from shadow use. This is strongest when paired with clear usage rules, because technical controls alone cannot stop every manual paste into a browser session.

Data loss controls and browser controls also matter because public AI use often happens outside managed application pathways. If you can monitor web access, restrict unsanctioned domains, and detect uploads or prompt content that matches sensitive patterns, you reduce both accidental disclosure and deliberate policy evasion. That combination is more reliable than asking staff to remember a general warning.

What should be blocked, monitored, or redirected?

The highest-risk inputs are material that would be damaging if disclosed, retained, or reused in another context. That includes secrets, API keys, credentials, customer records, personal data, internal code, security findings, and incident details. Organisations should treat those categories as prompt-exclusion data, not just as “careful” content, because once the information leaves the workflow it may be stored, logged, or used for future service improvement by the provider.

Monitoring should focus on where policy breaks in practice. Look for direct browser access to consumer AI tools, unmanaged devices, copy-and-paste behaviour from ticketing or code tools, large pasted blocks, and access from roles that should not need external model interaction. If the question is who can use public AI services, the answer should be role-based and workflow-based, not blanket permission based on seniority or convenience.

Where public AI is still allowed, route usage through approved enterprise access paths that can enforce retention settings, authentication, logging, and content filtering. For broader identity and access governance around these decisions, see the AI Risk Assessment Guide and the AI Governance Guide.

Why policy, telemetry, and user behaviour all need to line up

Public AI risk is usually a control-gap problem, not a single-technology problem. If the policy says “do not paste secrets,” but the browser is unmanaged, the gateway is optional, and logs are incomplete, the organisation has little practical assurance. Conversely, if the policy is too strict for ordinary work, users will route around it and create shadow AI use.

That is why the control set has to be balanced: make the safe path easy, make the unsafe path visible, and make the disallowed path hard enough that it is not the default. In many environments the strongest signal is not the model prompt itself but the surrounding context, such as a developer account using a consumer chatbot from an unmanaged browser or a support analyst pasting incident notes into a public interface.

For teams building broader AI governance and vendor controls, the relevant operating assumption is that public services may retain, inspect, or otherwise process submitted material according to their terms. Use the Third-Party AI Risk Guide to structure vendor questions around retention, training, and acceptable use, and the AI Security Posture Management (AI-SPM) Guide to think about discovery, misconfiguration, and AI exposure paths.

Risk and Threat Considerations

Public AI services create disclosure risk because users can unintentionally send sensitive material outside the organisation, where it may be retained, logged, or exposed through weak account hygiene. The threat is not limited to malice; a single careless prompt can create an irreversible information leak if the pasted content includes credentials, source code, or incident evidence.

Failure mechanism: The organisation lacks an enforced control point for prompt content, so sensitive data moves from a governed workflow into an external service through browser use, copy-paste, or unmanaged accounts.

Impact: Confidentiality loss can lead to credential exposure, source-code leakage, incident compromise, privacy breaches, and harder containment because the data may have left the enterprise boundary.

Practitioner Guidance

What to prioritise: Start with the workflows that can cause the most damage if content leaks, especially engineering, incident response, legal, finance, and customer support. Those are the places where one prompt can expose more than a general business query.

What to verify: Confirm that the approved path actually blocks or flags disallowed content, not just that a policy exists on paper. Also verify that logs can show who accessed which service, from where, and through what browser or gateway path.

Common mistake: Treating public AI risk as a training problem only. User awareness helps, but the durable control is combining policy with technical enforcement and visibility.

Practitioner takeaway: The safest model use is the one that never receives sensitive input in the first place, and the next best control is a managed path that makes any exception visible, reviewable, and revocable.

Related resources from NHI Mgmt Group

• How can organisations reduce shadow AI risk without blocking adoption?
• How can organisations reduce risk from AI tools without banning them?
• How can organisations reduce the risk of shadow SaaS and shadow AI during offboarding?
• How can organisations reduce risk from long-lived AI agent access?