• By Dan Mintz. 3x founder, Wharton MBA, MIT MS in Machine Learning.

• Leading enterprise AI transformation expert with experience in many projects, operating in the intersection of business strategy and AI technologies to drive impactful results.

• The blueprint: business strategy should drive the AI transformation.

Introduction

For the last two years, most enterprise AI programs have been organized around a single question: what can the model do? That was the right question in 2024. It is the wrong question now.

Something else changed while attention stayed on model benchmarks. The gap between describing a piece of internal software and having it running on a URL has nearly closed. OpenAI shipped Sites inside ChatGPT, where a user describes what they want and receives a hosted, live application. Anthropic and Google are moving in the same direction. Within a year this will be a standard capability across every major assistant, not a differentiator.

That matters for transformation leaders for a specific reason. The reason AI pilots stall is rarely that the model underperformed. It is that changing a workflow requires a piece of software nobody has time to build. When a business user can build it themselves in an afternoon, the economics of the entire transformation portfolio change. So does the risk profile.

What actually changed with tools like ChatGPT Sites?

The unit of work shifted from writing code to describing intent. A user opens a project, describes the application they want, and the assistant builds, hosts, and returns a live link.

In the demonstration that prompted this piece, the build times were the point:

• A full business site with lead capture, generated imagery, and a private inquiry inbox: roughly 15 minutes.

• An interactive analytics dashboard, reverse-engineered from an agency's reference dashboard and rebuilt against a live data API: roughly 15 minutes.

• A multi-branch dynamic form with conditional routing and lead scoring: roughly 20 minutes.

• An internal quoting application, built by reading an existing Excel pricing model and extracting its formulas, complete with per-user login and discount guardrails that block out-of-policy offers.

• An expense application with photo capture, AI receipt extraction, authentication, and a managed database.

Three properties matter more than the speed.

The source files stay yours. The generated application lives in a project folder you control. Every file is visible and portable to another host. This is not a locked template. It is a codebase you happen not to have typed.

The logic is inspectable. The dashboard's number-crunching is saved as readable Python scripts, not hidden inside a black box. For anyone who has tried to audit a spreadsheet with eleven years of nested formulas, this is a material improvement in transparency, not a reduction in it.

It reads existing artifacts. The quoting tool was built by handing over the spreadsheet the sales team already used. The dashboard was built by pointing the assistant at a dashboard someone else had designed. The system meets your organization where its logic already lives.

Why is the internal software backlog the real bottleneck in AI transformation?

Because most workflow change requires a small piece of software, and small pieces of software never clear the queue.

Walk the floor of any mid-sized enterprise and you will find the same pattern. The process that needs fixing is understood perfectly by the people doing it. They can describe the fix in two sentences. The fix requires a form, a calculator, a dashboard, or a portal. That request enters an IT backlog ranked against ERP upgrades and security remediation, and it does not surface for three quarters, if ever.

So the business does what businesses do. It builds the workaround in Excel. The workaround becomes load-bearing. Eleven versions circulate. Pricing changes and four of them stay stale.

This is the actual texture of enterprise operations, and it explains why so many AI initiatives produce a pilot that everyone praises and nobody uses. The model was never the constraint. The last mile was.

When the last mile costs an afternoon instead of a quarter, the portfolio math inverts. Initiatives that were never worth a business case become trivially worth doing. The long tail of process improvement, which is where most cumulative value actually sits in a large organization, becomes addressable for the first time.

What does this look like inside a mid-sized or large enterprise?

It looks like the work that was always too small to fund. Some concrete shapes:

Claims intake triage at a regional insurance carrier. First-notice-of-loss currently arrives through a generic web form and gets manually sorted by a coordinator who reads each one and assigns it. Replace it with a dynamic form that branches on loss type, policy class, and estimated severity, routing directly to the right adjuster queue and flagging suspected total losses on submission. The routing rules already exist in a coordinator's head and a laminated card. The build is a description, not a project.

