Choosing an AI implementation partner for an accounting firm is a due diligence exercise before it is a buying decision. 

If your firm handles customer information covered by the FTC Safeguards Rule, you may already have obligations around the service providers you select. That includes taking reasonable steps to choose providers capable of protecting customer information, requiring those protections in the contract, and reviewing the provider again over time.

Professional responsibility also stays with your firm. Under the AICPA Code of Professional Conduct, hiring an outside company to build or operate technology does not transfer responsibility for the professional services your firm delivers.

Most vendor-selection advice tells you to check references, review the contract, and compare capabilities. Those steps are useful, but they are not enough in the current AI market. Vendors can use similar language to describe very different technical capabilities, and product categories such as AI agent or AI automation no longer tell you much about what a provider can actually build.

A better evaluation process focuses on evidence instead of claims.

This article starts with the regulatory and professional requirements that can already shape vendor due diligence. It then covers six practical criteria: a prototype built on your own data, written assignment of the code, a SOC 2 report you examine rather than simply accept, a documented data exit, a named person accountable after launch, and production history that a reference can confirm.

Each criterion should leave you with something concrete: a document, a name, a date, a test result, or another piece of evidence that can be kept on file.

The Person Who Signs Off Carries the Exposure

The main reason to take vendor evaluation seriously is that hiring an implementation partner does not remove your firm's responsibility for the outcome. Because, if your firm falls within the scope of the FTC Safeguards Rule, the person designated to manage the information security program must report in writing to the governing body at least annually. That report covers areas including risk assessments, security events, and service provider arrangements.

For that reason, an AI implementation provider can become part of the governance process your partners are expected to review. The decision is not limited to whether the vendor performed well during a demonstration or offered attractive commercial terms.

Professional standards point in the same direction. In August 2026, the AICPA Professional Ethics Division published guidance on the use of AI in the profession and addressed the question of whether AI is developed internally or provided by an outside company. In either case, responsibility for the final work product remains with the accounting firm.

The same principle applies to competence, due care, confidentiality, and independence. Those responsibilities do not move to the vendor simply because the vendor built the technology.

That changes the question a COO should ask during evaluation. Instead of trying to identify the vendor that looks best during the sales process, ask what evidence would allow you to defend the decision a year later if the implementation fails or partners want to know why the firm selected that provider.

AI Vendor Due Diligence: What the Rules Already Require You to Check

Vendor due diligence is sometimes treated as a matter of internal judgment. But in several important areas, the work is already shaped by regulatory and professional requirements.

Under 16 CFR 314.4(f), the FTC Safeguards Rule sets out three obligations related to service providers. A covered firm must take reasonable steps to select and retain providers capable of maintaining appropriate safeguards for customer information, require those safeguards by contract, and periodically assess providers based on the risks they present and whether their protections remain adequate.

The third requirement is especially important because it makes vendor diligence an ongoing process. Signing the contract does not finish the assessment, and the provider must be reviewed again as its systems, controls, subprocessors, and the risks around the engagement change.

The Safeguards Rule also addresses externally developed applications. Section 314.4(c)(4) calls for procedures to evaluate, assess, or test the security of applications used to transmit, access, or store customer information.

For an accounting firm implementing AI, the practical implication is that if an outside partner builds a system and your firm plans to run client information through it, the firm needs a defined way to test the system before treating it as safe for production use.

The AICPA Code also matters when an implementation provider participates in work involving client information. The Code's definition of a third-party service provider can include outside entities and individuals that assist firms in providing professional services. Examples include services such as bookkeeping, tax return preparation, and consulting.

An implementation partner that accesses client ledgers or supports professional work can therefore create obligations around areas such as qualifications, supervision, client information, and confidentiality.

Two principles carry particular weight. The General Standards Rule requires firms to undertake work they can perform competently and with due professional care. When AI is part of the process, understanding what the technology can and cannot reliably do becomes part of that competence.

The Confidential Client Information Rule addresses the protection and disclosure of client information. If client information will pass through an implementation partner's systems, the data flow needs to be understood before the system is approved.

What each obligation looks like in a vendor conversation

Is client information used to train anything, and where is it stored?

