Can You Put Confidential M&A Data into an AI Tool? A Decision Framework

The question "can we put deal data into an AI tool" has no general answer, and the search for one is why teams get stuck. The answerable version is specific: may this material, under these confidentiality undertakings, be processed by this tool, in these locations, with these retention and training terms, by these users?

Five variables. Answer them and you have a decision you can defend.

I have run this assessment from the data protection side and I have been asked for it by deal teams at eleven at night, which is exactly when it should not be happening. So here is the framework, and a strong recommendation to complete it before a process opens rather than during it.

Step 1: classify the material precisely

"Deal data" is not a category you can assess. Break it apart, because the answer differs by type.

Most teams assess the second row and act as though they have assessed all seven. The rows that cause real damage are the last four.

Privilege deserves a specific note. Processing privileged material through a third party service can raise questions about whether privilege is preserved. That is a legal question with a jurisdiction specific answer, and it belongs with counsel rather than with an IT decision.

Step 2: read the actual undertaking

This is the step that gets skipped, and it is the one where a policy compliant decision can still breach a contract your firm signed.

Confidentiality undertakings commonly contain provisions that bear directly on tool use:

• Permitted recipients. Often defined as employees, advisers and affiliates who need to know. A cloud service provider may or may not fall inside the definition.
• Processing location restrictions. Some undertakings restrict where material may be held or accessed.
• Sub processing consent. A requirement to obtain consent before involving further parties, which a subprocessor chain may trigger.
• Purpose limitation. Material provided for evaluating the transaction, and nothing else.
• Return or destroy obligations. On termination or on request, with a defined timescale.
• Security standards. Sometimes specific, sometimes referencing reasonable measures.

A tool that satisfies your internal policy can still breach any of these. Counsel should check the undertaking against the tool's actual processing chain before material is uploaded. Not the marketing description of the chain. The documented one.

Step 3: assess the processing chain, not the interface

The chain is what you are actually approving. Six questions, and the answers must be documented rather than assumed.

Where is data processed? Every component. Retrieval, generation, rendering, storage.

Which subprocessors are involved? Including model providers, and where they operate.

Where do support engineers sit and what can they access? The question most frequently absent from a trust page, and part of the same chain.

What goes into logs, telemetry and backups? Content or only metadata, and for how long.

Are inputs used for training? Contractually, not as a website statement. A commitment on a page that can be edited is not a commitment.

How does deletion work, and can it be demonstrated? Across uploads, prompts, indexes, drafts, outputs, logs and backups.

That last question is where transaction work differs from ordinary business use. Deals break. When they do, the return or destroy obligation activates, and a tool that cannot comply puts you in breach of an agreement with a counterparty who now has a reason to look closely.

Step 4: the inside information overlay

If the material is or may be inside information, the assessment gets stricter and a different function owns it.

Considerations:

• Insider list management, and whether tool access is captured in it.
• Need to know access, enforced technically rather than by instruction.
• The ability to demonstrate, after the fact, who accessed what and when.
• Whether retrieval can cross into or out of the restricted material set.
• Whether outputs containing inside information can leave the controlled environment through export, sharing or an API.

Compliance owns this, not the deal team and not IT. And it should be settled before the wall crossing, because the moment somebody is inside is not the moment to start assessing a tool.

Step 5: the personal data assessment

Deal material carries far more personal data than teams expect. Employee lists with compensation, management assessments, customer records, contracts naming individuals, litigation files, pension data which is frequently special category.

Four decisions:

Lawful basis for processing counterparty personal data in diligence, identified and documented. Rarely consent.

Minimisation before upload. Redact, aggregate or exclude. The data room hands you everything at once, which makes over collection the path of least resistance. Resist it, because it is also the cheapest control available.

Processor arrangement. An Article 28 agreement with terms that match the actual data flows, not just a signed template.

Retention after close or break. Defined in advance, executed in practice.

Step 6: the tool tier decision

Not all tools are in the same category, and being explicit about tiers avoids a lot of case by case argument.

Prohibited for all transaction material. Consumer accounts, personal subscriptions, unapproved browser extensions, any service without a processor arrangement. State this in terms nobody can misread, and explain why rather than just forbidding it, because people route around rules they think are arbitrary.

Approved for internal analysis only. Enterprise tools with an appropriate arrangement, used on your own analysis and public information, not on counterparty material under NDA.

Approved for counterparty material. Tools that have passed the full assessment above, with deal team isolation, contractual training exclusion, demonstrated deletion and confirmed NDA compatibility.

Approved for inside information. A narrower set, with compliance approval and access demonstrably captured.

Publish the tiers. A deal team at midnight needs to look up an answer, not start a process.

Step 7: enforce the deal boundary

Every control above fails if retrieval can cross transactions. This is the specific technical risk that M&A adds to ordinary AI deployment, and it deserves its own verification.

• Each transaction has an isolated workspace.
• The agent runs with the invoking user's entitlements, never a service identity.
• Retrieval returns nothing across a boundary, and does not indicate that anything exists.
• The same boundary holds through search, export, share links and any API.
• The boundary has been tested adversarially, by someone trying to break it.

Do that test before the process opens, with a user account created specifically to fail. If a vendor will not let you run it, that is your answer about the product.

The decision record

Whatever the outcome, write it down. One page, before the process opens.

If you cannot complete this page, the answer for that material is no. That is a legitimate outcome and it is far better than the alternative, which is a deal team improvising at midnight and a difficult conversation with a counterparty six weeks later.

The two failure modes

I want to name both, because organisations tend to fall into one or the other.

Blanket prohibition. No AI tools on any deal material, ever. This feels safe and is not, because the work still happens and people find their own solutions. A prohibition that is impossible to comply with under deal pressure produces shadow usage on consumer accounts, which is the exact outcome the prohibition was meant to prevent, with no visibility and no controls.

Blanket permission. One enterprise agreement and an assumption that everything is now covered. This ignores that the NDA, the inside information overlay and the personal data assessment are separate questions with separate answers.

The workable position is between them: a small number of approved tools, assessed properly, with clear tiers, and a genuinely fast route to approve a new case. Speed of approval is a control, because slow approval is what drives people around the process.

Where offgen fits

We publish what this assessment needs rather than asking you to trust a summary. Our trust center, security overview and data processing agreement cover processing locations, subprocessors, support access, retention and the contractual position on training.

On the deal boundary specifically: retrieval runs with the invoking user's entitlements inside workspace boundaries that map to your deal teams, and an unmatched request produces a marked gap rather than an invention. Output is native PowerPoint, which matters for the return or destroy obligation because your material is portable rather than locked in a proprietary store.

The framing worth keeping: you are not assessing whether AI is safe for M&A. You are assessing a specific arrangement against specific undertakings. Do that once, properly, before the process opens, and the answer exists when your team needs it.