Writing an AI Confidentiality Policy for a Boutique Investment Bank

Start from the obligations the bank already has

The policy should translate the bank's existing confidentiality, record-keeping, employment, and engagement obligations into rules for a new category of tool. Before writing a word, list the confidentiality obligations the bank already carries: the engagement letter with each owner, the NDAs signed with each buyer, any regulatory record-keeping that applies to the firm, and the firm's own employment agreements. The AI policy is a bridge between those documents and the software people use every day.

This framing matters because it keeps the policy short. The bank does not need to explain why confidentiality matters. Every banker already knows. The policy only needs to say how that known standard applies when the counterparty is a software vendor instead of a buyer. For a regulated firm, the exact duties depend on its status and the information involved. For example, the SEC's 2024 Regulation S-P amendments describe written policies for oversight of service providers and protection of customer information, but they do not replace a firm's own legal analysis. [1]

It also makes the policy defensible. If an owner's counsel asks how the bank protected the client's information, the answer is that the firm's standing confidentiality obligations were extended to every tool that touched the content, and here is the page that says so. A policy is an internal control, not a substitute for the engagement letter, an NDA, or advice from qualified counsel.

Section one: the approved tool list

The first section is a list, and it should be short. Name each tool approved for client content, the firm's contract reference for it, and the categories of content it may receive. Three to five tools is a useful starting point for a boutique bank. More than that may suggest the list has not been curated.

For each tool, record the answers to three questions: where the content is stored and processed, whether it is used to train models for other customers, and who can access it. If a tool cannot answer all three, it does not go on the list. The list should also state who owns the accounts, the firm rather than the individual, and who provisions and revokes them.

Everything not on the list is prohibited for client content. Say that explicitly. The sentence "any tool not listed here may not receive client content" does more work than a page of examples. It also future-proofs the policy: a new product launched next month is prohibited by default until a partner adds it.

Assign one partner as owner of the list. Changes go through that person. The list is reviewed quarterly, and the review takes fifteen minutes if nothing has changed. The review should also check the vendor's current terms, access roster, deletion process, incident-notification terms, and any new use of the tool in a client mandate. The SEC rule's discussion of service-provider oversight reinforces why vendor due diligence and monitoring belong in the control, while the exact rule that applies remains jurisdiction-dependent. [1]

Section two: content categories and what goes where

Not all client content carries the same risk, and the policy should say so rather than treating everything as maximally sensitive, which leads people to ignore the rule for the low-risk cases and then for the high-risk ones.

A practical scheme has three tiers. Public and blind content: the teaser, industry research, generic templates. This may enter any approved tool. Client-identifying content: the questionnaire, financial statements, the CIM, the buyer list, correspondence with the owner. This may enter only approved tools whose contract covers client content. Buyer-confidential content: IOIs, LOIs, buyer financial information shared under NDA. This follows the same rule as the second tier, with the added note that the buyer's NDA may impose its own limits.

The scheme answers the question an analyst actually asks: "can I put this in that." The answer should be obvious from the tier of the content and the entry on the approved list. If it is not, the policy has failed the first-day test. The bank should also define whether de-identification changes the tier, and who decides when a prompt still reveals a mandate through a combination of facts.

One rule deserves its own sentence: no client content of any tier enters a personal account. Firm accounts only. The tier scheme governs which firm tools; it never opens the door to a personal one. A policy owner should be able to answer what happens to retained prompts, uploaded files, and generated exports when a mandate ends. Those details belong in the vendor review and the bank's own retention schedule.

Section three: who may use the tools and what they must do with the output

The third section covers people and review. Every person with access to an approved tool should be named by role: managing directors, associates, analysts, and any contractors. Contractors are the usual gap. A freelance designer formatting the CIM or an outside analyst building a model is bound by the policy only if the firm says so and the contractor agreement reflects it.

Output review is the part most policies leave out, and it is where the real risk sits. A generated draft may contain a number that does not trace to the data room, a sentence that overstates a client's position, or a fragment that belongs to a different mandate. The policy should state that no generated content leaves the firm without a named reviewer who has checked every figure against its source. The reviewer's name goes on the document record. The policy does not need to specify the checklist; it needs to require that one exists and that the reviewer is a person, not the tool.

This is consistent with the risk-management approach in NIST's Generative AI Profile, which is designed to help organizations incorporate trustworthiness considerations into the use and evaluation of AI systems. It is voluntary guidance, not a legal safe harbor, and it does not turn a generated draft into a verified work product. [2]

This section should also cover prompts. Bankers sometimes include more context in a prompt than the task needs, such as the client's name and location when asking for help with an industry overview. The rule is to include only what the task requires. It is a habit, and the policy can state it in one line. When the task involves a CIM, financial statement, IOI, or LOI, the reviewer should know which source version was used and whether the output was checked against the current record.

Section four: incidents and the amnesty clause

The fourth section says what happens when the rule is broken, and it should start with the understanding that it will be. Someone will paste a paragraph into the wrong place. The policy's goal is to find out quickly.

State the reporting path: tell the policy owner the same day, describe what content went where, and do not attempt to clean it up alone. State what the firm will do: assess whether the content was client-identifying, request deletion from the vendor if a contract exists, preserve relevant records, document the incident, and decide with qualified counsel whether the engagement letter, an NDA, or applicable law requires notifying the owner or a buyer. The FTC's breach-response guidance likewise emphasizes moving quickly, documenting the investigation, checking service-provider access, and determining legal requirements rather than applying one universal notice rule. [3]

For firms subject to applicable SEC requirements, the incident plan may also need service-provider oversight and prompt notification processes. The 2024 Regulation S-P amendments discuss policies designed to require a service provider to notify the covered institution as soon as possible, and no later than 72 hours after learning of a security breach involving unauthorized access to customer information. Whether that rule applies to a particular bank, and what additional duties follow, requires a status- and fact-specific review. [1]

Then include an amnesty clause for self-reporting. An associate who reports her own mistake within the day should be encouraged to report it without automatic punishment for the disclosure itself, subject to the firm's employment and legal obligations. An associate who conceals it may create a more serious control failure. This clause is intended to make incidents visible. It should not promise immunity from legal duties, client obligations, or serious misconduct consequences.

Section five: training, acknowledgment, and the annual review

The last section is procedural and short. Every person with tool access reads the policy and signs an acknowledgment when they join and once a year. New tools added to the list trigger a one-paragraph update, not a new signature. The policy owner reviews the whole document annually and whenever the firm signs a new vendor contract.

Training is a thirty-minute walkthrough for new hires: here are the tools, here are the tiers, here is who reviews output, here is who to call. The walkthrough is done by an associate who uses the tools daily, not by the partner who wrote the policy, because the associate knows where the real questions come up.

A practical step for this week: write the approved tool list first, before any other section. It forces the firm to look at what is actually in use, and the rest of the policy follows from the answers. Have the policy owner test the list with one harmless sample prompt and one redacted deal artifact, then record what should happen if an analyst chooses an unapproved account.

How Acquivo Pro fits

A short approved list is easier to write when one platform covers several parts of the work. On Acquivo Pro, the firm runs valuations across 21 industry verticals, generates teasers and CIMs from the client questionnaire and data room, builds buyer shortlists using documented matching criteria, and manages NDA, IOI, and LOI flow on one login. Client data is isolated and not used to train models for other customers, which gives the bank specific vendor-review information to record, not a reason to skip its own review. Figures from the deterministic valuation engine trace to their source, which supports the reviewer's job under section three. The bank operates the software and remains responsible for every decision and buyer contact. To see it on a live mandate, request a demo through the Contact page.