Category: Resources / Regulated work
The name on an AI interface may tell you little about the service your work depends on. A workspace supplier can route requests to a separate inference host, draw documents from another service and use a further supplier for diagnostic storage. Start with the chain. Then ask which agreement, evidence and person explains each part. This worksheet gives a small financial-sector team a way to turn those questions into an actionable review.
Establish applicability before using the worksheet
EIOPA’s DORA overview describes a financial-sector framework covering ICT risk, third-party risk, contractual provisions, testing and incident reporting. Do not assume every regulated organisation or every AI-related engagement has the same scope. Ask your legal and risk owners to establish the entity’s position, the service classification and whether a critical or important function is supported. The questions below are suggested due-diligence prompts, not a complete statement of DORA duties.
A supplier’s regulatory status does not settle the buyer’s responsibilities. In its final Q&A 3501, DORA 286, EIOPA explains that financial entities retain responsibility and that a provider’s NIS2 status does not determine the application of DORA Articles 28–30. Treat broad assurance language as a reason to ask for the relevant evidence and contractual position, rather than a reason to stop the review.
Draw four boxes before sending the questionnaire
The business function: write the work in ordinary language, its owner and the consequence of interruption or misleading output. “AI service” is too broad. “Preparing internal draft summaries from public documents” gives the reviewer somewhere to start. Record what people do with the answer and whether another activity has quietly become dependent on it.
The workspace or application: identify who supplies the interface, workflow, identity integration and administration. Ask whether the contract covers all of those components. A locally installed application can still depend on remote identity, licensing, retrieval or inference. The word “local” should lead to a data-flow diagram with named boundaries.
The model and inference service: distinguish the organisation that developed a model from the organisation receiving and processing requests. Record the selected endpoint, routing rules, fallback behaviour and version-change process. Approval of a model name alone cannot explain the service chain used by a particular request.
Supporting services: include document retrieval, storage, observability, remote support and any service capable of receiving content or changing the route. Mark a box “unknown” where information is missing. A diagram with visible unknowns is more actionable than a complete-looking picture built from assumptions. Give each unknown an owner and a question to send to the supplier.
Copy this supplier evidence worksheet
Create one record per proposed arrangement. Include a reference, supplier legal identity, service description, function owner, scope reviewer, decision owner, evidence location and review trigger. For every question below, keep the supplier’s answer separate from your assessment. Use “received”, “reviewed”, “gap” and “not assessed” as evidence states. None means that all risk has disappeared.
- Who does what? Request a service-chain description that distinguishes contracting party, inference host and supporting suppliers. Ask who can change that chain and how your organisation would learn of the change. Owner: procurement with architecture.
- What reaches each party? Request separate paths for prompts, attachments, retrieved passages, outputs, usage records and support bundles. Ask whether error handling or debugging changes those paths. Owner: security with the data protection lead.
- Where does work happen? Ask for processing, storage and support-access locations, then compare the answer with the contracted service. A marketing region label is not a complete map. Owner: legal with architecture.
- What happens when inference stops? Ask whether requests queue, fail, retry or move to another service. Test whether the fallback would change the data boundary. Owner: operations and continuity.
- What changes without a new purchase? Ask about model replacement, routing changes, new support tooling and altered retention settings. Identify which changes the firm can refuse and which require a fresh decision. Owner: service management.
- What evidence can be obtained? Request a sample event export, scope of available assurance information and route for investigating an incident. Separate an account of controls from evidence that covers the actual contracted service. Owner: risk and security.
- Who responds during an incident? Ask for operational contacts, the information the firm can receive and the route when the supplier itself loses access. Rehearse a synthetic escalation rather than relying only on a support link. Owner: incident management.
- Can the firm leave? Identify export formats, configuration portability, document retrieval dependencies and the people needed to rebuild the workflow. Test an example export and explain what it cannot reconstruct. Owner: continuity with the business owner.
- What dependencies are shared? Compare the chain with other important services. Separate suppliers can share an inference host, identity service or storage dependency. Record the common point and what an interruption there would mean. Owner: architecture and risk.
- What does the agreement actually say? Ask legal to map the relevant contractual provisions, gaps and proposed remedies. Do not let a completed questionnaire stand in for reviewing the agreement. Owner: legal and procurement.
Completed synthetic example: the hidden fallback
Fully synthetic example. All service names, events and evidence references are invented. Arrangement TPR-EX-A concerns an internal document-summary tool at a fictional financial firm. Workspace A supplies the interface. Host B receives inference requests. Store C holds the retrieval index. The supplier’s initial response says “regional processing”, but its error-handling description permits rerouting when Host B is unavailable.
The architecture reviewer marks routing “gap” because the fallback host and location are missing. Evidence reference EX-FLOW-A contains the synthetic diagram, with an unknown box after the retry step. The open action is to obtain the fallback details and decide whether rerouting should be disabled. The owner is the service manager, with legal and security review. The worksheet records no approval for confidential documents while that question remains unanswered.
The continuity row is also open. The proposed manual alternative depends on the same retrieval index as the AI workflow, so it would fail during a Store C interruption. The business owner must specify an independent source route or accept and document the limitation through the firm’s decision process. Changing the model would not resolve that dependency. This is why a service-chain review asks different questions from a model approval register.
Finish with a decision somebody can maintain
Write a short decision covering the allowed function, data boundary, service configuration, unresolved gaps and change triggers. Assign who watches supplier notices and who decides whether a change matters. A record that nobody maintains becomes a description of an earlier arrangement. Put the next question beside the person who can answer it, and keep the evidence reference close enough that another reviewer can follow the reasoning.
Related: Article 26 deployer checklist, worked AI decision file, Model independence is a governance property and our AI governance principles. Our vision for Synainesi is model choice within clear organisational rules. This worksheet can be used with any proposed service, independently of that vision.
General information, not legal advice. Establish your organisation’s scope and applicable obligations with qualified advisers; this resource is a practical question set, not a complete legal checklist.