AI Audit Tools and the Independence Gap Nobody Fixed

This article will count 0.25 units (15 minutes) of unverifiable CPD. Remember to log these units under your membership profile.

The AICPA has proposed changes to its Code of Professional Conduct dealing with independence for CPA firms on private equity - when take money from outside investors or work closely with outside vendors. The proposal exists because private equity has been buying into US accounting firms at speed, which raises an obvious question: if an investor owns part of your firm, and that investor also owns businesses you audit, are you still independent? It also, quietly, governs your software vendors, even though the software industry did not seem to notice.

On 31 August, Accounting Today reported on the 81 comment letters filed on the proposal. Dozens came from state boards of accountancy but none of them came from a technology company. That silence is the story.

Can licensing an AI tool become an independence issue?

Christina Ho, a former board member of the PCAOB and now chief assurance officer at assurance technology firm Oath Verified, filed a second comment letter making the point. Her argument is that even in the revised draft, it is still unclear when licensing an AI audit tool becomes an independence conflict. And the reason software companies have not engaged is that the rule reads, on its face, as being about private equity roll-ups. So the vendors assume it has nothing to do with them.

Ho's broader observation is the one worth keeping. Auditing used to mean a person checking another person's work. It is becoming a machine checking a machine, when independence rules do not cover this type of arrangement.

The question nobody has answered, here or there

Lets look at a simple example. Your practice licenses an AI review tool. The vendor is a normal software business, so it sells to whoever will buy. One of its customers is your client, who uses the same platform to prepare the figures you are reviewing. Now the same software vendor sits on both sides of the engagement. Its model produced the output your client relies on, and its model is helping you test that output. You are paying the vendor and so is your client.

Is that an independence problem? A self-review threat? A familiarity threat? Nothing at all?

If we add a second layer where the vendor gives your firm a discount, a revenue share for referrals, or free licences in exchange for using your client data to improve the model. Now there is a financial relationship with a party that has a commercial interest in the outcome of your work.

The honest answer is that nobody has settled this problem yet. The IESBA technology revisions tell you that you remain accountable for outputs you cannot explain, and they name automation bias as a threat to objectivity. They do not tell you where the vendor relationship sits.

What to do about it

You cannot wait for a standard. So document your own position now, before somebody asks. For every tool that touches client work document: who owns the vendor, whether that vendor also serves your client, what you pay and whether any part of that payment is contingent on volume or referrals, and whether the vendor can use your client data to train its models.

Then ask whether an informed third party would think any of it compromises your objectivity. That is the same test the Code already applies to every other relationship. Nothing about it needing a software chapter stops you applying it today.

If you find something uncomfortable, disclose it in writing to the client and record your reasoning. Documented judgement is a defence. Silence is not.

👉 Join CIBA and we'll help you build a technology independence policy your practice can actually stand behind.