The problem no one mentions in the commercial proposal
When a mid-size company engages an AI vendor, the conversation typically revolves around use cases, timelines, and price. What rarely appears in the proposal is a more uncomfortable question: what happens if we decide to switch vendors in twelve months?
If the answer is "we would have to start from scratch," there is a structural problem worth identifying before you sign — not after.
Technology dependency is not new. It has existed since the first ERP systems. But with AI it carries a particular characteristic: agent systems and workflows are more opaque, harder to audit, and easier to build in ways that only the vendor understands. That is not always intentional. Sometimes it is simply the result of moving fast without thinking about the long term. But the effect is the same.
Below are five questions any CFO or COO should ask before committing to an AI vendor.
Question 1: Who owns the code and the documentation?
This is the most fundamental question and, surprisingly, the one most often left unasked.
Some vendors build on proprietary infrastructure, using proprietary tooling, without delivering source code to the client. When the contract ends, the system leaves with them.
What you should require: full repository access from the first sprint, technical documentation readable by your team, and contractual clarity on the intellectual property of everything built during the engagement.
If the vendor hesitates or attaches conditions, that is a warning sign.
Question 2: Does your team learn to operate the system, or only to use it?
There is an important difference between a team that knows how to use a tool and a team that knows how to operate, maintain, and extend it.
A vendor that builds dependency delivers simple interfaces for the end user while retaining control of the underlying logic. When something breaks or needs adjustment, the client must call the vendor.
A vendor oriented toward autonomy works alongside the client's team throughout implementation, explains design decisions, trains the people who will operate the system, and documents workflows in a way that allows someone internal to modify them without external assistance.
The concrete question you can ask: "How many hours of hands-on training does the project include, and what capability will remain within my team at the end?"
Question 3: How is the system governed once it is in production?
An agent in production is not static software. Language models are updated. Data changes. Business processes evolve. Without active governance, a system that performs well in month one can degrade silently by month four.
The relevant question is not whether the vendor monitors the system, but how — and who makes decisions when something changes.
A dependency model centralizes all of that control with the vendor. An autonomy model establishes from the outset which metrics are monitored, who on the client's team reviews them, and when to escalate to the vendor versus when to resolve the issue internally.
Ask to see the governance framework before you sign. If one does not exist, there is likely no clear plan for when something fails either.
Question 4: What happens if you decide to change vendors?
This question makes many vendors uncomfortable, and that reaction is already useful information.
A vendor that builds for client autonomy should have no difficulty answering: "If you decide to work with another team, we hand over the complete repository, the documentation, and a transition session. The system will keep running."
A vendor that builds dependency tends to respond with ambiguity: "That would depend on the contract," "we would need to assess the situation," or simply redirects the conversation.
To illustrate the financial impact: a distribution company with 80 employees that contracts a report-automation system for EUR 40,000 and then discovers it cannot migrate the system without rebuilding it from scratch is absorbing a hidden cost that was never in the original proposal. If the system takes six months to build and another six to stabilize, the true cost of that dependency can exceed the cost of the initial project.
Question 5: Do you define the roadmap, or does the vendor?
In a dependency model, the vendor controls what gets built next, in what order, and according to what criteria. The client receives proposals and approves or rejects them, but rarely has enough visibility to question the priorities.
In an autonomy model, the client has a clear map of their agent ecosystem, understands what has been built, what is pending and why, and can make prioritization decisions on their own terms.
The practical signal: if your team cannot explain in fifteen minutes which agents are in production, what they do, and what the next step is, the vendor has not done its knowledge-transfer work properly.
A concrete example
A professional services firm with 120 employees engaged an AI vendor to automate the consolidation of financial data across three systems. The project ran four months and the result worked correctly.
Twelve months later, one of the source systems changed its data structure. The process stopped working. The internal team did not know how to intervene. The vendor took three weeks to free up availability to address the problem and billed additional hours for the fix.
The direct cost of those three weeks — in manual work hours, delays in the financial close, and vendor fees — was estimated at between EUR 8,000 and EUR 14,000. The indirect cost, in terms of the team's confidence in AI systems, was harder to quantify but equally real.
The problem was not the technology. It was that the vendor never transferred the knowledge the internal team needed to operate the system autonomously.
How to use these questions in practice
You do not need to ask all five questions in the first meeting. But it is worth keeping them as evaluation criteria before signing any AI implementation contract.
If a vendor answers all five clearly, their model is oriented toward client autonomy. If they deflect any of them, ask for more context before responding, or answer in generalities, it is worth pressing further before committing.
Well-implemented AI reduces costs, improves operational visibility, and frees up team capacity. But those benefits are only sustainable if the system is operable, auditable, and extensible by the client's own team. Without that, what appears to be an investment in efficiency can become a new operational dependency.
Conclusion
The question is not whether your AI vendor is good. The question is whether the delivery model they propose leaves your organization in a stronger position than before — or simply replaces one dependency with another.
If you have questions about how to assess your current situation or are evaluating a new vendor, we can review your case in a brief call and offer an independent perspective.
