AI Risk Registers, Model Cards, and Audit Documentation

Last Updated May 10, 2026

AI risk registers, model cards, and audit documentation concern the evidence infrastructure through which artificial intelligence systems become governable, reviewable, comparable, contestable, and accountable. AI governance cannot depend on informal memory, scattered spreadsheets, undocumented design choices, or assumptions held by individual teams. Once AI systems affect rights, safety, access, knowledge work, organizational decisions, public services, infrastructure, or institutional trust, they require durable records: what the system is for, how it was developed, what risks it creates, how it was evaluated, where it should not be used, who approved it, how it is monitored, and what happens when it fails.

Documentation is often treated as administrative overhead. In responsible AI systems, however, documentation is a control surface. A risk register makes foreseeable harms visible. A model card communicates intended use, limitations, performance, evaluation context, and ethical considerations. Audit documentation preserves evidence for review, compliance, incident response, public accountability, and institutional learning. Together, these artifacts help transform AI governance from aspiration into operational practice.

The deeper point is that AI documentation is not simply a record of the past. It shapes future behavior. A risk register assigns ownership. A model card defines boundaries. A monitoring record triggers review. An incident report preserves lessons. A corrective-action log shows whether the organization learned. Documentation is therefore part of the governance system itself: it connects technical work to institutional responsibility.

This article develops AI Risk Registers, Model Cards, and Audit Documentation as an advanced article within the Artificial Intelligence Systems knowledge series. It explains risk registers, model cards, system cards, data documentation, audit trails, evidence ledgers, documentation completeness, traceability, model lifecycle records, monitoring logs, incident documentation, risk ownership, governance review, and accountable AI operations. Selected Python and R examples appear here, while the full GitHub repository contains expanded computational scaffolding for risk-register scoring, model-card completeness checks, audit evidence tracking, SQL governance schemas, documentation templates, and reproducible notebooks.

Why Documentation Matters in AI Governance

Documentation matters because AI systems are rarely self-explanatory. A model output does not reveal the data used to train the system, the assumptions behind the evaluation, the populations for which the system performs poorly, the risks that were accepted, the incidents that occurred, the reviewer who approved deployment, or the corrective actions taken after failure. Without documentation, AI governance becomes dependent on memory, trust, and institutional improvisation.

AI documentation is also necessary because responsibility is distributed. Model developers, data engineers, product teams, security teams, legal teams, compliance officers, domain experts, vendors, deployers, and frontline users may all shape the system. A risk register identifies what could go wrong and who owns the response. A model card explains what the system is intended to do and where it should not be used. Audit documentation preserves evidence that an organization can inspect, challenge, compare, and improve.

The key point is that documentation is not merely descriptive. It is operational. It supports review, escalation, monitoring, accountability, procurement, compliance, incident response, and public explanation. A poorly documented system may be technically impressive while remaining institutionally ungovernable.

Documentation also protects institutional memory. AI systems often outlast the teams that built them. Engineers move to new projects. Vendors update services. Product owners change. Legal interpretations evolve. Without records, later reviewers may be unable to reconstruct why a threshold was chosen, why a dataset was accepted, why a limitation was tolerated, or why a system was allowed to remain deployed after an incident.

In high-impact settings, this is not a minor administrative problem. If a system influences benefits, healthcare, employment, education, credit, housing, migration, policing, infrastructure, or public information, the inability to reconstruct decisions becomes an accountability failure. People cannot challenge what the institution cannot explain. Auditors cannot assess what the institution did not preserve. Governance cannot improve what the institution did not measure.

Back to top ↑

Foundations of AI Governance Documentation

AI governance documentation refers to the structured records used to describe, evaluate, monitor, and govern AI systems across their lifecycle. It should connect system purpose, data provenance, model design, performance, intended use, limitations, risks, controls, human oversight, monitoring, incidents, and accountability.

A mature documentation system should include:

