Buying an AI tool at a regulated firm is not the same as buying a normal SaaS product. Beyond the usual security review, you have to ask what the model does with your data, whether the vendor can change it underneath you, and whether the tool's output ever touches a decision about a customer. This checklist turns those questions into something you can run through and file.
The short version
A defensible review answers seven things, and records the answers: what the tool is used for, what independent assurance exists, where your data goes and what happens to it, what the contract lets you do, how you get out, whether the outsourcing rules apply, and how the tool is classified under the EU AI Act. The rest of this page expands each one.
Which frameworks usually apply
Which rules matter depends on your firm type and jurisdiction, so treat this as a map for conversation with your compliance team rather than a definitive list.
| Framework | Why it matters for an AI vendor |
|---|---|
| DORA (Regulation (EU) 2022/2554) | Applies to EU financial entities since 17 January 2025. Covers ICT third-party risk, a register of information on ICT providers, mandatory contract provisions and exit planning. |
| EBA outsourcing guidelines (EBA/GL/2019/02) | Expectations for EU credit institutions, payment and e-money institutions on outsourcing arrangements, including due diligence, audit rights and sub-outsourcing. |
| PRA SS2/21 and FCA SYSC 8 | UK expectations on outsourcing and third-party risk management for PRA- and FCA-regulated firms. Material outsourcing carries extra requirements. |
| GDPR / UK GDPR | Processor contract (Article 28), international transfers (Chapter V), and a data protection impact assessment where processing is likely to be high risk (Article 35). |
| EU AI Act | Risk classification of the tool by use case. See our AI Act guide for the current timeline. |
Whether a given tool counts as a material outsourcing or a critical ICT service is a judgment for your firm and its regulator. A meeting-notes tool and a transaction-monitoring platform will not land in the same place.
1. Define the use case first
Everything else flows from what the tool is actually for. Write it down before you send a questionnaire.
- What task does the tool perform, and who in the firm will use it?
- What data goes in? Client data, personal data, confidential deal information, recorded calls?
- Does any output feed a decision about a customer, such as credit, pricing, onboarding, or a fraud or AML outcome? If so, flag it now, because it changes the classification and the oversight needed.
- Is a human reviewing the output before it is relied on, and can you show that they do?
2. Independent security assurance
Vendor claims are not evidence. Ask for the report, not the badge.
- SOC 2 report: Type I describes controls at a point in time, Type II tests that they operated over a period. For a vendor handling sensitive data, Type II is the one worth asking for.
- Check the report's scope and dates: which systems and trust criteria are covered, whether the period is recent, and whether the AI features are in scope or only the surrounding platform.
- Read any exceptions or qualified opinions and ask how they were remediated.
- Other evidence worth asking for: ISO/IEC 27001 certificate and scope, a recent independent penetration test summary, and a vulnerability disclosure process.
- Ask about the vendor's own sub-processors and whether they hold equivalent assurance.
3. Data handling and the training question
For AI tools this is usually where the real differences show up.
- Training use: is customer data used to train or fine-tune any model, the vendor's or a third party's? Get the answer in the contract or DPA, not just a web page.
- Underlying model providers: which third-party models or APIs process your data, and under what terms, including their retention and training policies.
- Data residency: where data is stored and where it is processed, including any support access from other regions. These can differ.
- Retention and deletion: default retention periods, whether you can configure them, and how deletion is confirmed, including from backups and logs.
- Encryption and access: encryption in transit and at rest, who at the vendor can access customer content, and how that access is logged.
- Transfers outside the UK or EEA: what mechanism covers them, and whether a transfer risk assessment is needed.
4. Contract terms to look for
- A data processing agreement that meets Article 28 requirements, with a current sub-processor list and a notification process for changes.
- Audit and access rights for you and your regulator, or an acceptable alternative such as reliance on independent reports. Regulated firms are generally expected to retain these.
- Incident notification with a defined timeframe that lets you meet your own regulatory reporting deadlines.
- Sub-outsourcing controls: notice of, and the right to object to, changes in the chain that affect your service.
- Change notification for the AI itself: advance notice of material model changes, provider swaps or changes to data-use terms.
- Service levels, liability and insurance proportionate to the role the tool plays.
- For EU financial entities, check the contract against the provisions DORA requires for ICT services.
5. Operational resilience and exit
- How does the vendor handle outages, and what is the realistic impact on your business if the tool is unavailable for a day, or a week?
- Is there a business continuity and disaster recovery plan, and has it been tested?
- Are you exposed to concentration risk, for example a single vendor, or a single underlying model provider, behind several of your tools?
- Exit plan: can you export your data in a usable format, what is the termination assistance period, and what happens to your data afterwards? Document an alternative.
6. Outsourcing and ICT third-party arrangements
For many firms an AI tool is also an IT outsourcing or ICT third-party arrangement, and the outsourcing rules sit on top of the AI-specific questions. Whether it counts, and whether it supports a critical or important function, is a judgment for your firm and its regulator, so record the reasoning.
- Classification: write down whether you treat the service as outsourcing, and why. A meeting-notes tool and a transaction-monitoring platform will not land in the same place.
- Register: EU financial entities under DORA must keep a register of information on their ICT third-party arrangements. Check that the vendor and its subcontractors can be recorded accurately.
- Due diligence before signing: the vendor's operational and financial standing, security assurance, and ability to meet your regulatory obligations.
- Contract content: a clear description of the service and where it is delivered, service levels, termination rights, audit and access rights, cooperation with your regulator, and conditions on subcontracting.
- Subcontracting chain: who sits behind the vendor, including any underlying AI model provider, and whether you are told when that changes.
- Concentration and substitutability: how hard it would be to replace the vendor, and whether several services depend on the same provider.
- Ongoing monitoring: periodic review, performance and incident reporting, and a named owner.
7. AI-specific governance
- EU AI Act classification: record how you classified the tool and why, and ask the vendor for its own position. See the AI Act guide for what counts as high-risk for financial firms and the current deadlines.
- Accuracy and error handling: how does the vendor measure output quality, and what are the known failure modes, such as fabricated or misattributed content in summaries?
- Human oversight: where can a user review, correct or override the output, and is that review logged?
- Logging and explainability: can you reconstruct what the tool produced and when, for example in a complaint or an examination?
- Model risk: if the output feeds a model-driven decision, check it against your firm's model risk management framework, such as PRA SS1/23 for in-scope UK banks.
- Recordkeeping: if the tool records, transcribes or stores client communications, confirm it supports the retention and retrieval obligations that apply to those records. See archiving AI meeting notes.
8. Document the decision
An examiner will want to see the reasoning, not just the outcome. Keep a short file for each approved tool:
- The use case and data classification you assessed
- The evidence you reviewed, with dates and report versions
- Open risks and the mitigations or conditions you attached
- The AI Act classification and the reasoning behind it
- Approval owner, review date, and the trigger events that would reopen the review, such as a model change, a new sub-processor, or a scope change
Start from documented facts
Attestly tracks SOC 2 status, training policy and data residency for AI tools across meeting notes, governance, research, fraud and AML, communications archiving, and KYC and onboarding, so your first pass is not a blank page.
Browse the directoryThis checklist is a general starting point for orientation and is not legal, regulatory or compliance advice. Requirements depend on your firm, its regulators and the specific service, and they change. Confirm what applies to you with a qualified compliance or legal professional, and verify current rules before relying on anything here.