ChatGPT Sites Makes Internal Apps Easy. Shadow IT Is Still Shadow IT.

OpenAI just made it dramatically easier to create an internal app. It did not change what it takes to own one. Those are different problems — and the gap between them is exactly where the trouble starts in a regulated environment.

On June 2, 2026, OpenAI's ChatGPT Business release notes introduced ChatGPT Sites, now in preview for ChatGPT Business workspaces with Codex access. The pitch is straightforward and, on its own terms, impressive: a team can ask Codex to create, iterate on, and deploy a lightweight full-stack JavaScript or TypeScript web app for internal use. The result isn't a mockup. Sites ship with a hosted site URL, Sign in with ChatGPT for access, and data and file storage — a working application, not a prototype.

Access stays internal to the workspace, and admins and owners can manage enablement and access through workspace settings and role-based access control. For Business workspaces, ChatGPT Sites is enabled by default, and admins or owners can disable created sites from Workspace settings > Sites.

This is good engineering, and the friction it removes is real. The distance from "we need a small internal tool" to "the tool exists and people are using it" used to be measured in tickets, sprints, and budget approvals. ChatGPT Sites collapses it to a conversation. That's worth taking seriously.

It's also worth being precise about what got easier — because creating an app and owning an app are not the same thing.

Why this is genuinely useful for SMBs and small teams

Start with where ChatGPT Sites is a clear win, because it is one.

Plenty of internal work is held together by a spreadsheet that three people email back and forth, a manual handoff that lives in someone's head, or no tool at all because building one was never going to clear the priority list. A small team that needs a shared intake form, a lightweight tracker, or a quick lookup tool has rarely had a good option — custom development is overkill, a SaaS subscription is overhead, so the work stays in the spreadsheet, and the spreadsheet quietly becomes load-bearing.

For that team, ChatGPT Sites is a genuine upgrade. When the realistic alternative is a spreadsheet, a manual process, or nothing, an app that actually runs — with a URL, sign-in, and storage — is strictly better. The bar it has to clear isn't "enterprise-grade software." It's "better than the spreadsheet," and it clears that easily.

That framing matters, because it sets the right expectation. ChatGPT Sites isn't trying to replace your cloud platform, your low-code suite, or your development organization. It's filling the gap below all of those — the long tail of small internal tools that never justified a real build. For SMBs and small internal teams, that gap is most of the gap.

But that is not the same bar a regulated enterprise has to clear.

Where the line is in regulated and enterprise environments

The line isn't "small teams good, big companies bad." It's about what the app touches.

An internal tool that helps three people coordinate a recurring task carries almost no risk, regardless of who builds it. The exposure changes the moment the app starts touching sensitive data, approvals, compliance workflows, operational records, or business-critical decisions. At that point you're no longer talking about a convenience tool. You're talking about a system whose behavior has consequences — and consequences are what governance exists to manage.

This is the distinction that gets lost. ChatGPT Sites keeps apps internal to the workspace and gives admins RBAC and a disable switch, which are real and appropriate controls for access. But access control is one question among many, and in a regulated context it's rarely the hardest one. The harder questions show up after the app is running and someone needs to account for it: Who owns this? Who is accountable when it's wrong? How do we know it still does what it's supposed to do?

A regulated enterprise — healthcare, financial services, a federal agency, pharma — operates under frameworks that assume change is controlled, traceable, and reversible. Those frameworks don't care how the software was created. They care whether someone is accountable for what it does in production. An app that was prompted into existence in an afternoon inherits the same accountability requirements as one that took a quarter to build — the requirements attach to the function, not the effort.

So the question a regulated buyer should ask isn't "can we build this in ChatGPT Sites?" The answer is usually yes. The question is "what happens to this app once it matters?"

Source control is the concrete version of the question

The cleanest way to see the gap is to ask one ordinary engineering question of a generated app: where is the source code, and what can you do with it?

In a governed software practice, that question has a long and boring answer, and the boringness is the point. The code lives in a repository. Changes go through review before they ship. The history is versioned, so you can diff what changed between any two points. You can run security and dependency scanning against it. You can roll back to a known-good state when something breaks. And — critically — someone other than the original author can read it, understand it, and maintain it, because the code is an asset the organization holds rather than a thing one person conjured.

Now ask the same questions of an app a colleague generated last month and then changed teams: Where is the code? Who reviewed it before it went live? Can it be exported? Is it versioned in a way you can diff? Has it been scanned? Can you roll back the last change? And if that colleague is gone, can anyone else maintain it — or is the next change another prompt against a codebase nobody on staff has actually read?

None of this is a knock on the generated code's quality. It may be perfectly good code. The issue is that "good code you can't account for" and "governed software" are different things, and only one of them survives an audit. The auditor's question is not only "does it work?" It's "how do you know it does what it's supposed to, who reviewed the last change, and how would you reverse it?" Those questions have answers when the source is owned. They don't have answers when the source is generated, used, and never owned by anyone.

This is the same failure mode that shows up in low-code platforms in regulated environments: the tool optimizes for time-to-first-deployment, and the organization discovers later that nobody priced in the audit trail.

How shadow IT changes when it looks like a real app

Shadow IT isn't new. What ChatGPT Sites changes is how it presents.

The classic forms of shadow IT announce themselves. A spreadsheet that's become a system of record looks like a spreadsheet — clearly informal, clearly outside the governed stack, clearly something IT would flag if they saw it. A rogue SaaS subscription shows up on a credit card statement or a vendor security review. Both are problems, but both are legible problems: they look unofficial, so the organization has a reflex to treat them as unofficial.

