A provider’s general security documentation is useful, but it may not answer how a particular AI workflow will operate inside a financial institution. Due diligence should connect the vendor’s commitments to the data, decisions and dependencies in the intended deployment.
Establish what the provider will do
Separate the model provider, implementation partner, hosting provider and any connected data services. Identify which party receives data, operates software or provides support. The federal banking agencies’ third-party guidance describes a relationship lifecycle from planning and selection through monitoring and termination. The review should cover the complete chain relevant to the use. Interagency third-party guidance.
Resolve data and access questions
Document processing locations, retention, training use, subcontractors and support access. Determine how access is granted and removed. Ask for evidence appropriate to the proposed sensitivity and criticality. A broad statement about encryption does not answer whether a support user can view content or whether the institution can obtain its records on exit.
Make service and change responsibilities explicit
Clarify incident notification, support, availability commitments and responsibility for model or API changes. Agree how the application will be tested when a dependency changes. Identify who can pause the workflow and how the established process resumes. These questions are operational design inputs as well as contract topics.
Separate an attestation from implementation evidence
A security report may describe the provider’s controls at a point in time. The institution still needs to understand the proposed configuration, data flow and allocation of responsibilities. Ask which controls the provider operates and which the institution must configure or monitor. Record the answer in terms that the implementation team can act on.
For any critical dependency, test whether the exit materials are usable. Can configuration be exported? Are test cases available in a readable format? Is another operator able to deploy the application? An orderly transition depends on these details and on the contract, not on a general assurance that the client owns its data.
Plan monitoring and an orderly exit
Decide which evidence will be reviewed during the relationship and what triggers reassessment. Confirm ownership and export of code, configuration, test cases and records. Check whether another team could run the workflow with the handover materials. Exit should be an executable plan with dependencies identified, rather than a single clause.
Before the next decision
Planning checklist
- Provider and subcontractor responsibility map
- Data-use, retention and access terms
- Incident, support and change commitments
- Monitoring evidence and executable exit plan
Sources and further reading
Sources checked 5 October 2026. The design recommendations in this guide are AID’s analysis. Sector obligations depend on the use case and jurisdiction.
Apply this to a defined workflow
AID can provide implementation documentation and responsibilities that support the institution’s vendor review.
