Why the market is so confusing
The AI implementation market has become crowded in a short space of time. There are parties that configure off-the-shelf AI tools on top of existing software. There are consultancies that write an advisory report and leave the execution to you. There are integration parties that build API connections between tools. And there are parties that build domain-specific systems and then keep them running in the operation. These are fundamentally different propositions, but they all call themselves an 'AI implementation partner'. The result: you end up comparing offers that are not apples and apples, but apples and asphalt.
What types of partners exist and what do they deliver?
There are broadly three types. First, the tool configurator: this party helps you set up an existing AI platform, such as document processing or chatbots. Quick to get started, but the system is generic and you depend on the tool vendor's roadmap. Second, the project bureau: this party designs and builds something custom, but once the project is complete, the partner is gone. You manage the result. A good fit if you have a strong internal IT department. Third, the operating partner: this party builds and stays. The system runs in production, the client owns the code and data, but the partner remains responsible for further development and performance. This type is more expensive as a collaboration, but the risk of the system grinding to a halt after three months is far lower. Which type you need depends on how critical the process is and how well your own organisation can sustain it.
Adding an AI layer or replacing a core system: two fundamentally different choices
A common misconception is that AI implementation always means adding something to what you already have. That is true in some cases. If your TMS or ERP functions well but surrounding processes such as email handling, document recognition, or quote creation are still manual, adding an AI layer around it is the logical step. But if the core system itself is the problem, too slow, not adaptable, built on outdated architecture, then an AI layer is a patch on a burst pipe. In that case, it makes more sense to rebuild the system itself, AI-native, so that the logic and the data are aligned from the start. The choice between these two directions is the first question a good implementation partner should work through with you, not which tool you are going to use.
What are the right questions to evaluate a partner?
Ask the same four questions in every conversation. First: who owns the code and the data? If the answer is vague or leads to a licensing arrangement, you have a lock-in risk. Second: what is the go/no-go moment and what does it cost if you stop at that point? Serious parties work with milestones. Third: who is responsible after delivery if the system does not do what was promised? Bureaus that only send invoices after delivery have no incentive to make it work properly. Fourth: do they have domain knowledge in your sector? An AI implementation in transport or customs requires different model choices and a different data architecture than an implementation in finance. Generic AI knowledge is not enough.
When is custom development not the right choice?
Being honest about trade-offs is part of this kind of decision. Custom-built, AI-native software with a partner that stays is not the right route for everyone. If your process has limited complexity, your data is reasonably structured, and a standard SaaS package covers ninety percent of your needs, investing in custom development will not pay off. Custom development becomes worthwhile when the process is too specific for a standard package, when integration problems with current systems are slowing down your operation, or when ownership of data and systems is strategically important. If in doubt, start small. Validate with a limited scope that the approach works before tackling a full core system.