Rolling out ChatGPT Enterprise: a plan for the first 90 days

OpenAI's admin rollout guide lists its steps with a plain instruction: complete them in order for a new rollout. The table below puts that order on a calendar. The week counts are mine, not OpenAI's, and access requests, security review and procurement will move them more than anything in the product does. Each stage should end with something you can check in the admin console.

Start by naming owners. OpenAI's rollout guide asks for an owner for each part: workspace access, local runtime policy for its desktop and coding tools, Codex in the cloud, connected systems, and reporting and compliance. Its Academy adds the people side: an executive sponsor who sets the vision and unblocks budget, a project lead who runs the plan, departmental leaders, HR and learning teams, the workspace admins and a group of champions. If nobody on that list can make the day-90 decision, fix that before you configure anything.

Then sign-in. OpenAI strongly recommends SSO for all workspaces and SCIM for Enterprise workspaces, and says to pilot the login flow with a small group before a wide rollout. With SSO, staff sign in with their company credentials and your identity provider's rules apply, including multi-factor authentication and conditional access. SCIM (System for Cross-domain Identity Management) keeps workspace membership in step with your directory, so joiners arrive and leavers go without a ticket. Verify your email domain too, so only people on that domain can join.

Two details are easy to miss, and both are in OpenAI's documentation. Do not run Automatic Account Creation alongside SCIM: people who joined that way may not be managed by SCIM, so removing them from a directory group might not remove their access. And remove leavers in the identity provider, not only in the workspace, because if the directory still assigns them the next sync can add them back. Decide as well what happens to staff who already use a personal ChatGPT account on a company email address, since OpenAI treats merging those into the workspace as your choice.

Last, write down the baseline. OpenAI's Academy suggests metrics your teams already track, such as average ticket resolution time or hours spent on requests for proposal, measured again at 30, 60 and 90 days alongside survey feedback. Skip it and the day-90 review becomes an argument about impressions, and seat counts win that argument.

Set retention before anyone starts working in the workspace, and set it with legal in the room. OpenAI's documentation for ChatGPT Work, the agent inside the workspace, says conversations follow the workspace's retention setting and that deleting a chat schedules permanent deletion within 30 days, subject to published exceptions. Files saved to the Library, project files and saved memories each follow their own rules, and deleting a conversation does not delete a file saved to the Library. So the retention decision has to cover files, projects and memories as well as chats.

Then switch on compliance collection. The Compliance API is how your security, legal-hold and eDiscovery tools pull auditable records out of the workspace, and OpenAI is clear that it is for audit and investigation, not a productivity dashboard. OpenAI's ChatGPT Work cloud security page says Compliance Logs Platform records are available for 30 days, and its Compliance API guide warns against assuming that the source retention window replaces your own retention policy. So the collector has to be running into your security information and event management (SIEM) or eDiscovery system before the pilot starts. Switch it on in month two and the first month's records may already have aged out.

Review the workspace-wide settings while you are there. On Enterprise, owners decide for the whole workspace whether features such as web search, code execution in canvas, meeting recording and Codex are on. Web search, for example, may send search queries and general location information to Bing, which OpenAI says is not linked to user accounts. None of these is wrong to enable, but someone should decide each one on purpose and write the decision down. If data location matters to you, check what the region you buy actually covers: OpenAI says residency applies only to eligible content and supported workloads, and that connected apps and some processing can follow separate location rules.

OpenAI states that ChatGPT Enterprise does not train on business data by default and that the data is encrypted in transit and at rest. That answers the first question a security team asks. It does not answer the second, which is what your staff are allowed to put into it.

That is the use policy's job, and it should be signed before launch rather than written after the first incident. OpenAI's Academy gives a sensible skeleton. Staff check facts and own the final output. The policy says what data may and may not be shared, which uses are encouraged and which are off-limits. A working group from legal, security, privacy, HR, communications and the champions drafts it, executives approve it, and it carries a review date so new features do not outrun it. Our AI governance framework guide, linked at the end of this page, has a clause-by-clause template if you need a starting point.

US healthcare organisations need one more line in that policy, on protected health information (PHI). OpenAI's Academy tells admins to instruct staff not to put PHI into ChatGPT unless the workspace has signed a healthcare addendum. OpenAI's HIPAA guide for Codex ties PHI use to an applicable OpenAI Business Associate Agreement (BAA), says that agreement does not cover Codex in the cloud, and says it does not make another vendor's connected service a HIPAA-compliant destination. Under the HIPAA Privacy Rule, the assurances a covered entity obtains from a business associate must be documented in a written contract or other written agreement (45 CFR 164.502(e)). That describes the documents as read on 29 September 2026. It is not legal advice, and your privacy officer or counsel makes the call.

