Why do public AI tools create different risk conditions for corporate data and regulated data?

Why This Matters for Security Teams

Public AI tools change the risk profile because the enterprise often loses direct control over where prompts, uploads, and derived outputs are processed. That matters for corporate data, but it becomes much more serious for regulated data such as personal data, payment information, healthcare content, or material covered by contractual confidentiality. The core issue is not only user choice. It is whether data can be classified, blocked, routed, and retained under policy before it ever reaches the tool.

Security teams also need to separate convenience risk from governance risk. A public tool may be acceptable for low-sensitivity drafting, while the same workflow can create compliance exposure if employees paste source code, customer records, legal drafts, or credentials into a prompt. Current guidance suggests treating the tool as an external processor unless the provider’s terms, data handling commitments, and retention settings are explicitly approved. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to align data protection, governance, and monitoring rather than relying on individual user judgement alone.

In practice, many security teams encounter these issues only after sensitive data has already been shared in a public prompt rather than through intentional AI governance.

How It Works in Practice

Public AI tools create different risk conditions because the organisation usually cannot fully control the data path. A prompt may be copied into a consumer interface, stored for abuse monitoring, sent to a model hosted in another region, or used for service improvement depending on the provider’s terms. Even when the vendor says data is not used for training by default, that does not automatically solve residency, subprocessors, retention, or access control concerns.

For corporate data, the main control question is whether the information can be shared safely and whether the output can be trusted enough for internal use. For regulated data, the question is stricter: can the data be prevented from entering the service at all, and if it does enter, can the enterprise prove how it was handled? That is where classification, DLP, approved-use policies, and technical guardrails matter.

• Classify data before users reach the tool, not after an incident review.
• Block or redact secrets, customer identifiers, and privileged content at the point of entry.
• Review provider terms for retention, training use, subprocessors, and support access.
• Apply legal and compliance review where personal data, payment data, or export-controlled material is involved.
• Log usage for auditability, but avoid logging regulated content more broadly than necessary.

This is also where AI governance intersects with identity and access management. If a public AI account is shared, unmanaged, or authenticated with weak credentials, the organisation loses accountability for who submitted what and under which role. That weakens both incident investigation and policy enforcement. Best practice is evolving, but most mature programmes now treat public AI access like any other third-party risk surface, with explicit approval workflows and monitoring. The MITRE ATT&CK framework can help teams think about abuse patterns such as credential theft, data collection, and exfiltration pathways around these tools.

These controls tend to break down when employees use personal accounts or browser extensions in unmanaged endpoints because the organisation cannot reliably enforce policy at the point of data entry.

Common Variations and Edge Cases

Tighter AI controls often increase friction for staff, requiring organisations to balance productivity against confidentiality, compliance, and auditability. That tradeoff is especially visible when a public tool is used for harmless drafting in one context and for regulated analysis in another. The answer is not always a blanket ban, but there is no universal standard for this yet. Policy should reflect the data type, the business purpose, and the provider’s contractual posture.

One common edge case is anonymised or redacted data. If re-identification remains plausible, many privacy teams still treat it as sensitive. Another is model output: even if the input was low risk, the output can embed confidential logic, client details, or inferred personal data that should not be redistributed. A third edge case is employee experimentation with consumer-grade AI in approved business workflows. If the tool is not covered by enterprise terms, the enterprise may still inherit legal and reputational risk.

Where the organisation operates across borders, jurisdictional issues can dominate the decision. The NIST AI Risk Management Framework helps structure the review, while the NIST AI 600-1 GenAI Profile is useful for considering GenAI-specific governance, data handling, and output integrity. In public-tool scenarios, the safest operational stance is to assume data may persist beyond the immediate session unless the provider contract and controls clearly state otherwise.

Related resources from NHI Mgmt Group

• Why do public AI tools create data leakage risk even when employees are acting in good faith?
• Why do AI tools create new compliance risk for financial data access?
• Why do approved AI tools still create data leakage risk?
• Why do AI agents create different financial risk than conventional AI tools?