Skip to content
← Guides

Guide for M&A professionals

When Should Bankers Pause an AI Pilot and Return to the Manual Workflow?

Published · Updated

Bankers should pause an AI pilot as soon as it produces an unsupported claim, cannot show the source record behind a material statement, crosses a permission boundary, or creates more review work than the accountable reviewer can safely clear. The pause should be a controlled switch to the last approved manual workflow, not an informal decision to keep experimenting on a live mandate. Before restarting, the pilot owner should document the incident, preserve the relevant inputs and output, resolve the source or permission defect, and obtain a named human reviewer’s approval. The exact threshold depends on the task, engagement, client instructions, applicable law, and the bank’s own policies.

Start with a narrow task and a hard stop rule

A pilot needs a defined task before it needs a model. For example, the task might be to extract stated operating metrics from a client-provided data room into a working checklist. That is different from asking a tool to decide which buyer should receive information, draft a representation about the business, or communicate with a counterparty. The latter tasks introduce judgment, disclosure, and approval questions that should remain with authorized people.

Write the stop rule before the first trial. The rule should say what the tool may produce, what it may not produce, who reviews every output, which records are authoritative, and what event returns the work to the manual process. NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. It is useful as a planning structure, not a promise that a workflow is compliant or secure. [1]

For a boutique investment bank, the accountable owner is usually the banker responsible for the workstream, with an escalation owner such as the engagement lead, compliance contact, or designated risk owner. Put the names or roles in the pilot record. If nobody has authority to stop the test, the pilot is not ready for live mandate work.

Stop when a material claim cannot be traced

The clearest pause trigger is an output that sounds plausible but cannot be tied to a source-of-truth record. A material claim includes a revenue figure, customer concentration statement, debt term, transaction assumption, valuation input, buyer requirement, or description of an approval. The reviewer should be able to locate the underlying document, page, worksheet, or approved instruction and confirm that the output preserves the meaning and period.

Treat missing provenance as a failed output, not as an invitation to search casually until something similar appears. Record the claim, the output version, the input set, the retrieval date, and the reviewer’s disposition. If the source is absent, pause the pilot and use the manual workflow. If the source exists but is ambiguous, route the question to the person who owns the record rather than allowing the tool to resolve the ambiguity by guesswork.

A citation that points only to a folder, a long document, or a general website is not enough for a high-consequence statement. The review record should distinguish a direct quotation, a calculated figure, an interpretation, and an unresolved question. That distinction helps the next reviewer understand what still needs human judgment.

Stop for source mismatch, stale data, or conflicting versions

A pilot should stop when it uses the wrong version of a document, mixes periods, confuses reported and adjusted figures, or combines internal and public records without an explicit basis. Version control is part of document-control discipline. The reviewer should compare the output with the designated source register and check the date, period, units, currency, and adjustment basis where those details affect the conclusion.

The OCC’s 2026 revised model-risk guidance describes validation and monitoring, governance and controls, and vendor considerations as parts of a risk-based approach. It also says practices suitable for one banking organization may be inappropriate for another, and that the guidance is not prescriptive. A boutique bank can use those ideas to tailor its control record, but should not describe them as a universal rule or as direct regulation of generative AI. [2]

Stop when permissions or confidentiality are unclear

Do not continue a pilot when the team cannot answer what information may be entered, where it will be processed, who can access the output, and how the record will be retained or deleted under the applicable arrangement. A permission failure includes an unapproved data source, an account with broader access than intended, an output shared with the wrong internal group, or a proposed use that the client instructions do not cover.

The remedy is not to rely on a general confidentiality statement or a vendor label. Pause, isolate the affected material, notify the designated escalation owner, and follow the bank’s incident and information-handling process. The applicable contract, client instruction, professional duty, and jurisdiction may change the analysis, so legal or compliance review may be appropriate. Do not promise that a tool preserves privilege, confidentiality, or security merely because it is used inside a controlled environment.

A safer pilot record states the data classification, permitted inputs, excluded inputs, approved users, review location, retention decision, and manual alternative. If those fields cannot be completed, the tool should remain outside the live mandate workflow until the permission question is resolved.

Stop when the reviewer cannot keep up

Human-in-the-loop means more than placing a person at the end of a process. The reviewer must have enough time, context, access to the underlying sources, and authority to reject the output. Pause when the queue grows beyond the agreed review capacity, when reviewers begin accepting claims without checking them, or when the pilot creates parallel copies that make it unclear which version is approved.

Review overload is itself an operational incident. Record the number and type of unresolved items in the queue, the age of the oldest item, and the work that was diverted from the manual process. Do not frame those observations as a verified productivity gain or loss unless the bank has a defined measurement method and reliable baseline. The immediate decision is whether the current reviewer can safely clear the work, not whether the tool appears impressive.

