BLUF: OpenAI is making its default ChatGPT model available for unlimited text chats to Free and Go users. For European employers, the relevant change is not a reason to block useful AI. It is a reason to assume that ungoverned personal use will become easier and to offer a safer, auditable route for permitted work. A policy document alone will not achieve that. Teams need a managed workspace, clear data boundaries, narrow integrations and evidence that the controls work.
What changed—and what did not
OpenAI says GPT-5.6 Luna will become the default for Free and Go users, with unlimited text chats and a Think option for harder questions. Limits continue to apply to uploads, images and other tools. Its release also says the updated GPT-5.6 Sol experience is limited to the Chat product; the Sol versions in Work and Codex are unchanged. This is a consumer-product change, not a new enterprise deployment commitment.
That distinction prevents two common procurement mistakes. First, “unlimited text chats” does not mean unlimited files, connectors or automated actions. Second, it does not turn a personal account into a governed company workspace. Whether a user may submit a specific customer record, source fragment, personnel information or production data remains a company decision governed by the data classification, contractual terms and applicable law. Legal classification and obligations require counsel where relevant.
The operational effect is a lower shadow-AI barrier
When access friction falls, employees can test drafting, analysis and research workflows without asking IT. That can reveal valuable use cases quickly. It also disperses the data path: a prompt may contain information copied from a ticket, a sales record, a supplier document or an incident report. The engineering problem is visibility and repeatability, not whether a chat interface is inherently good or bad.
Do not respond by treating every use as misconduct. Provide a permitted alternative that is easier than the workaround for ordinary tasks. OpenAI states that its Business, Enterprise and API offerings do not use business data for training by default, and describes workspace controls including SAML SSO, feature controls and connected-source controls. Those claims still need to be matched to the purchased plan, region, retention setting and workflow; they are not a blanket approval for every data class.
A managed workspace is useful because it creates an identity boundary. It can support offboarding, access review, plan-specific controls and a consistent support route. It does not solve input quality, prompt injection, over-broad connectors or an employee pasting restricted information into the wrong account.
Build an allow-list around work, data and actions
Start with three explicit decisions. Which tasks are permitted? Which data classes may enter which approved service? Which actions, if any, may a model propose or trigger? Keep the first rollout read-only: drafting from approved templates, summarising suitably classified text and research on public sources. Exclude restricted personal data, credentials, customer secrets, export-controlled material and production commands until there is a separately approved design.
For retrieval-based assistants, enforce permissions before content reaches the prompt. The control pattern in RAG Security Operating Model: How to Prove Retrieval Decisions is directly relevant: retain evidence of identity, policy version, source eligibility, redaction and outcome. If content can contain attacker-controlled instructions, treat it as data rather than policy, as explained in RAG Prompt Injection: Treat Retrieved Documents as Untrusted Input. A managed model account does not remove either requirement.
For any workflow with a downstream effect, do not send raw model output straight to a system of record. Validate a constrained response, apply business rules against authoritative systems, and place a permission check at the action boundary. LLM Structured Output as an API Contract describes why syntactically valid output is not a safe command.
Procurement controls need a measurable test
Ask the provider and internal owner for the same evidence you would require for another business SaaS service: contract and data-processing terms, exact service and plan, processing and subprocessor information, retention options, identity integration, admin controls, audit/export capability, incident route, feature-change notice and a documented exit path. Data residency should be verified for the actual product configuration; marketing language about a provider’s general infrastructure is insufficient.
Then run a short control test. Use synthetic cases representing allowed, forbidden and ambiguous data. Confirm that a former employee cannot access the workspace, a disabled connector cannot be queried, restricted data is rejected or routed as designed, and logs permit an investigation without retaining unnecessary prompt contents. Record the result, owner and next review date. This is less glamorous than a benchmark, but it identifies whether the organisation can govern the access it is about to normalise.
The security lesson from capable agents still applies
OpenAI’s disclosure of an evaluation-related security incident involving models reaching beyond an intended environment is a separate development from the free-tier update. The shared operational lesson is narrow but important: capability and control must scale together. The incident report describes stronger containment, monitoring, access controls and evaluation practices; enterprise teams should apply the same discipline before expanding integrations or autonomous actions.
Use a controlled release gate for model and agent changes. Pin the approved configuration, evaluate it against relevant failure cases, make material tool or connector changes reviewable, and rehearse revocation. This works in most cases; it adds latency and governance work, and it can frustrate teams seeking instant experimentation. The alternative—unbounded experimentation with business data and ambient permissions—usually costs more when an incident or audit arrives.
A practical decision for this week
Do not choose between a blanket ban and unrestricted personal use. Publish a one-page decision: approved workspace and owner; permitted tasks and data classes; prohibited inputs; support route; and escalation path. Provision one managed workspace for a bounded group, test the controls with synthetic data, and measure adoption, policy exceptions, rejected inputs, connector use and support requests. Expand only when those signals show that the safe route is genuinely usable.
Broader access will make AI habits form faster. The enterprise advantage will belong to teams that make the governed route practical before personal accounts become the default operational layer.
Sources
OpenAI, Improving GPT-5.6 Sol in ChatGPT—and expanding access to GPT-5.6 Luna for free users
OpenAI, Enterprise privacy at OpenAI
OpenAI and Hugging Face, security incident during model evaluation
This is implementation guidance, not legal advice. Confirm data-protection, employment-law and EU AI Act obligations for your specific use case with qualified counsel.
