I have to admit I love building products and the feeling that comes with it, but I can't hide my technical background (which is considerable) or my side as a software architect. I've worked with Clean Architecture and DDD for many years, and there's a rule from that world that I repeat on almost every project: dependencies point inward, never outward and never sideways. Why? Because in technology everything changes fast, and what changes fast (frameworks, databases, vendors) has to depend on what changes slowly (business rules), never the other way around. When that rule gets broken, you notice two years later, when swapping out a single library costs you half a project.
Given what that lesson has taught me over time, and what I'm seeing in companies as they adopt AI, I think it's the right moment to write a series of articles on how to bring this experience into the business world without getting burned.
Why? Because at the last few companies I've worked at, what I see with AI is exactly the opposite.
Everyone used it their own way: one person with a personal subscription, another with a tool a friend had recommended, another with an assistant they'd hacked together on a Friday afternoon. It worked well enough, which is exactly what makes it dangerous, and nobody had stopped to ask what data was going in. Then came the serious part: one vendor, agents and tools built on top of it, and everything ended up tied to that vendor without anyone really deciding it. And every department doing its own thing, without talking to the others. It's the classic result of designing an architecture without involving the business.
I went looking to see if it was just me. It isn't.
The numbers tell the same story
In McKinsey's 2026 survey (1,719 people in 97 countries), 80% say AI has improved their productivity, but only 37% attribute any impact to their organization's EBIT. It helps people more than it moves the company. In another survey, by S&P Global, of more than a thousand companies in North America and Europe, 42% had abandoned most of their AI initiatives in 2025, up from 17% the year before. And Gartner, surveying data leaders, estimates that 63% of organizations either don't have data management practices ready for AI or don't know whether they do.
Give an excellent model to a company whose knowledge isn't in order, and it will answer with total confidence about a discount, a deadline or a policy that doesn't exist. The model isn't the problem. Nobody has told it how your company works.
What comes out of that
Vendor lock-in shows up late. This year, two of a major provider's most powerful models were switched off for all of its customers for 19 days (from June 12 to July 1, 2026) because of a US export control directive. A regulated company takes months to validate a new model.
And it doesn't take a regulation. Decagon built its voice product on ElevenLabs and now competes with it; ElevenLabs' own CEO describes it as the lines between model, platform and application blurring. And Windsurf lost direct access to Claude's models overnight. The vendor serving you AI today can be your competitor tomorrow, or shut off your access.
Data leaks out quietly. If the company doesn't provide an easy path, people find their own. LayerX, using data from its own customers, estimates that 77% of employees paste data into generative AI tools, and that most of it comes from personal accounts. Those numbers come from a security vendor and have their bias, but I recognize the pattern firsthand. If you think about it coldly, it's very serious: it puts your company at real risk of an information leak, with the added danger that the provider may use that data.
And the regulation is already here. Since February 2025, the AI Act has required companies to take steps to train the people who use AI (the Digital Omnibus has softened that requirement, but not removed it). The high-risk rules have been pushed back to December 2027 and August 2028, and plenty of people have breathed a sigh of relief, but the GDPR is exactly where it was: Italy fined OpenAI €15 million for using data without a legal basis. To comply with either one, you need to know which AI is in use, with what data, and who is using it. In OneTrust's survey (1,200 executives at companies with at least $100 million in annual revenue, across eight countries, Spain included), only 5% say they have clear coordination and accountability across the whole AI lifecycle.
The CORE Model: the dependency rule, taken to the enterprise
This doesn't start from zero. Clean Architecture comes from Robert C. Martin, and some people are already applying the same logic to the code of AI agents, with the model as a swappable adapter around a core.
I propose taking what we know works in software architecture and applying it to the architecture of the company: a concrete way to bring those principles to the entire organization. And what better name than the CORE Model for Enterprise AI, or Enterprise AI with an Owned Core.
It's drawn the way Clean Architecture is, in circles, and each letter is a piece:
- C · Company knowledge. What your company knows, with its source and with what's confirmed and what isn't. It sits at the center.
- O · Orchestration. The agents and applications of each department, which rely on the core instead of each going it alone.
- R · Rules. Governance: who can access what, what trail each action leaves, and what regulation requires. Also at the center, right next to the knowledge, and applied to everything around it.
- E · Extensions. The tools you already use, plus your model and cloud providers. They plug into the core, at the edge, and can be swapped without touching it.
One detail to avoid confusion: the letters follow the order in which you build (first the knowledge, then the agents, the rules and the extensions), while the circles show the order of dependency. That's why the R appears at the center even though it's the third letter.
The rule is simple: dependencies point toward the core. AI depends on what your company knows, not on who serves it to you, so switching models or clouds means changing an extension, not rebuilding the company.
Here's an example, so this doesn't stay a drawing.
A sales agent receives a question about a discount. Before answering, it checks the core: which policy is currently in force, who approved it and since when. If there's a confirmed answer, it uses it and leaves a record. If two sources contradict each other or the data is missing, it doesn't fill the gap: it asks a person. And some decisions stay human: changing the policy, approving an exception, deciding which of two sources to trust. The architecture automates the lookup and the record-keeping, not that decision.
Today it usually works the other way around. The knowledge lives inside the vendor's tool, the first year you move incredibly fast, and in the second you discover you can't leave.
Give an excellent model to a company whose knowledge isn't in order, and it will answer with total confidence about a discount, a deadline or a policy that doesn't exist. The model isn't the problem. Nobody has told it how your company works.
And one limitation I don't want to hide: almost everything I've read about these context layers comes from the people selling them, and there are hardly any independent studies at scale. A shared core also spreads mistakes: a wrong price reaches every agent at once. That's why the rules go inside from the start, not as an add-on.
A few questions to sit with about your company
If you switch providers tomorrow, what do you take with you and what do you leave behind?
And the one I find hardest to answer: when two sources in your company say different things, who decides which one is right?
Dependencies point toward the core. AI depends on what your company knows, not on who serves it to you, so switching models or clouds means changing an extension, not rebuilding the company.
In the next article I get practical: where to start, which is the C, company knowledge, without waiting until everything is in order, because that's never going to happen. After that we'll go piece by piece, in this order: O, R and E.
CORE Model for Enterprise AI · 1