What Client Information Should Stay Out of AI Tools During a Sell-Side Process?

Treat the upload decision as a governance decision

An AI prompt is still a data transfer. A user who pastes a customer schedule, uploads a management presentation, or asks a model to summarize a diligence folder is deciding where information will be processed. That decision should be made against the engagement letter, confidentiality terms, internal policy, applicable privacy obligations, and the tool’s actual controls. It is not enough that the tool is popular, convenient, or available inside another application.

For a securities firm, FINRA says existing rules continue to apply when a member firm uses generative AI, whether the technology is built internally or supplied by a third party. FINRA also points to tool evaluation, technology governance, data privacy and integrity, reliability, and accuracy as matters that may need to be addressed in policies and procedures. The notice is not a universal rule for every adviser or transaction, so the bank should map the decision to its own obligations and use case. [1]

Name the information owner before classifying data

The first control is a named role, not a model setting. For each data set, identify the person or function authorized to decide whether it may be used. Depending on the engagement, that may be the deal lead, the client’s designated information owner, compliance, privacy counsel, or another person named in the bank’s procedures. The owner should be able to answer who supplied the data, what the engagement permits, and whether the proposed AI task is within scope.

Do not infer authority from possession. A banker may have access to a payroll export without having authority to send it to a third-party model. A client may have shared information for buyer diligence without approving use for model training, product improvement, or a different purpose. If the owner, purpose, or permission cannot be established, stop at the boundary and escalate. The decision record should identify the data category, tool, task, date, reviewer, and expiration or recheck condition.

Use three categories instead of a single safe or unsafe label

A three-part classification is more useful than calling everything either confidential or safe. The categories are operational labels for a bank’s policy, not legal conclusions. They should be defined by the engagement, the people represented in the data, and the verified controls of the selected tool.

Permitted means the information owner has approved the specific tool and task, and the bank has checked the tool’s relevant handling terms. Redacted means the task may proceed only after removing fields that are not necessary. Prohibited means the information must not be entered into that tool or task. A fourth internal state is useful: undecided. Undecided data is not a softer version of permitted data. It is a stop condition until the owner resolves the question.

What may be permitted after tool and engagement checks

A permitted input might be a public company description, a non-confidential industry source, an internal template with no client data, or a client-approved excerpt that has been cleared for the named task. Even then, approval should be specific. “Use AI” is not necessarily approval to upload every file, use every model, retain prompts indefinitely, or allow a provider to use inputs for service improvement.

Before upload, check whether the tool has an enterprise or consumer configuration, whether prompts and files are retained, whether they are used for training or improvement, who can access them, where processing occurs if that matters to the engagement, and how deletion works. Record the version or configuration reviewed. A vendor statement is evidence for the decision, not a substitute for the bank’s information-owner approval. FINRA’s guidance emphasizes that firms should evaluate tools before deployment and remain able to comply with existing obligations. [1]

What should normally be redacted for a narrow task

Redaction should remove identity and linkage fields that the task does not require. Depending on the use case, this can include names, personal addresses, phone numbers, email addresses, account or policy numbers, government identifiers, bank details, exact employee identifiers, and unique transaction references. It can also include the combination of fields that would identify a person even when each field looks harmless on its own.

Keep only what the reviewer needs to assess the question. For example, a task that checks whether a table has missing months may need column labels and anonymized values, not customer names or full account histories. A task that drafts a neutral question list may need a description of an issue, not the underlying customer file. Replace identifiers with stable placeholders only when stable linkage is essential, and keep the re-identification key outside the AI tool. Redaction is not automatically anonymization. A small group, rare job title, unusual transaction, or exact date may still identify someone.

What should stay prohibited during a sell-side process

Prohibited inputs should include credentials, API keys, authentication codes, private encryption material, and access links that could open a broader system. They should also include data the engagement or client has restricted, information subject to a non-disclosure term that does not permit the proposed transfer, and personal or financial records whose use has not been cleared for the tool and purpose.

Treat transaction-sensitive material cautiously. Unannounced bids, counterparty identities, exact offer terms, non-public forecasts, cap tables with personal details, customer concentration schedules, employee compensation records, health or leave information, and payment or tax records may create risks that a generic prompt cannot resolve. The correct classification can differ by jurisdiction, institution, engagement letter, and data subject. The point is not to declare a blanket prohibition for every bank. The point is to require a documented owner decision before any sensitive item crosses the tool boundary.

Do not use an AI tool to decide that it is allowed to receive the data. The classification must precede the upload. If the task requires an unredacted source, use an approved workflow with the appropriate human and technical controls, or do the task without that tool.

Check the data path, not only the prompt

A prompt can expose more than its visible text. Files may contain hidden sheets, comments, tracked changes, metadata, embedded images, formulas, or prior versions. A copied table may carry names in an unseen column. A screenshot may reveal a browser tab or account number. A model response may reproduce sensitive content, and a connected feature may send the request to another service. Review the input package and the output destination as one workflow.

NIST’s generative AI profile describes privacy risks that include leakage, generation, and inference of sensitive information. It also recommends policies for data collection, retention, quality, and third-party data use, storage, and protection, together with monitoring for possible personal-information exposure. Those recommendations support a practical rule: minimize the input, verify the route, and inspect the output before it is stored or shared. [2]

Assign a task owner and human review gate

Every approved AI use should have a task owner who can stop the workflow. The owner defines the source-of-truth record, the requested transformation, and the acceptance checks. The source of truth remains the approved deal file, accounting record, client instruction, or other authoritative material. The model is not the source of truth, and a plausible summary is not evidence that every field was preserved.

For document summarization, compare the output with the source for names, dates, amounts, qualifiers, exceptions, and missing sections. For extraction, sample rows against the original and check whether blanks were treated as zero. For drafting, verify that no unapproved fact, buyer, commitment, or conclusion was added. A human with appropriate deal knowledge must approve any output before it goes into a client communication, marketing material, diligence response, valuation analysis, or disclosure.

Define stopping conditions before a pilot

A small pilot should have explicit conditions for stopping rather than relying on enthusiasm or a good first result. Stop if the tool’s retention, training, access, deletion, or service-provider terms cannot be verified. Stop if a prompt reveals a prohibited field, if the model returns sensitive material unexpectedly, or if the human reviewer cannot reconstruct the output from the source. Stop if users begin adding files outside the approved category or if the use expands from internal drafting to external communication without a new review.

The bank should record incidents and near misses, including accidental uploads that were deleted. The SEC’s Regulation S-P amendments illustrate why service-provider oversight and incident response matter for covered institutions: the release discusses written policies and procedures for due diligence and monitoring of service providers, and obligations related to unauthorized access or use of customer information. Applicability depends on the institution and rule, so qualified compliance or legal review should determine what applies. [3]

Turn the classification into a pre-upload checklist

A usable checklist asks seven questions in order. What is the exact task? What is the source of truth? Who owns the information and approved this purpose? Which fields are unnecessary and can be redacted? What verified tool configuration will process the input? Who will review the output and where will the approved result be stored? What event causes the workflow to stop or be re-approved? If any answer is missing, classify the input as undecided and escalate to the designated information owner.

Keep the checklist close to the work rather than burying it in a policy manual. The owner can attach the classification to the task record, use a standard redaction template, and require a second review for customer, employee, or transaction data. The checklist should be updated when the engagement changes, when the tool changes, or when a new type of data enters the workflow. NIST recommends connecting generative AI policies to existing legal, compliance, risk, data, and IT governance rather than treating AI as a separate exception. [2]

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 user-operated workflow, the bank still decides what information to upload, which permissions apply, and when a human reviewer must intervene.