Module 4 — Governance Gates: Procurement, Purpose, Modification

Module 4 of the AI Act Compliance certification: three gates that between them prevent most of the expensive failures in this Regulation, and what each one must actually check.

Most of the expensive failures in this Regulation are not caused by a decision somebody got wrong. They are caused by a decision nobody made, because the moment at which it should have been made did not look like a decision point.

Three gates fix that. They are cheap, they sit inside processes that already exist, and between them they prevent the Art. 25 traps, the shadow-AI problem and the undocumented determination.

Gate 1 — Procurement

Trigger: any acquisition or adoption of software with an AI component, including a feature toggle in an existing product and a free tool adopted by a team.

Checks:

1. Register entry created, with the fields from Module 2.
2. Instructions for use obtained and read. Art. 13 obliges the provider to supply them; a vendor who cannot is selling something you cannot deploy compliantly for a high-risk purpose. This check alone kills more bad procurements than any other.
3. Declared intended purpose captured verbatim.
4. Vendor's classification obtained, and independently sanity-checked — you live with the consequences.
5. Where Art. 6(3) is claimed, the Art. 6(4) documentation and Art. 49(2) registration reference. If neither exists, the derogation has not been claimed.
6. Sample Art. 12 log export seen, so you know what you will be retaining and that you can retain it.
7. Oversight measures the provider considers appropriate, per Art. 14.
8. Contract clauses: log access and export; Art. 25 cooperation on information and technical access; incident notification with a timeframe connecting their Art. 73 duty and your Art. 26(5) duty; change and deprecation notice.
9. Art. 5 check. Is what this system does prohibited.
10. Art. 50 check. Which of the four duties will attach, and to whom.

Every one of these is close to free before signature and close to impossible afterwards. That asymmetry is the entire argument for the gate.

Gate 2 — Purpose change

Trigger: any new use case for a system already in the register. Not a new system — a new use.

This is the gate that does not exist in most organisations, because reusing a working pipeline is what good engineering practice tells a team to do, and nobody thinks of it as an acquisition.

Checks:

1. Compare the proposed use against the declared intended purpose in the register.
2. If it differs, re-run classification for the new use. Would it be Annex III? Prohibited? Does an Art. 50 duty now attach?
3. If the new use makes the system high-risk, stop: Art. 25(1)(c) makes you the provider, with the whole of Chapter III attaching.
4. Check the vendor's acceptable use policy. A prohibited use puts you outside your licence as well as into Art. 25.
5. Update the register, whatever the answer.

The worked example from the Deployer track is worth repeating because it is entirely ordinary: an insurer's document-understanding platform, configured by a claims team to score claims for fraud — outside Annex III 5(b), which carves fraud out — and then reused eighteen months later by a pricing team for health insurance risk assessment, which is Annex III 5(c). Two teams reused a pipeline. Nobody rebranded, nobody retrained, and the insurer became the provider of a high-risk system and one of the narrow set of deployers owing an Art. 27 FRIA.

One form at the moment of reuse would have caught it.

Gate 3 — Modification

Trigger: any change to a system you provide, or any change you make to a system you deploy.

Checks:

1. Is this a substantial modification? A change not foreseen or planned in the initial conformity assessment which affects compliance with the Chapter III requirements, or which results in a modification to the intended purpose.
2. If you are the provider: a substantial modification requires a new conformity assessment under Art. 43, an updated Annex IV file, a new declaration of conformity, and a database update. Changes pre-determined at the initial assessment and documented are not substantial modifications — which is the commercial argument for declaring update behaviour up front.
3. If you are the deployer and the modification is yours: Art. 25(1)(b) may make you the provider.
4. If you modified a general-purpose model: separately ask whether you have become the provider of a model under Chapter V. Different regime, different analysis.
5. Record the assessment either way.

Who owns the gates

Not compliance.

A compliance function that owns all three gates becomes a queue, and a queue gets routed around. The gate belongs to whoever already owns the process it sits in: procurement owns gate 1, the product or engineering change process owns gate 3, and gate 2 belongs wherever new use cases are approved — usually a product or business owner.

The compliance role is to define what each gate checks, to see the exceptions, and to audit a sample. That is a sustainable position; being the bottleneck is not.

What the gates produce

Each gate produces a record, and those records are the programme's evidence base:

• Gate 1 → the register entry, the vendor file, the contract clauses.
• Gate 2 → the purpose-change determinations, including the negatives.
• Gate 3 → the modification assessments, which are also what Art. 17's modification-management element asks a provider to show.

An organisation with three working gates can answer almost any supervisory question by pulling records, rather than by reconstructing history.

Check yourself

1. We run an annual AI review, which catches purpose changes. — Annually is too late. Art. 25(1)(c) fires at the moment of reuse, and a year of operating a high-risk system without any Chapter III artefact is the finding.
2. Procurement is a bottleneck; compliance should approve AI purchases directly. — That makes compliance the queue. Define the checks, let procurement run them, and audit a sample.
3. We fine-tuned a vendor's high-risk system on our data. — Gate 3. Assess it against the definition of substantial modification; Art. 25(1)(b) may make you the provider.
4. A team switched on an AI ranking feature in our existing CRM. — That is gate 1. A feature toggle is a new system for classification purposes, and it is the category technical discovery misses entirely.

Previous: Module 3 — The Art. 4 AI literacy programme Next: Module 5 — AI Act and GDPR together →