Buying an enterprise AI licence changes who controls your data, but only through specific contract terms and admin settings, and many organisations pay for the licence without checking which of those terms they actually got. This guide compares enterprise and consumer tiers of generative AI assistants term by term: training use of prompts, retention, admin and identity controls, audit logs and data residency. It is written for security, privacy, procurement and IT teams deciding whether a business plan is enough or whether further controls are needed. Platforms named as examples are listed alphabetically, and order is never a ranking; vendor statements were checked against each vendor's own documentation in November 2026.
Key takeaways
- The licence changes the default on training. The vendor pages checked for this guide state that business and API data is not used to train models by default, while consumer tiers rely on a user setting that the organisation does not control.
- Retention and audit are where tiers really differ. Enterprise tiers add organisation-set retention, audit logs and exportable records; consumer accounts give the individual user, not the employer, control over history and deletion.
- Identity is the enforcement point. SSO, SCIM provisioning and domain capture are what turn a contract into a control, because they decide which account a member of staff actually signs in with.
- Some risks do not change with the tier. Prompt injection, oversharing of internal data through connectors and wrong outputs are the same on a paid plan; the enterprise tier only makes them visible and governable.
- Verify the exact plan, not the brand. Terms differ between plan names inside the same product family, and some features (audit log export, data residency) are limited to the top tier.
Short answer: what actually changes
A consumer AI tool is a contract between the vendor and an individual. The individual accepts the consumer terms, chooses (or ignores) privacy settings and can take the account with them when they leave. An enterprise licence is a contract between the vendor and the organisation, usually with a data processing addendum, where the organisation is the customer, the vendor acts as processor for the business content, and administrators hold the settings. That shift in who is the customer is the whole difference.
The table below compares the two tiers on the five contract terms that matter for data protection. It describes the typical pattern; the next section shows what four vendors actually document.
| Term | Consumer tier (free or individual paid) | Enterprise or business tier | What to verify |
|---|---|---|---|
| Training use of prompts and files | Often used to improve models unless the user opts out; feedback and safety-flagged chats may be retained and used separately | Not used for training by default under the business terms; feedback may be an exception unless the admin disables it | The exact clause in the commercial terms or DPA, and whether thumbs up or down feedback is treated differently |
| Retention | Set by the vendor and the user; history kept until the user deletes it or an auto-delete period ends; reviewed chats may be kept longer | Organisation-set retention on some plans; deletion propagation periods stated; zero data retention by agreement on some API offerings | Default period, minimum configurable period, what survives deletion (safety logs, feedback), and backup purge time |
| Admin and identity controls | None for the employer; the user owns the account | SAML SSO, SCIM provisioning and deprovisioning, domain verification, feature and connector toggles | Whether SSO is enforced, whether SCIM is included in your plan, and whether personal accounts on your domain can be captured |
| Audit logs and records | Not available to the employer | Admin and user activity logs, conversation export or compliance API on top tiers; retention windows for log export | Which events are logged, whether prompt content is included, export method, retention window, SIEM integration |
| Data residency and processing location | Processed wherever the vendor chooses | Regional storage at rest on eligible plans; regional processing commitments on some; subprocessors listed | Storage versus inference location, excluded features and models, subprocessor list and change notice |
What four vendors document
The table lists each vendor's own statements on the terms above, from its public documentation as of November 2026. Vendors are listed alphabetically. Plan names change often, so confirm against current documentation. Product-specific hardening is covered in the Claude for Enterprise Security Guide, the Gemini for Google Workspace Security Guide, the Microsoft 365 Copilot Security Deep Dive and the ChatGPT Enterprise Security Guide.
| Vendor | Consumer tier: training and user control | Business tier: training default | Organisation records and admin controls |
|---|---|---|---|
| Anthropic (Claude) | Free, Pro and Max chats may be used for training if the user allows it through the Model Improvement setting; Incognito chats are not used for training; feedback stores the related conversation for up to five years, de-linked from the user ID | Inputs and outputs from commercial products (Team, Enterprise, API) are not used for training by default; feedback is the stated exception, and owners can turn off the "Rate chats" setting under Organization settings, Data and Privacy | Audit log export from Organization settings covers the past 180 days and records sign-in, SSO changes, domain verification, file uploads and conversation events; titles and content are exported by identifier only |
| Google (Gemini) | With Keep Activity on, chats are used to improve Google services, including training, with human review of a subset; reviewed chats are kept up to three years disconnected from the account; activity auto-deletes after 18 months by default | Workspace states it does not use customer data for training models without the customer's prior permission or instruction; prompts count as customer data under the Cloud Data Processing Addendum | Admins can disable the Gemini app, switch Gemini features on or off per Workspace app, control conversation history and retention, and review audit logs of Gemini activity |
| Microsoft (Copilot) | For eligible signed-in consumers, conversation data may be used for training unless the user opts out; conversation activity is stored for 18 months by default; Microsoft notes this training section applies to the older Copilot app | Prompts, responses and data accessed through Microsoft Graph are not used to train foundation LLMs; users signed in with an organisational Entra ID account are excluded from consumer training | Copilot interactions are recorded in Microsoft Purview Audit as CopilotInteraction records with the app host, accessed resources and model details; Purview retention policies apply to Copilot chat data |
| OpenAI (ChatGPT) | Consumer ChatGPT improves by further training on conversations unless the user opts out; opting out applies to new conversations | OpenAI states it does not train on organisation data by default across ChatGPT Enterprise, Business, Edu and the API platform | Enterprise features listed include SAML SSO, SCIM provisioning and an Audit Logs API; retention controls are offered to qualifying organisations |
Availability notes. Anthropic: audit log export is documented for Enterprise organisations, and organisations using customer-managed keys receive audit events through the Compliance API. Google: the Workspace privacy hub notes that file sharing and data region settings do not apply to Gemini Notebook data. Microsoft: Copilot interaction auditing is part of Audit (Standard) for Microsoft Copilot apps, while auditing of non-Microsoft AI apps is billed pay-as-you-go with 180-day retention; Anthropic models used as a Microsoft subprocessor are currently excluded from the EU Data Boundary. OpenAI: data residency at rest is offered to eligible ChatGPT Enterprise, Edu, Healthcare and API customers in regions including the US, Europe, UK, Japan and Canada.
Consumer tier: threat model and failure modes
Architecture in words. A member of staff opens the vendor's website or app in a browser, signs in with a personal email or with a work email address that the vendor treats as an individual account, and pastes or uploads content. The content is processed in the vendor's consumer service, stored in the user's history and, depending on the user's settings, made available for model improvement and human review. The employer sees at most a web proxy record that the domain was visited.
Threat model. The organisation is exposed to four things it cannot control: the training default chosen by the user; retention decided by the vendor and the user; human review of a sample of chats under the consumer terms; and account ownership, because the history stays with the person after they leave. These are the risks summarised in the Top 10 Shadow AI Risks.
- Retention beyond deletion: deleting a chat does not remove copies already selected for human review or submitted as feedback, and the vendor documentation above shows those copies can be kept for years, disconnected from the account.
- Work email is not a work account: signing up with a corporate address does not by itself place the account under the organisation's contract or admin control.
Enterprise tier: threat model and failure modes
Architecture in words. Staff sign in through the organisation's identity provider using SAML SSO. Accounts are created and removed by SCIM from the HR-driven directory. The workspace sits under the organisation's commercial terms and DPA. Admins decide retention, which features and connectors are on, and where logs go. Connectors let the assistant read mail, files and chat with the signed-in user's permissions, which is a new data path the consumer tool did not have.
Threat model. The training and ownership risks move to the contract and the admin console, where they can be managed. New risks arrive with integration: the assistant can now reach everything the user can reach, connectors and custom agents hold tokens that act as non-human identities, and the vendor tenant becomes a store of sensitive prompts that needs the same protection as any other SaaS data store. Assistants that ground answers on internal content work within the signed-in user's permissions, which means the existing permission model is the data boundary. See the Enterprise AI Copilot Security Guide for permission clean-up before rollout.
- Licence bought, SSO not enforced: users keep password logins, so a leaver whose directory account is disabled can still sign in to the AI workspace.
- Mixed tiers inside one company: a team on a lower business plan is assumed to have the top tier's retention or residency terms.
- Feedback exception overlooked: thumbs up or down submits the full conversation to the vendor under different handling; the admin setting to disable it is left on.
- Logs never collected: audit export exists but nobody schedules it, so the 180-day window passes before an investigation needs it.
- Connectors added without review: a business user connects a file store or mailbox, and the assistant starts grounding answers on overshared content.
What does not change with the licence
Paying for an enterprise tier changes the vendor's handling of your data. It does not change how the model behaves. The following risks need their own controls on both tiers.
| Risk | Why the tier does not fix it | Control that does |
|---|---|---|
| Prompt injection (OWASP LLM01:2025) | Instructions hidden in a document, email or web page are processed the same way by any tier; connectors increase exposure | Limit connector scope, require confirmation for actions, monitor for injection detections; see the Prompt Injection Guide |
| Sensitive information disclosure (OWASP LLM02:2025) | Users can still paste regulated data the contract allows the vendor to process but your policy does not | Classify which data may enter which tool, apply sensitivity labels and AI-aware DLP; see the Generative AI Data Loss Prevention Guide |
| Oversharing through grounding | The assistant respects existing permissions, so broken permissions become searchable answers | Permission review, restricted search scopes and label-based exclusions before rollout |
| Misinformation (OWASP LLM09:2025) | Wrong or fabricated output is a model property, not a contract term | Human review for decisions, citations required, use-case limits in the acceptable use policy |
| Account takeover | An enterprise account with SSO is only as strong as the identity provider's sign-in policy | Phishing-resistant MFA and conditional access on the AI application, session limits |
Contract checks before signing
Read the commercial terms, the DPA and the vendor's trust documentation against this list. The AI Vendor Security Questionnaire Template has the full question set.
- Training clause: the exact words that exclude your inputs, outputs and files from training, and every exception (feedback, safety review, opt-in programmes).
- Plan scope: which plan names and products the clause covers; a clause for the API may not cover the chat product, and vice versa.
- Retention: default period for chats and files, configurable minimum, deletion propagation time, retention for safety-flagged content and feedback, and backup purge. Expect separate, longer periods for content flagged by trust and safety systems, and ask for each in writing.
- Zero data retention: whether it is available, for which endpoints, and whether it is in your agreement rather than a separate request.
- Identity: SAML SSO, SCIM, domain verification and the ability to block or capture personal accounts created with your domain.
- Audit: which events are logged, whether prompt and response content is available for eDiscovery, export method (console, API), retention window and cost.
- Residency: storage location at rest, inference location, which features or models fall outside the regional commitment, and subprocessor list with change notification.
- Connectors and agents: which third-party models, web search or plug-ins send data outside the stated boundary, and whether admins can switch each off.
- Incident terms: breach notification time and content; plan for the vendor being the source of an incident with the AI Vendor Breach Response guide.
Enforcing use of the licensed tier
A licence protects nothing if staff keep using personal accounts. Enforcement is an identity and network problem, and it works best in this order.
- Inventory current use. Pull web proxy, SSE or DNS logs for AI domains and expense claims for individual AI subscriptions. The Shadow AI Discovery Guide covers discovery sources.
- Turn on SSO and SCIM first. Enforce SSO for the workspace, provision through SCIM from the authoritative directory and verify your email domains with the vendor so new sign-ups land in the organisation's workspace.
- Apply conditional access. Require phishing-resistant MFA and a managed or compliant device for the AI application, as for any other sensitive SaaS application.
- Steer personal-account use. Where your SSE, CASB or enterprise browser supports tenant restrictions or account-level controls, allow the corporate workspace and coach or block personal sign-ins to the same service. Pilot in monitor mode for two weeks before blocking, and keep block rules in a separate policy so they can be returned to monitor mode quickly. The AI Gateway vs CASB/SSE for Controlling Shadow AI guide compares the enforcement points.
- Publish the rule. State in the AI Acceptable Use Policy Template which data classes may go to which tier, and that personal accounts are not used for work content.
Decision criteria
| Situation | Reasonable choice | Why |
|---|---|---|
| Regulated or client-confidential data will be used | Enterprise tier with DPA, SSO, SCIM, audit export and stated retention; residency where required | You need contractual processor terms and evidence for regulators and clients |
| Public information only, low volume, a few users | Business tier with SSO may be enough; block consumer sign-ins on work devices | Training default and account ownership are the main gaps, and the business tier closes them |
| Small organisation without SSE or CASB | Business tier with domain verification and SSO from your identity provider; policy and training | Identity controls give most of the benefit without network enforcement |
| Large organisation, many AI tools | Approved tool list per data class, gateway or SSE enforcement, central audit collection to the SIEM | Scale makes per-tool exceptions unmanageable without central enforcement |
Worked scenario: a consultancy moves from personal accounts to an enterprise plan
A 600-person consultancy finds through proxy logs that 240 staff use a consumer AI assistant, about a third with personal email addresses, and that client documents are being summarised. Legal asks whether buying the enterprise plan solves the problem.
- Contract: the team confirms the business terms exclude training by default, notes the feedback exception and asks for it to be disabled at organisation level; it records the deletion propagation period and the longer retention for safety-flagged content in the client data register.
- Identity: SSO is enforced through the corporate identity provider, SCIM is connected to the HR-driven directory, and the email domain is verified so new sign-ups join the workspace.
- Personal accounts: staff are asked to export anything they need and delete client material from personal histories; the firm accepts it cannot verify deletion and records the residual risk.
- Enforcement: SSE policy allows the corporate workspace and shows a coaching page for personal sign-ins for 30 days, then blocks them on managed devices.
- Unchanged risks: connectors to the document store are delayed until a permission review removes "everyone" access from 14 project sites; prompt injection and output review are covered in the AI policy.
Detection and measurement
- Personal-account share: percentage of AI sessions on managed devices that use a non-corporate account; target falling to near zero after enforcement.
- SSO and SCIM coverage: percentage of workspace users created by SCIM and signing in through SSO; leavers removed within your standard deprovisioning time.
- Audit continuity: days since the last successful audit export or API pull; alert if it exceeds the collection interval.
- Contract coverage: percentage of AI tools in use with a reviewed training clause, retention term and DPA on file.
- Connector review: number of connectors enabled without a recorded owner and scope review.
Monitor sign-in events to the AI application in the identity provider, admin changes in the vendor audit log (SSO settings, retention changes, data exports) and, where available, interaction records. Where the vendor's interaction records list the files or messages an assistant accessed, keep them: they show what content an answer drew on during an investigation. The AI Usage Monitoring Guide covers the monitoring stack.
Framework mapping
| Framework | Reference | How this guide applies it |
|---|---|---|
| NIST CSF 2.0 | GV.SC-05 | Training, retention, residency and audit terms written into supplier contracts |
| NIST CSF 2.0 | GV.SC-07 | AI vendor terms reviewed and monitored over the relationship as plans change |
| NIST CSF 2.0 | ID.AM-02 | Inventory of AI services in use, including consumer tools |
| NIST CSF 2.0 | PR.AA-01 | Workspace identities managed through SSO and SCIM |
| NIST CSF 2.0 | DE.CM-03 | Monitoring AI usage and personal-account sign-ins |
| NIST SP 800-53 Rev 5 | SA-9, SA-4, SR-6 | External system services, acquisition terms and supplier assessment for AI vendors |
| NIST SP 800-53 Rev 5 | AC-2, AU-2, AU-11 | Account management, event logging and audit record retention for the AI workspace |
| OWASP Top 10 for LLM Applications 2025 | LLM01, LLM02, LLM09 | Risks that remain on every tier |
Common failure patterns
- Treating the brand as the contract: assuming every plan in a product family has the same training and retention terms.
- Ignoring exceptions: missing that feedback, safety review and opted-in programmes are handled outside the main training clause.
- Residency assumed for every feature: regional commitments often exclude specific features, notebooks, web search or third-party models.
Practitioner checklist
- List every AI assistant in use and which tier and plan name each team is on.
- Record the training clause, its exceptions and the plan scope for each enterprise contract.
- Disable feedback submission at organisation level where your data classes require it.
- Enforce SSO, connect SCIM and verify email domains for each licensed workspace.
- Apply conditional access with phishing-resistant MFA to AI applications.
- Schedule audit log export to the SIEM and alert on gaps.
- Confirm residency terms per feature and model, and track subprocessor changes.
- Coach, then block, personal-account use of the same services on managed devices.
Standards and references
- Anthropic: Is my data used for model training? (commercial products)
- Google: Generative AI in Google Workspace Privacy Hub
- Microsoft Learn: Data, Privacy, and Security for Microsoft 365 Copilot
- Microsoft Learn: Audit logs for Copilot and AI applications
- OpenAI: Business data privacy, security, and compliance
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: Enterprise AI Copilot Security Guide, Embedded AI in SaaS Guide, AI Data Retention and Deletion, Shadow AI Policy Template.