AI arrives through procurement, not projects
Most of the AI running in a regulated organisation was never the subject of an AI project. It arrived inside products the organisation already buys: the CRM added an assistant, the document management system added summarisation, the HR platform added candidate screening. Often the feature appears in a release note rather than a contract variation — which means it was never assessed, never inventoried, and never priced into the risk register.
Third-party risk frameworks were built for software licensing and information security, not for systems whose behaviour changes after signature. The standard questionnaire asks about encryption, uptime and penetration testing. It does not ask whether your client data is training someone else’s model, or whether the model you assessed in March is the model you are running in June.
Regulators do not distinguish between AI you built and AI you bought. The FCA and PRA’s expectations on outsourcing and operational resilience, and the ICO’s position on controller accountability, all point the same way: responsibility for the system’s behaviour stays with the firm deploying it. Intake is the cheapest moment to establish your position — every question deferred at signature becomes a negotiation from weakness later.
Provider or deployer: the question that sets your obligations
The EU AI Act splits its obligations by role. Providers — those who develop an AI system and place it on the market under their own name — carry the heavier set: risk management, technical documentation, conformity assessment. Deployers carry their own duties: using the system in accordance with its instructions, assigning human oversight to competent people, ensuring input data is relevant, monitoring operation, retaining the logs the system generates and, for certain uses including creditworthiness assessment, a fundamental rights impact assessment. UK organisations are within scope wherever the system or its outputs are used in the EU.
The trap is that the role is not fixed at purchase. Put your own name or trademark on the system, substantially modify it, or change its intended purpose, and you can become the provider — inheriting the full obligation set. Firms that describe themselves as “just buying a product” are often closer to that line than they assume: heavy configuration, white-labelling and novel use cases all push towards it.
Intake should therefore establish, in writing: which role the vendor claims for each AI feature, how the vendor has classified the system under the Act, and what documentation will flow to you — instructions for use, technical documentation summaries, evaluation results — so that you can actually discharge deployer duties. ISO 42001 and the NIST AI RMF both treat third-party AI as a governance object in its own right, so the questions below map directly onto frameworks your risk function may already use.
What a good answer looks like
The purpose of intake is not to receive perfect answers. It is to distinguish vendors who govern their AI from vendors who market it. Three signals separate them: specificity — the vendor names the underlying model, the version discipline and the retention period rather than gesturing at “enterprise-grade AI”; documentation — the vendor offers artefacts, not assurances; and notice — the vendor commits, contractually, to telling you when something material changes.
Watch for the standard evasions: “proprietary” offered as a reason not to name the model provider behind the feature; a SOC 2 report presented as an answer to a question about training data; silence on retraining cadence. A vendor who cannot tell you when its models change cannot support your obligation to monitor a system whose behaviour will.
The intake checklist
Use these questions as the spine of a standard intake questionnaire for any product with embedded AI. Ask for answers in writing — the willingness to give them is itself a signal.
Model provenance
- Which models power this feature — built in-house, fine-tuned, or a third-party foundation model? Which one, and under what terms?
- How are model versions identified, and can you tell us which version we are running at any given time?
- What evaluation and testing has the system undergone, and can we see the results or a meaningful summary?
Data handling
- Is our data — prompts, documents, outputs — used to train or improve any model? Can that be excluded contractually, not merely in a settings toggle?
- Where is our data processed and stored, how long is it retained, and how is it deleted?
- How is our data segregated from other customers’, including in logs and caches?
Retraining and model change
- How often are models retrained, updated or replaced, and what triggers a change?
- What notice do we receive before a material model change, and can we test before it reaches production?
- How do you detect performance drift between updates, and how is it communicated?
Sub-processors
- Which sub-processors sit behind the AI features — including the underlying model provider — and in which jurisdictions?
- What notice and objection rights do we have when a sub-processor changes?
- Do your sub-processor terms flow down our data-handling commitments, including any no-training clause?
Incident duty
- What counts as an AI incident under the contract — beyond a security breach — and within what period must you notify us?
- Where an incident touches our regulated activity, who is responsible for which notifications?
- Can you provide the logs and records we would need to investigate and to evidence our response?
Audit rights
- What documentation will you provide — technical documentation, instructions for use, evaluation results — and how often is it refreshed?
- Do we have a right to audit, or independent assurance such as ISO 42001 certification or third-party testing in its place?
- Will you support requests for information from our regulators about the system?
Exit and portability
- At exit, what do we get back — data, configurations, prompts, fine-tuned artefacts, logs — in what format and timeframe?
- What functionality and records disappear when the contract ends, and what does that do to our audit trail?
- What happens after termination to our data, and to any model improvements derived from it?
EU AI Act role split
- For each AI feature, who is the provider and who is the deployer — and does the contract say so explicitly?
- What is your classification of the system under the Act, and what documentation supports it?
- Which configurations or uses on our side would amount to substantial modification — and shift provider obligations onto us?
Turning questions into a standing control
A questionnaire only works if it sits inside the procurement workflow as a gate, and if the answers land in a contract schedule rather than an email thread. Answers also decay: vendors swap model providers, add features and revise terms mid-contract. Revisit the intake position at every renewal and every material change notice — keeping that picture current across the estate is precisely what continuous monitoring in Citadel exists to do.
Where a single vendor system needs more than a questionnaire, EAIC takes it as a bounded engagement: a bespoke assessment of the system and its classification, independent expert review of vendor documentation for procurement or legal purposes, or training for the procurement and risk teams who will run intake from here on. Fixed scope, fixed fee wherever the deliverable can be defined upfront, delivered by the founders directly.