12.3 AI-Specific Evidence: Model Cards, Lineage, Logs, Impact Assessments

12.3 AI-Specific Evidence: Model Cards, Lineage, Logs, Impact Assessments

Auditor focus: ISO/IEC 42001 is a management system standard, but its operational proof often sits in AI lifecycle artifacts. Learn what “good enough” looks like for each artifact type, which requirements it supports, and how to test sufficiency without becoming a full-time ML researcher.

Why AIMS evidence looks different

AIMS audits still need policies, procedures, and training records—but trustworthiness (reliability, safety, security, privacy, fairness, transparency, accountability) is proven through system-specific technical and socio-technical records. An AI policy PDF plus org chart is not enough. Names vary; map substance to criteria.

Artifact catalog and mapping

Mappings are risk- and SoA-dependent. Always tie evidence to the organization’s applicable controls and documented processes—not to an invented universal checklist.

Model and system cards

Model cards (and broader system cards) summarize purpose, evaluation, and limits. Test: existence for sampled systems (not only demos); intended use vs. real product behavior; version binding to production; honest limitations; and operational linkage—monitoring and oversight claimed on the card must exist live. A glossy marketing card without the described tests is weak control evidence and a transparency red flag.

Training data documentation and lineage

Data documentation should answer: Where did data come from? Under what rights? How labeled? How quality-checked? How often refreshed? What sensitive attributes are present or proxied?

Lineage connects raw sources to training sets, features, and model versions. Sufficiency tests:

• Can the organization identify which data version trained which model version?
• Are exclusion rules (e.g., remove minors, remove expired consents) evidenced in pipeline configs or jobs—not only in a slide?
• When a data defect is found, can they trace affected models and open impact/incident handling?

Missing lineage for a high-impact model is rarely a minor paperwork nit; it undermines corrective action, reproducibility, and accountability.

Evaluation reports (performance, fairness, safety)

Evaluation evidence should fit intended use and risk. A chatbot, a medical triage assist tool, and a hiring ranker need different evaluation emphasis. Auditor questions:

• Were tests run on representative data, including relevant slices?
• Are metrics defined and thresholds justified (not only “accuracy improved”)?
• For fairness claims, are group definitions, metrics, and limitations explicit?
• Did evaluation occur before production promotion, and after material changes?
• Who reviewed and accepted residual risk when thresholds were missed?

Beware one-time launch reports with no re-evaluation after major data or prompt changes. Also beware metric shopping: beautiful offline scores that ignore production distribution shift.

Impact assessment reports

AI system impact assessment (aligned with Clause 6.1.4 and Annex A.5 themes) examines effects on individuals, groups, and other interested parties—beyond pure model accuracy. Sufficiency tests:

Auditors should sample impact assessment → control implementation linkage: if the assessment requires human review of high-stakes denials, oversight logs must show that review occurring.

Human oversight logs and deployment approval gates

Oversight logs prove that human control is not theoretical. Look for case IDs, reviewer identity/role, decision (accept/override), rationale where required, timestamps, and quality sampling of reviews. Empty queues, 100% auto-accept with “rubber stamp” reviewers, or logs that cannot be retrieved for the sample period are warning signs.

Deployment approval gates (CAB tickets, MLOps policy checks, signed release checklists) show operational planning and control. Sample recent promotions:

• Required artifacts attached (eval, impact, security/privacy sign-off as applicable)?
• Approver independence proportionate to risk?
• Emergency hotfixes documented with retrospective controls?

A perfect procedure with zero gated releases in the ticket system for a “highly controlled” model is a triangulation failure.

Third-party model terms and residual risk

Foundation models, APIs, and vendor platforms limit white-box inspection. Evidence shifts to:

• Contracts / DPAs / acceptable use and data retention terms
• Vendor due diligence and ongoing monitoring of provider notices
• Organization-side evaluation of outputs for the intended use
• Documented residual risk acceptance when provider opacity remains
• Exit / contingency if the provider changes model behavior or terms

“We use Vendor X, so ISO 42001 doesn’t apply” is not a valid exclusion pattern for systems the organization provides or uses under its AIMS scope. A.10 and Clause 8 external process control still apply to what the organization can and must control.

Drift/incident tickets and sufficiency tests

Production AI fails via data/concept drift, prompt abuse, retrieval corruption, and silent decay. Tickets should show detection source, AI-harm severity (not only uptime), containment (rollback, human-only mode), root cause across data/model/process/vendor, and Clause 10 learning. Claimed drift monitoring with never-opened tickets despite metric breaches is not effective.

For each critical artifact ask: relevant to criterion and system; authentic from systems of record; current to the production version; complete enough for risk level; consistent with interviews/observation; actionable when defects appear. Failures become potential NCs or need-more-evidence—criteria vs. evidence, not personal criticism.

Common NC patterns involving AI artifacts

Frequent patterns: model cards for demos only; generic impact assessments disconnected from monitoring; offline-only evaluations with no production review; lineage broken after platform migration; oversight logs shorter than stated retention; vendor models adopted via shadow SaaS with no A.10 trail. Mastering these artifacts lets you audit AIMS with ISO 19011 rigor in the language of AI delivery teams.