In the early 1990s, the economist W. Brian Arthur published a series of papers on a phenomenon he called "lock-in." His observation was deceptively simple: when a new tool enters an organization, we tend to measure its worth by its immediate, isolated output. A typewriter is faster than a quill. A word processor is faster than a typewriter.
What we fail to notice is what happens next. As the tool takes root, the rest of the enterprise quietly adapts around it. Workflows adjust. Expectations shift. The technology ceases to be something you simply use; it becomes the subtle architecture governing how you operate.
We are currently watching this exact pattern play out across corporate America, under the banner of enterprise AI adoption.
When a Chief Executive asks about their company's AI strategy, the answer almost always comes back as an inventory—a spreadsheet listing dozens of pilot programs, vendor subscriptions, and custom assistants. It looks organized. It feels controlled. But this inventory conceals a fundamental misunderstanding of what is actually occurring.
Consider a standard customer service organization. They introduce a generative AI assistant to help agents resolve customer complaints. Before the tool, the average issue takes 45 minutes to resolve. Afterward, it takes 30 minutes. That fifteen-minute improvement may not sound transformational at first, but if the organization handles 100,000 incidents a year, those fifteen minutes represent 25,000 hours of recovered employee capacity. At an average loaded labor cost of $48 an hour, that equates to approximately $1.2 million in annual productivity value.
This is exactly the kind of outcome executives want from AI. The organization gains more capacity, lowers operating cost, improves response times, and increases productivity without a corresponding increase in headcount. The pilot becomes a production service, more employees begin using it, service-level expectations are adjusted, and staffing assumptions begin to reflect the new level of productivity. Customers may even begin to experience faster service as the new normal.
Over time, however, something more important begins to happen. The business starts to depend on the AI capability. The assistant may retrieve customer information from the CRM, search knowledge repositories, access product information, call internal APIs, authenticate through enterprise identity services, use an MCP service to interact with other systems, run on shared cloud infrastructure, and rely on a third-party model provider.
What began as a productivity experiment has now become part of the machinery through which customer service operates. The organization did not simply introduce an AI tool. It changed its architecture.
AI Capability Is the New Player in the Enterprise Ecosystem
Enterprise Architecture has always been concerned with understanding how the pieces of the business fit together. It looks at which business capabilities the organization requires, which business processes enable those capabilities, which applications support those processes, what data those applications consume and create, how systems communicate, which platforms support them, and where third parties participate in the ecosystem.
For years, that relationship was relatively familiar:
AI changes that picture because it introduces a new type of capability that reaches across several of those layers at the same time. An AI capability can participate directly in a business process while consuming enterprise data, interacting with multiple applications, invoking APIs or MCP services, running on shared platforms, and depending on external model providers. At the same time, employees, workflows, applications, and even other AI capabilities may begin depending on it.
This makes AI both a consumer of the enterprise ecosystem and something the enterprise itself increasingly consumes. It is not simply another application feature. It becomes a distinct participant in the way the business operates, which is why AI Capability needs to be treated as a first-class citizen in the enterprise architecture.
The significance is not simply the addition of another box to an architecture diagram. The significance is that AI creates new relationships across the organization, and those relationships begin to matter as soon as the business relies on them for productivity, decision-making, customer experience, or revenue-generating activities.
When Productivity Becomes Dependency
Return to the customer service example. The AI assistant is saving 25,000 hours annually, and management has incorporated those gains into normal operating expectations. The organization may now plan staffing, customer service levels, and workload distribution around the assumption that those productivity improvements will continue.
If the service becomes unavailable, the business impact becomes visible very quickly. If the team processes approximately 400 incidents during a typical business day and resolution time rises from 30 minutes back to 45 minutes, the organization suddenly requires approximately 100 additional labor hours each day to process the same workload. At $48 per hour, that represents roughly $4,800 in lost productivity per day, before considering delayed customer responses, missed service levels, additional escalations, or the effect on customer satisfaction.
Nothing has necessarily been hacked, no confidential data has necessarily been exposed, and there may be no cybersecurity incident at all. Yet the business still has a meaningful operational problem.
This is where the distinction between security governance and architecture governance becomes important. Security asks whether the AI capability is adequately protected, while Enterprise Architecture asks what happens to the enterprise when that capability changes, fails, or disappears. Both are essential, but they answer different questions.
Consider What Happens in Finance
Now imagine the model provider releases a major update. The service remains available, the security controls are still functioning, and no data has been exposed, but the updated model begins interpreting certain historical patterns differently.
The organization now has a much harder question to answer: what business processes, decisions, and systems could be affected by that change? If those dependencies have never been mapped, the answer may not be obvious. A change that appears isolated to the AI service could influence Revenue Recognition, Finance, Planning, executive reporting, downstream analytics platforms, or another AI capability relying on its output. The impact may cross several organizational boundaries before anyone recognizes that the original model change was the cause.
The important question is therefore no longer simply whether the AI works or whether it remains secure. The question becomes whether the organization understands what depends on the way that AI behaves and what happens across the enterprise when either side of that dependency changes.
An AI Inventory Is Not an Architecture
This is why the current focus on creating AI inventories, while important, is only a starting point. An inventory can tell an executive that the organization has 63 AI solutions, but that number alone says very little about how important those solutions are to the business.
Perhaps 40 of those solutions are isolated productivity tools with little downstream dependency. Perhaps one of the remaining 23 has quietly become essential to a business process responsible for hundreds of millions of dollars in revenue. Those two situations should not be governed in the same way because their business impact is fundamentally different.
The more important questions are relational. Leaders need to know where the AI participates, what it depends on, what depends on it, and what happens when either of those dependencies changes. To answer those questions, the AI capability has to be connected to the business architecture around it, including the business capability, business process, applications, data, integrations, platforms, and third parties.
That turns an AI inventory into something far more valuable: an enterprise dependency model.
You Cannot Govern What You Cannot See
This leads to one of the central problems executives will face as AI adoption accelerates. AI often enters the enterprise quietly through a series of decisions that individually appear small and reasonable. A business unit subscribes to an AI service because it can save employees a few hours each week. Someone connects enterprise data to make the tool more useful. Another person builds an integration. An MCP server provides access to an internal application. A workflow is automated, employees begin depending on the output, and the business process gradually changes around the capability.
None of those decisions individually may feel like an enterprise architecture decision, but taken together they unquestionably are. A new dependency structure has been created across people, systems, data, platforms, and vendors.
Organizations have spent decades dealing with shadow IT, where technology emerges outside normal technology management processes. AI introduces a variation on that same problem, but with the potential to reach much deeper into business processes. Shadow AI can become Shadow Architecture.
The concern is not experimentation itself. Organizations should encourage responsible experimentation because that is often how valuable use cases emerge. The risk appears when successful experiments quietly become operational dependencies and the organization fails to recognize that the architecture has changed around them.
Why Enterprise Architecture Belongs at the AI Governance Table
Security therefore has an essential—but not exclusive—role in AI governance. Security should be asking whether sensitive information is protected, access is appropriate, vulnerabilities are managed, third-party risks are understood, and the technology operates within established security controls.
Enterprise Architecture asks a complementary set of questions. This is where AI-powered Enterprise Architecture becomes practical: connecting business capabilities, applications, data, integrations and technology so leaders can understand the impact of change before AI becomes an invisible operational dependency.
What business capability is this AI supporting? Where does it participate in a business process? What applications does it interact with? What data does it consume? Which integrations and MCP services connect it to the enterprise? Which platforms and third parties does it rely on? What other teams or systems depend on its output? What happens if it changes? And perhaps most importantly: Where else in the enterprise are we solving the same problem?
That last question will become increasingly important. Imagine five business units independently discover that AI can automate document analysis. Each buys a different service. Each builds its own integrations. Each connects its own data. Each negotiates with a different provider. Each creates its own operating model.
Every individual decision may appear reasonable. The aggregate architecture may be anything but reasonable. The organization has created five solutions, five sets of integrations, five vendor dependencies, five potentially different control environments, and five technologies that someone will eventually have to operate, govern, support, and rationalize.
That is not simply an AI problem. It is an enterprise architecture problem created by AI.
AI Risk Extends Beyond Security
Once AI becomes embedded in business processes, the risk profile expands well beyond cybersecurity. Operational risk increases when a process becomes dependent on an AI capability without an appropriate fallback. Dependency risk grows when multiple functions rely on the same model, platform, or provider. Change risk appears when models, APIs, MCP services, data sources, or vendors evolve in ways that alter downstream behavior.
Architecture risk also increases when business units independently create overlapping capabilities or introduce platforms that do not align with the broader technology environment. Business continuity risk emerges when AI becomes critical to operations without being recognized as a critical dependency, and cross-domain risk appears when an AI capability introduced by one team begins affecting systems, data, or processes owned by another.
These risks cannot be understood by examining the AI model in isolation. They require understanding the ecosystem around it, including the business processes it supports and the systems and data that support it in return.
That is exactly what Enterprise Architecture is designed to do.
Governance Should Not Mean Slowing AI Down
This is where executives should be careful. Bringing Enterprise Architecture into AI governance should not mean creating another committee through which every experiment must pass. That would defeat much of the purpose of AI adoption.
Good architecture governance should actually make adoption easier. Enterprise Architecture can establish reusable patterns for connecting AI to enterprise data, approved approaches for APIs and MCP services, common platform strategies, architectural standards for agents, expectations around observability and resilience, and visibility into capabilities that already exist elsewhere in the organization.
Instead of asking every team to invent an AI architecture from scratch, the enterprise provides a paved road. Governance then becomes less about asking permission and more about making good architectural decisions repeatable.
That is how governance can increase speed rather than reduce it.
The Question Changes as AI Becomes Successful
There is an irony in all of this. The biggest governance challenge may not come from the AI initiatives that fail, because failed experiments tend to disappear. The successful ones remain, expand, and become increasingly embedded in the business.
They save 25,000 hours. They reduce cost by $1.2 million. They shorten customer response times. They give analysts thousands of hours back. Because they work, employees use them more, processes adapt around them, additional systems connect to them, and management begins to incorporate their benefits into operating expectations. Eventually, what began as an experiment becomes infrastructure.
That is the point at which executives need to return to the question we started with:
AI is moving into customer service, finance, operations, software development, analytics, decision support, and an expanding number of core business processes. The more successful AI becomes, the more deeply embedded it will become in how the enterprise operates. That means AI can no longer be treated as something sitting outside the architecture. AI Capability is the new player in the enterprise ecosystem.
Security must protect it, Data Governance must help govern the information that fuels it, business leaders must remain accountable for the outcomes it produces, and Enterprise Architecture must make the connections visible so the organization understands how all of those pieces fit together.
Once AI becomes part of how the business works, understanding those relationships is no longer simply an architecture exercise. It becomes part of governing the business itself.