Who’s who in your AI supply chain?
By Iain Barclay ·
Here's a scenario that software companies will recognise, as they try to maintain a competitive edge.
Ledgerfield makes accounting software for small businesses, and they have just added receipt scanning. An employee photographs a receipt, and the app fills in the supplier, the date, the amount and the VAT. Ledgerfield didn't build the part that reads the receipt. It sends each photo to Parsewell, a specialist document-reading company, whose own AI does the reading and sends the answer back. Ledgerfield built it into the app's expenses screen, where their customers' staff check the result before it goes into the accounts.
It's a cool feature, with some baggage that's easy to miss. Ledgerfield didn't build the AI, but by shipping it, they have taken on new commitments. Bringing in AI built by external specialists and vendors adds new dependencies, and because their customers' data flows through them, these aren't just technical concerns.
Five layers, four handovers
One way to visualise this is to draw the supply chain:
- Source Materials: the underlying AI model, and the data it was trained on.
- Capability Builders: Parsewell, the document-reading company, which trained that model and turned it into a service that reads receipts.
- Integrators: Ledgerfield, the accounting software company, which put that service into their product.
- Operators: the businesses that use the accounting software, and their finance teams.
- Affected Parties: the employees whose receipts are read, and the suppliers named on the invoices.
These layers come from Boundsmap's Roles & Boundaries Framework, which originates from published research on accountability in AI supply chains, tested with practitioners from industry, government and academia. Its point is that the interesting questions sit in the gaps between the layers, where one party hands something to the next and has to be trusted about it. One of the practitioners interviewed predicted how integrators would judge an AI they bought in: "oh, it's from Google and must be good."
In the supply chain of our story, two companies stand between the AI and the business using it, and the people at the sharp end have probably heard of neither.
What is settled, and applies now
Look at the handover between Parsewell and Ledgerfield - the document-reading company and the accounting company.
Ledgerfield handles their own customers' data: staff receipts and supplier invoices. When they pass those to Parsewell, UK and EU data protection law treats that company as a sub-processor, a supplier handling someone else's personal data on your behalf (GDPR Article 28). The law then says three things have to be true of that dependency, and they are the same in both jurisdictions:
- Your customers know it is there, and have authorised it in writing.
- It is held to the same standard you are. Whatever data protection terms you promised your customers have to pass down to it. The law calls the document that does this a processing agreement.
- You own it. If it fails, you stay fully liable to your customers, the same way a bug in a third-party library you shipped is still your bug.
And there's more to it: if Parsewell can use what they receive to improve their own models, then for that use they are not working for you at all. They are now making their own decisions about your customers' data.
None of this is new law. It applies to every supplier a small software company already sends their customers' data to. Adding an AI feature brings a new company into the supply chain, and obligations follow the data. To be honest, most companies probably know this - or should do.
The same applies if you call Claude or GPT yourself. Most SMEs don't use a specialist AI vendor, their own engineers call a general-purpose model from one of the big firms. The model's supplier then becomes a dependency that sees your customers' data every time it runs. Here the deciding fact is simple: is it an account your company pays for, on the provider's business terms, or a personal, free or consumer one? As of September 2026, the big providers' business terms describe the provider as handling your data on your behalf, include a processing agreement, and say they don't train on your inputs by default. But their consumer versions don't. And the crucial line is the paid business account, not the word "API": at least one provider's consumer terms cover API keys used by individuals, and some free API tiers train on what you send.
And if any of these suppliers, Parsewell or a model provider like OpenAI or Anthropic, processes the data outside the UK and EU (US for example) sending it there is an international transfer. That has rules of its own: the data needs a recognised safeguard to travel, on top of the processing agreement.
What is not settled
So far, this has been all about data, which is pretty well-trodden ground: the rules are years old, and most software companies have been through them before. Adding AI features raises new questions, and the first is whether (and whose) AI laws and regulations apply at all.
Currently, the UK has no AI Act of its own - the EU does. It does reach UK companies, though, when they sell their systems into the EU, or when the output produced is used there. If Ledgerfield had customers in Ireland, for example, it would apply.
The EU AI Act gives obligations to roles. The provider develops an AI system, or has one developed, and puts it out under its own name (Article 3(3)); the business that uses it is a deployer (Article 3(4)). The provider carries most of the weight, including the obligation to tell people when they are dealing with an AI (Article 50(1)).
So the first question to ask is: who is the provider? Is Ledgerfield the provider of their receipt-scanning feature, a deployer of someone else's system, or something else? For a system like this, which is not high-risk, the Act does not say. The rule for when a reseller or integrator becomes the provider, Article 25, is written for high-risk systems only, and does not apply to most of them until December 2027. As of September 2026 I have yet to find any guidance from the Commission on it, but it will come in time.
For now, that is uncomfortable - some of the questions people most want answered about AI regulation do not have answers yet. But the questions that do have answers, about your AI supply chain and your customers' data, are the ones you can act on today. And we can flag the others as known but open questions.
Boundsmap
That's why we've built Boundsmap: a map of your AI supply chain, and what the law asks at each handover in it.
To get started, you (or your AI assistant) simply describe your system in plain words. Boundsmap maps it onto the five layers and four boundaries, which you can check and correct if needed. Then a rules engine works out what UK and EU law asks at each boundary, and whose obligation each item is. The engine is deterministic and tested - it's not an AI model. Where your answers leave something open, Boundsmap asks you a question you can answer without knowing the law, such as which kind of account you use, or whether your supplier keeps what you send it. Where the law itself is open, as with the provider question above, it says so and lays out the readings, rather than picking one.
Importantly, Boundsmap isn't providing legal advice, and it doesn't replace an adviser. It just gives you a clear, checkable map of your AI system and a spotlight on your own position. This is the right place to start conversations - with your team, suppliers, customers, investors - and a lawyer.
If you are building AI into a product, or advising companies that are, you can see an example map with no account, or map your own product. Explorer is free: map one AI product.