Notifications
Clear all
Topic starter
19/08/2026 3:26 pm
TL;DR: Enterprise AI privacy depends on the access path, because Claude, GPT, and Gemini apply different training, retention, and in-use rules across consumer apps, APIs, and cloud resellers, according to Axoflow. The practical lesson is that teams must verify all three switches separately, because one safe setting does not imply the others.
NHIMG editorial — based on content published by Axoflow: Same model, three sets of rules: a 2026 privacy map for Claude, GPT, and Gemini
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, meaning organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.
Questions worth separating out
Q: How should security teams govern AI in the security stack?
A: Security teams should treat AI as a governed decision aid, not an autonomous authority.
Q: Why do AI privacy controls fail when teams only check the training setting?
A: Because training is only one switch.
Q: What should organisations do when employees use personal AI accounts for work?
A: Treat it as shadow AI and a data-governance issue, not just policy misuse.
Practitioner guidance
- Classify every AI door by contract and identity boundary Create an inventory that distinguishes consumer apps, direct APIs, and cloud reseller endpoints, then bind each route to the owning account type, tenant, and policy set.
- Separate training, retention, and in-use reviews Require security and legal sign-off for each of the three privacy switches before any AI service is approved for sensitive data.
- Eliminate shadow AI access paths Block personal accounts and unmanaged AI tools from handling code, customer data, or regulated content.
What's in the full article
Axoflow's full article covers the operational detail this post intentionally leaves for the source:
- A per-provider breakdown of consumer, API, and cloud reseller privacy terms for Claude, GPT, and Gemini.
- The retention and legal-hold exceptions that can change what happens to prompts after submission.
- Confidential computing specifics, including where encryption terminates and how remote attestation is verified.
- Practical deployment notes for deciding when a cloud-hosted route is preferable to a first-party endpoint.
👉 Read Axoflow's analysis of Claude, GPT, and Gemini privacy terms →
AI model privacy terms vary by access path, not just provider?
Explore further
19/08/2026 4:10 pm
The real AI privacy control is the access path, not the model brand. Organisations still talk about Claude, GPT, and Gemini as if the model name determines privacy posture, but the article shows that the door determines the actual governance model. Consumer, API, and reseller paths can differ on training, retention, legal hold, and review rights, which makes identity-aware access classification essential. Practitioners should treat model routing as an IAM decision, not just a procurement one.
A question worth separating out:
Q: When is confidential inference worth the extra complexity?
A: Use it for high-sensitivity workloads where contractual privacy is not enough and the organisation needs cryptographic assurance over data in use. It is most valuable when prompts contain regulated data, proprietary code, or other material that would be damaging if exposed during processing. Teams should still verify attestation, enclave ownership, and excluded model classes before relying on it.
👉 Read our full editorial: AI model privacy depends on the door, not just the model