• System documentation: purpose, owner, scope, users, deployment context, lifecycle status, and authorized use.
• Data documentation: data sources, provenance, quality, consent, representativeness, privacy, and known gaps.
• Model documentation: architecture, training process, evaluation, limitations, performance, and intended use.
• Risk documentation: foreseeable harms, likelihood, impact, controls, owners, residual risk, and review status.
• Audit documentation: approvals, version history, decision records, logs, monitoring evidence, incidents, and corrective action.
• Public-facing documentation: explanations, transparency notices, impact summaries, user instructions, and contestability pathways.

Documentation should be maintained as a living governance system. A model card written before deployment may become misleading if data, users, context, risk profile, or monitoring results change. A risk register may become stale when new incidents arise. A monitoring plan may become inadequate when use expands. Documentation is only useful when it tracks the real system rather than the remembered system.

A strong documentation architecture should answer four basic questions:

• What is the system? The institution should know the system’s purpose, architecture, owner, scope, users, and dependencies.
• What evidence supports it? The institution should preserve data records, evaluation results, limitations, approvals, and monitoring evidence.
• What risks does it create? The institution should document harms, affected groups, controls, owners, residual risk, and mitigation plans.
• What happens when it fails? The institution should document incident response, appeals, corrective action, system updates, and decommissioning criteria.

Back to top ↑

Documentation as a Control Surface

Documentation becomes a control surface when it influences decisions rather than merely recording them. A system should not move from development to deployment if its model card is incomplete, its risk register has unresolved high-risk items, its data documentation lacks provenance, or its monitoring plan is missing. Documentation should create decision gates.

A documentation control surface can operate at multiple stages:

• Before development: use-case documentation clarifies purpose, stakeholders, prohibited uses, and success criteria.
• Before training or configuration: data documentation records provenance, permissions, quality, representativeness, and limitations.
• Before deployment: model cards, risk registers, evaluation reports, and security reviews support approval decisions.
• During operation: monitoring logs, incidents, appeals, drift reports, and override records support ongoing governance.
• After failure: incident reports, root-cause analysis, and corrective-action records support repair and learning.

This changes the role of documentation. Instead of being produced after decisions are made, documentation becomes part of how decisions are made. It can trigger escalation, restrict use, require human review, force remediation, or pause deployment.

The institutional test is simple: does documentation have consequences? If missing documentation does not delay launch, if stale model cards do not trigger review, if risk-register items do not have owners, and if incident reports do not produce corrective action, then documentation is not governance. It is paperwork.

Back to top ↑

AI Risk Registers

An AI risk register is a structured record of risks associated with an AI system. It identifies foreseeable harms, affected groups, risk sources, severity, likelihood, existing controls, residual risk, risk owner, mitigation plan, review date, and status.

A strong AI risk register should include:

• risk identifier;
• risk description;
• risk category;
• affected stakeholders;
• source of risk;
• likelihood;
• impact;
• detectability;
• existing controls;
• residual risk;
• risk owner;
• mitigation plan;
• review cadence;
• status.

Risk registers are useful because they convert abstract concern into accountable action. Instead of saying “bias is a concern,” the register asks: bias against whom, through what mechanism, with what severity, detected how, owned by whom, mitigated by what control, and reviewed when?

This formula is only a simplification. In practice, risk scoring should consider rights sensitivity, reversibility, detectability, affected population, uncertainty, and institutional power.

Back to top ↑

Model Cards and System Cards

Model cards are structured documents that describe a model’s intended use, training and evaluation data, performance characteristics, limitations, ethical considerations, and appropriate usage boundaries. They are especially useful because many model failures arise from misuse outside the context in which the model was evaluated.

A model card should usually include:

• model name and version;
• model owner and contact;
• intended use;
• out-of-scope use;
• training data summary;
• evaluation data summary;
• performance metrics;
• performance by subgroup or context where appropriate;
• known limitations;
• ethical considerations;
• security and misuse considerations;
• human oversight requirements;
• monitoring plan;
• date of last update.

A system card extends this idea beyond the model. It documents the full deployed system: model, data pipelines, retrieval layers, tools, user interface, human review, monitoring, security controls, incident response, and governance. This distinction matters because many AI harms arise not from the model alone but from the system in which the model is embedded.

