Why the obligations attach to you as well as to the builder

The assumption that buying rather than building transfers the compliance burden is the single most expensive misconception in this field. It is not true under the AI Act, it is not true under Swiss sector supervision, and it is not true under model risk guidance. Each of those regimes puts duties on the organisation that uses the system, and two of them say so in terms.

The deployer obligation set

Article 26 is not a light-touch provision. A deployer of a high-risk system must use it in accordance with the instructions for use; assign human oversight to natural persons with the necessary competence, training and authority, and give them the support to exercise it; ensure input data is relevant and sufficiently representative where the deployer controls that data; monitor operation and inform the provider of what it finds; suspend use and notify where it identifies a risk; and retain the automatically generated logs for at least six months, the same floor that applies to providers under Article 19.

Four further duties are the ones most often missed. Deployers who are employers must inform workers' representatives and affected workers before putting a high-risk system into use at the workplace. Deployers that are public authorities must register. Deployers must use the information the provider supplies under Article 13 to carry out a data protection impact assessment where GDPR requires one. And deployers must inform natural persons that they are subject to an Annex III decision.

None of those can be performed by the vendor. They are duties about your workforce, your customers, your processes and your records.

The role flip

Article 25 turns a deployer into a provider in three situations: putting your name or trade mark on the system; making a substantial modification to it; or changing the intended purpose so that the system becomes high-risk. The consequence is not incremental. The full provider obligation set attaches, including technical documentation, a quality management system, conformity assessment and post-market monitoring.

No notification accompanies the change. It is discovered later, typically by whoever is asked to produce a technical file that was never assembled because the firm believed it had bought one.

Supervisors say the same thing in their own language

FINMA's Guidance 08/2024, published on 18 December 2024 on governance and risk management when using artificial intelligence, states that responsibility remains with the institution even where AI is bought in or outsourced. Its expectations run to an inventory of AI applications, risk classification, clearly allocated roles, testing before deployment and continuous monitoring, documentation proportionate to risk, and independent review separate from the developing unit. That is guidance rather than a circular and it creates no new rules, which is a point worth being precise about in your own policy. What it does is state how the supervisor will read existing obligations.

The US interagency model risk guidance takes the same position from a different direction: vendor models are expressly in scope, and the expectation is that you validate a vendor model in your own context rather than accepting the vendor's validation. The NAIC Model Bulletin on the Use of AI Systems by Insurers, adopted 4 December 2023, expects a written AIS Program covering governance, risk management, internal controls and third-party AI. It is a model bulletin rather than a model law, so it binds only where a state has adopted it, but where adopted it puts third-party AI squarely inside the insurer's programme.

What a contract can and cannot move

A contract can allocate cost, secure information rights, and oblige a supplier to notify you of changes. Those are worth having and you should negotiate for them: documentation provided, instructions for use sufficient to operate the system correctly, disclosure of sub-processors and upstream model providers, audit rights, and an exit plan if the supplier withdraws the product or becomes non-compliant.

A contract cannot move a public law duty. If the duty to inform affected persons falls on the deployer, an indemnity does not discharge it; it only pays for the consequences of not discharging it. Record what the supplier refused to provide, because a refusal is a finding rather than a blank.

Worked example: the assistant nobody procured

A Swiss private bank licenses a customer relationship platform. In March the vendor enables a meeting-summarisation feature and a next-best-action recommendation in a routine release. No procurement request is raised because no purchase occurred. Relationship managers begin relying on the recommendations within days.

The bank is a deployer of two AI systems it never assessed. It holds no instructions for use for either, has assigned oversight to nobody, is not retaining logs, and cannot say what data leaves the platform. Its third-party assessment for that supplier was completed at contract signature and describes a product that no longer exists in the form assessed.

The position is worse than an unassessed system. FINMA's expectation of an inventory of AI applications is now demonstrably unmet in a way the bank's own change records will evidence, and the responsibility sits with the institution regardless of the outsourcing. The remedy is structural: intake triggered by vendor release notes rather than by procurement events, and reassessment on any material change by the supplier rather than only at renewal.

As of 24 September 2026.