A practical control is a release gate: no output moves to an external draft, buyer list, diligence response, or approval package until the assigned reviewer marks each material item as supported, corrected, or deliberately omitted. If the gate cannot be staffed, return to the manual workflow and reduce the pilot scope.

Use a fail-closed checklist during an incident

When a stop condition occurs, the owner should take the same sequence every time. First, stop distribution of the affected output and label it as unapproved. Second, preserve the prompt or instruction, input references, output version, reviewer notes, and time of discovery. Third, identify whether the issue is a source defect, model behavior, access problem, reviewer-capacity problem, or unclear business rule. Fourth, notify the named escalation owner. Fifth, switch the affected task to the approved manual procedure.

For securities firms, FINRA states that technology-neutral rules and securities laws continue to apply when member firms use generative AI or similar technologies, including third-party tools. FINRA also encourages a comprehensive review of applicable obligations and says its AI page is informational rather than a source of new legal requirements. That supports a cautious control design, while leaving the bank to assess its own facts and jurisdictions. [3]

Decide what evidence is required to restart

A pilot should not restart because the team is under deadline pressure or because the output looks better on the next attempt. Define restart evidence in advance. Depending on the task, that evidence may include a corrected source map, a permission decision, a test set of known examples, a documented reviewer procedure, a reduced input scope, or a change to the output format that makes unsupported claims easier to detect.

The owner should also define a new stopping threshold. For example, one unsupported statement in a buyer-facing draft may be an immediate stop, while a harmless formatting error in an internal scratchpad may require correction and monitoring. The threshold must reflect the task’s consequences. Do not use an error rate from one task to justify another task with different records, reviewers, or disclosure risk.

If the cause cannot be explained, the source cannot be verified, or the permissions remain uncertain, keep the pilot paused. A manual process may be slower, but it provides a known control path while the issue is investigated. Restart only after the escalation owner records the decision and the accountable reviewer accepts the revised conditions.

Keep AI away from irreversible deal actions

A pilot can support a banker’s preparation without taking an autonomous deal action. The tool should not send outreach, select or contact buyers, negotiate terms, approve a disclosure, submit a filing, or represent that a client or bank has taken a position. Those actions require the authority, judgment, and records applicable to the engagement.

FINRA’s report on AI applications in the securities industry describes concerns about corrupt or misleading data, privacy, unusual conditions outside model training, and autonomous behavior. It also describes cautious approaches to tools that may provide investment advice directly to retail customers. These observations are not a rule for every boutique bank, but they explain why a pilot should stop before an output becomes an external or irreversible act. [4]

Use a human approval boundary even when a task appears routine. The approval should identify the exact artifact being approved, the source checks completed, unresolved issues, and the person authorized to release it. If the approval cannot be reconstructed later, the workflow has not established adequate document control.

Turn the decision into a repeatable owner checklist

The implementation outcome is a pilot stop-condition checklist and manual fallback procedure with a named escalation owner. Keep the checklist short enough to use during a live issue: Is every material claim supported by the controlling record? Are versions, periods, units, and permissions confirmed? Can the assigned reviewer complete the checks? Is the output still within the approved task boundary? Has any external or irreversible action been blocked? If any answer is no or unknown, pause and switch to manual handling.

After the incident, update the pilot record rather than quietly correcting the visible draft. Note the trigger, affected work product, containment step, escalation decision, fallback used, corrective action, and restart conditions. A small bank does not need to copy a large institution’s process to gain discipline. It does need a clear owner, a source trail, a reviewer with real authority, and a stop that happens before unsupported work reaches a live mandate.

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. A bank using software in this workflow should still configure its own permissions, source checks, review gates, and escalation responsibilities. The software is user-operated, and the professional remains responsible for deciding when work is ready to move forward.

Key Points

  • Write the task boundary, source-of-truth records, reviewer, escalation owner, and stop rule before the pilot starts.
  • Pause immediately for unsupported material claims, source mismatches, permission failures, or unresolved confidentiality questions.
  • Treat review overload as an operational incident and return to the manual process when the reviewer cannot safely clear the queue.
  • Preserve the affected inputs, outputs, versions, and decisions so the cause can be investigated without contaminating the manual fallback.
  • Restart only after the owner documents corrective evidence and a human reviewer accepts the revised conditions.

Sources and references

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

  1. [1] AI Risk Management Framework · Accessed
  2. [2] OCC Bulletin 2026-13: Model Risk Management: Revised Guidance · Accessed
  3. [3] Artificial Intelligence (AI) · Accessed
  4. [4] Artificial Intelligence in the Securities Industry: AI Applications in the Industry · 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.