What Should a Boutique Investment Bank Put in Its First 90 Days of AI Implementation?

Treat 90 days as a control cycle, not a deployment deadline

The useful question is not whether a bank can switch on AI in three months. It is whether the bank can make a well-supported decision about one or two bounded workflows after three months of preparation and supervised testing. This distinction keeps the plan compatible with the bank’s risk tolerance, staffing, client commitments, and technology maturity.

NIST’s AI Risk Management Framework organizes risk work into govern, map, measure, and manage. It says the functions are iterative, lifecycle-based, and not a mandatory sequence or checklist. [1] A 90-day plan can therefore use those functions as a management frame while keeping the implementation sequence conditional. If evidence is weak, the correct milestone is a pause or narrower test.

Days 1 to 15: assign ownership and approve the information boundary

Name an accountable implementation owner with authority to stop a test, plus a workflow owner for each proposed use. Include a deal-team representative, an information-security or technology reviewer where available, and a compliance or legal reviewer when the workflow touches regulated communications, client data, personal information, or engagement obligations. Record who approves the use, who operates it, who checks the output, and who decides whether the pilot continues.

Before anyone pastes material into a tool, classify the information that may be used. Separate public information, internal methods, confidential client information, personal information, deal-room content, and privileged or legally sensitive material. Confirm the vendor or tool’s retention, access, training, export, deletion, and account controls from current documentation. If those terms cannot be verified, exclude the information or pause the test. A tool’s label is not proof that a document is secure, confidential, or privileged.

For a U.S. FINRA member firm, FINRA says existing rules and securities laws continue to apply when the firm uses generative AI, and it recommends evaluating tools before deployment. Its notice identifies privacy, data integrity, reliability, accuracy, bias, intellectual-property, and threat-actor concerns. [2] That is a prompt for use-case-specific review, not a blanket rule for every boutique bank or jurisdiction. Obtain qualified advice on obligations that apply to the firm.

Days 1 to 20: choose a narrow workflow and create a baseline

Choose a task with a clear input, a stable source of truth, a reviewable output, and a low-cost fallback. Suitable illustrative candidates include extracting selected fields from a public filing into a review sheet, organizing an internal research queue, or producing a first-pass checklist from an approved template. Do not begin with autonomous outreach, negotiation, valuation conclusions, client advice, approval decisions, or disclosure of deal information.

Write the workflow in ordinary language: who starts it, what records are allowed, what the tool is asked to do, what it must not do, what the reviewer checks, and where the approved result is stored. Capture a small baseline before the pilot. The baseline can describe review steps, common error types, source coverage, and the time required under the current process. Avoid claiming a productivity improvement unless the same task, quality standard, and review scope are compared consistently.

Define acceptance criteria before seeing pilot results. For example, every extracted field must point to an identifiable source passage; uncertain or missing fields must be marked for human resolution; and no output may move into a client-facing or transaction-critical document without approval. These are proposed controls for the bank’s process, not assurances that a model will meet them.

Days 15 to 30: build the sandbox test and source checks

Use a segregated test space and representative, approved material. Start with public or synthetic examples if the tool’s data handling is not yet established. Maintain a test log containing the input version, tool or model version when visible, prompt or instruction version, output, reviewer decision, error category, and disposition. A simple record makes it possible to distinguish a repeatable workflow from an impressive one-off answer.

Require the output to show its basis. For document work, the reviewer should trace each material statement to the source-of-truth record and check dates, definitions, units, scope, and omissions. For classification or routing, test ambiguous examples and make an explicit unknown or escalation state available. For drafting, compare the output to the approved template and remove unsupported assertions, invented details, and language that implies approval or advice.

FINRA’s securities-industry research describes potential AI use in document, compliance, surveillance, and risk workflows, while also warning about misleading data, privacy, opacity, and bias. [3] These risks make source checks and a human escalation path part of the pilot design, rather than cleanup after a model has been trusted.

Days 31 to 45: run controlled tests and record failure modes

Run the same bounded task across ordinary, incomplete, ambiguous, and adversarial examples. Include stale documents, conflicting source passages, unusual formatting, missing fields, and instructions that attempt to override the workflow. The purpose is not to make a model look good. It is to discover where the process fails and whether a reviewer can detect the failure before the output is used.

