Skip to main content

Command Palette

Search for a command to run...

A European Investment Bank Just Asked Who Bears Regulatory Responsibility in Your AI Analytics Supply Chain: Answering the Article 25 Value Chain Questions

Published
4 min read

The email came from a vendor risk team at a mid-sized European investment bank. They're evaluating your AI-powered transaction analytics tool. The questionnaire has forty-three questions. Question 31 reads: "Under Article 25 of the EU AI Act, who in the AI value chain bears regulatory responsibility for this system, and what evidence can you provide of any responsibility allocation agreements?"

You forward it to your head of engineering. She forwards it to legal. Legal has not seen Article 25 before.

This post explains exactly what Article 25 says, how responsibility is allocated in an AI supply chain, and how to answer when an enterprise financial services buyer asks.

What Article 25 Actually Says

Article 25 of the EU AI Act addresses situations where multiple parties are involved in developing, deploying, or modifying a high-risk AI system. It establishes that regulatory obligations follow whoever performs a specific function — not just whoever built the original system.

The key rule: if a party places a high-risk AI system on the market under their own name or trademark, they take on provider obligations. If a party substantially modifies a high-risk AI system, they become a provider for the modified version and take on the full provider obligations that come with it.

This matters in fintech because AI models often pass through several hands: a foundation model provider, a fintech SaaS company that fine-tunes and wraps it, and a bank that deploys it for specific use cases. Each step in that chain can shift or create new regulatory obligations.

The Three Scenarios That Trigger Article 25 Questions

Scenario 1: You built the model and sell it as-is. You are the provider. You hold all provider obligations under Articles 9–23. Your customer is the deployer and holds deployer obligations under Article 26.

Scenario 2: You built the model and your customer customises it. If their customisation is substantial enough to change the intended purpose or performance characteristics, they may become a provider for the modified version and inherit provider obligations. Your questionnaire answer should describe what customisation you permit and what constitutes a substantial modification.

Scenario 3: You are built on a third-party model or component. If your transaction analytics tool uses a third-party AI component — whether an open-weight model, a vendor API, or a data enrichment layer — you need to describe the obligation allocation between you and that upstream provider.

How to Answer the Article 25 Question

Your answer needs to address two things: where you sit in the value chain, and what agreements govern responsibility allocation.

Where you sit: State clearly whether you are the provider (you built and market the system), a deployer (you use a third-party model for your own operations), or a downstream provider (you built a product on top of a third-party AI system). For a B2B SaaS fintech tool, you are almost always the provider.

Responsibility allocation agreements: Article 25(1) allows responsibility to be reallocated by written agreement between parties. If you have upstream agreements with foundation model providers or data vendors that address regulatory responsibility, summarise them. If you do not have explicit agreements, note that you as the placing-on-market entity bear full provider responsibility.

What your customer can do: As the deployer, your bank customer holds obligations under Article 26: use the system as intended, do not modify it in ways that change the risk classification, maintain logs for the required period, ensure human oversight is operational. Providing a clear deployer obligations summary as part of your vendor documentation is good practice and often what procurement teams are looking for when they ask the Article 25 question.

The Answer That Clears Procurement

The answer that moves an enterprise fintech deal forward is one that makes the responsibility map legible. Who built it. Who is responsible for conformity. What your customer is responsible for when they deploy it. Whether any third-party components are involved and how their obligations are handled.

Ambiguity on Article 25 is a procurement stall. Clarity is a deal accelerant.

Try Complizo free at complizo.com

More from this blog

Complizo

87 posts