ISO 42001 Audit Evidence: What an AI Gateway Record Proves for Your AIMS
ISO 42001 certifies an AI management system, and a certification audit tests whether your controls operate and asks for evidence. Most AIMS documentation describes policy for AI use without a record that a given model call was governed. This piece maps AI gateway records onto the ISO 42001 controls an auditor samples, so operational control over AI use produces artifacts instead of assertions.
An ISO/IEC 42001 certification audit does not stop at reading your AI policy. A certification auditor tests whether each control in your AI management system operates, and asks for evidence a sample can be pulled from. ISO 42001 was published in December 2023 as the first management-system standard for AI, and it inherits the audit posture of ISO 27001: documented controls, operational records, and a sampling exercise where the auditor picks a date and asks you to show the control ran. The gap shows up at one control in particular, the operational control over how AI systems are actually used, because most AIMS documentation describes a policy for AI use without a record that any specific model call was governed by it.
I want to walk through which ISO 42001 controls an AI gateway record maps onto, so operational control over AI use produces artifacts an auditor can sample rather than statements they have to take on trust.
The control that asks for a record you probably do not have
ISO 42001 Annex A covers the AI policy, roles and resources, impact assessment, the AI system life cycle, data for AI systems, information for interested parties, and the operational use of AI systems. The operational-use controls expect an organization to define how AI may be used and then to run that use under control. When an auditor reads "the organization controls how its AI systems are used" and asks to see it for a specific week, the honest answer at most organizations is a policy document plus application logs that never recorded who sent what to which model.
That is a control described but not evidenced. The impact assessment exists as a PDF, the AI policy names acceptable use, and the actual model traffic runs under a shared API key with no per-user record. My view is that the operational-use controls are the ones that decide a 42001 audit, because they are where the management system meets the live system, and they are the hardest to fake after the fact.
Mapping gateway records onto the AIMS controls
The mapping becomes direct once each model call produces an identity-bound record.
For operational planning and control of AI use, the control expects defined rules applied to real usage. An enforcement gateway applies per-route and per-role policy to every model call and writes a per-decision record naming the identity, the policy version, and the outcome. That record is the evidence the operational control ran on the day the auditor samples.
For the AI system life cycle and monitoring, the standard expects the organization to observe its AI systems in operation. Per-decision records carry identity, data classification, and result for each call, and they feed the same review the auditor wants to see evidence of. For third-party and data controls, the record shows which model provider received which class of data under which policy, which is the artifact that supports the third-party relationship control instead of a vendor questionnaire filed a year ago.
Evidence an auditor trusts is produced outside the audited system
A certification auditor discounts evidence the audited application could edit. Logs written by the same service that made the model call sit in a store that service controls, and they document that service's own behavior, which weakens them. A gateway record is produced by the enforcement point rather than the calling application and committed before the model responds. That independence is the property I would insist on before calling a record audit-grade, and it is what separates ISO 42001 evidence from a screenshot of a config. It also maps cleanly onto the logging expectations already familiar from ISO 27001 and how the two standards overlap.
DeepInspect
This is the gap DeepInspect closes for an AIMS. DeepInspect runs as a stateless proxy between your applications, staff, agents, and any LLM. It binds a named identity to each model call, applies per-route and per-role policy with detection and redaction of sensitive data in the prompt, and writes a tamper-evident per-decision record holding identity, role, policy version, data classification, outcome, and timestamp.
Those records extend your operational-use, monitoring, and third-party controls to model traffic, and give a certification auditor artifacts to sample that were produced independently of the applications they document. DeepInspect does not run your ISO 42001 program or write your Statement of Applicability; it produces the operational evidence the controls call for. To map your model traffic onto your AIMS controls, book a compliance mapping session.
Frequently asked questions
- Does ISO 42001 require logging of AI use?
ISO 42001 does not prescribe a specific log format, but its operational-use and life-cycle controls expect an organization to control and monitor how its AI systems run, and a certification auditor asks for evidence that control operated. In practice that means a record of AI use exists and can be sampled. A per-decision record of model calls, carrying identity and policy state, is the concrete artifact that satisfies "show me this control ran" for the operational controls, which is otherwise the hardest part of the standard to evidence.
- How is ISO 42001 evidence different from ISO 27001 evidence?
ISO 27001 evidence covers information-security controls across your systems, and much of it carries over. ISO 42001 adds controls specific to AI management: impact assessment, AI system life cycle, and the operational use of AI. The new evidence an auditor asks for describes what an AI system did with a specific request, which most 27001 evidence does not capture. A gateway record of model calls fills that AI-specific gap while slotting into the logical-access and monitoring evidence your 27001 program already produces.
- Can one AI gateway record serve both ISO 42001 and SOC 2?
Yes. The same per-decision record naming identity, data classification, policy version, and outcome maps onto ISO 42001 operational-use controls and onto the SOC 2 logical-access and monitoring criteria at the same time. Producing AI access evidence once and mapping it to multiple frameworks is the efficient path, which is why the same record also appears in SOC 2 AI gateway evidence and in EU AI Act Article 12 record-keeping.
- Where do impact assessments fit if the gateway logs calls?
The impact assessment is a design-time control and stays a separate artifact. The gateway record is a run-time control that shows the assessment's conclusions were enforced, for example that a system classified higher-risk only accepted calls from authorized roles with sensitive data redacted. The two work together: the assessment states the intended controls, and the per-decision records prove those controls operated across the audit period rather than existing only on paper.