AI in Procurement: What Should Stay Human? Lessons from PASIAWorld 2026

AI can assemble a supplier brief faster than a buyer can move between a contract folder, a spreadsheet and an ERP screen. Whether it should negotiate, approve or commit the business is a different decision. That distinction should shape the next procurement pilot before anyone chooses a model.

At PASIAWorld 2026, the conversation about AI-ready procurement brought that boundary into focus. Embiggen X’s account of CEO Rolan Marco Garcia’s contribution emphasised a practical division: let agents prepare and reconcile information, while people retain responsibility for consequential supplier decisions. This article develops that position into an operating framework for procurement leaders.

01 The procurement question at PASIAWorld 2026

PASIAWorld 2026 took place on October 8–9 at SMX Convention Center Manila, organised by the Procurement and Supply Institute of Asia. The venue’s event listing confirms the dates. The conference connected supply-chain, procurement and logistics discussions with the accompanying SupplyCon exhibition.

The organiser’s published programme included sessions on agentic procurement, AI governance and the changing role of procurement professionals. A panel on the second day addressed the balance between AI capabilities and work that remains human. It is a useful question because procurement combines repeatable administration with decisions whose consequences extend far beyond a purchase order.

In its event post, Embiggen X identifies Rolan as an AI transformation subject-matter contributor to the procurement panel. The practical recommendations below build on that company account and the cited research. They are not a transcript of the panel or a claim that all speakers endorsed the same approach.

02 Set the boundary by consequence, not the task name

A task label is a poor way to decide how much authority to give an agent. “Supplier negotiation” could mean exploring payment terms on a routine contract. It could also mean changing a relationship that keeps a factory operating. “Invoice checking” could mean finding a mismatch, or authorising a payment. The same label can conceal very different risks.

Begin with the action the system would be allowed to take. Reading records, drafting an explanation, sending a message, changing a master record and making a commercial commitment are separate permissions. A pilot can deliver useful assistance at the first two levels without receiving the others.

Consider a low-value component from the only qualified supplier for a production line. The amount on the invoice is small, but an incorrect decision may threaten continuity. Conversely, a larger, routine purchase under an established agreement may be easier to evaluate. Spend size belongs in the assessment, alongside substitutability, reversibility, delivery criticality and the ability to detect an error.

For each candidate workflow, write down the worst plausible mistake, who would notice it and how the business would recover. If nobody can answer those questions, “human in the loop” is only a phrase. The loop needs an owner, a decision point and enough information to make review meaningful.

03 What the Walmart example actually helps us understand

Walmart’s supplier-negotiation work is a useful reference for bounded deployment. Pactum’s account describes a Canadian trial involving indirect purchases for store operations, including fleet services and shopping carts. That is a specific commercial setting, not proof that every supplier relationship should be automated.

The operational lesson is to define the eligible scope before introducing autonomy. Decide which suppliers, terms and exceptions belong in the workflow, then evaluate the result in that context. A procurement team should not treat another company’s agreement rate or savings as its own forecast. Its contracts, supplier base and negotiating authority may be materially different.

For a first deployment, distinguish preparing a negotiation from conducting one. An agent might collect historical spend, identify the applicable agreement and draft options for a buyer. Allowing it to communicate those options externally requires a further decision about approved wording, permitted concessions and escalation. Authority should expand only when the evidence supports that specific step.

04 Start with one observable handoff

A useful first problem is often a handoff that already consumes time: turning a purchase request into a complete brief, reconciling invoice evidence, or gathering the documents needed to review an expiring contract. Choose a point where the current delay is visible and where a person can judge whether the proposed output is correct.

Take invoice checking as an illustrative workflow. An assistant receives an invoice, locates the purchase order and compares it with receiving information and the relevant commercial terms. Its initial job is to present a traceable comparison. It does not need payment authority to make a discrepancy easier to investigate.

Suppose the invoice quantity differs from the recorded receipt. The assistant should identify the conflicting records and route the exception to the person responsible. It should not invent a missing delivery, silently change the purchase order or interpret a supplier’s message as permission to release payment. The useful output is a well-supported question that reaches the right owner.

The illustration shows that distinction: records become a comparison, a mismatch reaches a buyer, and the payment remains on hold until the authorised process resolves it. It depicts an operating rule, not a measured customer result. A clear exception path can be more valuable than a demonstration that completes only easy cases.

05 Make the data usable for that decision

Procurement information often spans an ERP, supplier files, email and spreadsheets. Connecting those sources is necessary only to the extent that they support the chosen decision. Start with a small inventory of authoritative inputs rather than an unrestricted search across every company document.