A ChatGPT Site doesn't look unofficial. It has a hosted URL, real sign-in, stored data, and a polished interface. It looks like an internal application — because, functionally, it is one. That polish is genuinely useful for the people using it, and it's also exactly what makes the governance question easier to skip. A spreadsheet acting as a production system feels obviously wrong; an app that looks like every other internal app feels obviously fine. The risk hasn't gone up because the tool is bad. It's gone up because the tool is good enough to stop looking like shadow IT while still being ungoverned.

That's the shift worth naming. The danger isn't a flood of junk. It's a small number of polished, useful, widely-adopted apps that quietly become load-bearing — handling an approval, holding an operational record, feeding a decision — without ever passing through the review, ownership, and accountability that a load-bearing system is supposed to have. The better the tool, the more invisible the gap.

The right enterprise question: what stays, what gets guardrails, what graduates

The useful response isn't to disable ChatGPT Sites, and it isn't to wave it through. It's to decide, deliberately, what belongs in each of three categories.

What stays in ChatGPT Sites. Low-stakes internal tools where the alternative was a spreadsheet or nothing: coordination aids, lookups, lightweight trackers, throwaway utilities. If the app touches no sensitive data, gates no approval, and informs no consequential decision, ChatGPT Sites is a fine home and the speed is pure upside. Let it be easy.

What needs guardrails. Apps that are useful and probably fine, but touch something that warrants a check before they spread. This is where the admin controls earn their keep — RBAC to scope access, the Sites view in workspace settings to see what's been created, and a light internal norm about what a Site is allowed to handle. The goal isn't a heavy approval process; it's visibility, so a Site that starts drifting toward load-bearing gets noticed before it gets relied on.

What should graduate into governed enterprise software. When an app starts touching sensitive data, compliance workflows, operational records, or business-critical decisions, the right move isn't to govern it in place — it's to recognize that it has outgrown the category. At that point the value of ChatGPT Sites was as a prototype: it proved the tool was worth having and showed exactly what it should do. The production version belongs in a place where the code is owned, reviewed, versioned, scanned, and maintained by the organization rather than the original author. Knowing where that line sits — and building the production version on the right side of it — is the platform-neutral engineering judgment that no release note makes for you.

The discipline is in drawing the lines, not in picking a side. Most apps will sit comfortably in the first category. A few will need the second. The ones that reach the third are the ones worth being deliberate about — and they're also the ones most likely to slip through, because by the time they matter, everyone's already depending on them.

What this means for buyers

ChatGPT Sites is a strong addition to the workspace, and for a lot of internal work it's the best option a small team has had. The mistake isn't adopting it. The mistake is letting the ease of creation stand in for the discipline of ownership — and then discovering, in production or at audit, that they were never the same thing.

The custom-build era enforced a discipline that the prompt era quietly removes. When standing up an internal app meant a project, the ownership questions got answered because you couldn't ship without confronting them: where the code lives, who reviews it, how you roll it back. When it takes a conversation with Codex, nothing forces that conversation — so it gets skipped, and the gap surfaces later, in the exception case, on a quarter when no one's watching.

So the lesson runs the other way from how it'll be read. The speed ChatGPT Sites unlocks should free your teams to spend more attention on the small set of apps that graduate into governed software, not give everyone permission to treat every generated app as if it were already governed. Use it freely for what it's good at. Be deliberate about the moment an app stops being a convenience and starts being a system.

Easy internal app creation is useful. Mistaking it for software ownership is where the cost begins.

What is ChatGPT Sites?

ChatGPT Sites is a feature introduced in OpenAI's June 2, 2026 ChatGPT Business release notes, in preview for ChatGPT Business workspaces with Codex access. It lets a team ask Codex to create, iterate on, and deploy lightweight full-stack JavaScript or TypeScript web apps for internal workspace use. Sites include a hosted site URL, Sign in with ChatGPT for access, and data and file storage.

Who can use ChatGPT Sites and how is access controlled?

It's available to ChatGPT Business workspaces with Codex access, and it's enabled by default for Business workspaces. Access to created apps stays internal to the workspace, and admins and owners manage enablement and access through workspace settings and role-based access control. Admins and owners can disable created sites from Workspace settings > Sites.

Is ChatGPT Sites a good fit for my team?

It's a strong fit when the realistic alternative is a spreadsheet, a manual handoff, or no internal tool at all — typically low-stakes internal tools for SMBs and small teams. It's a poor fit, as-is, for apps that touch sensitive data, approvals, compliance workflows, operational records, or business-critical decisions, because those require software ownership and governance that easy creation doesn't provide.

Why isn't a ChatGPT Site the same as governed enterprise software?

Governance attaches to what an app does, not how it was made. Governed software has owned source code that can be reviewed, versioned, diffed, scanned, rolled back, and maintained by someone other than the original creator — and a clear answer to who is accountable in production. A generated internal app can be perfectly good and still lack all of that, which is the gap that matters once the app starts handling anything consequential.

How should an enterprise decide what to do with a ChatGPT Site?

Sort apps into three categories. Low-stakes tools stay in ChatGPT Sites and benefit from the speed. Useful apps that touch something sensitive get guardrails — RBAC, visibility through Workspace settings > Sites, and a light norm about what a Site may handle. Apps that touch sensitive data, compliance workflows, operational records, or critical decisions should graduate into governed enterprise software the organization owns and maintains.