Assign the reviewer a defined checklist. It should cover source traceability, factual accuracy, confidentiality handling, prohibited conclusions, formatting, and escalation. Record false positives, false negatives, unsupported citations, leakage concerns, and cases where the reviewer cannot confidently resolve an issue. If the workflow involves communications or supervision, route the design through the firm’s applicable compliance process before testing real communications.

Set stopping criteria in advance. Stop or narrow the pilot if material errors recur, reviewers cannot detect them reliably, the source record is incomplete, the tool’s data terms are unacceptable, the workflow drifts into advice or approval, or the review burden exceeds the value of the experiment. A stopping rule is a control, not evidence of failure.

Days 46 to 65: practice with the deal team under supervision

Train the people who will actually use the workflow. Practice should cover approved inputs, prohibited data, prompt or instruction patterns, source verification, uncertainty labels, escalation, and recordkeeping. Use a short scenario set rather than a generic AI presentation. Each participant should demonstrate how they would reject an unsupported output, correct a source mismatch, and stop when the workflow leaves its approved boundary.

Keep the human-in-the-loop role concrete. The reviewer is not merely a final approver who skims a polished paragraph. The reviewer owns the comparison to source records, resolves or escalates ambiguity, and decides whether the output can enter the next internal step. For capacity-planning purposes, count reviewer availability and exception handling as part of the workflow. An AI draft that creates a large verification queue may change where work sits without reducing the work itself.

Do not let training examples become client or deal records by default. Use the approved information class, retain only what the bank’s policy permits, and document the removal or deletion step where applicable.

Days 66 to 80: conduct a limited pilot with an explicit owner

Move to a limited pilot only when the sandbox evidence supports it. Keep the scope to a named workflow, named users, approved information classes, and a defined review path. The deal-team owner should be accountable for operational fit, while the designated reviewer remains accountable for each output’s acceptance. No pilot should authorize autonomous external contact, negotiation, transaction approval, client advice, or disclosure.

Track a small set of decision-useful measures: completion status, source-traceability rate, error categories, escalations, reviewer disposition, and exceptions caused by missing or conflicting information. Compare results with the baseline only when the task and quality threshold are comparable. Do not convert a pilot log into a claim of guaranteed accuracy, security, compliance, privilege, or time savings.

If the workflow touches regulated activity, communications, personal information, or a client engagement, pause for the appropriate internal and external review. FINRA specifically notes that obligations can apply whether a firm builds a tool itself or uses a third-party feature. [2]

Days 81 to 90: hold the review gate and choose the next safe step

At the end of the period, hold a documented gate with the implementation owner, workflow owner, reviewer, and relevant risk or compliance participants. Review the test log, baseline comparison, unresolved errors, data-handling evidence, training completion, and incidents or near misses. Ask whether the workflow stayed within scope and whether a qualified human could detect and correct the known failure modes.

Choose one of four outcomes: continue the same pilot with tighter controls, expand to a closely related internal task, redesign and retest, or stop. Each outcome should name the next owner, the evidence required, and the date of the next review. If the bank cannot explain what the tool saw, what the reviewer checked, or why an output was accepted, it is not ready for broader use.

NIST emphasizes ongoing monitoring, periodic review, clear roles, training, testing, and safe decommissioning as governance practices. [1] Treat the day-90 decision as the beginning of that review cycle, not as a finish line.

Make the plan usable without overstating the software

A practical implementation plan should leave behind an owner map, approved information classes, a workflow description, baseline notes, test cases, source-check instructions, a reviewer checklist, pilot logs, stopping criteria, and a dated decision record. Those artifacts let the bank improve the process without pretending that a model is an accountable professional.

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 this article, the 90-day sequence is an implementation framework for user-operated software and related workflows. It does not mean Acquivo represents a bank or client, provides legal or investment advice, or guarantees an implementation outcome.

The strongest first 90 days therefore produce disciplined evidence and a reversible decision. A bank can then expand only where the information boundary, source checks, accountable reviewer, and stopping conditions remain clear.