A written answer and your firm's position on disclosure or consent

This article describes regulatory and professional requirements in general terms. Whether the Safeguards Rule applies to your firm, and what these requirements mean in your particular circumstances, should be confirmed with your counsel.

How to Evaluate an AI Implementation Partner: Six Criteria That Require Evidence

In our experience, the strongest evaluation criteria have one thing in common. It is that the vendor cannot satisfy them with a polished answer alone. Each should produce something you can inspect, test, keep, or verify independently.

1. A prototype built on your own data before you commit to a full build

A vendor demonstration can show that a system works under conditions the vendor controls. However, very rarely does it show that the same approach will work with your firm's data.

Demo environments are normally prepared in advance. The provider chooses the workflow, cleans the inputs, and removes many of the exceptions that make production systems difficult. But the main difference between demo and your case is that your accounting data will be different.

A real general ledger may contain years of inconsistent coding. Different partners may classify similar transactions differently. The chart of accounts may include legacy entries from acquisitions or system migrations. Historical data may contain missing fields, unusual naming conventions, and exceptions that nobody designed a demo around.

That is why the first meaningful test should use your own environment. Ask the provider to build a working prototype against your data for a fixed fee and by a fixed date before discussing a larger production build. The goal is to find out whether the vendor's approach still works when it meets your actual ledger and exceptions.

A provider that will only demonstrate its own prepared environment has not yet shown that it can solve your problem. A provider willing to prototype against real data is giving you evidence you can evaluate before making a larger commitment.

2. Written assignment of the code instead of a verbal promise that you own it

Accounting firms sometimes assume that paying for custom software means they automatically own everything that was developed. The contract needs to make that position clear.

Software commissioned from an outside developer does not necessarily become the client's property simply because the client paid for the work. Copyright and ownership questions can depend on the structure of the engagement and the written agreement between the parties.

For that reason, "you own the code" should be treated as a contract question rather than a sales statement.

Ask the vendor to identify the clause that assigns the relevant rights to your firm. Have your counsel review that clause before signature. The agreement should also make clear what applies to code created specifically for your project and what applies to software, libraries, frameworks, or other intellectual property the provider already owned before the engagement.

It is also worth asking what happens if the support relationship ends. Your ability to operate, modify, or move the system should not become unclear simply because you stop purchasing ongoing services from the original implementation partner.

The exact ownership structure should be confirmed by counsel, particularly where pre-existing components, third-party software, or work-for-hire questions are involved.

3. A SOC 2 report you actually examine

Asking whether a vendor has SOC 2 is a useful starting point, but a yes-or-no answer does not tell you enough about the quality or relevance of the report.

In May 2026, the AICPA Peer Review Board issued guidance after observing SOC 2 engagements that were not designed around the individual service organization. According to the guidance, some engagements used identical risk assessments, sample sizes, and testing procedures across unrelated clients. The AICPA characterized such engagements as nonconforming.

That means the presence of a SOC 2 report should begin the security conversation rather than end it.

Start by asking which firm performed the examination and whether that firm participates in the appropriate peer review process. Then check the period the report covers and the systems included in scope.

Scope matters because the report only provides assurance over the systems and controls it actually examines. A vendor may operate several environments, while the system that will process your client information sits outside the part covered by the report.

You should also read the exceptions section instead of relying on a badge, certificate, or summary page. Exceptions do not automatically mean a vendor is unsafe. They tell you where testing found issues, how serious those issues were, and what the organization did about them.

The goal is not to find a report with no questions. It is to understand what was actually examined and whether that examination is relevant to the system your firm plans to use.

4. A documented way to get your data and system out

Vendor continuity should be designed into the engagement rather than treated as an assumption about how long the provider will remain in business.

Botkeeper illustrates why. The company closed in February 2026 after eleven years serving accounting firms, and customers were told to export their information before access ended. The useful question is what happens to your operation if the provider becomes unavailable for any reason.

Before signing, ask what information your firm can export, which formats are available, how much notice is required, and whether the export includes configuration or other information needed to move the workflow elsewhere.

Also establish who controls the environment where the custom system runs.

