AI Architecture Before Tools: How to Avoid Vendor Lock-In
AI tools change quickly, but architecture decisions can lock organisations into years of cost and complexity. Dr Jan van Niekerk explains why modular design, data ownership and exit planning must come first.
Architecture decisions have to come before tool selection, because vendor lock-in isn't caused by picking the wrong AI tool. It's caused by building on one before you've decided how you'd ever leave it.
An RFP crossed my desk recently from a Johannesburg manufacturer, with 37 requirements for selecting an AI platform. Model benchmarks, feature checklists, roadmap commitments, integration counts.
Not one requirement about what it would cost to leave.
That document is why this issue exists. The most expensive AI decisions I've seen weren't bad tool choices. They were good tool choices made in the wrong order, welded into architectures that couldn't let go.
The wrong first question
“Which tool should we buy?” feels like the responsible opening question. It's measurable, it's comparable, procurement knows how to run it.
It's also the most perishable decision on the list. Model leaderboards reshuffle every quarter. Vendors reprice, repackage, and retire products on their schedule, not yours; the last 18 months have been a masterclass in that. The pricing you're evaluating today is often designed to not last. When the US government's procurement arm got frontier AI for a dollar per agency in 2025, every procurement professional watching understood the number wasn't the price. It was the hook.
Meanwhile, the market itself is telling you how uncertain it is. Best-of-breed buying preferences dropped to 20.7% of enterprises in 2026 (Futurum), while 41% plan consolidation. Buyers are visibly unsure whether to spread bets or concentrate them. When the whole market is oscillating, locking your architecture to this quarter's answer is the risk.
The order that works
Across the implementations I've led, including helping clients from Cape Town to Pretoria adopt AI without disrupting operations, and the unwinds I've been called into, the sequence that holds is this.
- Which decision are we automating? Not which task, which decision. A decision has an owner, an error cost, and a tolerance. If you can't name those, no tool can help you yet.
- Who is accountable when it's wrong? Answer it before the demo, because after the demo everyone is in love and nobody wants custody.
- What does swapping cost in 18 months? Price the exit before you sign the entry. If the honest answer is “we'd be stuck,” you're not buying a tool, you're marrying one.
- Now the tool. And by this point, the shortlist usually writes itself, because the first three answers eliminated most of it.
What “modular” actually means
Architecture-before-tools gets nodded at in principle and skipped in practice, because the practice is unglamorous. Concretely, it means five things.
- Your data layer belongs to you, not to the platform. The single biggest unwind cost I've seen wasn't licences; it was data shaped around one vendor's schema. Export formats and access patterns are architecture decisions, not implementation details you delegate to whoever's onboarding you this quarter.
- Orchestration sits separate from models. The logic that routes work should treat any model as a socket, not a spine. Build the routing logic once, and swapping a model becomes a config change instead of a rewrite.
- Interfaces are contracts. Anything that talks to a model does it through a layer you control, so the engine can swap without the plumbing moving. It's more upfront work than calling the API directly, and it's the difference between a Tuesday-afternoon migration and a quarter-long one.
- Governance evidence lives outside the tools. If your audit trail lives inside a platform, your compliance posture has a landlord. The day you leave, you want that evidence walking out with you, not staying behind as someone else's export feature.
- And exit clauses go into contracts while you still have leverage, which is only ever before signing. After signing, you're asking a vendor for a favour; before signing, you're negotiating a term.
None of this slows you down. It's roughly a week of design discipline upfront. I've watched the absence of that week cost a client most of a year on the way out of a platform bet that had aged badly. It's also why modernising the technology foundation for AI has to happen alongside this work, not after it. Architecture built on brittle legacy systems inherits their fragility.
As Louis de Klerk, a South African CIO, put it: “Upgrading to the latest LLM model is easy — upgrading your harness is hard, and often expensive and painful.” That's the orchestration layer above, in one sentence.
The school-fees test
A South African client of mine told me recently they were done paying school fees, done funding vendors' and advisors' learning curves. The architecture version of that principle is one where your future state should assume the market will surprise you, because it will (trust me). Modular design is how you stop paying tuition on every market shift.
One honest caveat. If you're running a 6-week experiment, don't architect a cathedral around it. Speed beats purity for anything with a kill date measured in weeks. The discipline above is for what you intend to keep.
So, before the next AI purchase, work through those four decisions in order, and give the tool discussion the final 15 minutes. Ask the vendor what leaving costs, in writing. If anyone calls the architecture week a delay, ask them what 11 months of unwinding feels like.
Frequently Asked Questions
What does architecture before tools actually mean in AI?
Architecture before tools means defining how an organisation's AI systems, data, integrations and governance will work before selecting specific AI platforms or vendors. This approach prioritises business requirements, accountability, data ownership and long-term flexibility over individual product features. By establishing a modular AI architecture first, businesses can integrate different AI models, replace technologies and scale their systems without becoming dependent on a single provider.
Does choosing the wrong AI tool cause vendor lock-in?
Vendor lock-in is not necessarily caused by selecting the wrong AI tool. It usually develops when an organisation builds its data structures, workflows, integrations and governance processes around a single vendor's proprietary technology. Even a suitable platform can become restrictive if replacing it requires extensive redevelopment. Businesses can reduce this risk by maintaining control over their data, using standardised interfaces and separating AI orchestration from individual models.
How long does it take to build a modular AI architecture?
The initial architecture planning for a clearly defined AI implementation may take approximately one week, depending on its complexity and business requirements. This planning typically covers data ownership, system integrations, model flexibility, governance and potential migration costs. Implementing the architecture can take considerably longer, particularly when legacy systems require modernisation. Investing time in these decisions early can help prevent expensive restructuring when technologies or business requirements change.
What should an AI vendor contract include to protect against lock-in?
An AI vendor contract should clearly define data ownership, data export rights, supported formats, integration access, termination conditions and migration assistance. Businesses should also understand potential exit fees, data retrieval timelines and how governance records will remain accessible after the agreement ends. These requirements should be negotiated before signing, when the organisation has greater leverage to secure favourable terms and protect its long-term technology independence.
Does architecture-first planning apply to short AI pilots or experiments?
Architecture-first planning should be proportionate to the expected lifespan and complexity of an AI initiative. A short experiment lasting approximately six weeks may not require a comprehensive modular architecture, particularly if the technology will be discontinued after testing. However, businesses should still consider data security, accountability and basic integration requirements. For AI systems intended for long-term operational use, architecture-first planning becomes more important because future changes can be expensive and disruptive.
Why is AI architecture important for South African businesses?
AI architecture is particularly important for South African businesses managing legacy technology, operational budgets, data protection requirements and evolving digital infrastructure. Organisations must consider compliance with the Protection of Personal Information Act (POPIA), appropriate data governance and the practical costs of changing technology providers. A modular architecture helps businesses maintain control over sensitive information, accommodate changing operational requirements and avoid unnecessary dependence on individual AI vendors.
How can businesses avoid AI vendor lock-in?
Businesses can avoid AI vendor lock-in by designing flexible systems that allow different models, applications and service providers to be integrated or replaced independently. Important measures include maintaining ownership of organisational data, using open standards where practical, separating orchestration from AI models and documenting integration requirements. Organisations should also assess migration costs before purchasing a platform and ensure vendor agreements provide suitable exit options.
What is the difference between modular AI architecture and vendor-dependent AI systems?
Modular AI architecture separates components such as data storage, model execution, orchestration, application interfaces and governance into independently manageable layers. This allows organisations to replace individual technologies without rebuilding their entire AI environment. Vendor-dependent systems often combine these functions within a proprietary platform, making migration more complicated. Modular architecture generally offers greater flexibility, although it may require additional planning, integration management and technical expertise.
Our secure AI services team runs this same audit before recommending a platform to any client. Netsurit's whitepaper, The Agent Platform Trap, makes the fuller case for architecture-first. Read it before your next platform conversation, not after.
