In this article (5)
Organisations adopting AI in supply chain operations are encountering a constraint in the shape of their supplier data. The Achilles Global Supplier Risk and Sustainability Survey 2026, drawing on responses from 2,805 organisations, found that interest in AI-driven supplier risk management is growing quickly, and that adoption is being held back by fragmented supplier information, legacy platforms, and disconnected systems. The sample skews towards heavy industries rather than the sectors I spend most of my time in, but the pattern is consistent across both.
The conversation in the market has settled on the wrong axis. The AI questions being worked through inside most supply chain teams at the moment are about which model, which vendor, or which use case to pick. The question that actually decides whether any of those answers matter is whether the supplier data a model would need to read is held in a shape a model can read.
What the AI constraint in supplier data looks like in practice
The supplier data most buying organisations hold today sits across customer-specific portals, supplier-maintained spreadsheets, emailed attachments, PDF exports, and point-in-time CSV files. Each of these formats requires interpretation before any system can use it. A PDF certificate has to be parsed. An email thread has to be read to decide which of three attached files supersedes the others.
Every one of these formats assumes a human in the middle. The question arriving in most supply chain teams at the moment is whether a model can do that work instead. With supplier data held in these formats, the honest answer is that a model cannot read the files without the same interpretation layer a person currently provides. That is the shape of the constraint Achilles is describing. The bottleneck sits in the formats, and the formats are what supplier-side infrastructure has to change.
Four properties supplier data needs
For AI systems to be useful in supplier-facing operations, the supplier data they read needs to exhibit four properties. None of them is unusual on its own. Together they describe a different architecture from the one most buying organisations currently have.
Structured. Data held in defined fields with defined types, reachable directly rather than through an attached document. A model should be able to retrieve a material composition, a country of origin, or a certification expiry date as a value, without a document parser standing in front of it.
Maintained at source. The supplier holds the authoritative copy and updates it as the underlying reality changes. When a certificate is renewed, a formulation changes, or a manufacturing site is added, the update happens where the data is published. A system reading the supplier record reads what the supplier currently considers correct, rather than a copy taken during a point-in-time export earlier in the year.
Permissioned. Each consuming system sees only the data its user has been granted access to, with the permission boundary enforced at the data layer rather than in the consuming application. This matters for AI systems in particular, because models have no native concept of who is asking. If the permission is applied where the data lives, the same query can serve different customers correctly without relying on the consuming application to filter the response.
Queryable through an open interface. Any consuming system, whether an ERP, a BI tool, or an AI assistant, can reach the data through a standard interface, without a bespoke integration for each consumer-supplier pair. Every bespoke integration is a project, a timeline, and a cost. A standard interface collapses that work into a single connection that every consuming system reuses.
How supplier-published data meets these properties
When supplier data is published once by the supplier and made available to permitted consuming systems through an open interface, the four properties are present by construction rather than by aspiration. The supplier is the source of record, so the data is maintained where it is read. The publication format is defined at the point the data goes on the network, so the data is structured from the outset. The permission model is enforced where the data lives, so every consuming system receives the view its user is entitled to. The interface is open, so any consuming system can reach it without a bespoke build.
This is the shape supplier-side data infrastructure needs to take for AI adoption in supplier-facing operations to move from pilot into everyday use. It is also a different architectural starting point from the one most current platforms occupy, which tend to organise around the buyer sending requests rather than the supplier publishing records. The record is what a model can read.
What this means for AI adoption in supply chain operations
Structured, maintained, permissioned, and openly queryable supplier data is the precondition for AI systems to be useful in supplier-facing operations. The choice of model or vendor follows from that foundation; it does not substitute for it. Buying organisations that want their AI investments to produce work beyond the pilot stage will get there faster by asking where their supplier data is published and how a model would query it than by asking which model to run against the documents they already hold.
The missing piece
LinkXG is the supply chain data network built around this architecture. Its open interface is a standard API surface together with an MCP server, so AI systems in a customer’s stack can query supplier-published data within the permissions their user has been granted, through the same mechanism a human operator would use. Suppliers publish their product data once and decide what each customer sees, and buyers retrieve the current record through their own tools. The supplier-side starting point is the piece the agentic supply chain conversation has been missing.