The minimum viable AI governance pack: eight artifacts before production

Principles such as fairness, transparency, safety, and accountability are useful direction, but a product team cannot release against a principle alone. It needs named decisions, evidence, thresholds, owners, and procedures connected to the system being built.

NIST organizes AI risk management around Govern, Map, Measure, and Manage. ISO/IEC 42001 defines requirements for an organizational AI management system. The EU AI Act applies obligations according to role and risk. The eight artifacts below do not replace any framework or legal assessment; they create an operational spine that can map to each one.

Keep each artifact proportionate. A low-impact internal assistant does not need the same review depth as a system influencing access to employment, credit, healthcare, or critical infrastructure. The important property is traceability: every control and test should connect back to an intended use and identified risk.

An organization cannot govern systems it cannot identify. The AI register should include internally built systems, embedded vendor features, models used through APIs, automated decisions, and material experiments approaching production. Assign a business owner and technical owner rather than listing a committee as accountable.

The system card is the stable description of one deployed system. It should state the intended purpose, users, boundaries, data flows, model and vendor dependencies, prohibited uses, and known limitations. Update it when a change could alter behavior or risk, not for every cosmetic release.

The impact assessment should describe plausible consequences in the actual workflow: an incorrect recommendation, disclosure of sensitive information, discriminatory treatment, unsafe automation, inability to explain a decision, service interruption, or dependence on a provider the organization cannot replace.

For every material risk, the control map should identify a control owner and the evidence that proves the control operates. A policy statement is not evidence that access restrictions, evaluation gates, human review, or incident procedures work in production.

Evaluation should use representative tasks, data, languages, user groups, and operating conditions. Record the baseline, thresholds, known gaps, security tests, and performance by meaningful subgroup where relevant. A single average score can hide the failure that matters most.

The release record identifies who reviewed the evidence and who accepted residual risk. Conditional approval should name the condition, owner, deadline, and operational restriction. Approval should expire when the system, model, data, intended use, or risk materially changes.

A person is not meaningful oversight if they cannot understand the recommendation, access supporting context, override the result, pause the workflow, or escalate before harm occurs. Define which decisions require review and measure whether reviewers actually intervene when needed.

Production monitoring should cover more than uptime. Track task quality, error patterns, drift, security events, costs, escalation volume, override rates, complaints, and downstream outcomes. The incident plan should state when to restrict, roll back, notify, investigate, and reassess the system.

The eight artifacts should be produced through existing discovery, architecture, security, procurement, release, and incident processes wherever possible. A separate governance lane creates duplicate meetings and late surprises.

Review higher-risk systems at defined intervals and after material changes. Review lower-risk systems by exception and automated monitoring. The objective is not equal paperwork for every use case; it is reliable evidence that the organization understands and controls the AI it operates.