Audit Evidence for AI Systems: What Auditors Ask For and How to Build It In
Overview
When an AI deployment is audited – by an internal audit team, a statutory auditor, a sector regulator or a customer’s vendor-risk assessor – the questions are rarely about model quality. They are about evidence: who accessed the training data, who approved this model version, where are the logs, how long are they kept, and can you prove erasure happened. Teams that treat evidence as a by-product of good engineering pass these reviews at low cost; teams that must reconstruct history from ticket systems and shell histories pay heavily and still look weak. This article lists what auditors actually request from AI systems running on GPU infrastructure in India, and how to configure clusters so the evidence accumulates from day one.
Key takeaways
- Auditors ask for artefacts, not assurances: access records, change approvals, lineage, retention proof and incident history, each tied to named individuals and timestamps.
- Four logging layers matter on a GPU platform: infrastructure access, data access, job and pipeline execution, and model lifecycle events.
- Indian retention anchors include the CERT-In direction to maintain logs for 180 days and the DPDP Rules’ requirement to retain specified logs, as published, for at least a year.
- Lineage answers two audit questions at once – what data trained this model, and which model version produced this output – and cannot be reconstructed afterwards.
- Evidence-by-design costs little at build time: central log shipping, immutable storage, registry-based promotion and a quarterly self-audit close most gaps.
What an auditor actually asks for
Across DPDP-driven reviews, RBI-supervised entities and enterprise vendor assessments, the request list converges on a familiar set: an inventory of AI systems and the personal data they touch; access control matrices with joiner-mover-leaver evidence; privileged access records for the GPU environment; change and release history for models in production; dataset documentation and consent basis; security-testing and patching records; breach and incident logs with response timelines; and retention and erasure evidence. The BFSI variant of this list is examined in BFSI Private AI GPU Server Controls and Auditability. Notice what is absent: nobody asks for your accuracy metrics first. They ask who could touch what, and whether you can prove it.
The four logging layers of a GPU platform
Evidence is only as good as the layer it is captured at, and AI platforms need four:
- Infrastructure access. SSH and console sessions, sudo events, BMC access, VPN and jump-host records – centrally shipped, tied to individual identities, never to shared accounts.
- Data access. Reads and writes against datasets, object buckets and RAG indexes, including service accounts. This is the layer most GPU shops skip, and the one DPDP-style security-safeguard questions land on.
- Job and pipeline execution. Scheduler records – who submitted which job, on which nodes and GPUs, against which dataset version, with what container image digest. Slurm accounting or Kubernetes audit logs largely provide this if retained.
- Model lifecycle. Registration, evaluation, approval, promotion, rollback and retirement events for every model version, with named approvers.
Lineage: the record you cannot reconstruct
Two audit questions require lineage: “what data went into this model?” and “which model produced this decision?” A minimal lineage record links dataset version (content hash, source, consent basis, transformation history) to training run (code commit, container digest, hyperparameters, job ID) to model artefact (weights hash, evaluation results, approver) to deployment (endpoint, dates, config). Every element exists naturally at training time and none can be recovered reliably six months later. Registries and experiment trackers make this cheap; the discipline is refusing to let any production model exist outside the registry – covered in depth in the companion piece on model and data governance in this category.
Retention: how long, and where
Retention duties layer up in India. The CERT-In directions of 2022 require covered entities to maintain logs of their ICT systems for a rolling 180 days, to be produced on demand, as published by CERT-In. The DPDP Rules 2025 list logging and monitoring among reasonable security safeguards and provide, as published, for retaining specified logs for at least one year. Sector overlays can extend this – RBI-supervised entities carry their own record-keeping expectations, and contracts often demand longer. The pragmatic design: one year of searchable retention for the four layers above, with legal-hold capability, stored on infrastructure whose location is consistent with your residency posture – see Data Residency Architectures for AI. Verify current rule text before fixing retention budgets; this is planning guidance, not legal advice.
Evidence-by-design beats reconstruction
Building evidence in is mostly configuration, not product purchases: enable and ship scheduler accounting; put datasets behind versioned, access-logged storage rather than loose NFS exports; make the model registry the only path to production; write approval gates as pipeline steps that record the approver; and store logs on write-once or object-locked storage so their integrity survives an incident. Then rehearse: run a quarterly internal pull of five audit questions – pick a production model and produce its lineage, its approvers, its data access records – and fix whatever took longer than an hour. Under the DPDP Act’s penalty structure, where security-safeguard failures carry the highest cap, this evidence is also your primary defence exhibit, as discussed in The DPDP Act for AI Infrastructure.
Auditor questions mapped to evidence artefacts
| Auditor question | Evidence artefact | Produced by |
|---|---|---|
| Who can access training data? | Access matrix plus data-layer access logs | IAM review + storage audit logging |
| Who approved this model for production? | Registry promotion record with named approver | Model registry / CI gate |
| What data trained this model? | Lineage record: dataset hash, run ID, commit | Experiment tracker + registry |
| Can you detect and investigate a breach? | Centralised logs, alert rules, incident records | SIEM / log pipeline |
| Was erased data actually erased? | Erasure tickets linked to dataset versions and backup cycles | Data governance workflow |
Frequently asked questions
How long must we keep logs in India?
The CERT-In directions require 180 days of ICT system logs for covered entities, and the DPDP Rules provide, as published, for at least one year for specified logs. Sector rules and contracts can extend this, so confirm against current texts.
Do we need special AI audit tooling?
Rarely at the start. Scheduler accounting, storage access logs, a model registry and central log shipping cover most requests. Specialised governance tooling helps at scale but does not replace the underlying records.
What is the most common evidence gap?
Data-layer access logging. Teams log SSH but not dataset reads, so they cannot answer who accessed personal data – the exact question DPDP-driven reviews ask first.
Should logs live on the GPU cluster itself?
No. Ship them to separate, access-controlled storage – ideally immutable – so a cluster compromise or failure does not destroy the evidence you need to investigate it.
How do we evidence erasure from trained models?
Record which dataset versions contained the erased data and which model versions consumed them, then document the chosen remedy – retraining, filtering or scheduled model retirement – as an auditable decision.
Ready to deploy?
Talk to an RDP architect about power, cooling and lead time.