Quote configuration at an industrial distributor. The pricing model lives in a spreadsheet with volume breaks, freight assumptions, and regional surcharges. Sales reps each keep a personal copy. Hand the spreadsheet to the assistant, get back a web application with per-rep login, live calculation, hard blocks on discounts outside policy, and a customer-ready PDF. One version of pricing truth, updated centrally.

Shift handover in plant operations. Maintenance handover happens on a whiteboard photographed and sent over WhatsApp. Build an internal tool where the outgoing shift logs open work orders, equipment status, and safety notes, and the incoming shift sees a structured view with outstanding items carried forward. No integration project, no vendor selection.

Vendor onboarding at a hospital network. Procurement chases insurance certificates, credentialing documents, and signed terms by email across dozens of suppliers. Build a portal with a folder per vendor, a status view, and an outstanding-document list that updates as items land.

Benefits eligibility in HR shared services. A benefits advisor answers the same eligibility questions all day, applying rules that differ by employment class, tenure, and jurisdiction. Build an internal calculator that encodes the rules and returns a plain answer with the applicable policy reference. The advisor's time moves to the exceptions.

None of these are transformational alone. That is exactly the point. Two hundred of them, shipped over eighteen months by the people who understand the processes, compound into something no top-down program delivers.

Why does this drive adoption better than training programs do?

Because people use tools they built for their own pain, and they tolerate tools that were handed to them.

Most enterprise AI adoption programs follow the same arc. Licenses get provisioned. Training sessions get scheduled. Usage dashboards show a spike in week one, a decline in week four, and a plateau where a small group of enthusiasts carry the average. The organization concludes that people need more training. People did not need more training. They needed the tool to solve a problem they actually had.

Building changes the relationship. When a claims coordinator builds the triage form, three things follow. She knows exactly what it does, because she specified it. She is invested in it working, because it is hers. And she iterates, because the cost of a change is a sentence rather than a change request.

There is a second-order effect that matters more for transformation leaders. Building a working tool teaches AI fluency faster than any curriculum. The user learns what these systems are good at, where they need precise specification, and where they fail. That knowledge transfers to every other AI use case in the organization. You get capability development as a by-product of shipping useful things.

What breaks if you let this run without governance?

Everything that broke with spreadsheets, faster, and with worse exposure. This is the section transformation leaders should read twice.

The failure mode is not bad software. Generated applications are often cleaner than what an overloaded internal team produces under deadline. The failure mode is an ungoverned estate.

Data exposure is the first-order risk. The expense application in the demonstration stored credentials as environment variables, including a Google service account key and an API key. That is standard practice and reasonable in context. Now picture four hundred business users across your organization doing the same thing, some of them pasting production database credentials into a tool nobody in security knows exists. The applications themselves are fine. The credential sprawl is not.

Nobody knows what exists. Traditional shadow IT was discoverable because it needed a purchase order. This does not. Applications get created inside an assistant subscription your organization already pays for, and they never touch procurement. Within a year you can have hundreds of live internal tools with no inventory.

Business logic fragments again. The quoting application solves the eleven-spreadsheet problem for one team, then five other teams build their own quoting tools with subtly different assumptions. You have replaced spreadsheet sprawl with application sprawl unless someone owns the canonical logic.

Ownership decays. The coordinator who built the triage form leaves. The form still runs, still routes real claims, and nobody knows how it decides. This is the same orphaned-macro problem enterprises have carried for decades, now with more surface area.

Regulatory obligations do not pause. If the tool processes personal data, GDPR obligations attach. If it touches patient information, HIPAA attaches. If it produces a figure that lands in a financial statement, SOX controls attach. The tool being easy to build has no bearing on any of this.

The response is not to block the capability. Organizations that prohibit it get the same activity with worse visibility. The response is a lightweight control layer, built before volume arrives rather than after an incident:

