AI systems your auditor can read.

Banks now put AI questions in their vendor-risk questionnaires. GDPR and UK GDPR apply to any AI system that handles personal data, DORA applies to EU financial firms and reaches their ICT suppliers by contract, and the PRA’s model-risk principles (SS1/23) apply to the banks they cover. The EU AI Act fixes a deployer’s logging and oversight duties for stand-alone high-risk systems from 2 December 2027. Most AI systems in production cannot say what the model saw, what it returned, or who approved what happened next.

• When do the EU AI Act’s high-risk rules apply after the Digital Omnibus?
• What must a deployer of a high-risk AI system be able to show under Article 26?
• What should an AI audit trail record, and how do you show it was not altered?
• How do I answer the AI section of a bank’s vendor-risk questionnaire?
• What does the DORA regulation require for an LLM application, and what will an EU bank ask its suppliers?
• Does PRA SS1/23 cover LLMs?
• Which rules apply to which firm: GDPR, DORA, SS1/23 and the AI Act?
• Sovereign AI deployment in the UK and EU: where can the model run, and what proves it?

1. Controls Audit

   Two to three weeks

   A fixed-scope review of one AI system against the controls matrix. You receive the matrix filled in for your system, a gap register giving the fix and the effort for each gap, a deployment-mode recommendation, and a one-page summary your CISO can take to the board.

   £12,000 (€14,000), fixed fee

2. Governed Build

   Twelve to sixteen weeks

   The system built, or repaired, inside your tenant with the kit, closing every gap the audit found. It ships with the matrix reading Pass, the evidence pack for its first period, and a handover your own engineers can run from.

   £75,000 to £140,000 (€90,000 to €165,000), fixed scope where the audit has bounded it

3. Assurance Retainer

   Twelve months minimum

   I run it. Each month: a ceilings review, a killswitch drill, a log-retention attestation, model-change control and the incident log. Each quarter: a new evidence pack and the matrix run again.

   £5,000 (€5,900) per system, per month

   Or £3,500 (€4,100) for a single light system, and £8,000 (€9,500) for a high-risk or multi-model system.

Six of the twenty-one controls in the matrix, with the obligations each one answers and the record it produces.

1. GD-01

   Control

   Every paid model call is metered through one function, and the ledger is the only record of spend

   Obligations

   Art. 12, Art. 26(6), DORA Art. 9

   Record produced

   Ledger extract: time, subject, model version, estimated and actual cost, outcome

2. GD-02

   Control

   An append-only audit log, hash-chained

   Obligations

   Art. 12, GDPR Art. 5(2), DORA Art. 17

   Record produced

   Chain verification output for the period

3. GD-03

   Control

   A human approves before any consequential output leaves the system

   Obligations

   Art. 14, Art. 26(2), GDPR Art. 22

   Record produced

   Approval log: who, when, what they saw, what they decided

   SAMPLE

   Decided

   2026-09-01 09:31:40 UTC

   By

   sample.reviewer

   Decision

   Approved

   What the reviewer saw

   Proposed category: "Billing dispute". Model claude-sonnet-5. The reviewer saw the model output, the complaint text it was given, and the two categories it ranked below this one.

4. GD-05

   Control

   A killswitch read on every paid call, tested by breaking it on purpose

   Obligations

   Art. 14(4)(e), Art. 26(5), DORA Art. 11

   Record produced

   Drill record: date, operator, what stopped, recovery time, the safe-state behaviour observed

   SAMPLE

   Ran

   2026-09-01 09:14:45 UTC

   By

   sample.operator

   Recovery

   180 s

   What stopped

   Every paid model call, at the spend path, before any provider was contacted

   Safe state

   No call was in flight when the flag was set: the previous one had already completed and booked. The next call was refused at the spend path rather than being dropped, so it stands in the ledger as a refusal instead of going missing from it.

5. GD-09

   Control

   A tenant boundary, with egress only to named providers

   Obligations

   GDPR Art. 32, GDPR Art. 44 to 49, DORA Art. 28

   Record produced

   The provider list, and the code test showing no unmetered egress

6. GD-18

   Control

   One script exports the evidence pack

   Obligations

   Art. 26(12), DORA Art. 30

   Record produced

   The pack: twelve items in a dated folder, generated rather than written

All twenty-one controlsThe sample evidence packThe same pack as a PDFAnswer fifteen questions about your own system

Three deployment modes, in order of strictness. Moving between them swaps one adapter; the controls, the ledger and the format of the evidence pack stay the same.

S1In-tenant managed

A managed model service (Azure OpenAI, or Anthropic on Bedrock or Vertex) in an EU region of your own cloud tenant, under your identity and network controls, with no training on your data. The default for most UK and EU firms.

S2EU-hosted open weights

An open-weight model your model-risk review has approved, on EU-resident GPU capacity you rent or own. For a policy that rules out US-parented API providers, or where a DORA assessment of ICT concentration risk argues against one.

S3Air-gapped on premises

Open weights on hardware inside your building, with no egress at all. For the systems a CISO says must never leave it.

Thirty minutes on one system: what it does, who is asking about it, and which engagement fits. Nothing to prepare. For firms in the UK and Europe.