Follow an AI purchasing assistant from supplier research to an authorized order, exploring the data, controls, infrastructure, and human decisions needed to make it work.
One Operational Ecosystem, Part 1
Imagine a purchasing manager asking an AI assistant to find a replacement supplier for a component. The current supplier has missed two deliveries. Production needs an alternative by Friday.
The assistant searches supplier records, compares prices, checks specifications, and prepares a recommendation. It could save someone hours of work. Give it access to the purchasing system and it could also prepare an order.
Before that order goes out, someone needs to know whether the specifications are current, whether the supplier is approved, and whether the person requesting the purchase can authorize that amount. The quoted price may have expired. A document might belong to a different business unit. The assistant may have found a convincing substitute that fails one essential requirement.
This is a hypothetical example, but it describes the kind of work I want to focus on in this series. An ordinary business task brings AI, data, cloud services, and cybersecurity into the same decision. Each part affects what the organization can safely ask the system to do.
In December, I will join the Day 1 panel at Koncept Conference in Phuket to discuss these technologies as one operational ecosystem. My starting point is the work itself: what needs to happen, who can authorize it, and what happens when something goes wrong.
Agree on the job
For the purchasing team, the initial goal might be to reduce the time spent finding suitable suppliers. That gives the project a clear scope. The assistant retrieves information and prepares a comparison. A purchasing manager reviews it and makes the decision.
Letting the assistant place orders would expand that scope considerably. It would gain the ability to commit money and create obligations with another company. That calls for a fresh decision about its authority, controls, and ownership.
In the first chapter of my Applied AI Handbook, I set out four conditions for proceeding with an AI initiative: a real problem, a justified use of AI, a named outcome owner, and explicit conditions for stopping. For this purchasing assistant, those conditions should be settled before choosing a model or a hosting provider.
The team should also compare the proposal with simpler improvements. A better supplier search or a cleaner approval process may solve enough of the problem to change the business case. That comparison helps establish where AI earns its place.
Follow the information
The purchasing assistant needs to distinguish a current specification from an old copy attached to an email. It needs a way to check the supplier's approval status and the terms attached to a quote.
I would want the recommendation to show the records it used, their versions, and any missing information. If two specifications conflict, the person reviewing the recommendation should see the conflict before placing an order.
Access rules need to apply along this path. Information that a user cannot open directly should also be protected when it appears in search results, summaries, or generated comparisons. A useful design review follows the information through each of those steps.
This is where the data work becomes inseparable from the AI work. The usefulness of a fluent answer depends on the material behind it and the conditions under which that material can be used.
Make the approval specific
Suppose the manager approves an order for 500 units from a particular supplier at an agreed price. The approval should remain attached to those details. A change to the supplier, quantity, or price needs a defined response.
In The Hyperproof Manifesto, I describe a mandate as a signed declaration of intent tied to a specific decision and explicit constraints. Applied here, that means keeping a verifiable record of what the manager actually authorized and checking it when the purchase is submitted.
The purchasing system should enforce the amount and supplier restrictions at the point where the order is committed. An instruction in the assistant's prompt can help guide its behavior, but the transaction needs its own checks. If the assistant proposes an order outside the approved terms, the system should hold it for review.
The review screen matters too. The manager needs to see the terms, supporting records, and unresolved questions clearly enough to make a decision. Someone who has neither the time nor the information to review an order cannot provide useful oversight by clicking an approval button.
Choose where the work runs
The same workflow can involve several locations. Supplier records may sit in a business application, documents in cloud storage, and the model on a hosted service or a local appliance.
I would assess those choices against the actual task. Which information will leave the organization? What will the receiving service retain? How quickly must the assistant respond? What should remain available during a connection failure? Who will maintain the equipment and software?
A local deployment still needs access controls, updates, backups, and someone responsible for operating it. A cloud deployment needs clear decisions about data handling, service dependencies, and recovery. The right arrangement depends on the organization's requirements and its ability to support that arrangement over time.
For the purchasing example, a connection failure might leave an assistant able to read a cached catalog while unable to confirm current prices. The interface should make that limitation visible and hold the order until the required checks can be completed.
Give someone the means to intervene
The outcome owner needs a practical way to pause the assistant, investigate a recommendation, and return the team to a workable process.
That means retaining enough information to review the source records, proposed order, approval, and final action. It also means deciding what to do with pending work during an interruption. A stopped assistant could leave partially prepared orders that need attention.
Chapter 3 of the Applied AI Handbook treats these choices as part of system design. The ability to observe and intervene needs to be built into the workflow. It affects the interface, access permissions, records, and operating procedures.
I would measure the purchasing assistant against the job we started with: how long it takes to produce a usable comparison, how much checking it creates, and whether the resulting purchases meet the team's requirements. Those measures give the owner a basis for continuing, changing, or stopping the system.
For anyone preparing to introduce AI into a business, I suggest choosing one ordinary task and following it all the way through. Bring the people responsible for data, security, infrastructure, and the business outcome into that discussion. Use a specific transaction so that unclear responsibilities and missing checks become visible.
For our purchasing manager, the final test is straightforward: can the team explain how a supplier recommendation became an authorized order, and can it stop that order when the conditions change?
Dom Jocubeit is the founder of Hypermodern and an AI systems architect working across software and hardware. He will join the panel “Tech Convergence: AI, Cloud, Data & Cybersecurity: One Ecosystem” on Day 1 of Koncept Conference in Phuket, December 3, 2026, from 10:15 to 11:00 AM.
Further reading
- Dom Jocubeit, Applied AI Handbook: Implementing AI Without Breaking the Business, the Law, or Trust, Chapter 1, “Problem Framing and Legitimacy,” pp. 23–27; Chapter 3, “System Design as Governance,” pp. 35–39.
- Dom Jocubeit, The Hyperproof Manifesto: On Legitimacy, Consent & Executable Authority, Chapter 7, “What a Mandate Is,” pp. 77–82.