AI architecture: what locks you in, and what doesn't
An AI architecture decision rarely has a clean owner. The architect recommends, the business owner decides, and the deciding happens in conditions nobody quite writes down. Most of what gets decided does not matter much later. A small number of choices do — and on the day you make them, they look exactly like the ones that don't.
Why this mattersWhy the costly decisions don't look costly
When a decision is easy to reverse, undoing it costs you a migration and some disruption, and then it is behind you. When a decision is hard to reverse, undoing it costs you years, because everything else in the system has been built on top of it.
That cost is not fixed, though. It grows with the size and age of the system around the decision. A small team can reverse a core dependency in a month, while a larger and older system takes a year to do the same thing, because far more has been stacked on top. This is why a startup changing its mind feels a bruise and an enterprise making the identical change feels a fracture.
One question separates the reversible decision from the locked-in one, and on the day you ask it the question carries no visible cost: if we had to undo this in eighteen months, what would it take. A short answer means the decision is reversible, and an answer that makes the room go quiet means it is not.
The lensFour questions that expose a lock-in
The eighteen-month question is the first of a small set. None of them is technical. Each one can be asked by the business owner and answered by the architect, and the value is in asking them out loud, before the decision, while the cost of a wrong answer is still zero.
If we had to undo this in eighteen months, what would it take. This is the core question, and the other three are ways of pressuring it. A reversible decision has a short, concrete answer. If the answer is long, vague, or starts with ‘well, it depends what else we've built by then,’ that is the decision to slow down on.
What of ours gets shaped around this choice. Some decisions stay contained. Others quietly become the thing everything else assumes. A model provider is not just a model provider once your prompts, your data formats, and your team's habits have all formed around it. The more of your own system bends to fit a choice, the more expensive that choice is to remove later.
Who else holds the keys. Every architecture choice hands some control to someone outside the room. A vendor, a framework's maintainers, a provider's pricing team. The question is not whether that happens, because it always does. It is how much they control, and what it costs you if they change their mind.
What would have to be true for this to be the wrong choice. This one is asked of the future, not the system. If the honest answer is ‘nothing realistic,’ the decision is safe to make fast. If it is ‘if our volume grows, or if the vendor changes terms, or if the regulation shifts,’ then you are not making a permanent decision. You are making a bet, and a bet should be sized and watched, not signed and forgotten.
Asked together, these four turn an architecture recommendation from something the owner approves on trust into something the two of them can actually weigh. The architect already knows most of these answers. The questions just get them into the room.
The sharpest tensionWhere the two sides pull hardest: governance and security
This is the sharpest tension in any architecture decision, and both sides usually pretend it is not there.
The architect wants boundaries: data controlled, access narrowed, vendors held at a distance. Every one of those is correct, and every one costs something the architect does not feel: slower to build, more expensive to run, fewer options. The owner feels exactly those costs, and pushes back, not out of recklessness but because the cost of caution is visible today while the risk is hypothetical and later. The architect is pricing a risk. The owner is pricing a delay. Both prices are real, just paid in different currencies, which is why the disagreement so often goes unspoken.
That silence is the failure, because a governance choice is the most irreversible architecture decision there is. Where data lives and who can reach it is poured into the foundation. Undoing it later is not a migration, it is a rebuild. A tension settled silently becomes a permanent feature of the business.
So make the trade out loud. The owner says what risk is being accepted and what it costs if it lands. The architect says what the safe version adds in delay or expense. Said openly, it is a decision the business made on purpose. Left to the architecture, it is one the business discovers it made, years later, when changing it is no longer cheap.
The principleHow to actually make the choice
There is no formula here, and any article that hands you one is selling something. What there is, is a principle: you do not avoid lock-in, you choose it on purpose, or you do not choose it at all.
Avoiding lock-in entirely is not an option. Every architecture decision hands some control to something outside the room, and a system built to depend on nothing depends on so little that it can barely do anything. The goal was never zero lock-in. The goal is that every lock-in in your system got there because someone looked at it, named what it would cost to reverse, and decided the payoff was worth it.
A lock-in chosen deliberately is a strategy. The same lock-in arrived at by drift is a liability that happens to be sitting in your foundation.
That is the whole move. The same technical choice can be either. What separates them is whether anyone decided it.
So the principle is not ‘reversible good, irreversible bad.’ Some of the best decisions a business makes are deeply irreversible, and that is fine, because they were made with the price in view. The principle is that the architect and the owner should be able to point at every locked-in part of their system and say what it buys and what it would cost to undo. The parts they can speak to are decisions. The parts they cannot are just things that happened.
If it's already doneIf you are already deep in it
Most of this article assumes the decision is still ahead of you. For many readers it is not. The architecture is built, the dependencies are set, and some of them were never decided so much as drifted into. The eighteen-month question is not much use when the eighteen months have already passed.
It is still worth asking, just in a different tense. Not ‘what would this cost to undo’ but ‘what is already expensive to undo, and did we ever actually choose it.’ You cannot un-make those past decisions. You can do something more useful: find out which ones they are, before the next decision gets stacked on top of them.
The exercise is the same four questions, turned to face the present. Which parts of our system has everything else been built around. Who outside the room currently holds control, and over how much. What would have to change in our business for one of these choices to become the wrong one. And the honest one: which of these did we decide, and which did we just end up with.
What comes back will not be a clean map. In a system that has been running for a while, the dependencies are tangled into each other, and pulling on one moves three others. That is normal, and it is not a sign you did something wrong. It is the point. The goal of the exercise is not a tidy diagram, it is knowing where the knots are. You do not have to untangle them. You have to stop adding to them blindly. The worst lock-ins are not the expensive ones, they are the expensive ones nobody knew were there. Even a rough sense of where your system is knotted does not cost you anything, and it changes every decision that comes after it.
The closeThe decision under the decision
Architecture sounds like a technical subject, and most of it is. But underneath the technical choices sits a business one that never gets named: how much of your future are you willing to commit, and to whom. That question does not belong to the architect alone, and it does not belong to the owner alone. It sits in the gap between them, and it gets answered either way, by conversation or by default.
The buy, build, wrap, or partner decision carries this same weight. Buying and wrapping both hand control to a vendor. The point was never to avoid that. It is to know, at the time, what you handed over and what it would cost to take back. A separate piece walks through that decision in detail.
So the work is not to make every decision reversible. It is to make sure that every irreversible one was actually decided. An architecture you can speak to, point at any locked-in part and say what it buys and what it would cost to undo, is a business that knows what it has committed to. An architecture nobody can fully speak to is a set of commitments the business made without noticing. Same system. The only difference is whether anyone was in the room.
AI architecture lock-in — answered
What is AI architecture lock-in?
Lock-in is the cost of changing your mind about an architecture decision later. A decision is reversible if undoing it would take a known, bounded effort. It is locked in if undoing it would force you to rebuild things stacked on top of it. The same technical choice can be either, depending on how much else has grown around it.
How do I tell a reversible AI architecture decision from a locked-in one?
Ask one question out loud: if we had to undo this in eighteen months, what would it take. A short, concrete answer means reversible. A long answer, or one that starts with “it depends what else we've built by then”, means locked in.
What are the four questions to ask before an AI architecture decision?
One, if we had to undo this in eighteen months, what would it take. Two, what of ours gets shaped around this choice. Three, who else holds the keys. Four, what would have to be true for this to be the wrong choice. Asked together, they turn an architecture recommendation into a decision the business owner can actually weigh.
How should architects and business owners decide AI architecture together?
By making the trade out loud. The architect prices a future risk; the business owner prices a present delay. Both are real, paid in different currencies. The goal isn't avoiding lock-in — every system has some. The goal is that every lock-in got there on purpose, with both sides knowing what it buys and what it would cost to undo.
What if we are already locked into an AI architecture we didn't fully decide on?
Run the same four questions in the present tense. Which parts has everything been built around. Who outside the room holds control, and over how much. What would have to change for one of these choices to become wrong. And honestly: which of these did we actually decide, and which did we end up with. You don't have to untangle the knots — you have to stop adding to them blindly.
Is it bad to be locked into an AI vendor or framework?
Not in itself. Some of the best decisions a business makes are deeply irreversible. The principle isn't reversible-good, irreversible-bad. It is that every locked-in part of your system should be something you can point at and say what it buys, and what it would cost to undo. The parts you can speak to are decisions. The parts you can't are just things that happened.