A model card answers, “What is this model, how was it evaluated, and what are its limitations?” A system card answers, “How is this AI capability actually deployed, what can it affect, who is responsible, what safeguards exist, and how is it monitored?” In many operational settings, the system card is more important than the model card because users experience the deployed workflow, not the model in isolation.

System cards are especially important for retrieval-augmented generation, agentic AI, automated decision support, clinical decision support, hiring tools, educational analytics, public-sector systems, and infrastructure systems. In these environments, the relevant governance unit is not simply the model. It is the model plus data pipelines, retrieval sources, prompts, tools, interfaces, permissions, users, procedures, and human oversight.

Back to top ↑

Data Documentation and Datasheets

Data documentation describes where data came from, how it was collected, what it represents, what it excludes, what permissions apply, how it was cleaned, what transformations were performed, and what limitations should shape use. Without data documentation, model documentation is incomplete because model behavior depends heavily on the data environment.

Data documentation should include:

• data source and provenance;
• collection method;
• time period covered;
• population represented;
• known exclusions or undercoverage;
• labeling process;
• data-quality checks;
• privacy and consent considerations;
• permitted uses and prohibited uses;
• retention and deletion rules;
• known biases or measurement limitations;
• version history.

Datasheets for datasets are especially useful because they force teams to document the social and operational context of data. A dataset is not a neutral resource. It is produced through choices: what to collect, what not to collect, who was included, who was excluded, what labels mean, what instruments were used, and what historical conditions shaped the data.

Data documentation is also essential for contestability. If an affected person challenges an AI-influenced decision, the organization may need to identify whether inaccurate, stale, incomplete, or irrelevant data shaped the outcome. Without data documentation, the organization may not know what evidence the system relied on.

Back to top ↑

Audit Documentation and Evidence Records

Audit documentation preserves the evidence needed to determine whether an AI system was designed, deployed, monitored, and governed appropriately. It supports internal review, independent audit, regulatory assessment, incident investigation, procurement review, public accountability, and legal defense.

Audit documentation should answer:

• What system was used?
• Which model version was active?
• What data sources were used?
• What evaluation was performed?
• What risks were identified?
• What controls were implemented?
• Who approved deployment?
• What monitoring occurred?
• What incidents were reported?
• What corrective actions were taken?
• What documentation was updated?

Auditability depends on evidence quality. A system cannot be meaningfully audited if records are incomplete, inconsistent, inaccessible, outdated, or disconnected from operational reality.

Audit documentation should also support chain of custody. If an incident occurs, reviewers may need to know which logs are authoritative, who accessed them, whether they were altered, and how long they were retained. Evidence that cannot be trusted cannot support accountability. This is why documentation governance must include retention policies, access controls, tamper-resistant logs where appropriate, and privacy-aware evidence handling.

Back to top ↑

Traceability, Versioning, and Lifecycle Control

Traceability links AI-system artifacts across the lifecycle. A complete trace should connect the use case, data sources, model version, evaluation results, risk register, model card, deployment approval, monitoring logs, incidents, and corrective actions.

Traceability is essential because AI systems change. Models are retrained. Prompts are edited. Retrieval indexes are updated. Data pipelines drift. User populations shift. Tool permissions expand. Monitoring thresholds change. Documentation must therefore track not only what the system was, but when it changed and why.

Versioning should apply to:

• datasets;
• model artifacts;
• prompts and system instructions;
• retrieval indexes;
• evaluation suites;
• risk registers;
• model cards;
• monitoring thresholds;
• governance approvals;
• incident records.

Without versioning, organizations may be unable to reconstruct which system produced which decision. This is especially important when a system changes after deployment. If a model update improves average performance but worsens outcomes for a subgroup, documentation must preserve the before-and-after state. If a prompt update changes agent behavior, the organization needs a record. If a retrieval index is updated, reviewers need to know what sources were available at the time of a generated answer.