• A registry. Every internal application is recorded with a named owner, its purpose, and what data it touches. Registration takes two minutes and is the condition of being allowed to build.

• A data tier policy. Clear rules on what data classes may enter a self-built tool. Public and internal data proceed freely. Customer, personal, financial, and regulated data require review.

• A credential standard. Business users never hold production credentials. Provide scoped, read-only, revocable service accounts through a defined request path.

• A promotion path. When a tool crosses a usage or criticality threshold, it graduates to IT ownership with proper version control, monitoring, and support. Define the threshold in advance so graduation is routine rather than a negotiation.

• A retirement process. Applications expire unless the owner re-confirms them. Unconfirmed tools go dark. This is the single cheapest control and the one most often skipped.

• A canonical logic register. Pricing rules, eligibility criteria, and risk scoring have one authoritative home. Tools reference it rather than re-implementing it.

This is governance proportionate to the risk, not an approval committee. The objective is an inventory you can reason about, not a queue that recreates the bottleneck you just removed.

How should a transformation lead sequence this?

Start with the backlog you already have, not with a platform decision.

Pull the list of small internal requests that IT has declined or deferred over the past two years. That list is your pipeline, already validated by the business and already prioritized by frustration. Pick six, spread across functions, where the process owner is capable and the data is non-sensitive.

Run those six with the process owners building, not with IT building for them. Put the governance scaffolding in place during those six, while the volume is small enough to get the design right. Measure whether the workflow changed, not whether the tool was pretty.

Then widen access deliberately, function by function, with the registry and data tier policy already operating. The organizations that get this wrong widen first and govern after an incident. The organizations that get it right build the control layer while the estate is still small enough to count.

The stakes

The capability to turn a described workflow into running software is about to become ordinary. ChatGPT Sites is the current example, and Anthropic and Google are building toward the same thing. Within a year, no organization will have an advantage from access to this. Every organization will have it.

The advantage will come from organizational readiness. Whether your process owners know how to specify what they need. Whether your governance can absorb hundreds of small applications without either strangling them or losing track of them. Whether your transformation portfolio is structured to capture long-tail process value rather than only funding large programs.

That is a business design question before it is a technology question. It always was.

FAQ

What are ChatGPT Sites?

It is a capability inside ChatGPT that builds and hosts a working website or web application from a description. The user provides the requirements in natural language, and the system returns a live URL along with the underlying project files.

Is this different from a no-code platform?

Yes, in two ways that matter. There is no visual builder to learn, since the interface is a description of what you want. And the output is a real codebase you own and can migrate elsewhere, rather than logic locked inside a vendor's environment.

Can these applications handle authentication and data storage?

They can. The demonstrated expense application included user login and a managed database without the builder configuring either. That capability is precisely what makes the governance question urgent, because tools that store real data carry real obligations.

Does this replace the IT function?

No. It changes what IT should spend its time on. Routine small-tool requests move to the business, and IT focuses on integration, security architecture, the canonical logic register, and the promotion path for tools that become operationally critical.

How should an enterprise decide where to apply this first?

Start from the strategic outcome, then work backward to the workflows that drive it. The common failure is picking use cases by technical appeal rather than business impact. My enterprise AI transformation work begins with mapping which processes actually move the numbers leadership is accountable for, then identifying which of those are blocked by missing internal tooling.

What does a governance framework for self-built internal applications look like in practice?

It is a registry, a data tier policy, a credential standard, a promotion path, and a retirement process, sized to the organization rather than copied from a template. I design these control layers to be light enough that business users comply willingly, because governance people route around is not governance.

We have run AI pilots that did not scale. Why would this be different?

Usually it is not the technology that failed, it is that the pilot never changed how work is actually done. The diagnostic I run identifies where the transformation is stalling, whether that is missing tooling, unclear ownership, misaligned incentives, or a business case that was never connected to strategy in the first place. The fix follows the diagnosis, not the other way around.