AI in Procurement Processes: An AI Builder on What Actually Works

Most procurement teams no longer ask whether to use AI. They ask which of the AI they already pay for changes outcomes, and which only changes the slide deck.

Few people see that line as clearly as the engineers who build these systems. Nazar Ponochevnyi runs Harmix, a company that deploys AI agents into knowledge-intensive business processes, from email-driven workflows to matching mortgage deals with lenders.

Our interview with former Microsoft CPO Mike Simms examined AI in procurement from the operator’s seat. This conversation takes the builder’s view: what AI needs in place before it delivers, where it fails, and how to keep it inside its mandate.

Meet Nazar Ponochevnyi, CEO of Harmix

Nazar Ponochevnyi is CEO of Harmix, the AI company he founded as a student at Igor Sikorsky Kyiv Polytechnic Institute. Harmix started with AI music search for the media industry and now builds Pam, the Proactive AI Manager: an assistant that onboards itself into a company, learns its processes, and helps teams stay on top of priorities, follow-ups, and key decisions.

Nazar has worked as an AI researcher at the University of Toronto and is completing a PhD in Computer Science at the University of Toronto.

Where AI in Procurement Processes Delivers Real Improvement

The first test for AI in procurement processes is whether it changes a decision, or only the way a product is marketed.

Natalie Eksi: Where does AI improve decisions, and where does it only create the appearance of improvement?

Nazar Ponochevnyi: For decisions that rely on general knowledge, AI improves quality. Which markets to invest in, which countries to expand into: a manager who works these questions through with an AI agent makes a better call, because the agent knows more about the topic than any one person.

The appearance of improvement comes from products marketed as “AI-native.” Very often that means a base product with a thin AI layer on top, usually a chatbot that answers questions you could find on the website yourself. No decisions are made there.

Usage is the real test. Products have claimed AI for years while nobody uses it. If people don’t work with it daily, there was no improvement, only a brand.

Natalie Eksi: And internal strategic decisions?

Nazar Ponochevnyi: That’s where a general-purpose model is weakest. It doesn’t know how your company works, so its answers can look better while being less accurate. Internal decisions need internal context, and that means analyzing which decisions and tasks are involved before choosing the approach.

Why AI Gets Added for Its Own Sake

Natalie Eksi: Repetitive tasks and criteria-based decisions are obvious candidates for AI. What is the most common mistake?

Nazar Ponochevnyi: Starting from the solution. Teams imagine what a client could do on the platform and add a feature because the technology allows it. They move from solution to problem instead of from problem to solution.

Summarization is the clearest example. When LLMs became good at it, almost every service added a summarization feature. Not because users had a summarization problem, but because it was possible and it looked good in advertising. AI for AI’s sake is the biggest problem I see.

Where to Start: Automation as a Company Diagnostic

For leaders evaluating AI in procurement processes, Nazar’s most practical point is that even a failed automation attempt produces value.

Natalie Eksi: How should a company decide what to automate first?

Nazar Ponochevnyi: Start with what repeats most often and absorbs the most manual work. Then look at where the money sits: where the business earns the most and where it spends most often. That is the core of the business. Map the processes inside that core, find where you lose money or time, and evaluate the investment: how long a solution takes to build, and how much it saves or adds in revenue.

Natalie Eksi: What about processes that look too hard to automate?

Nazar Ponochevnyi: Start anyway. An automation attempt is an excellent diagnostic of a company. A process usually resists automation not because it can’t be automated, but because the company doesn’t capture information about it. There are no criteria, the documentation is outdated, or the knowledge sits in one person’s head, which makes that person a bottleneck for the whole organization.

The real constraints are regulation and cost, not technology. Some processes are too expensive to automate, and some are too rare to justify the investment. But if a process recurs constantly and the opportunity is large, automate it. Even if it fails, you will understand the process far better.

What “Right Data” Means for AI in Procurement

Data readiness is the first constraint on AI in procurement processes, and it starts earlier than most teams expect.

Natalie Eksi: What does “right data” mean to someone who builds AI systems?

Nazar Ponochevnyi: Very often, it simply means data that exists. In most processes we analyze, there is no data at all. The knowledge lives in people’s heads, or in one head. We extract it through interviews: the process, its stages, its criteria, the outcome it should produce. Only once it is documented do we start on automation. That is the most common situation in enterprises.

In more mature companies, the data exists but sits in the wrong place, so nobody can access it quickly. Or it is dirty: noisy, inaccurate, or stored in a format that doesn’t suit analysis. Cleaning it and improving the underlying systems turns it into data AI can work with.

Our focus is unstructured knowledge work: email, documents, decisions, deadlines, projects. That information lives outside any system, so structuring it is always part of the job. A factory running cameras and sensors on a production line has entirely different requirements.

AI in Supplier Sourcing: Four Points Where It Adds Value

Supplier sourcing is where AI in procurement processes shows its most concrete value, and its clearest limits.

Natalie Eksi: Take a concrete case. A food importer loses its usual supplier of sunflower oil and needs alternatives: the same product from another origin at a higher price, a cheaper substitute such as corn oil, or a lower grade within budget. Where does AI help?

Nazar Ponochevnyi: At four points.

Data mining

AI gathers what public sources hold on suppliers, products, market trends, average prices and volumes, and which countries offer better terms for political or other reasons. Wherever the volume of data exceeds what people can process, AI takes over. It lowers the price of intelligent work.

Capturing requirements

Buyers often don’t know exactly what they need, or their parameters are vague. An agent interviews the buyer and fills in the request: criteria, priorities, and where they are willing to compromise.

Matching

