A business system must be able to incorporate artificial intelligence capabilities when they add value, and it must be able to function without them when they don't or when the provider changes the terms. Being prepared and being dependent are different things, and confusing them when making purchases transfers all the volatility of a market that changes several times a year to the system.
The distinction has a practical translation: If the model's provider were to stop providing service tomorrow, what would stop working? If the answer is "a feature," the system is ready. If it's "the system," it's dependent.
Seriously API-first. Each function is exposed through a documented and versioned contract, not just a user interface. This allows any future capabilities—AI or otherwise—to be integrated without completely opening up the system.
Accessible and structured data. With a clear source of truth and the ability to export relationships, not just a flat dump. Without this, no top layer can be built.
Permissions resolved in the data. Not on the screen. This is the condition for an assistant or agent to be able to consult without becoming a bottleneck, for the reasons we explain in AI can also leak secrets [internal link].
Factory traceability. A record of what changed, who did it, and when. This record is irreversible and is an increasingly stringent regulatory requirement.
Event model. The system should be able to notify you when something happens, instead of requiring you to check periodically. This is what makes any subsequent automation possible without degrading performance.
Configurability of business rules. The criteria should be changeable without deploying code. When the rules are written in a readable format, they can be audited, compared, and replaced.
All six are good architectural properties independent of AI. That's precisely the argument: A well-built system is already prepared., And one that needs extraordinary adaptations to incorporate AI had a previous problem.
Sign | What does it involve? | Risk |
|---|---|---|
The core functionality requires the model | Without a supplier, there is no product. | Business continuity |
There is no defined alternative behavior | In case of model failure, the system stops. | Daily operations |
The rules live in unversioned prompts | They cannot be audited or compared | Compliance and quality |
The cost scales with unlimited use. | A spike in activity drives up the bill | Budget |
The second row is the most frequent and easiest to correct in design: defining what the system does when the model doesn't respond. This could be queuing, downgrading to a simple rule, or escalating to a human. Any of the three is better than stopping, and none of them decides itself.
Six specific questions for any provider, whether or not it's an "AI" product:
The six questions are answered in a meeting and filter more effectively than any comparison of features.
The financial argument is straightforward. A system that meets all six requirements has three properties that are valued in any corporate transaction: it can be integrated with future systems, it can be audited, and another team can take it over.
A dependent system, on the other hand, transfers the volatility of the model market to the buyer: prices that change, versions that are withdrawn, and suppliers that, according to Gartner's 2025 forecast, will largely no longer be in the market—the firm estimated that of the thousands of suppliers that present themselves as specialists in agents, only about 130 really were.
Buying a dependent system today means buying full exposure to that market.
When discussing a software purchase, there is a way to frame it that organizes the decision without going into technical details: We want a system that can be enhanced with AI, not an AI system..
The first is an investment with a lifespan of several years, whose capabilities will grow with the market. The second is a bet on which supplier and model will dominate in three years, and that's not a bet that a company whose business is something else should make.
It can incorporate artificial intelligence capabilities when they add value and continue functioning without them. The proof is straightforward: if the model's provider were to stop offering service tomorrow, a system equipped with AI would lose a feature, and a dependent system would cease to operate.
Six: Documented and versioned API for all its functions, accessible and exportable data with its relationships, permissions resolved at the data level and not the interface level, factory traceability, an event model that notifies instead of forcing querying, and configurable business rules without deploying code.
When the core functionality requires the model to exist, when there is no alternative behavior defined in the event of a vendor failure, when the rules reside in non-versioned prompts that cannot be audited, and when the cost scales with usage without any ceiling.
Are all functions available via documented APIs? Can data be exported with its structure? Are permissions resolved on the data or in the interface? What is logged for each change? What happens if the model provider fails? Can a custom provider be used?.
No, and that's the argument: these are good architectural properties regardless of AI. A well-built system is already prepared, and one that needs extraordinary adaptations to incorporate artificial intelligence had a prior design flaw.
Because it transfers to the buyer all the volatility of a market that changes several times a year in terms of prices, capabilities, and availability. Gartner estimated in 2025 that of the thousands of providers advertising themselves as agent specialists, only around 130 actually were.
Are you going to buy software this year? We assess whether what you're about to sign is ready for future needs or ties you to a specific supplier. Independent technical judgment, without presenting ourselves as candidates. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
