Lungile Mginqi, digital transformation strategist. Somewhere in your organisation this quarter, a small team will build something impressive in an afternoon. A business analyst will describe a problem to an AI tool and, by the end of the day, there will be a working application: a dashboard or a small engine that does something genuinely useful. The demo will land well. Someone will say the words every executive now wants to hear: we built this ourselves, and it only took a few hours.Then the hard questions will go unasked.Who owns the architecture? Who tested the security? Where is the documentation? What happens when it breaks at month-end and the person who prompted it into existence has moved on? The thing that took an afternoon to build may have no owner, no support model and no audit trail, yet sits underneath a process the business depends on.This is the central paradox of enterprise AI: AI has compressed the effort required to create software. It has not compressed the burden of owning it.AI wrote the code. A person will decide what it becomes.Call it the creation-ownership gap, and it's becoming one of the most important leadership problems in the enterprise.The first idea to retire is that faster creation means better capability. It does not.GitHub's own usage data now show AI writing close to half the code committed inside many enterprise codebases. On the surface, that's a productivity story. Underneath, it's a maturity story: the people producing that code were never trained to think about scale, security, resilience or support, because until recently they never had to. Their tools improved dramatically. Their engineering discipline did not, because nobody asked it to.The first idea to retire is that faster creation means better capability. It does not.That gap was tolerable while the output stayed small, internal and disposable. Most business-built software still sits at that level, functional enough to impress a demo audience, nowhere near governable enough to carry real consequence. A prototype needs to prove an idea, not carry enterprise-grade architecture. This software isn't the problem. What happens to it next is.What happens next is that somebody senior starts asking whether it can be sold.A growing number of CIOs are no longer just tolerating business-built software. They are asking whether it can be commercialised: packaged, licensed, sold, carried to market as reusable enterprise IP. That ambition isn't naive. CIOs have been told for years to stop running a cost centre and start running a profit centre, sitting on real intellectual property, and AI has simply made that old ambition feel newly achievable. The trouble is that it's arriving well ahead of the organisational capability required to deliver on it responsibly.Gartner's 2026 research is blunt: enterprises that let AI-generated code, content and design accumulate without disciplined review already face rising maintenance costs and delayed upgrades as unmanaged technical debt erodes the AI investment's returns. An asset that runs quietly inside one department is rarely good enough to survive a customer's due diligence, a regulator's audit or an acquirer's technical review. Commercialisation is a capability decision, not a governance formality, and most enterprises haven't made it yet.AI can build the asset. Deciding whether it's ready to sell is still a person's call.The bottleneck, in other words, is rarely the model. It's the distance between what an enterprise can create and what it's equipped to own, support and sell.Ownership isn't paperwork bolted on after the fact; it's the line between an asset and a liability wearing a demo's clothing.Governable ownership means the enterprise understands why the asset exists, can operate and support it, has the evidence required to govern it, and retains the knowledge and rights needed to change, transfer or retire it.A codebase isn't ownership. Neither is a working demo, and a successful release doesn't prove operability. None of it shows the enterprise can recover, support, change or sell the asset without the original builders in the room.The risk does not begin when someone creates a prototype. Experimentation must remain fast, and a disposable prototype should not carry a business-critical platform's control burden. The risk begins when experimentation becomes operational dependency, or commercial ambition, without a deliberate change in ownership, controls and support. Governance should follow consequence, not novelty.It's the next wave of shadow IT: not only unsupported spreadsheets and rogue databases, but AI-generated software multiplying faster than architecture, cyber, risk and audit can absorb it, some of it already dressed for a shop window it was never built to survive.Once the problem is understood as a capability and ownership failure rather than a coding failure, an inconvenient question follows: how did the enterprise lose that capability?For the past decade, the answer was commoditisation, and it was the right call. Delivery went to vendors. Integration went to systems integrators. The plumbing of IT became someone else's problem, lowering cost, adding flexibility, and freeing people who once wired systems together for higher-value work. Nobody should apologise for that. It worked.What it also did was move the muscle of building and owning software outside the building. Architecture judgement, production discipline, the intelligence required to govern an estate: all of it came to live with the vendor, not the enterprise. That trade-off was survivable for a decade, because the enterprise was never asked to build for itself again.AI has just asked it to build again, and asked cheaply, of anyone with a laptop and a prompt.That is the CIO's dilemma: not whether to adopt AI, but whether an organisation that spent a decade training itself to buy can rebuild the discipline to own what it can now create, before the commercialisation ambition outruns whatever is left of that muscle.The organisation that wins will not be the one with the most AI tools. It will be the one that can convert rapid creation into durable, sellable enterprise capability, and prove it the moment somebody checks.For a decade the enterprise bought software cautiously, through committees, blaming the vendor when it broke. Now it can build software itself, at speed, with almost nobody left to say slow down. Neither extreme was ever the actual goal. Owning what you build always was.So, the test is uncomfortable.If your CEO asked how many of the applications already running this business were built by someone with no formal engineering training, would you know the number, or even where to look?If your board asked which AI-built applications are already being positioned as the profit centre IT was promised it would become, could you name them, and defend their readiness to be sold, not merely used?And if you held every AI-built asset in this business to the standard you once demanded of a vendor, how many would actually survive?The next enterprise crisis will not be caused by AI that was too weak.It will be caused by software someone decided to sell before anyone decided whether it was actually theirs to sell.