With clear criteria on one side and supplier data on the other, AI filters candidates, recommends the best fit, and shows where trade-offs are needed.

Negotiation and execution

Without a platform and contract templates, AI runs the back and forth: documents, follow-ups, reminders so nobody forgets to respond. In execution, it works alongside systems such as escrow accounts, so contracts and invoices go out correctly and nobody gets cheated.

Natalie Eksi: How does international sourcing change the picture?

Nazar Ponochevnyi: Trust. When I buy equipment from a large retailer, I trust the numbers it publishes. In international procurement, trust in any published figure is much lower, so verification of what suppliers claim becomes part of the process.

Supplier verification is where platforms close the trust gap. APSentra lets procurement teams define the documents every supplier must submit before entering the approved pool, as part of its supplier management workflows. See how Kernel standardized supplier selection across 700+ users on one platform.

How Accurate AI in Procurement Needs to Be

Natalie Eksi: Sourcing decisions bind money and contracts. How accurate does AI need to be?

Nazar Ponochevnyi: It depends on the stage and on the cost of an error. In our work with mortgage brokers and lenders, the structure is close to procurement. Brokers bring deals; lenders have criteria: which regions they invest in, their LTV limits, their rates. The agent has to master that terminology and know which criteria matter, and that matching works well.

Where an error is unacceptable, a general-purpose LLM is not enough. You build something custom: fine-tuning, custom models, or additional checks written directly in code. That brings the risk of error close to zero.

How Executives Should Verify AI-Generated Insights

Verification is where AI in procurement processes succeeds or fails in practice, because a person still signs off on the outcome.

Natalie Eksi: What should an executive check before acting on an AI-generated insight?

Nazar Ponochevnyi: The reasoning. I always ask the AI to explain, briefly and in plain language, how it reached its conclusion from start to finish. Then I verify the intermediate steps. If it says a source document contains a particular point, I check that the point is there. That is the first signal it isn’t hallucinating.

This works because I know the input data and have the domain knowledge to judge where the result should land. If the intermediate steps hold and the result matches my expectations, I act on it.

I don’t verify 100% of an agent’s analysis. I select the most important 10% and check it manually. For critical decisions, I do the task myself first, then give the AI the same data and compare. For a prototype, where an error costs little, I check less and automate more.

The approach mirrors the judgment line Mike Simms described: the cheaper an error is to reverse, the more can be delegated; the costlier it is, the more a human must own.

Proactive AI vs. AI That Oversteps Its Mandate

As agents gain the ability to act, the governance question for AI in procurement shifts from accuracy to authority.

Natalie Eksi: Pam works proactively. Where is the line between proactive AI and AI that oversteps its mandate?

Nazar Ponochevnyi: Pam proactively reads everything a person has, documents and email, to understand what is happening in the company. But in the production release, Pam Memory MCP, it acts only on workflows the user sets up, such as “check my email and draft the replies.” The user decides which permissions to grant. Pam collects and analyzes information; it does nothing with it on its own.

The direction is clear: an assistant that gathers information, calls you, reminds you, and gets things done like a colleague. At that point, the line works the same way it does with people. People can be too proactive too, which is why companies set access rules for information and actions. When someone breaks protocol, a detection system flags it and escalates it to management. AI should work the same way: defined access, detection of out-of-protocol actions, blocking, and escalation.

Natalie Eksi: So overstepping is the main risk?

Nazar Ponochevnyi: The bigger risk is distraction cost. AI processes information far faster than people. A task you would give a colleague for a week comes back from an AI in five minutes, and instead of doing your own work, you spend the day answering your AI. The challenge is guiding AI without spending all your time on guidance.

The goal is AI you trust with more autonomy, without micromanagement. But the moment you stop micromanaging, you meet the overstep problem: the agent does something you never wanted, because it didn’t know it needed to ask.

AI Agent Permissions: How to Design the Boundary

Permission design is the control layer that makes AI in procurement processes safe to scale.

Natalie Eksi: Vendors sell agentic capability; organizations grant autonomy. How do you design for that permission boundary?

Nazar Ponochevnyi: We work through the same sequence on every integration.

1. Regulation and certification. We start with the rules that apply to the client’s industry and data, and whether that data needs special processing or certification. We certify our own processes too: we have completed a SOC 2 compliance audit, which allows us to handle sensitive data categories.
2. Data scope. We check which features actually need which data, and remove everything else. Data the agent doesn’t need is data it shouldn’t analyze.
3. Action scope and isolation. We define which actions the agent may take and run it in a new, isolated environment rather than inside existing systems. It proves itself in a limited beta before a gradual release.
4. Technical deployment checks. Which agent runs, on which servers, whether any data leaves the environment, and under which data management, regulatory, and retention policies.

These checks are standard across enterprise security guidelines. We design so a blocker sits wherever something could go wrong, and we build every new capability in isolation, so we see the whole environment and can stop any problem immediately.

Nazar’s sequence complements the minimum controls Mike Simms set out: a named owner, an audit trail, and a kill switch. It adds what comes first, limiting what an agent can see and do before it acts. For a wider view of this in advisory work, see our analysis of AI in procurement consulting.

Key Takeaways

• Usage is the test of real AI value. A thin chatbot marketed as “AI-native” changes no decisions.
• Start from the problem. AI added because the technology allows it is the most common failure.
• An automation attempt is a diagnostic. It exposes missing criteria, outdated documentation, and knowledge held by one person.
• “Right data” usually means data that exists. Documenting the process comes before automating it.
• Verification scales with the cost of error. Check the reasoning, review the critical 10%, and run critical decisions in parallel by hand.
• Govern agents like people. Defined access, detection, escalation, and a narrow permission boundary before go-live.