What to Demand from an AI Vendor Before You Sign

I have seen a corporate system that absorbed billions of roubles of investment. Formally it works, and nobody plans to switch it off, but it survives only on compulsion: people log in because they have to, and do their real work somewhere else whenever they can. In my estimate, most corporate IT products end up this way or worse, roughly 70 to 80% of them. BCG gave a similar figure in its 2020 research, finding that 70% of digital transformations fall short of their objectives.

AI products follow the same path, only faster. A system's fate is decided in its first days, when people choose whether to work with it or around it. That is why training should be agreed with the vendor before the contract is signed, while the buyer can still put requirements in writing. I ask vendors for three things: a training programme for three groups of staff, acceptance based on a user solving their own task, and follow-up support as a separate line in the pricing schedule. Below I explain why each one matters and how to phrase it.

By training I mean everything that gets a person to work in the system on their own by day three. A classroom course is part of it, but training starts earlier, with what the person sees on the screen.

There is also a regulatory reason for buyers in Europe. Article 4 of the EU AI Act, which has applied since 2 February 2025, says that providers and deployers of AI systems "shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf". If you deploy AI in the EU, training your people is already your obligation, and the contract decides how much of that work the vendor carries.

Why people avoid the system you bought for them

The most common reason applies to almost every corporate system: a complex, overloaded interface. I have seen people quietly sabotage such systems, and some candidates even turn down a job once they learn what they would have to work in. Survey data points the same way. In Ivanti's 2022 study of 10,000 office and IT workers, 49% said they were frustrated by the technology their employer provided, and 26% would consider leaving their job because of it.

Products built for another market add translation and layout problems, and Chinese products show this most clearly. A Chinese character carries more meaning than a letter, so a menu item takes far less space in Chinese than in English or Russian: 设置 is two characters, while "Settings" is eight letters. The W3C internationalization guidance warns that text translated from English and Chinese usually gets longer. If the interface was laid out for short labels, it starts to break after translation: labels wrap, buttons overlap, and words get cut off. Users do not try to separate a localization bug from a product bug. They see a broken screen and decide the system is not ready.

A subtler reason is the logic of the screen itself. In 2008 Dong and Lee tracked the eye movements of Chinese and American participants looking at the same web page: the Chinese participants scanned the whole page, while the Americans went straight to the main block. Yet cognitive tests show that Central and Eastern Europeans, Russians among them, think more holistically than Americans and Western Europeans (Varnum, Nisbett and colleagues, 2008 and 2010). By that measure Russians are closer to the Chinese than Americans are, and they still struggle with Chinese screens. I put this down to habit. For the past twenty years Russian companies have worked mostly in Western software, or in Russian software built on the same principles, and users have absorbed its logic. Habits can be retrained, but the work has to start before launch. The same holds for any team moving to a product designed in another culture.

AI products add two more barriers. Some people do not understand how AI works and fear it, while others expect a miracle, and in both cases they miss that results still rest on described processes and good data. On top of that, most AI products are built as a chat, and most people do not want to hold a conversation with a machine and keep track of it. They want a guided interface that shows what is happening and what to click next, and a product that is already configured for their tasks.

What else to check in the product itself before you buy it is collected in my article Nine Quality Criteria for an IT Product.

"But nobody trained us to use ChatGPT"

This is the objection I hear most often when the training budget comes up. People did learn ChatGPT and DeepSeek on their own, without courses, and in January 2025 the DeepSeek app climbed to number one among free apps in the US App Store within a few days, according to Appfigures data cited by TechCrunch.

For a personal tool that is true. The person chooses what to ask, decides whether the answer is good enough, and is responsible for what they do with it. In a company the task comes from a process, other people check the result, and the company pays for mistakes. People learn their own chat by themselves, but they will not learn to work inside a shared process without support. So if you are buying AI to change how a department works, rather than to give every employee an assistant, this objection does not apply to you.

What to put in the RFP and statement of work

The most useful thing a buyer can do before signing is to specify the training programme in the RFP and the statement of work. I look at it from two sides: who is trained, and how long the material will stay useful.

Three groups need training, and each brings its own question to the system. Users work in it every day: specialists, engineers, heads of departments. They need to understand how the model works and where it fails, learn to check its output, and go through three to five of their own tasks in the system hands-on. Technical specialists configure and maintain the system, so they learn how data and processes drive quality, how the closed environment and security are set up, and how to carry settings over on upgrade.

By the business owner I mean the executive who commissioned the system and answers for its effect, and who may hardly work in it at all. They do not need to know which buttons to press. They need to understand what the system can and cannot do, why there will be no miracle without a described process, how to measure the effect, and what will change in their people's procedures and roles. A user comes with the question "How do I do my job in this system?", a business owner with "What does this system change in my department, and how will I see it?" Train them with one programme, and users will be bored by the talk about effect, while the executive leaves a hands-on session feeling the day was wasted.

