Question four is the one that doesn't resolve once and stay resolved. A recent industry ledger counted 89 model-ID retirements across ten vendors this year; notice periods were computable for 51 of those and ranged from 39 to 184 days, a spread of over four months between fastest and slowest. Nailing that down at signing settles today's model. That spread means the same question may need a different answer the third time the model changes.
That points at a gap underneath the incentive argument. Vendors answer now partly because the clock hasn't started, but also because most vendor-risk processes are built to ask once, at procurement, with no mechanism to reopen dormant questions when a live contract's underlying model changes. Getting the answer in writing protects the deal you signed. It says nothing about the one three model updates from now.
I'd call this a filing problem more than a vendor problem. The questionnaire gets answered once, stapled to the contract, and doesn't get opened again until renewal. So a notice clause that only says "new model shipped" isn't worth much. It should also tell you whether the intended purpose or the instructions for use changed, otherwise you've basically paid for an email.
The role question has one answer no vendor statement can override: Article 25(1) turns a deployer into a provider by operation of law. Putting your own name or trademark on a high-risk system already on the market, making a substantial modification that keeps it high-risk under Article 6, or changing its intended purpose each pulls the full Article 16 provider obligations onto the buyer. Point (a) allows contractual reallocation; (b) and (c) do not. Same 2 December 2027 and 2 August 2028 dates apply, so the wording that matters sits in the signed statement of work, not in the compliance answer.
Small correction on (c): it's about a system that wasn't high-risk to begin with and becomes high-risk because someone changed what it's used for. It also names general-purpose systems, so a general chatbot put to work screening CVs is the typical case. And no clause moves (b) or (c): they follow what you do with the system, not what you signed.
That reading matches the text. Article 25(1)(c) covers a system not classified as high-risk, including a general-purpose one, whose intended purpose is changed so it becomes high-risk under Article 6.
Article 25(2) is worth adding. The initial provider then stops being the provider of that system and must hand over the necessary information and reasonably expected technical access. That handover duty falls away where the provider clearly specified the system is not to be changed into a high-risk one. The obligation does not move, but the documentation can.
Question four is the one that doesn't resolve once and stay resolved. A recent industry ledger counted 89 model-ID retirements across ten vendors this year; notice periods were computable for 51 of those and ranged from 39 to 184 days, a spread of over four months between fastest and slowest. Nailing that down at signing settles today's model. That spread means the same question may need a different answer the third time the model changes.
That points at a gap underneath the incentive argument. Vendors answer now partly because the clock hasn't started, but also because most vendor-risk processes are built to ask once, at procurement, with no mechanism to reopen dormant questions when a live contract's underlying model changes. Getting the answer in writing protects the deal you signed. It says nothing about the one three model updates from now.
I'd call this a filing problem more than a vendor problem. The questionnaire gets answered once, stapled to the contract, and doesn't get opened again until renewal. So a notice clause that only says "new model shipped" isn't worth much. It should also tell you whether the intended purpose or the instructions for use changed, otherwise you've basically paid for an email.
The role question has one answer no vendor statement can override: Article 25(1) turns a deployer into a provider by operation of law. Putting your own name or trademark on a high-risk system already on the market, making a substantial modification that keeps it high-risk under Article 6, or changing its intended purpose each pulls the full Article 16 provider obligations onto the buyer. Point (a) allows contractual reallocation; (b) and (c) do not. Same 2 December 2027 and 2 August 2028 dates apply, so the wording that matters sits in the signed statement of work, not in the compliance answer.
Small correction on (c): it's about a system that wasn't high-risk to begin with and becomes high-risk because someone changed what it's used for. It also names general-purpose systems, so a general chatbot put to work screening CVs is the typical case. And no clause moves (b) or (c): they follow what you do with the system, not what you signed.
That reading matches the text. Article 25(1)(c) covers a system not classified as high-risk, including a general-purpose one, whose intended purpose is changed so it becomes high-risk under Article 6.
Article 25(2) is worth adding. The initial provider then stops being the provider of that system and must hand over the necessary information and reasonably expected technical access. That handover duty falls away where the provider clearly specified the system is not to be changed into a high-risk one. The obligation does not move, but the documentation can.