Traceability also supports rollback. A system cannot be safely rolled back if the organization does not know which data, model, prompt, configuration, and dependencies produced the prior stable state.

Back to top ↑

Monitoring Records, Incidents, and Corrective Action

Monitoring records connect documentation to operational reality. A model card may state intended performance, but monitoring records show whether the deployed system continues to behave as expected. A risk register may identify foreseeable harms, but incident records show which risks became real.

Monitoring documentation should include:

• performance metrics over time;
• drift indicators;
• calibration metrics;
• subgroup performance;
• human override rates;
• appeal and complaint rates;
• security events;
• misuse signals;
• data-quality alerts;
• system availability;
• incident records;
• corrective actions.

Documentation should not stop at identifying failures. It should show whether the organization learned from them.

Incident documentation should distinguish between isolated events and systemic problems. A single failure may require case correction. A recurring pattern may require model retraining, threshold change, workflow redesign, access restriction, vendor review, or system decommissioning. If incident documentation only records events without root-cause analysis, it may preserve evidence without producing accountability.

Back to top ↑

Documentation Quality, Completeness, and Staleness

Documentation quality is not the same as documentation volume. A large collection of records can still fail if it is incomplete, outdated, inconsistent, inaccessible, or unused. Governance documentation should be assessed for completeness, accuracy, currency, traceability, usability, and decision relevance.

Important quality dimensions include:

• Completeness: required fields, evidence items, approvals, and monitoring records are present.
• Accuracy: documentation reflects the actual deployed system rather than an outdated design.
• Currency: records are updated after model changes, incidents, risk changes, or monitoring findings.
• Traceability: artifacts are linked across the system lifecycle.
• Usability: documentation can be understood by the people who need to use it.
• Actionability: documentation triggers review, escalation, or corrective action when needed.

Stale documentation can be worse than missing documentation because it creates false confidence. A model card that describes an earlier model version, an outdated risk register, or an old monitoring threshold may mislead reviewers. Documentation should therefore include last-updated dates, owners, review cadence, and change history.

Back to top ↑

Access, Retention, and Public-Facing Documentation

Not all AI documentation should have the same audience. Some documentation should be public, some internal, some regulator-facing, some auditor-facing, and some restricted for security or privacy reasons. Governance requires deciding who needs access to which evidence.

A public-facing transparency notice may explain that AI is used, what decision it supports, what data categories may be involved, how human review works, and how people can challenge an outcome. An internal model card may include more detailed evaluation results. A restricted security assessment may include sensitive threat-modeling information. A regulator-facing audit package may include evidence not appropriate for general publication.

Documentation governance should therefore classify artifacts by audience:

Retention is equally important. Records should be preserved long enough to support audit, appeal, incident investigation, and legal obligations, but not retained indefinitely without purpose. Documentation should include retention rules, deletion rules, access controls, and privacy protections.

Back to top ↑

Governance, Ownership, and Review Cadence

Documentation requires ownership. A risk register without owners becomes a list of concerns. A model card without update responsibility becomes stale. An audit trail without retention policy becomes unreliable. Governance must define who creates, reviews, approves, updates, and uses each artifact.

Important governance questions include:

• Who owns the risk register?
• Who approves residual risk?
• Who maintains the model card?
• Who reviews documentation quality?
• Who verifies monitoring evidence?
• Who updates documentation after incidents?
• Who can pause deployment if documentation is incomplete?
• What documentation is public, internal, confidential, or regulator-facing?
• How often are documents reviewed?
• What triggers mandatory update?

Review cadence should depend on risk. A low-risk internal productivity tool may require periodic documentation review. A high-impact system affecting rights, health, safety, employment, credit, education, or public benefits requires stronger review, monitoring, and audit evidence.

Mandatory documentation updates should be triggered by:

• model retraining or replacement;
• data-source changes;
• new use cases;
• expanded user groups;
• changed permissions or tool access;
• performance drift;
• security incidents;
• appeals or complaints;
• regulatory changes;
• high-severity risk-register updates.