The material also ages at different speeds. Product skills (which buttons to press, which scenarios exist, how to solve your own tasks) deliver results here and now but go out of date with every release. Foundational understanding (how the technology works, where it fails, what drives quality) stays relevant for three to five years and survives any interface change. A programme with only the first layer will need rewriting in six months. A programme with only the second will leave people understanding everything and still not working in the system on Monday. So I ask for both layers for each group.

The general principles behind staff training are in my article Personnel training: a systematic approach.

One case shows how this works in practice. We ran training for a large steel company whose staff had had their own AI system for more than six months and had ignored it. Over three days we explained the basics of AI, showed on training examples how to solve their own tasks, which criteria to follow and what drives the quality of AI output, and, most importantly, people did everything hands-on throughout. After three days they started using the system, even though nobody had changed the system itself. What changed was that people understood what they could do with it.

Two or three days of intensive preparation with a trainer who shows, explains and supports are what immersion takes. The trouble starts afterwards, because training usually ends there and people are left alone with the system. In my experience, if there is no trainer support after that, more than 90% of people drop off and go back to their old way of working. So after the immersion people need targeted instructions or short videos on how to do the most frequent tasks, and it is worth asking the vendor for them together with the programme.

What to put in the contract

The main condition concerns acceptance. Delivery should count as complete not when the system is installed, but when a user, three days after training, solves their own task in it without a trainer. Technical specialists and business owners have their own results, taken from their row of the table: settings carry over on upgrade without the vendor, and the way to measure the effect is described and agreed.

Next comes preparation before the pilot. The vendor's engineer configures three to five of your real tasks in advance, so that on day one people see their own work in the system, and prepares targeted instructions or short videos for the most frequent tasks. If the product was built in another language, add a check of the live screens by a native speaker before release, because layout errors only show up in a working interface.

Finally, the pricing schedule. Training and follow-up support should sit next to each other as separate lines. I treat training without support as an expense: people get knowledge in a course, but skill forms later, on their own task, with someone nearby to correct them.

The vendor will probably object that acceptance by task shifts the risk onto them. But the vendor already controls that risk, because they configure the product and train the people. If a vendor refuses to put in writing a result you expect from them anyway, that is an answer too, and it is worth weighing when you choose.

What the buyer does

Some of the work no vendor can do for you. From each group, pick four or five of the most capable and motivated people and support them on a real task until they write the procedure or method for everyone else. From there the company scales the change itself, using rules written by its own people.

Resistance will appear along the way; I wrote about handling it in Implementation of changes.

All of this needs to start earlier than it seems. People cannot be switched on at the same time as the system: installation takes weeks, while habits take months to change. If training only comes up on launch day, the programme gets assembled on the fly, and users spend their first and most important days without it.

A product that teaches by itself

The best training is built into the product, and you can check for that in a demo. This is how we build BAEOS, an operating system for executives: processes, rules and scenarios are built in, so a user can start alone and the system leads them step by step.

Earlier I said that most people do not want to hold a conversation with a machine. That is why in BAEOS guided scenarios with buttons and a chat live in one product and pass into each other, and the user chooses how they prefer to work.

In the morning an executive opens the diary, and the first line offers a morning check-up: state, day and the main task, and if you agree with everything, three taps are enough. Below it sits the main task of the day with a "Change" button, and under that a timeline where meetings and tasks are already laid out by the hour. The whole scenario runs on buttons, with nothing to type.

The chat is always at hand, because the "Ask AI" button is on every screen. In complex tasks, though, it works differently from the familiar chat with an empty box for a question: the scenario and the conversation run in one window. When an executive sets a new goal, the Goals Strategist leads them step by step and brings in the context itself. It reminds them that two goals are already running in the 2027 window, and that a similar goal was dropped in September: the mall closed, but there were no people for it either. The question "What to do about scale?" comes with four answer options, one of them recommended, and in the fifth line you can answer in your own words, by text or voice. Meanwhile the goal card fills in on the right, showing which field is being decided in the conversation now and what is still missing for launch.

Decisions follow the same pattern. In the screenshot below, the executive has described the situation in their own words: the December table run depends on one machine, its load is above 85%, and the 28 December date will not hold without a second line. The system parsed the story and showed that only one of the five input fields is filled, then asked two clarifying questions and merged the answers into three options, each with its stake and risk. You accept an option or go another round with a button in the panel, and on the right you can see which step of the decision course the person is on: inputs, working, result, outcome. The choice stays with the person, and the panel says so: "waiting for you".

So people learn as they work: they see what information a decision needs, what the system does by itself and what it leaves to them.

In the end, a person who prefers buttons goes through the task as a scenario, a person who would rather write talks to the system, and in both cases they can see what is happening and what to click next.

In any vendor's demo, this is what I would watch: whether a new user can get through their own task without a trainer, whether they understand what is happening on the screen, and whether they can choose between buttons and words.

For more on how to bring AI into a company, see my book Artificial Intelligence. Freefall; the third edition is a free download.