Algorithm Integrity: Audit vs Review

We don’t need to always be precise with our terminology.

But when you’re commissioning an assessment to determine whether your algorithm has integrity, you need to know what to ask for, to make sure that you get what you want.

So understanding the distinction between an audit and a review is important. But there are no standardised definitions, so this is often misunderstood. Or understood differently by different people.

This article explores this in more detail, then explains what to focus on regardless of the terminology used.

Reviews

A review typically aims to identify potential issues before they become problems.

They are sometimes less formal and may not always follow a standardised methodology.

They include:

1. Self-assessments: Internal teams evaluate their own AI systems for potential risks or areas of improvement.
2. Peer reviews: Colleagues or other teams within the organisation examine the AI system.
3. Informal external reviews: Consultants or experts provide feedback without following a strict audit protocol.
4. Agreed upon procedures: More formal, but not full “audits”. They involve specific procedures as agreed. Usually conducted by an external party, but could be internal. Result in a report of findings, without an opinion.
5. Internal audits: Conducted by teams within the organisation that are dedicated to conducting internal “audits”. Can be more formal than other types of reviews. In practice, may be considered “audits”, as the name suggests. Could also be agreed upon procedures. May result in a conclusion, but not necessarily for external distribution.

In short, any type of assessment can be called a review.

In fact, an audit could be considered a special type of review, with a distinct type of output.

Audits

An audit is structured and most often conducted by independent external parties. When conducted by external parties, they are sometimes called external audits.

Before we get into what an external audit is, let’s explore a couple of other types of “audits”.

Internal Audits

An audit is sometimes performed by independent internal auditors, with opinions/conclusion and reports that may be distributed. However, as outlined earlier, not all internal audits are audits, and most are other types of reviews.

Adversarial Audits

Another type of review that is sometimes called an audit. These are performed without a contract in place, usually by non-profit entities, without engaging with the entity. Beyond AI/algorithm reviews, these are not typically called “audits”. The terminology is loose – for example, the EU AI Act expects developers to include “adversarial testing” of their own systems. Importantly, you don’t typically commission an adversarial audit of your own systems, by definition, so let’s ignore this item for now.

This all becomes quite confusing, so let’s explain what a “real audit” comprises.

External Audits

• The most widely recognised reference to “Audits”.
• Performed with a contract or agreement in place between the entity and the auditor.
• Performed by independent entities who offer auditing-as-a-service. This includes traditional consulting firms and specialised auditing companies.
• In the public sector, can be performed by supreme audit institutions – national audit offices or state audit offices.
• Often performed for regulatory compliance or public accountability.
• Typically more rigorous and impartial.
• The result is an opinion or conclusion, and often distributed outside of the organisation being audited.

The last point is important. An audit results in an opinion, often with a report that can be distributed.

Key Differences

While audits are really just a special type of review, there are some key differences between “audits” and other types of reviews:

1. Formality: Audits follow structured methodologies and adhere to specific standards or regulations. Other types of reviews can be less formal.
2. Independence: Audits require independence and objectivity. Other types of reviews can be undertaken internally.
3. Scope: Audits tend to be comprehensive, including technical, ethical, and governance aspects. Other types of reviews may focus on specific areas of concern.
4. Documentation: Audits require extensive documentation and evidence gathering. Other types of reviews may be less rigorous.
5. Result: Audits produce opinions or conclusions. Other types of reviews may produce facts, or findings, without an opinion.
6. Deliverable: Audits result in formal reports and are usually used for compliance or certification purposes. Other types of reviews typically lead to internal recommendations, with reports for internal use.

Again, the result and deliverable are the most important distinctions.

Audits produce formal reports, with opinions or conclusions. In some cases, these reports are shared with other organisations – like regulators, clients, or even out in the public domain.

Bottom line

If you forget the rest of the complexities in this article, make sure that the deliverable is clearly understood and documented before the assessment starts.

Whatever you decide to call them, it is useful to know what to ask for. Regardless of what term you use to describe the assessment, make sure that the nature of the result and deliverable are clear, and documented.

For instance, a bank commissioning an evaluation of its AI-driven loan approval system would likely require an audit if the report is to be shared with regulators. Here, the bank and auditor will agree, upfront, what to opine or conclude on, and who the report may be distributed to. This agreement will be in writing.

On the other hand, an insurance company looking to improve its internal underwriting process might opt for a less formal review. Here, the insurer and the reviewer will agree, upfront, that the report will contain facts or findings, and will not be for distribution. This may also be in writing. (Or there could be no report.)

If you want a formal opinion in a report that can be shared, you probably want an “Audit”.

In most other cases, a different type of review will meet your needs.

Regardless of what terminology you use, make sure that the deliverable is clearly understood, and documented.

• Will there be a report?
• Will the report detail findings, facts, an opinion or a conclusion?
• Will the report be for internal use, for a select pre-defined set of stakeholders and/or third parties, or for publishing in the public domain?

Documenting the answers to these questions, upfront, will help ensure that you get what you asked for.

Disclaimer: The information in this article does not constitute legal advice. It may not be relevant to your circumstances. It was written for specific algorithmic contexts within banks and insurance companies, may not apply to other contexts, and may not be relevant to other types of organisations.