If the provider owns the only cloud account, controls the credentials, and hosts the only usable copy of the system, changing vendors can become a technical migration project at the exact moment you need continuity.

If your firm owns the relevant code and controls the cloud environment and credentials, the implementation partner becoming unavailable is still inconvenient, but it is much less likely to stop the workflow entirely.

The exit path should therefore be documented before you need it.

5. A named person accountable when the output is wrong

.Before implementation, ask who is responsible when the system produces a material error in production. You should be able to identify a specific person or role rather than being directed only to a general account manager or support queue.

Consider what that looks like during a real close. If the system misclassifies a batch on the second day of close and your senior staff are correcting entries manually, somebody needs to own the technical response, investigate what happened, and decide how the issue will be resolved.

Ask who that person is before go-live.

Then ask whether the same level of accountability continues after implementation. Many projects receive senior engineering attention during the build and then move into a different support structure once the system launches.

That handoff is worth examining during vendor evaluation. You need to know who will understand the system after go-live, who can make decisions during an incident, and how quickly the issue can reach someone with enough technical context to resolve it.

A named escalation path makes accountability visible before an error occurs.

6. Production history that a reference can confirm

The number of pilots a vendor has completed tells you less than how long comparable systems have been running in real production environments.

Pilots are controlled exercises. Production exposes the system to real users, changing data, unusual exceptions, integrations, deadlines, and the operational pressure that appears after launch.

Ask how many months comparable systems have been live. Then ask what went wrong during the first ninety days and what the vendor changed in response.

A provider with meaningful production experience should be able to discuss early mistakes. Complex software systems rarely enter production without revealing assumptions that need to be adjusted.

That is why a useful reference question is not simply, "Were you happy with the vendor?"

Ask a firm of similar size and structure what the vendor got wrong during implementation or early production and how the team responded.

A candid answer gives you more information than another customer logo. It shows whether the provider recognizes failures quickly, communicates clearly, takes responsibility, and improves the system after launch.

The six criteria

Questions to Ask an AI Consulting Firm on the First Call

You do not need to complete the entire due diligence process before deciding that a provider is not a fit. Here are six questions that can reveal a great deal during the first conversation, and they can usually be covered in about twenty minutes.

1. Will you build a working prototype using our own data first, for a fixed fee and by a fixed date?
2. Which contract clause gives our firm ownership or the agreed rights to the code you create for us?
3. Who performed your most recent SOC 2 examination, what did the scope cover, and can we review the exceptions?
4. If we ended the relationship, what exactly could we export, and who controls the cloud environment and credentials?
5. Who is accountable for output quality and technical problems after the system goes live?
6. Which comparable system has been running in production the longest, and what went wrong during its early months?

Pay attention not only to the answers but also to the form those answers take. Some questions should produce documents, contract language, report details, names, dates, or references that can be checked.

If every answer remains a verbal assurance, you still have very little evidence on which to base the decision.

How Codebridge Approaches This

We built our engagement model around many of the same questions because they are the questions clients ask when they are responsible for putting an AI system into a real professional-services workflow.

Codebridge came out of KPMG, so our approach to AI implementation developed from the professional-services side rather than from a software product model. We deliver custom AI systems as an engagement, with the aim of giving the firm control over what has been built rather than creating another permanent software dependency.

We begin with a fixed-fee, three-week discovery that includes a working prototype using the client's own data. The purpose is to answer the difficult question early: whether the firm's actual ledger, workflows, integrations, and exceptions are workable before anybody commits to a larger build.

Production work is scoped to a fixed price and a fixed delivery date. The ownership arrangement is documented in writing, along with the environment in which the system operates. That structure is intended to reduce the firm's dependence on Codebridge remaining the only party capable of operating the system.

Clients also work with named engineers rather than moving immediately into a general support tier after launch. The people responsible for the implementation remain visible when production questions appear.

We would rather an accounting firm apply the six criteria in this article to Codebridge than rely on our description of ourselves. Ask us to show how ownership is documented. Ask about the relevant security evidence. Ask who will be accountable after launch, and ask what has gone wrong on previous implementations and how we handled it.

If you want to find out whether your workflow is suitable for a three-week prototype, book a 30-minute call and we will assess whether that approach fits the problem.