An AI audit is new enough that most organisations facing one have no idea what will be asked, and the answer is much more mundane than the subject suggests. It is a management system audit with an unusual object. The auditor wants an inventory of the AI systems in use, a record of who decided each one was appropriate and on what basis, evidence about the data behind it, a description of how a human stays meaningfully in the loop, and monitoring that would notice the system drifting. Every one of those is a document with a date and an owner, and the checklist below is those documents in the order they will be asked for.
The inventory, which almost nobody has
The first request is a list of AI systems in use, including the ones bought as features inside other software and the ones a team started using without a procurement process. Building it is the largest single piece of work and it usually finds systems the organisation did not know it was running. For each entry: what decision it informs or makes, who owns it, what data it uses, whether it faces customers or staff, and whether a person reviews its output before anything happens. An audit against an incomplete inventory is an audit of the tidy half.
Impact assessment and the decision to deploy
For each system that matters, the auditor looks for a record of the assessment made before deployment: what could go wrong, who could be affected, what was done about it, and who signed off. The common failure is that this thinking happened in meetings and was never written down, so the organisation cannot show that the risk was considered even though it was. A short assessment written at the time is worth more than a thorough one reconstructed afterwards, and reconstruction is visible to an auditor from the dates.
Data, provenance and the questions you must be able to answer
Where the data came from, whether the organisation had the right to use it that way, what personal data is involved, how long it is kept, and whether any of it leaves the organisation when the system is used. For bought-in systems this becomes a supplier question, and the evidence is the supplier's documentation plus your own assessment of it. Auditors are not expecting a research paper. They are expecting the organisation to know what it is sending where, and to have decided that deliberately.
Human oversight and monitoring after go-live
Oversight is only real if the person reviewing has the information, the time and the authority to disagree with the system. Evidence is the procedure, the training of the reviewers, and cases where the human decision differed from the system output. Monitoring is the other half: what is measured after deployment, at what frequency, what threshold triggers a review, and what happened the last time it did. A system deployed and never re-examined is the finding that will be raised, and it is the easiest one to prevent.
Questions people ask about ai audit checklist
Who audits AI use in a normal business?
Usually the same internal audit or quality function that covers other management systems, sometimes a customer, and increasingly a certification body where the organisation has chosen to certify its AI management system.
Do we need a separate AI policy?
You need a decision record and an owner. A short policy that says which systems are permitted, who approves new ones and what has to be assessed first does the job. A long policy nobody consults does not.
What if we only use AI features inside tools we bought?
They belong in the inventory. Bought-in features are where uncontrolled use concentrates, precisely because nobody ran a procurement process for a feature that appeared in an update.
How does this relate to our existing information security audit?
It overlaps on data and access and adds questions about how outputs are used and overseen. Running the two together is efficient, as long as the AI-specific questions are not lost inside a security checklist that never asks them.