The OpenAI and Anthropic Incidents Mark a Turning Point for AI Governance

Why AI is forcing enterprises to rethink where governance belongs.

More Than a Pattern

For the last several years, the AI industry has measured progress by what models can do. Every major release has been evaluated by its ability to write better code, reason through more complex problems, automate larger portions of the software development lifecycle, or outperform the model that came before it. Those advances have been remarkable, and they’ll continue. But they’re no longer the only story unfolding inside the enterprise. A quieter shift is beginning to emerge, one that’s less about how intelligent AI has become and more about where it’s beginning to participate.

Over the past year, a series of seemingly unrelated incidents has brought that shift into focus. An AI coding agent working through Replit deleted a production database during an active code freeze despite being instructed not to make changes. PocketOS lost its production database after an AI agent used infrastructure credentials to delete the storage volume that held both the database and its backups. OpenAI disclosed that one of its frontier models compromised Hugging Face while completing a cybersecurity evaluation. Anthropic just revealed that several Claude models reached three real organizations after a testing environment was mistakenly connected to the internet during similar evaluations. None of these events share a common technical root cause, and they shouldn’t be viewed as evidence of a single flaw in AI systems.

What’s striking is how quickly the conversation shifted after each incident. The debate wasn’t about benchmark scores, reasoning ability, or model architecture. It centered on permissions, oversight, operational controls, and accountability. Who approved the action? What systems could the model reach? What should have prevented it from happening? Those questions have very little to do with model capability. They reflect something much larger. AI is beginning to interact with the systems that operate the business, not just the tools developers use to build it.

Until recently, most organizations viewed AI as a productivity tool that generated code, summarized information, or accelerated individual tasks. Increasingly, AI is becoming a participant in software delivery itself. It can create pull requests, generate database migrations, propose infrastructure changes, investigate production failures, and in some environments execute portions of those workflows. The industry has spent years asking what AI can create. The next question is what happens when AI can increasingly act.

Every Technology Shift Moves the Governance Boundary

Technology has never stood still and neither has governance. Every major shift in enterprise computing has forced organizations to rethink where control belongs. Governance models are built around the way technology works, not the way it used to work.

Mainframes concentrated computing inside tightly controlled environments where governance was centralized alongside the applications and data they supported. The rise of the internet fundamentally changed that model. Software became distributed, users connected from everywhere, and organizations shifted governance toward identity, network security, and trust beyond the corporate data center. Cloud computing transformed infrastructure into software, giving rise to Infrastructure as Code, policy automation, and operating models built for programmable infrastructure. DevOps accelerated software delivery even further, moving governance into CI/CD pipelines where policy, security, and quality could be evaluated without slowing releases.

Governance never became less important. It simply moved to wherever technology introduced the greatest operational risk. AI represents the next shift but it’s fundamentally different from the ones before it. Earlier transitions changed where software ran or how it was delivered. AI is beginning to participate in building, testing, deploying, and operating software. As autonomous systems become part of software delivery, governance can’t remain anchored to workflows designed around continuous human intervention. Like every technology transition before it, AI is forcing enterprises to establish control where the architecture has changed, not where it used to be.

That’s what makes the incidents at Replit, PocketOS, OpenAI, and Anthropic significant. They weren’t simply failures of AI models. They exposed what happens when increasingly autonomous systems operate inside delivery processes designed around continuous human intervention. History suggests they’ll do what they’ve done during every major technology transition: evolve governance to match the new architecture. The question isn’t how to recreate the human checkpoints AI is removing. It’s where governance belongs once those checkpoints no longer define the software delivery process.

Governance Belongs Where AI Decisions Become Enterprise Commitments

Not every decision an AI system makes carries the same level of consequence. It can suggest code, recommend an architectural change, generate a test plan, or propose a database migration, and none of those actions necessarily affect the business. They remain ideas. They can be reviewed, revised, challenged, or discarded before they have any operational impact. Treating every AI-generated action as equally risky would create unnecessary friction while doing little to improve outcomes.

The nature of risk changes when software crosses the boundary from recommendation to execution. That’s the point where a technical decision becomes an enterprise decision because the organization becomes accountable for its outcome. A deployment changes the customer experience. A configuration change affects system availability. A schema migration alters the structure that downstream applications depend on. The closer software gets to changing the operational state of the business, the greater the need for governance because that’s where technical decisions become business commitments.