Governance should also define what happens when documentation is incomplete. Possible responses include restricted deployment, additional review, required mitigation, delayed release, external audit, or decommissioning. Documentation should not merely advise governance. It should have authority within governance.

Back to top ↑

Common Failure Modes

AI documentation often fails in predictable ways. The problem is rarely that organizations have no documents at all. More often, the documents exist but are disconnected from decisions, incomplete, stale, unread, or treated as compliance artifacts rather than governance instruments.

Back to top ↑

Limits and Open Problems

Documentation has limits. A model card can be accurate but unread. A risk register can be complete but ignored. An audit log can exist but fail to capture the right events. A compliance document can be polished while the operational system remains unsafe. Documentation must therefore be connected to authority, monitoring, incentives, and corrective action.

There is also a standardization problem. Different organizations use different templates, risk categories, metrics, taxonomies, and evidence formats. This makes comparison difficult. AI governance would benefit from more interoperable documentation practices, but rigid standardization may also miss context-specific risk.

Finally, documentation can create a false sense of assurance. The existence of documentation does not prove that a system is safe, fair, secure, or accountable. The relevant question is whether documentation is truthful, current, complete, tested, used, and connected to decisions.

A further open problem is documentation burden. If documentation requirements become too heavy, teams may treat them as bureaucratic obstacles rather than governance tools. The answer is not to reduce documentation to symbolic checklists. The answer is to design documentation that is proportionate, structured, reusable, and connected to real decision points.

The hardest problem is cultural. Documentation requires an organization to treat AI governance as institutional memory rather than launch compliance. That requires leadership support, technical integration, clear ownership, and consequences when documentation is missing or ignored.

Back to top ↑

Mathematical Lens

A risk-register item can be represented as:

Residual risk can be represented as:

Documentation completeness can be represented as:

Traceability coverage can be represented as:

Audit evidence gap can be represented as:

Documentation priority can be represented as:

Documentation staleness can be represented as:

Evidence reliability can be represented as:

Back to top ↑

Variables and System Interpretation

Back to top ↑

Worked Example: Documentation for a High-Impact Decision System

Suppose an organization deploys an AI system to support eligibility review for public benefits. The system ranks cases for additional verification. It does not directly deny benefits, but its outputs may affect delay, administrative burden, stress, and access to essential support.

A weak documentation approach may include only a technical model summary and a performance metric. That is not enough. A high-impact decision system requires a risk register, model card, data documentation, audit trail, monitoring plan, appeal documentation, incident record, and review cadence.

A risk item might be:

Its residual risk is:

The model card should explain intended use, excluded use, performance across relevant populations, data limitations, human review requirements, and appeal pathways. Audit documentation should preserve model version, evaluation records, review approvals, monitoring logs, complaints, appeals, and corrective actions. If documentation is incomplete, deployment should be delayed, restricted, or escalated.

The public benefits example also shows why documentation must connect to contestability. If an affected person challenges a delayed benefit, the institution should be able to reconstruct the decision pathway: which model version was active, what data were used, what score was generated, whether a human reviewed the case, what explanation was provided, and whether correction was available. Documentation is therefore not only for auditors. It is part of procedural fairness.

Back to top ↑

Computational Modeling

Computational modeling can make governance documentation more concrete. A risk-register workflow can prioritize risks by residual risk and documentation gaps. A model-card completeness workflow can identify missing fields. An audit evidence workflow can detect lifecycle traceability gaps. A SQL schema can preserve system records, documentation artifacts, risk owners, evidence links, approvals, incidents, and corrective actions.

The examples below are intentionally lightweight so the article remains readable and WordPress-friendly. The GitHub repository extends the same logic into SQL schemas, documentation templates, audit checklists, risk-register examples, model-card templates, evidence ledgers, and reproducible notebooks.

These examples are not substitutes for legal, ethical, or domain review. They are governance-support tools. Their purpose is to make missing evidence, unresolved risks, stale documentation, and incomplete traceability visible enough for institutions to act.

Back to top ↑

Python Workflow: Risk Register and Documentation Completeness

