What Should a Boutique Bank Ask an AI Vendor Before Using Live Deal Data?

Start with the use case and risk boundary

Write down the exact task before asking a vendor to demonstrate its product. Examples include extracting terms from a confidentiality agreement, organizing a buyer list supplied by the bank, comparing versions of a management presentation, or flagging missing fields in a diligence index. Each task should identify the source-of-truth record, the users, the intended output, and the actions the software is not permitted to take. A tool that drafts an internal checklist has a different exposure from a tool that receives an entire data room or sends information outside the bank.

The accountable owner should also record the data classes involved. Separate public information, internal work product, client confidential information, personal information, privileged material, and information subject to a transaction-specific restriction. The classification should determine whether the task can use synthetic, redacted, or live material. Do not let a broad product demo decide the boundary after the fact. NIST explains that risks can change when a third party system or data is integrated into a particular deployment, and that developer risk measures may not match the deployer’s use case. [2]

Ask how data is collected, used, and deleted

Ask for a plain-language data-flow diagram that follows an input from upload or API call through storage, indexing, inference, logs, backups, support access, and deletion. Request the retention period for each layer and the event that starts the deletion clock. Ask whether prompts, documents, outputs, embeddings, metadata, or error logs are used to train or improve a model. The contract should distinguish service delivery from secondary use, and it should say whether the vendor may disclose data to affiliates, model providers, analytics providers, or other subprocessors.

Ask which data centers and legal entities may process or store the material, and whether the bank receives notice before a new subprocessor is used. Require an owner for approving exceptions. The answer should be specific enough to compare with the bank’s confidentiality commitments and applicable privacy review. If the vendor says data is not used for training, ask whether that statement covers human review, debugging, abuse monitoring, backups, and derived artifacts. NIST’s generative AI profile specifically points to secondary data use, third-party components, and contract terms as risks that require procurement review. [3]

Request security evidence, not logos

Build a security evidence register with the document name, coverage period, system boundary, control owner, exceptions, remediation status, and reviewer. Useful evidence may include an independent assurance report, penetration-test summary, vulnerability-management description, encryption design, access-control model, incident-response plan, business-continuity results, and a current subprocessor list. A certification or report can be relevant without proving that every feature, tenant, configuration, or workflow used by the bank is covered.

Ask what the bank can verify directly. Questions should cover tenant isolation, encryption in transit and at rest, key management, privileged access, multifactor authentication, audit logs, administrative activity, secure software changes, backups, and deletion verification. Identify the bank’s own configuration responsibilities. FFIEC guidance warns that institutions should not assume effective security and resilience controls exist merely because cloud systems are operating. It also recommends clear contractual allocation for access, keys, monitoring, patching, testing, subcontractors, data ownership, return, removal, and data location. [4]

For an assurance report, record the opinion, period, exclusions, complementary user controls, and any bridge letter or gap since the report date. For a penetration test, ask what was tested and whether the tested environment matches the proposed service. Treat unsupported answers as open items, not as negative proof. The procurement decision should state which evidence is current, which is limited, and which still needs a compensating control or a no-go decision.

Test exportability and the exit path

Confidential deal work must remain usable if the vendor is unavailable, changes its product, or the bank stops using it. Ask for an inventory of exportable objects: original files, prompts, outputs, annotations, structured fields, audit records, access history, and configuration. Specify formats, dependencies, export frequency, fees if any, and whether exports can be performed by the bank without vendor staff. Test an export with representative synthetic records and confirm that filenames, timestamps, relationships, and permissions remain intelligible.

Put termination mechanics in the contract. The bank should know when access ends, how data and backups are removed, what evidence of deletion is supplied, how legal holds are handled, and how the vendor supports a controlled transition. A continuity plan should identify a manual fallback for the critical task. NIST’s AI RMF calls for safe decommissioning and phasing out, while its generative AI profile recommends attention to rollover, fallback, incident response, contract liability, system changes, and support obligations. [2] [3]

Define permissions and human review

Ask the vendor to demonstrate role-based access, least privilege, separation between client matters, administrator controls, approval for support access, and rapid revocation. The bank should decide who may upload, configure, review, export, and delete. A deal team member should not automatically receive rights to every matter. Record whether the system exposes data through search, shared links, APIs, plug-ins, or browser extensions, and disable paths that are not needed for the approved task.

For each AI output, name the human reviewer and the source records they must inspect. The reviewer should verify citations or document locations, check for omitted clauses and invented text, compare extracted values to the source, and record disposition of material errors. AI should not autonomously contact buyers, negotiate terms, approve a disclosure, send a client deliverable, or change a deal record. NIST identifies documented responsibilities, monitoring, inventory, and human-AI oversight as governance requirements for organizations acquiring or deploying AI. [2]

Run a bounded trial with stopping criteria

Use a trial set that reflects the real task without exposing live mandate data. Include clean examples, poor scans, conflicting versions, tables, redactions, unusual terminology, and deliberately ambiguous instructions. Preserve a labeled answer key or reviewer rubric. Test whether the output identifies the right source location, distinguishes facts from assumptions, preserves confidentiality boundaries, and fails safely when the source is incomplete. Do not convert a favorable demonstration into a production conclusion.

Before the trial, define the accountable reviewer, sample selection, permitted prompts, logging method, and escalation route. Define stopping criteria in advance. Examples include an unapproved data path, inability to delete or export, a material confidentiality leak, unexplained access by support personnel, an incident with no workable notification path, or repeated material errors on the task’s acceptance rubric. NIST cautions that benchmark or laboratory testing may not reflect real deployment conditions, so the trial should be documented against the bank’s actual context. [3]

Turn answers into an unresolved-control checklist

Use one register rather than a long email thread. Suggested fields are requirement, risk rationale, vendor answer, evidence link, scope and date, bank control owner, test result, residual risk, compensating control, decision, and next review date. Separate facts supplied by the vendor from conclusions made by the bank. Mark unanswered questions explicitly. A verbal assurance can guide follow-up but should not close a control without written evidence or a recorded exception approved by the appropriate owner.

The final procurement memo should identify what the vendor selection does not decide. It does not replace the bank’s architecture review, information-security program, client engagement terms, records policy, legal analysis, or transaction-specific confidentiality restrictions. The OCC’s interagency guidance describes third-party risk management as a lifecycle and says the rigor should be commensurate with risk, complexity, and criticality. [1] That supports tiering the review, but it does not create a universal approval threshold for every bank or use case.

Make the decision and keep it reviewable

Choose among approved for the defined task, approved only for synthetic or redacted data, deferred pending evidence, or rejected. State the exact scope, user group, data class, retention setting, integrations, and human review requirement. A narrow approval should not silently expand when a new model, subprocessor, feature, or matter is added. Re-run the relevant checks after material product changes, incidents, changes in data location, or a new use case.

Acquivo is a software platform that delivers the entire sell-side M&A process, valuation, marketing materials, buyer matching, and deal management, on one platform for business owners, M&A attorneys, and boutique investment banks. In a bank’s vendor review, that description is not a substitute for the bank’s evidence register. The practical outcome is a documented procurement decision with known gaps, named owners, tested boundaries, and a clear stop or fallback path.