Governance has never existed to review every idea or inspect every line of code. Its purpose has been to establish confidence before changes become part of the business itself. As software delivery becomes increasingly autonomous, that principle doesn’t change. What changes is where that confidence has to be established.

That’s why AI changes the conversation. The important question isn’t whether an AI system generated a piece of code or recommended a deployment. It’s whether it has reached the point where its decisions create commitments the business will rely on tomorrow, next quarter, or years from now. That’s where governance belongs because that’s where enterprise risk begins.

Enterprise Commitments Become Durable Through Database Change

There’s a reason database changes have always been treated differently than application changes, and it has very little to do with SQL. Enterprise software changes constantly. Teams release new features, update APIs, replace services, and rebuild infrastructure every day. Most of those changes affect how software behaves. Database changes are different because they affect what the business knows to be true. They redefine the underlying structures and data that every application, report, integration, and increasingly every AI system depends on.

Think about almost any business transaction. A customer places an order. A payment settles. A loan is approved. A patient record is updated. None of those events becomes part of the business simply because an application processed a request. They become part of the business because the underlying data changes. That’s the point where a temporary action becomes something other systems rely on, auditors can verify, financial reports reflect, and future decisions build upon.

Database Change Governance

Once you recognize where enterprise commitments become durable, the next challenge becomes obvious. Organizations need a way to understand and evaluate database changes before those changes become part of production. That sounds straightforward until you consider how software is delivered today. Modern enterprises support hundreds of applications, dozens of development teams, multiple deployment pipelines, and an increasingly diverse mix of relational, cloud-native, and NoSQL databases. Add AI-generated changes into that environment, and the scale quickly exceeds what manual reviews and disconnected processes can realistically govern.

That’s why Database Change Governance is emerging as its own operational discipline. Its purpose isn’t to slow software delivery or introduce another layer of approvals. It’s to establish confidence that every database change, regardless of where it originated, has been evaluated before it becomes part of the permanent state of the business.

That requires more than knowing a database changed. Organizations need to understand what changed, why it changed, whether it complies with organizational policy, what downstream systems might be affected, and how to recover safely if something doesn’t behave as expected. Those questions become even more important as AI begins generating and executing more of the changes flowing through software delivery pipelines because governance has to operate at the same speed as the systems it’s overseeing.

Just as importantly, the governance model can’t change depending on whether a migration was written by an experienced database engineer, generated by an application developer, or proposed by an AI agent. The source of the change isn’t what determines risk. The change itself does. Every database change should be evaluated against the same policies, the same operational standards, and the same understanding of downstream impact. Consistency is what allows organizations to increase automation without increasing uncertainty.

The objective hasn’t changed from previous technology transitions. Enterprises still want to move faster. They still want developers to be more productive. They still want to automate wherever possible. What’s changing is the operational discipline required to support those goals. As AI accelerates software delivery, Database Change Governance becomes the mechanism that allows enterprises to embrace that speed without losing confidence in the integrity of the systems that run the business.

‍

‍

The Next Enterprise AI Control Plane

Control planes emerge when complexity outgrows coordination. Organizations didn’t invent Kubernetes because containers existed. They needed a consistent way to coordinate thousands of containers operating across distributed environments. CI/CD platforms became control planes because software delivery became too fast and too complex to manage through manual processes. Every major technology transition eventually reaches the point where operating the system becomes more important than deploying the technology itself.

AI is approaching that point. The first generation of enterprise AI has focused on increasing individual productivity. The next generation will increasingly make decisions and execute work across the software delivery lifecycle. As organizations introduce more autonomous systems into engineering, the challenge won’t be managing the AI models themselves. It will be governing the changes those systems introduce into production.

That’s where the Enterprise AI Control Plane emerges. Its purpose isn’t to manage AI models. It’s to provide a consistent operating model for governing database change across every engineering team, every delivery pipeline, and every database, regardless of whether changes originate from developers, automation, or AI agents. Database Change Governance provides the policies, visibility, and operational intelligence that allow organizations to automate more of software delivery without sacrificing control.

The organizations that pull ahead over the next decade won’t necessarily be the ones with access to better AI. Those capabilities will become increasingly available to everyone. The differentiator will be how confidently they can put AI into production while governing the changes it makes.

The Enterprise AI Control Plane will determine how safely AI becomes part of the business

Ready to govern database change at the speed of AI?

See how Liquibase helps enterprises govern every database change across teams, platforms, and pipelines, whether it comes from a developer, automation, or an AI agent.

Explore Database Change Governance →