• Identify the supplier and document keys used to join records, including duplicate or legacy identifiers.
• Record who owns each source and how quickly changes reach it.
• Specify which agreement or amendment takes precedence when terms conflict.
• Define the minimum evidence needed to produce a recommendation.
• Keep access limited to the workflow and preserve a route back to the original record.

Freshness matters as much as format. A correctly extracted price from an expired agreement is still the wrong basis for a decision. A receipt posted after the analysis should not be treated as information the assistant had earlier. Retain enough context to explain what was known when the recommendation was made.

This is where connected-data work can support a bounded pilot. Embiggen’s DataCore approach concerns bringing relevant information together. The implementation still needs source ownership, access decisions and an agreed handling rule for missing evidence. A connection alone does not resolve a disagreement between records.

06 Name the person who can resolve disagreement

One of the most useful questions in Embiggen’s post is what happens when an agent and a human disagree. A buyer may reject a recommendation because the system missed a constraint. The buyer may also be relying on an undocumented exception that other teams need to understand. Neither case is solved by counting overrides without investigating them.

Write a short decision policy before the pilot begins. Name the process owner, define who can approve each action and identify the escalation route when the reviewer lacks authority. Set a response expectation so an exception does not disappear into a shared inbox. Make the evidence available at the point of review.

Capture the reason for an override in operational language: wrong agreement, stale receipt, missing approval, unusual supplier condition or changed business priority. Review recurring causes with the relevant owner. Updating a rule or data source through a controlled process is different from assuming that the model automatically learns from every correction.

BCG’s 10–20–70 approach recommends directing the largest share of transformation effort towards people and processes, alongside algorithms, technology and data. Treat it as a resource-allocation guideline. It is not a measured failure rate, a universal budget formula or proof that a particular pilot will succeed.

07 Use a 90-day pilot to answer a bounded question

Embiggen’s post proposes a 90-day starting period. The plan below is one way to structure that window, subject to access, procurement controls and the frequency of the work. A calendar deadline does not create enough representative cases by itself. A low-volume process may need a different evaluation period.

Days 1–30: establish the baseline and permissions

Select one workflow, one accountable owner and a defined group of cases. Observe how people complete the work today, including checking and rework. Agree what the assistant may read, what it may draft and what it must never change. Assemble representative examples with both routine cases and exceptions. Define success and stop conditions before reviewing a polished demonstration.

Days 31–60: compare recommendations with the existing process

Run the assistant alongside the current workflow. Record its recommendation, supporting records, uncertainties and the reviewer’s decision. Keep real commitments with the established process. Investigate errors by type rather than compressing them into one accuracy number. Check whether the assistant saves time after review effort is included, and whether it makes exceptions easier to understand.

Days 61–90: decide whether to stop, improve or expand

Review the evidence with procurement, the process owner and the people responsible for technical reliability. Resolve recurring failure modes before increasing scope. A successful pilot may justify wider use of a reviewed brief; it does not automatically justify autonomous negotiation or payment. Document the exact permission being expanded, the monitoring required and who can suspend it.

08 Measure the work after review, not just generation speed

A fast first draft can create slow checking. Measure the complete journey from receiving usable inputs to a reviewed output. Separate time spent gathering records, analysing differences and resolving exceptions. Compare like-for-like cases so an easy pilot sample does not make the new process appear better than everyday work.

• Useful output: did the reviewer receive the correct records and a clear explanation?
• Review effort: how much checking and correction did the output require?
• Exception handling: were uncertain or conflicting cases routed to the right owner?
• Control compliance: did the system stay within its approved permissions?
• Operational effect: did the reviewed workflow improve the specific delay or problem selected at the start?

For negotiation pilots, define commercial measures carefully. An offered discount is not the same as realised savings, and a payment-term change can affect a supplier relationship. For invoice work, a flagged mismatch is not automatically a prevented loss. Keep proposed benefits, verified findings and realised outcomes distinct.

09 Bring one procurement decision into focus

The next step after an AI conference should be a decision about work. Choose a recurring procurement handoff, identify the evidence it needs and name the person who owns the result. Then test whether assistance improves that handoff under controls the team understands.

That is the practical opportunity behind the PASIAWorld discussion. AI can help organise information and prepare action. Leadership must decide where its authority begins, where it stops and who takes responsibility when the answer is uncertain. Those choices turn an interesting demonstration into a process that can be evaluated and maintained.

Discuss one procurement workflow with Embiggen X and define the evidence, ownership and boundaries for a first pilot.