"""
AI Risk Registers, Model Cards, and Audit Documentation Mini-Workflow

This example demonstrates:
1. synthetic AI risk-register entries
2. residual-risk scoring
3. documentation-completeness scoring
4. documentation-priority scoring
5. governance-oriented prioritization

It is educational and uses synthetic data.
"""

from __future__ import annotations

import pandas as pd


risk_register = pd.DataFrame({
    "risk_id": [
        "R-001",
        "R-002",
        "R-003",
        "R-004",
        "R-005",
        "R-006"
    ],
    "risk_name": [
        "unfair_outcome_disparity",
        "out_of_scope_use",
        "insufficient_human_review",
        "data_quality_gap",
        "security_or_misuse_event",
        "monitoring_not_reviewed"
    ],
    "likelihood": [0.35, 0.40, 0.30, 0.45, 0.25, 0.50],
    "impact": [0.90, 0.75, 0.85, 0.70, 0.80, 0.65],
    "mitigation_strength": [0.45, 0.55, 0.50, 0.40, 0.60, 0.35],
    "documentation_completeness": [0.60, 0.70, 0.55, 0.50, 0.65, 0.40],
    "owner": [
        "Responsible AI",
        "Product Governance",
        "Operations",
        "Data Stewardship",
        "Security",
        "AI Operations"
    ]
})

risk_register["residual_risk"] = (
    risk_register["likelihood"] *
    risk_register["impact"] *
    (1 - risk_register["mitigation_strength"])
)

risk_register["documentation_priority"] = (
    risk_register["residual_risk"] *
    (1 - risk_register["documentation_completeness"])
)

risk_register["priority_band"] = pd.cut(
    risk_register["documentation_priority"],
    bins=[0, 0.05, 0.10, 1.00],
    labels=["low", "moderate", "high"],
    include_lowest=True
)

priority = risk_register.sort_values(
    "documentation_priority",
    ascending=False
)

print(priority)

This workflow prioritizes documentation work where governance risk is highest. A low-risk documentation gap may be tolerable for a limited time. A high-risk system with incomplete documentation should trigger immediate review.

Back to top ↑

R Workflow: Audit Evidence and Documentation Gaps

# AI Risk Registers, Model Cards, and Audit Documentation Diagnostics
#
# This educational workflow simulates:
# - required audit evidence
# - completion status
# - evidence weight
# - audit gap scoring
# - documentation priority

audit_evidence <- data.frame(
  evidence_item = c(
    "system_purpose",
    "data_provenance",
    "model_card",
    "risk_register",
    "evaluation_report",
    "human_oversight_plan",
    "monitoring_logs",
    "incident_response_plan",
    "appeal_and_remedy_process",
    "approval_record"
  ),
  complete = c(1, 0, 1, 1, 0, 1, 0, 1, 0, 1),
  weight = c(0.08, 0.12, 0.12, 0.12, 0.14, 0.10, 0.12, 0.08, 0.08, 0.04)
)

audit_evidence$weighted_completion <-
  audit_evidence$complete * audit_evidence$weight

documentation_completeness <-
  sum(audit_evidence$weighted_completion) / sum(audit_evidence$weight)

audit_gap <- 1 - documentation_completeness

missing_items <- subset(audit_evidence, complete == 0)
missing_items <- missing_items[order(-missing_items$weight), ]

summary_table <- data.frame(
  documentation_completeness = documentation_completeness,
  audit_gap = audit_gap,
  missing_required_items = nrow(missing_items)
)

print(summary_table)
print(missing_items)

This workflow treats audit evidence as weighted evidence rather than a flat checklist. Missing an approval record may matter, but missing evaluation evidence, data provenance, or monitoring logs may be more serious depending on the system’s risk profile.

Back to top ↑

GitHub Repository

The article body includes selected computational examples so the conceptual and mathematical argument remains readable. The full repository contains expanded computational infrastructure for risk-register scoring, model-card completeness checks, audit evidence ledgers, lifecycle traceability schemas, SQL governance tables, Rust and Go examples, Julia sensitivity analysis, TypeScript validation, C++ scoring, documentation templates, and reproducible notebooks.

