An operations team wants sales colleagues to check order status without asking for a spreadsheet. A Site could make that information easier to reach. Before anyone builds it, though, the team needs to decide who can edit the page, who can see it, and what an underlying business service will disclose.
In its 15 October 2026 release notes, OpenAI says a ChatGPT Sites admin preview is rolling out to eligible Enterprise workspaces. Administrators can review creation and sharing access before enabling Sites for members. Public publishing is off by default in Enterprise and requires separate enablement. This update is as much about governing a Site as building one.
Keep creation, editing and publication separate
A member's ability to create a Site does not mean that the Site is public. OpenAI's workspace guide describes separate workspace and role controls for creating and publishing Sites. Site owners can choose an audience supported by their configuration, such as workspace members, selected users or the public when that option has been enabled.
Editing deserves its own decision. OpenAI says an editor can save changes and, after the owner's first publication, publish later versions to the same URL. Editors can also inspect the Site's live database and publish code that uses its secrets or storage. Granting edit access based only on who can make the page look right misses the data and operational access that comes with the role.
For an order-status example, a business team could begin with sample data and a small audience. The process owner confirms what each status means, IT checks access, and someone is assigned to correct stale information or revisit access when the audience changes. That is a suggested operating approach, not a mandatory OpenAI workflow.
A private-network connection still needs service-level access control
OpenAI says tunnels are rolling out to eligible Enterprise workspaces. They let a Site contact a service on the company's private network, such as an inventory API, without exposing the service itself to the internet. But its tunnel guide says a tunnel does not replace that service's authentication or decide what Site visitors may see or do.
Attaching a tunnel and publishing a Site that uses it publicly require different permissions. Public publication also needs the workspace's general publishing permission and the specific public-with-tunnel permission for the relevant people, according to OpenAI's control guide. A private backend therefore does not, by itself, make the page that calls it private.
Before connecting real data, the service owner should define the minimum data and actions the Site needs, enforce access at the service, then test with non-sensitive data to see what each intended audience can actually do. OpenAI's tunnel documentation recommends such testing. Customer information also calls for the organization's own privacy and contractual review.
Storage, hosting and model processing are different questions
OpenAI says new Sites in workspaces configured for US or EU data residency use their workspace region for supported storage and hosting. For workspaces configured in other residency regions, that regional setting does not currently apply to Sites storage and hosting. Existing Sites are not automatically migrated. See the Sites workspace documentation.
Site hosting is separate from inference residency, which concerns where eligible model processing occurs. OpenAI's data-residency guide also distinguishes stored customer content from processing and external integrations. A region label in workspace settings should therefore not be read as a blanket location guarantee for every part of a Site or as automatic compliance with privacy law.
Before using live data, confirm which Sites features are available in the workspace, where new and existing Sites are hosted, what the Site stores, and where connected services handle data. The privacy owner can then assess the actual information flows and agreements.
Teams can start with one genuinely useful, low-sensitivity page rather than a large portal. Limit its audience, and write down who creates, edits, publishes and maintains the source data. Those decisions make a later rollout easier to justify.
This article's illustration was generated with AI. It does not depict an actual product interface or customer system.
