Auditing AI: what to ask before the business deploys it.
AI tools are entering finance, procurement and customer functions faster than the controls around them. A practical note on what internal audit should ask before, during and after deployment.
1. Where AI has already arrived.
Ask a CFO in 2026 whether the company uses AI and the answer is often "not really". Then look closer. The accounts payable team runs invoices through an OCR tool that reads and codes them. The sales team uses a chatbot on the website that quotes delivery timelines. HR screens CVs with a scoring plug-in. The treasury desk has a cash-forecasting model that a vendor updates quarterly. Somebody in marketing has a paid subscription to a large language model and pastes customer data into it.
None of this was approved as an "AI project". It arrived as features inside software the company already paid for, or as tools individual teams adopted on their own. That is the first audit finding in most organisations: there is no inventory of where AI is making or shaping decisions.
2. Why this is an internal audit question.
Three reasons this sits squarely within internal audit's remit rather than only with IT.
First, AI tools now touch controls that internal audit already tests. If a model decides which vendor invoices need manual review, the model is part of the payables control. If it recommends a credit limit, it is part of the receivables control. When internal audit reports on the operating effectiveness of Internal Financial Controls under section 143(3)(i) of the Companies Act, 2013, it is reporting on those models too, whether or not anybody wrote that down.
Second, the data going in is often personal data. The Digital Personal Data Protection Act, 2023, and the rules under it, put obligations on the company as a data fiduciary regardless of whether a human or a model processes the data. Pasting a customer list into a public AI tool is a data transfer, and it is rarely covered by the consent that was collected.
Third, the audit committee is beginning to ask. Board agendas that once had "cyber" as a standing item now have "AI" next to it, and the audit committee wants to know who has looked at it.
The question is not "does the company use AI". It is "which decisions does the company no longer make itself, and who checked the thing that makes them".
3. Before deployment: the questions that matter.
When a business unit proposes an AI tool, or when internal audit discovers one already in use, the following questions have proved more useful than a long technical questionnaire.
What decision does it make or influence, and what happens if it is wrong? A model that drafts email replies has a different risk profile from one that approves refunds. Classify by consequence, not by technology.
What data goes in, where does it go, and who else can see it? Vendor terms matter here. Many consumer-grade AI tools reserve the right to train on inputs. That is incompatible with confidential client or customer data.
Is there a human in the loop, and is that human actually looking? A control that requires a reviewer to approve the model's output is only a control if the reviewer has the time, the information and the authority to disagree. Approval rates of 99.8 percent usually mean nobody is reading.
Can the output be explained to an auditor, a regulator or a customer? If the tool declines a loan or flags an employee, someone will eventually ask why. "The model said so" is not an answer the company can give.
Who owns it? Every AI tool should have a named business owner, a named technical owner, and a review date. Tools without owners are the ones that keep running after the person who set them up has left.
4. During and after: what to test.
Once a tool is live, the testing looks familiar to anyone who has audited an automated control, with a few additions.
Test the inputs. Full-population analytics work well here: compare the data the model actually received against the data it was designed for. Drift happens quietly, for example when a new product line or a new GST rate code appears that the model has never seen.
Test the overrides. Pull every case where a human overrode the model, and every case where the model's output was accepted without review. The first list tells you where the model is weak. The second tells you whether the human control exists at all.
Test the outcomes against a baseline. If the invoice-coding tool was meant to reduce errors, sample its coding against the old manual process. If the credit model was meant to reduce bad debts, look at the ageing of accounts it approved.
Test access and change. Who can change the prompt, the threshold or the training data? Is a change logged? Was the last change tested before it went live? This is ordinary change-management testing applied to a new object.
Test the exit. If the vendor disappears or the tool is switched off tomorrow, can the process run manually, and does anyone still know how?
5. Reporting to the audit committee.
The report that lands well is short. One page listing the AI tools in use, the decision each one influences, the owner, the risk rating, and whether a control review has been done. A second page with findings in the usual grammar: observation, root cause, risk, recommendation, management response, owner, target date.
The audit committee does not need to understand how a transformer model works. It needs to know which decisions have been delegated to software, whether somebody competent has looked at that software, and what the company would do if it failed.
This article is general in nature and does not constitute professional advice. Readers should seek specific advice before acting on any matter described here.
This website is meant for information purposes only. The contents are made available on a pull basis and are not intended to solicit work or advertise.
Frequently asked
Does internal audit need data science skills to do this?
Not to start. Most of the questions above are governance and control questions. Where a model is material, for example in credit decisions or fraud detection, the internal auditor can bring in a specialist for the technical validation, in the same way a statutory auditor uses an IT specialist for complex systems.
Is there an Indian standard or framework internal audit should follow?
There is no AI-specific standard yet from ICAI or SEBI. The relevant framework is the existing one: Internal Financial Controls under the Companies Act, 2013, the DPDP Act, 2023 for personal data, sector rules where they apply (for example RBI directions for regulated entities), and the Standards on Internal Audit issued by ICAI for how the work is documented and reported. Global frameworks such as the NIST AI Risk Management Framework are useful reference material.
What about staff using AI tools on their own?
Treat it as a policy and awareness matter first. A short, clear acceptable-use policy that names the tools permitted, the data that may never be entered, and the approval route for new tools removes most of the risk. Internal audit can then test compliance with that policy.