Back to top ↑

From Paperwork to Governance Infrastructure

AI risk registers, model cards, and audit documentation show that responsible AI requires evidence infrastructure. Documentation is not merely paperwork after the fact. It is how organizations remember decisions, assign responsibility, monitor risk, investigate incidents, support appeals, update systems, and justify deployment.

The central lesson is that documentation becomes meaningful only when it is connected to governance. A risk register must have owners. A model card must be updated. Audit logs must be preserved. Monitoring records must be reviewed. Incidents must produce corrective action. Documentation should make AI systems more governable, not merely more polished.

This distinction matters because AI systems often fail through institutional fragmentation. The data team may know the dataset. The model team may know the evaluation. The product team may know the workflow. The security team may know the threat model. The compliance team may know the policy. The user may experience the harm. Documentation is the infrastructure that connects these partial views into an accountable system.

Within the Artificial Intelligence Systems knowledge series, this article belongs near AI Ethics, Human Rights, and Public Accountability, Human Oversight, Contestability, and AI Accountability, Model Monitoring, Drift, and AI Observability, AI Security, Misuse, and Adversarial Threats, Calibration, Uncertainty, and Probability in AI Systems, and AI Governance and Regulatory Systems. It provides the documentation layer for transforming AI governance into reviewable, auditable, and accountable practice.

Back to top ↑

Related Articles

• Artificial Intelligence Systems
• AI Ethics, Human Rights, and Public Accountability
• Human Oversight, Contestability, and AI Accountability
• Model Monitoring, Drift, and AI Observability
• AI Security, Misuse, and Adversarial Threats
• Calibration, Uncertainty, and Probability in AI Systems
• AI Governance and Regulatory Systems

Further Reading

• NIST (2023) Artificial Intelligence Risk Management Framework. Available at: https://www.nist.gov/itl/ai-risk-management-framework
• Mitchell, M. et al. (2019) ‘Model Cards for Model Reporting’, Proceedings of the Conference on Fairness, Accountability, and Transparency. Available at: https://arxiv.org/abs/1810.03993
• ISO (2023) ISO/IEC 42001:2023 Artificial Intelligence Management System. Available at: https://www.iso.org/standard/42001
• European Union (2024) Artificial Intelligence Act, Article 11: Technical Documentation. Available at: https://artificialintelligenceact.eu/article/11/
• European Union (2024) Artificial Intelligence Act, Article 12: Record-Keeping. Available at: https://artificialintelligenceact.eu/article/12/
• Gebru, T. et al. (2021) ‘Datasheets for Datasets’, Communications of the ACM. Available at: https://dl.acm.org/doi/10.1145/3458723
• OECD (2019) Recommendation of the Council on Artificial Intelligence. Available at: https://legalinstruments.oecd.org/en/instruments/oecd-legal-0449

References

• European Union (2024) Artificial Intelligence Act, Article 11: Technical Documentation. Available at: https://artificialintelligenceact.eu/article/11/
• European Union (2024) Artificial Intelligence Act, Article 12: Record-Keeping. Available at: https://artificialintelligenceact.eu/article/12/
• Gebru, T. et al. (2021) ‘Datasheets for Datasets’, Communications of the ACM, 64(12), pp. 86–92. Available at: https://dl.acm.org/doi/10.1145/3458723
• ISO (2023) ISO/IEC 42001:2023: Information Technology — Artificial Intelligence — Management System. International Organization for Standardization. Available at: https://www.iso.org/standard/42001
• Mitchell, M. et al. (2019) ‘Model Cards for Model Reporting’, Proceedings of the Conference on Fairness, Accountability, and Transparency. Available at: https://arxiv.org/abs/1810.03993
• NIST (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology. Available at: https://www.nist.gov/itl/ai-risk-management-framework
• OECD (2019) Recommendation of the Council on Artificial Intelligence. Organisation for Economic Co-operation and Development. Available at: https://legalinstruments.oecd.org/en/instruments/oecd-legal-0449