The Vendor Accountability Gap explained | EU AI Act obligations

Most of the agents running in production today weren't built entirely in-house. They sit on top of a foundation model from one vendor, a tool or plugin from another, sometimes an orchestration layer from a third. When something goes wrong, the instinct is to ask which of those parties is responsible.

The updated regulatory accountability question is bigger than a vendor-management problem: it's a full set of legal obligations that fall on whoever operates the agent, regardless of who wrote the code underneath it.

Provider and deployer are now separate roles, and most organisations are both.

The EU AI Act splits obligations across two roles. 

1. Providers, the entities that develop an AI system and place it on the market carry the heavier set: a risk management system, technical documentation, conformity assessment, post-market monitoring, serious incident reporting. 

2. Deployers, the entity that puts the system into professional use, carry a separate legally binding set under Article 26: use it as per the provider's instructions, assign competent human oversight, monitor its operation, suspend use and report if something's wrong, retain logs for at least six months.

An organisation that builds its own agent in-house and deploys it, takes on both roles - provider and deployer. Buying from a vendor doesn't add an obligation that wasn't there before; it just means the provider duties sit with someone else while the deployer duties, i.e. the monitoring, the oversight, the logs, sit with you.

Traditional third-party risk management was built for software that doesn't change once you've signed it off. You review a vendor at onboarding: security questionnaire, SOC 2 report, maybe a penetration test. You set up an annual review cycle. In between, you assume the system behaves the way it did when you assessed it, because for deterministic software, it mostly does.

That model rests on two assumptions: the vendor's system is static between reviews, and the vendor will tell you if something material changes.

 

The obligation itself isn't new, it's consistent with DORA's Article 28. What's changed is what discharges it. Deterministic software could satisfy that standing obligation with a review at onboarding and another the following year, because deterministic software doesn't change behaviour between reviews. An agent can, and does.

ISO 42001, PRA SS1/23 and NIST AI RMF standards have specific controls for third-party and supply-chain due diligence on vendor AI components, and a separate control for continuous monitoring and drift detection. These are the hardest parts of the frameworks to operationalise, because it demands ongoing monitoring rather than a one-time onboarding check.

The mandate exists, but most organisations don’t have capability to meet it.

The EU AI Act adds a concrete legal version of the same expectation, i.e use it per the provider's instructions, assign competent human oversight, monitor its operation, suspend use and report if something's wrong, and retain logs for at least six months. This imposes financial penalties for non-adherence.

So the practical changes enterprises need are to operationalise these controls. This can be tiered based on the level at which autonomous decisions and actions are being taken.

What actually needs to change

1. The operational framework

Vendor risk tiering needs to include whether the vendor's system makes autonomous decisions or takes autonomous actions and vendor contracts need additional change notification clauses, e.g. when the underlying model changes, plus a right to independently verify behaviour at any time

2. The technical framework

You need to be able to verify behaviour in runtime whenever requested, which requires monitoring and alerting on AI system behaviour drift rather than code change/deploy. You also need to maintain an AI inventory with risk classifications, data governance moves from access review to purpose verification and authentication moves from ‘who did this’ to evidence of ‘what was done’ 

What non-compliance actually costs

EU AI Act Article 99 sets a three-tier penalty structure. Article 5 prohibited practices carry the highest fines: up to €35 million or 7% of global annual turnover, whichever is higher. Article 26 deployer duties sit in the second tier: up to €15 million or 3% of global annual turnover. Supplying incorrect or misleading information to a regulator sits in the third tier: up to €7.5 million or around 1% of global annual turnover

This penalty regime has applied since 2 August 2025.  Fines can already be issued for breaches of anything already in force, meaning Article 5 and GPAI breaches are sanctionable today. Article 26 deployer duties become sanctionable in December 2027, once Annex III comes into force.

None of this is a reason to slow down deployment. It's a reason to know, for every agent you ship, who's accountable, what's changed since it was approved, and what would tell you if it hadn't stayed within its approved boundaries. 

BASTYN's continuous, independent evidence layer provides the technical answers that most agent deployments aren't built to produce. Closing the full gap is an organisational and contractual job as much as a technical one: redrafting vendor terms, re-tiering risk registers, rebuilding change management. That sits with your teams, not with any vendor. 

Still, knowing that deployer duties is the easy part. Having evidence for a regulator, an auditor, or your board is the difficult part. BASTYN's adversarial assessment tests your agent against 23+ risk vectors mapped to the EU AI Act, DORA, FCA and ISO 42001. Get your cryptographically signed Trust Credential within three days within a confidential data environment. 

<Test Your Agent With a €10 Free Credit>

contact@rootedlogic.ai  |  www.trustyouragent.org