Skip to content
← Guides

Guide for M&A professionals

Three Questions to Ask Any AI Vendor Before It Sees a CIM

Published · Updated

Before an AI vendor touches a CIM, a boutique bank should ask three questions: where does the data go, is it used to train models for anyone else, and who inside and outside the vendor can see it. The answers belong in writing, in the contract, before a single client document is uploaded. A vendor that cannot answer all three in plain language has not earned access to a confidential information memorandum, no matter how good the demo looked.

Why the CIM is the right test document

A CIM is among the most sensitive artifacts a sell-side bank produces. It contains customer concentration, margin by product line, owner compensation, pending litigation, and the one or two weaknesses the bank has decided to address head-on rather than hide. A leaked teaser is embarrassing. A leaked CIM could disrupt a process, hand a competitor the client's pricing, and expose the bank to a claim from the owner.

That is exactly why the CIM should be the reference point when a managing director evaluates software. If the vendor's answers are good enough for the CIM, they are more likely to be good enough for the questionnaire, the financial model, and the buyer list. If they are not good enough for the CIM, the tool belongs nowhere near client work. Evaluating against a lower bar, such as "we will only use it for teasers," can lead to scope creep within a month. An analyst under deadline may paste the CIM into whatever worked last time.

The three questions below are ordered by practical risk: data movement and contractual handling, model-use restrictions, and access. The order is a review sequence, not a measured ranking of vendor failures.

Question one: where does the data go, physically and contractually

"Where does the data go" has two parts, and vendors often answer only the easy one.

The physical part is about location and movement. When an associate uploads a data room export, which servers receive it, in which jurisdiction, and does it pass through any third-party processor along the way? Many AI products are layers over a foundation model run by someone else. The vendor may store little or nothing itself, but a prompt or uploaded page can still travel to another provider. Ask the vendor to name every subprocessor that will handle client content, and ask whether the list can change without notice.

The contractual part is about ownership and retention. Who owns the uploaded documents and the generated output? How long is content retained after a mandate closes or after the bank cancels? Can the bank order deletion, and will the vendor confirm it in writing? A vendor that answers "we take security very seriously" has not answered. A vendor that answers "content is stored in the following region, processed by the following named providers, retained for the following period, and deleted on request with written confirmation" has given the bank something it can evaluate. NIST's AI Risk Management Framework treats governance, mapping, measurement, and management as part of managing AI risk, which supports asking for operational detail rather than accepting a general assurance. [1]

Something the managing director can do this week: pull the current contract for any tool that already touches client content and look for the word "subprocessor." If it is not there, the first question has not been answered in a form the bank can readily verify.

Question two: is client content used to train models for other customers

This is the question that separates a tool's stated data-use terms from a bank's assumption about how the tool works. A consumer product may use submitted data under its terms to improve a service. That may be acceptable for a low-risk drafting task. It is not an acceptable default for a document that describes a client's gross margin by customer.

The failure mode is subtle. The vendor may never store the CIM in a way a human reads. But if the model is tuned on it, fragments of the client's language, numbers, or deal structure could surface in another user's output later. The bank may not know, and neither may the owner. Confidentiality risk does not disappear because the processing is statistical. The FTC has warned that model-as-a-service companies may receive sensitive or confidential business information and that promises about how customer data is used, including promises not to use it to train or update models, need to be honored. [2]

Ask directly: is any client content, including prompts, uploads, and generated drafts, used to train, fine-tune, or otherwise improve models that serve any customer other than this bank? The acceptable answer is no, stated in the contract, not only on a marketing page that can be edited next quarter. Then ask the follow-up most banks skip: does the same answer apply to every subprocessor named in question one? A vendor that promises not to train on client data but routes content through a provider that does has made a promise it cannot keep.

Be alert to the phrase "we may use data to improve our services." Ask what "improve" means. If the answer includes model training on client content, the tool fails the bank's stated confidentiality test.

Question three: who can see it, inside the vendor and across customers

The third question is about access, and it has three layers.

The first layer is isolation between customers. If two banks are both working a mandate in the same industry, can one ever see the other's documents, buyer lists, or valuation inputs? The answer should be a description of how tenant data is separated, not a reassurance. A managing director does not need to understand the architecture, but should hear that isolation is a design property rather than only a policy.

The second layer is isolation within the bank. Can the vendor's tool restrict a junior analyst to the two mandates she is staffed on, or does every login see everything? Boutique banks are small enough that this is sometimes dismissed as unnecessary, until a departing associate exports every live CIM on the way out. Role-based access is a practical control that makes a confidentiality policy easier to enforce.

The third layer is the vendor's own staff. Which employees can access customer content, under what circumstances, and is every access logged? Support engineers may have broad rights by default. Ask whether access to client content requires the bank's permission for each instance, and ask to see what the audit log looks like.

Finally, ask who can see the output. Generated teasers and CIMs are derived from the client's data and deserve the same protection as the inputs. A vendor that protects uploads but treats generated drafts as its own property has created a gap the bank's confidentiality policy may not cover.

Turning the answers into contract language

Good answers in a sales call evaporate unless they are written down. The bank's engagement letter with the owner already promises confidentiality. The vendor contract should carry that promise forward without weakening it.

At a minimum, the agreement should state that the bank owns all uploaded content and generated output, that content is not used to train models serving other customers, that subprocessors are named and changes are notified in advance, that content is deleted on written request within a stated period, and that vendor staff access to client content is logged and limited. Many vendors have a data processing addendum that covers some of this; read it rather than accepting the summary. The FTC has specifically emphasized that AI companies can be held to privacy and confidentiality commitments made to customers, including commitments about data use. [2]

Have the bank's outside counsel review the addendum once, then reuse the review for every subsequent vendor. The questions do not change from tool to tool. Only the answers do.

One more practical step: keep a one-page register of every tool that touches client content, with the three answers recorded beside each. When an owner's counsel asks during diligence how the bank protects confidential information, the register is the starting record.

How Acquivo Pro fits

Acquivo Pro is built for firms that must answer these questions to their own clients. Client data is isolated and is not used to train models for other customers. The firm runs valuation, teaser and CIM generation, buyer matching, and NDA, IOI, and LOI flow on one login, so the number of vendors that ever see a CIM can be reduced, which makes the register shorter to review. The owner sees a branded document portal where requests appear and uploads happen once. To see it on a live mandate, request a demo through the Contact page.

Key Points

  • A boutique bank should evaluate every AI vendor against the CIM, its most sensitive document, rather than against the teaser.
  • "Where does the data go" has to be answered with named subprocessors, a storage region, a retention period, and a deletion process.
  • An AI vendor that uses client content to train models for other customers fails the confidentiality standard a sell-side bank should apply to its client work.
  • Access to client content should be isolated between customers, restricted within the bank by role, and logged for the vendor's own staff.
  • Answers given in a sales call protect little until they appear in the signed contract or data processing addendum.

Sources and references

Source retrieval dates record research access, not article publication. Read our editorial and date policy.

  1. [1] NIST AI Risk Management Framework · Accessed
  2. [2] AI Companies: Uphold Your Privacy and Confidentiality Commitments · Accessed

Choose your next step

Acquivo is user-operated software. Owners and their professionals remain responsible for decisions, communications, and professional review.

Educational information, not individual legal, tax, or investment advice. Consult qualified professionals for your circumstances. Acquivo provides software, not representation or negotiation on your behalf.