Security audits and AI: traceable decisions for the auditor

Two different subjects hiding behind the same search. Auditing with AI means using agents to prepare the campaign, generate questionnaires, cross-check evidence and draft findings: the audit method does not change, the collection work speeds up. Auditing AI means taking an artificial intelligence system as the object under audit and examining its data, its access rights, its human oversight and its effects. Both produce findings you handle the same way, but they do not rest on the same reference frameworks.

Three routes lead to an AI audit. Regulation first: the European AI regulation requires providers of systems classified as high risk to run a conformity assessment, on a staggered application timetable. Contracts next: a large customer or a public buyer increasingly asks for a security review before opening its data to a service that embeds a model. Certification finally: aiming at ISO/IEC 42001 means having your AI management system audited by a certification body. Many teams still start without any obligation at all, because AI reached production faster than governance did.

Not in the sense people usually mean. No body issues a company a certificate stating that its AI has been audited: the certifications carrying that name qualify auditors, not systems. What binds an organisation sits elsewhere. ISO/IEC 42001 is a requirements standard, therefore certifiable, and covers the artificial intelligence management system rather than a single model taken in isolation. The European AI regulation rests on a conformity assessment, run internally or through a notified body depending on the case, then on CE marking for high-risk systems.

The scope reaches well beyond the model. A serious audit looks at where training and context data comes from, who can query the system and with what rights, how secrets and API keys are protected, what is logged and for how long, and which data leaves the organisation for a third-party provider. On top of that sit the risks specific to applications built on language models, prompt injection first among them, along with the supply chain of models and libraries. The security recommendations published by ANSSI, the French cybersecurity agency, on generative AI systems give a workable starting point.

Yes, and the audit does not stop at launch. Before production, the review covers the use case, the data exposed, access rights, output safeguards and the level of human oversight planned: that is the point where fixing something costs least. Afterwards the system keeps moving, because the model changes version, context sources widen and real use drifts away from what was designed. An AI audit therefore belongs in the recurring control plan, not in the launch checklist.

No, and aiming for that would be a mistake of method. An agent takes the mechanical share of the campaign: gathering evidence, spotting the gap between a policy and the way it is actually applied, preparing questions, drafting candidate findings. What stays with the auditor is exactly what matters: qualifying the gap, weighing how serious it is, signing it off. A finding then has to hold up in front of a committee or a certification body, hence a practical requirement: every item an agent produces must be tied back to its source and approved by a named auditor.

Because a campaign is judged on what it leaves behind. A finding is worth something only when it is tied to the control tested, to the dated evidence behind it, to the risk it sheds light on and to the corrective action that closes it, with an owner and a due date. In a workbook those ties are held by hand: after the first reorganisation, the next auditor starts from a blank page instead of picking up where the previous campaign stopped. A dedicated tool keeps that thread and can say, at any given date, what is still open. In Vailor, each control is linked to its evidence and its actions, and every decision is recorded in an audit log where no application feature can delete an entry.