Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
This course is about checking an AI system before purchase, so a deployer can make a defensible buying decision. It rests on the EU AI Act as the main legal frame, and it treats procurement and compliance as the people who have to decide what to ask for and what to refuse. Many teams treat AI buying like software buying, where a demo and a security review feel like the hard part. The hard part is judging how the system behaves in use, because its outputs can shift with prompts, data, and context. That shift hides in plain sight, because the vendor can still show a polished workflow. The buyer still has to decide what evidence is enough.
An AI system, in this course, means software that produces outputs like text, scores, recommendations, or decisions from inputs, and those outputs can influence what people do next. That matters in procurement because the same feature can be low impact in one use and high impact in another, depending on who the outputs affect and how they are used. The work already happens in everyday steps like reviewing a supplier pack, approving a use case, and setting conditions for rollout. It gets hard when the purchase question is not only does it work, but also what could it do in our setting that the demo did not show. Seeing the whole workflow upfront helps, because each check belongs to a specific moment in the buying process. Here is the shape of that workflow at a glance.
A normal software tool usually does the same thing for the same input, so you can test it once and lock the result into requirements. An AI system can be consistent in uptime and still be inconsistent in content, because it generates or infers outputs rather than following fixed rules. That means you cannot rely on a single acceptance test to stand in for ongoing use, even if the vendor calls it production ready. You need to tie evaluation to the exact use you are buying for, including who will read the output and what action it can trigger.
The procurement trap is treating the model as the product, when the product is the whole system around it. The system includes the user interface, prompts, retrieval from your documents, integrations, and any human review step. Those parts decide what data flows where and what gets recorded. They also decide how easy it is to spot mistakes before they reach a customer, a candidate, or an employee.
Procurement and compliance do not have to own delivery to run good due diligence. You own the decision to buy and the conditions you set, which means you can require artifacts and clear answers before signature. Product and IT usually own integration details, while privacy owns the data protection view, but you can still ask each of them for one concrete input that supports the buying decision. The key is to ask questions that produce documents, not reassurance.
A useful division of labor is to separate what the vendor claims, what your internal teams confirm, and what you can observe in a trial. Vendor claims live in things like a datasheet, a security report, or an instructions for use document. Internal confirmations live in things like an integration note, a draft operating procedure, or a risk sign-off. Observations live in test records, red-team notes, and screenshots of what the system did with your prompts and your data.
This check is only worth doing if it changes what you pay attention to next. The same system can look safe in a demo and still raise a first-question concern once you name the use case and the affected people. Pick the first concern you would raise in each snippet, because that is what drives the next request you make to the vendor.