Connectors are where ChatGPT Enterprise starts earning its seat price, and where much of the risk sits, because they let it read, and sometimes act on, your other systems. OpenAI's advice is to begin a broad rollout with the categories teams use every day, such as email, calendar and file or document systems, and, whatever the first set, to start with read actions.

Two facts shape the permissions. Making a connector available in ChatGPT does not give anyone access to files or records they could not already reach, because the connected service's own permissions still apply to the account that signs in. And verifying your domain does not by itself stop staff connecting company accounts from a personal ChatGPT workspace. OpenAI documents a separate verified-domain restriction for supported apps that you have to activate, and existing connections are not disconnected when you do.

For each connector, OpenAI suggests recording the business owner, the permitted data, the read or write actions allowed, the authentication method and a contact for support or removal. I would add a review date. Before any write action goes live, OpenAI asks for a named owner, a review of scopes and service permissions, and a documented recovery path. Where an action changes a system of record, put a check in front of it: our write-up of the pattern where the model proposes and a deterministic check decides shows one way to build that step.

Custom GPTs need the same treatment. Admins control who can build GPTs and whether they can be shared with named people, groups or the whole workspace, and can restrict GPT actions to approved external domains; with no domains allowed, custom GPT actions cannot run. OpenAI also documents a route for migrating custom GPTs to plugins, so settle which of the two your builders should use before the pilot produces a pile of each.

Give the pilot to one or two teams with real, repeated work, and put them in a group of their own. OpenAI's documentation suggests groups for exactly this, naming a pilot cohort as an example, and a group synced from your directory keeps its membership honest. Pick two or three workflows tied to goals the business already has. OpenAI's Academy suggests mapping early work to two or three existing strategic themes, so staff can see a line from the tool to a number that matters.

Training decides whether the seats get used. OpenAI's Academy calls the first 30 days the best time to build habits, and recommends foundational training for everyone, a network of champions who coach peers and report friction, hands-on workshops on real tasks, and HR and learning teams folding AI training into existing paths. Give each workflow an owner who refines it and a written playbook (the problem, the prompt, the steps and the measure), so a win in one team can be copied by the next. Tell users what OpenAI's own guidance tells them: check outputs and important claims before using or sharing them, and approve consequential actions before they run.

If engineers are in scope, treat Codex as a track of its own. It sits behind separate workspace permissions and local policy for the desktop app, command line and IDE extension, and Codex in the cloud is off by default for Enterprise workspaces until an admin enables it. Our guide to rolling out coding agents to engineers, linked at the end of this page, covers that side.

Some pilot workflows will need a build rather than a setting, such as an agent that updates a system of record. Treat each one as an implementation of its own, with its own tests and owner. Our guide to what an AI implementation should produce in its first month sets out what to see each week.

Widen access in steps, and read the workspace analytics as a funnel. OpenAI's analytics guide tracks seats purchased, seats enabled, seats activated and weekly active users, and gives the rule I would follow: if progress slows at one stage, fix that bottleneck before investing further down. Bought but not enabled points to provisioning. Enabled but not active points to onboarding. Active but not weekly means people have not yet found a workflow worth coming back for.

Run the review monthly and keep it narrow. OpenAI's suggested rhythm is to check the funnel, read the trend, compare one lagging group with a healthy one, form a view of what is driving the difference, pick a single intervention and compare the two to four weeks before and after.

For the day-90 decision, count the money honestly. OpenAI's usage guidance says to compare the value of the improvement with the costs of the AI, setup, training and ongoing support, to include the time spent reviewing and correcting the work, and it notes that time saved is not automatically a cash saving. A slide of seat counts usually leaves that out.

Keep analytics and compliance records apart. OpenAI says workspace analytics is aggregated and does not expose message text, and its task insights, which group usage by kind of work, are on by default and can be switched off by an admin. Treat analytics exports as identifiable organisational data all the same, as OpenAI's documentation asks.

Each of these is cheap to prevent in the week the table puts it in, and costly to unpick once hundreds of people are working in the workspace.

1AYM is an OpenAI Select Partner, and the controls this guide puts first, identity, provisioning and audit, are core work for us. Our AI platform enablement case describes that work at a large international marketing agency, and its identity side includes the SCIM provisioning system we built, which ends a person's access when their HR record changes, across more than 1,000 users. The plan on this page is drawn from OpenAI's public documentation, and OpenAI has not reviewed it.

On a ChatGPT Enterprise rollout we would take the parts this guide calls expensive to fix later, sign-in and provisioning, retention and compliance collection into your own systems, connector permissions and the review rhythm, and build them as controls under our AI governance implementation work. That can be a small fixed-scope statement of work, which can start within a day of the scope being signed, or a longer engagement alongside your IT and security teams. If you have already scoped the rollout, we can resource it on contract from the associates who work with us, held to the same standard, and US clients can contract through our US entity. If a second opinion on your plan would help, book a call or email tayyeb@1aym.com.