Documentation, Model Cards, and Datasheets for Algorithms: Making Systems Reviewable

Last Updated June 22, 2026

Documentation, model cards, and datasheets for algorithms examine how algorithmic systems should communicate their purpose, data, assumptions, limitations, risks, evaluation results, intended uses, prohibited uses, governance controls, and conditions for responsible deployment. Documentation is not administrative decoration. It is the memory of an algorithmic system: what was built, why it was built, what evidence supports it, who is responsible for it, where it should not be used, and how harms should be detected and repaired.

Model cards and datasheets are structured documentation practices that make technical systems more reviewable. Model cards describe models, performance, intended use, limitations, evaluation, ethical considerations, and deployment constraints. Datasheets describe datasets, collection methods, composition, preprocessing, recommended uses, maintenance, distribution, and limitations. Together, they help prevent systems from becoming black boxes not only technically, but institutionally.

This article introduces algorithmic documentation, model cards, datasheets, system cards, data statements, use-case registers, risk documentation, evaluation reports, change logs, decision logs, provenance records, governance files, maintenance records, audit trails, contestability records, and representation risk. It shows why documentation must be accurate, maintained, accessible, actionable, and tied to accountability.

This article explains algorithmic documentation, model cards, datasheets, system cards, data provenance, evaluation reporting, intended use, prohibited use, limitation statements, risk records, maintenance notes, change logs, governance files, audit trails, contestability records, and representation risk. It emphasizes that documentation should help people make decisions, not merely satisfy a checklist.

Why Documentation, Model Cards, and Datasheets Matter

Documentation, model cards, and datasheets matter because algorithmic systems often travel farther than their designers expect. A model trained for one purpose may be reused in another. A dataset collected under one set of conditions may be interpreted as general evidence. A metric reported in one evaluation may be treated as proof of safety in a different context. Without documentation, these shifts become invisible.

Good documentation slows down inappropriate reuse. It records what the system is for, what it is not for, how it was evaluated, what data shaped it, what risks are known, what assumptions were made, and what responsibilities remain.

Documentation is a governance technology: it makes algorithmic systems inspectable, contestable, maintainable, and accountable.

Back to top ↑

Algorithmic Documentation Defined

Algorithmic documentation is the structured record of an algorithmic system’s purpose, design, data, assumptions, methods, evaluation, limitations, governance, deployment, monitoring, and change history. It includes technical information, institutional context, accountability records, and user-facing explanations.

Documentation should support multiple audiences: developers, users, reviewers, auditors, governance teams, affected people, procurement officers, researchers, regulators, and maintainers. Each audience needs different levels of detail.

Documentation should explain not only how a system works, but how it should be governed.

Back to top ↑

Model Cards Defined

Model cards are structured documents that describe trained models and their intended use. They usually include model details, use cases, evaluation data, performance metrics, ethical considerations, limitations, caveats, and recommendations for deployment. Their purpose is to make models more transparent and to help downstream users understand when a model is appropriate.

A model card should not be a marketing sheet. It should include weaknesses, failure modes, uncertainty, subgroup performance, evaluation conditions, and prohibited uses.

A useful model card tells readers when not to trust the model.

Back to top ↑

Datasheets Defined

Datasheets are structured documents that describe datasets. They record why data were created, how they were collected, who or what they represent, what preprocessing occurred, what labels mean, what gaps exist, what risks accompany use, how data are distributed, and how they should be maintained.

Datasheets are important because data often appear more neutral than they are. Collection practices, institutional histories, measurement choices, missingness, consent conditions, labeling rules, and sampling boundaries shape what datasets can responsibly support.

A useful datasheet makes the dataset’s history visible enough to question.

Back to top ↑

What Documentation Should Answer

Good algorithmic documentation answers practical governance questions. It should help someone decide whether to build, buy, use, limit, audit, update, challenge, or retire a system. It should also support incident response and affected-person review when something goes wrong.

Documentation should be written for decisions, not archives alone. A reader should be able to understand what the system is, what evidence supports it, what risks remain, and what actions are required.

Documentation is useful when it supports judgment under uncertainty.

Back to top ↑

Purpose, Intended Use, and Prohibited Use

Purpose documentation explains what the algorithmic system is designed to do. Intended-use documentation specifies appropriate users, contexts, inputs, outputs, decisions, and boundaries. Prohibited-use documentation states where the system should not be used, even if it technically can be used.

Prohibited-use documentation is especially important because algorithmic systems are often repurposed. A model trained for assistance may become a gatekeeping tool. A dataset collected for research may become operational evidence. A ranking system may become an eligibility system.

A system without prohibited-use documentation invites mission creep.

Back to top ↑

Data Provenance and Dataset Limits

Data provenance records where data came from, how they were collected, how they changed, who maintained them, what transformations occurred, and what limitations remain. Dataset limits describe gaps, missingness, bias, representational boundaries, measurement errors, label uncertainty, and contexts where the data should not be used.

Data documentation is essential because models inherit the assumptions, omissions, and histories of their data. A model card without a datasheet may explain model behavior while hiding the conditions that shaped it.

Provenance makes data accountable to history.

Back to top ↑

Evaluation, Performance, and Fairness Reporting

Evaluation documentation records how a model was tested and what the tests show. It should include datasets, metrics, baselines, subgroup performance, calibration, robustness, uncertainty, stress tests, failure modes, and deployment relevance. Performance documentation should avoid implying that one aggregate metric represents all users, contexts, or outcomes.

Fairness reporting should explain what groups or slices were examined, which fairness concerns are relevant, what tradeoffs appear, what harms remain, and what mitigation or monitoring is required.

Evaluation documentation should make performance claims narrower, not broader.

Back to top ↑

Limitations, Uncertainty, and Failure Modes

Limitations documentation records what the system cannot do, where it performs poorly, where uncertainty is high, what assumptions may fail, and what failure modes are known. This section is often the most important part of documentation because it prevents overuse.

Failure-mode documentation should include technical failures, social failures, governance failures, data failures, interface failures, and misuse risks. It should also identify monitoring signals and escalation triggers.

Documentation that hides limitations converts uncertainty into institutional overconfidence.

Back to top ↑

Risk, Governance, and Accountability Records

Documentation should connect algorithmic systems to governance. A model card or datasheet should not stand alone if a system affects consequential decisions. It should link to risk registers, control registers, ownership records, approval records, monitoring plans, incident response procedures, appeal pathways, remediation plans, and retirement criteria.

Accountability records show who is responsible for the system over time. They should identify owners for data, model, deployment, monitoring, review, appeals, incidents, remediation, and retirement.

Documentation should make responsibility visible enough to assign and review.

Back to top ↑

Versioning, Change Logs, and Maintenance

Algorithmic systems change. Data are updated, labels are corrected, models are retrained, thresholds shift, prompts are revised, evaluation sets expand, interfaces change, monitoring signals evolve, and governance rules are amended. Versioning and change logs make these changes reconstructable.

A change log should record what changed, why it changed, who approved it, what risks were reassessed, what evaluation was repeated, and what deployment effect is expected.

If a system changes without documentation, past decisions become harder to explain and future harms harder to prevent.

Back to top ↑

Accessibility, Audience, and Actionability

Documentation should be accessible to the people who need it. Technical teams need implementation details. Governance teams need risk and control summaries. Users need intended-use guidance and limitations. Auditors need evidence and version records. Affected people need understandable reasons, contestability information, and correction pathways.

One document may not serve every audience. Responsible documentation often requires layered artifacts: technical detail, governance summary, public explanation, user guide, and appeal-facing notice.

Documentation is not complete until it supports the decisions its audiences must make.

Back to top ↑

Contestability and Affected-Person Documentation

Affected-person documentation supports notice, explanation, appeal, correction, and remedy. It should communicate when an algorithmic system influenced a decision, what information mattered, what evidence can be reviewed, how wrong records can be corrected, how an appeal works, and what remedy is available.

Affected-person documentation should not reveal sensitive technical details unnecessarily, but it should be meaningful enough to support challenge. A person cannot contest a decision if the explanation is too vague to act on.

Documentation should serve the people affected by algorithmic systems, not only the people who operate them.

Back to top ↑

Documentation Quality

Documentation quality depends on accuracy, completeness, specificity, timeliness, accessibility, maintainability, and actionability. A long document can still be poor if it uses vague language, omits limitations, hides uncertainty, lacks ownership, or is never updated.

Documentation should be evaluated like any other governance artifact. Reviewers should ask whether the document is current, whether claims are supported by evidence, whether limitations are explicit, whether owners are named, whether risks have controls, and whether readers can make responsible decisions from it.

Documentation quality should be judged by whether it helps people act responsibly.

Back to top ↑

Representation Risk

Representation risk appears when documentation makes a system appear more responsible, transparent, fair, or well-governed than it is. A model card can become a legitimacy document rather than a warning document. A datasheet can describe data while omitting collection harms. A system card can list safeguards that do not work in practice. A risk register can record risks without assigning owners or controls.

Documentation should not be treated as proof of responsibility. It is evidence to be checked.

Documentation should reveal risk, not launder it.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

A documentation completeness score can measure how many required documentation fields are present:

A documentation quality score can combine accuracy, completeness, specificity, timeliness, accessibility, and actionability:

A documentation risk score can rise when system stakes are high and documentation quality is weak:

A maintenance freshness score can compare time since last update with required review cadence:

These formulas do not replace human review. They help detect documentation that is missing, stale, vague, or unfit for governance.

Back to top ↑

Python Workflow: Documentation Completeness Audit

The Python workflow below creates a dependency-light audit for documentation, model cards, and datasheets. It simulates algorithmic system documentation records, scores completeness, quality, freshness, actionability, and documentation risk, then writes reproducible CSV and JSON outputs.

# documentation_model_cards_datasheets_audit.py
# Dependency-light workflow for documentation completeness,
# model cards, datasheets, quality, freshness, and governance risk.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
from statistics import mean
import csv
import json
from datetime import datetime, timezone

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class DocumentationConfig:
    article: str = "documentation_model_cards_and_datasheets_for_algorithms"
    low_completeness_threshold: float = 0.80
    low_quality_threshold: float = 0.70
    high_documentation_risk_threshold: float = 0.30


def timestamp_utc() -> str:
    return datetime.now(timezone.utc).isoformat()


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        path.write_text("", encoding="utf-8")
        return
    fieldnames = sorted({key for row in rows for key in row.keys()})
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=fieldnames, extrasaction="ignore")
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def documentation_records() -> list[dict[str, object]]:
    return [
        {"system_id": "benefits_eligibility_model", "required_fields": 16, "completed_fields": 11, "accuracy": 0.62, "specificity": 0.58, "timeliness": 0.50, "accessibility": 0.56, "actionability": 0.52, "model_card": 1, "datasheet": 1, "risk_register": 1, "change_log": 0, "appeal_documentation": 1, "stakes": 0.92},
        {"system_id": "clinical_triage_support", "required_fields": 16, "completed_fields": 14, "accuracy": 0.82, "specificity": 0.78, "timeliness": 0.76, "accessibility": 0.72, "actionability": 0.76, "model_card": 1, "datasheet": 1, "risk_register": 1, "change_log": 1, "appeal_documentation": 1, "stakes": 0.96},
        {"system_id": "content_ranking_system", "required_fields": 16, "completed_fields": 10, "accuracy": 0.58, "specificity": 0.50, "timeliness": 0.44, "accessibility": 0.46, "actionability": 0.42, "model_card": 0, "datasheet": 1, "risk_register": 0, "change_log": 1, "appeal_documentation": 0, "stakes": 0.72},
        {"system_id": "document_routing_tool", "required_fields": 16, "completed_fields": 15, "accuracy": 0.86, "specificity": 0.84, "timeliness": 0.82, "accessibility": 0.78, "actionability": 0.80, "model_card": 1, "datasheet": 1, "risk_register": 1, "change_log": 1, "appeal_documentation": 1, "stakes": 0.30},
    ]


def score_record(row: dict[str, object], config: DocumentationConfig) -> dict[str, object]:
    required = float(row["required_fields"])
    completed = float(row["completed_fields"])
    completeness = 0.0 if required == 0 else completed / required
    quality = mean([
        float(row["accuracy"]),
        completeness,
        float(row["specificity"]),
        float(row["timeliness"]),
        float(row["accessibility"]),
        float(row["actionability"]),
    ])
    artifact_coverage = mean([
        float(row["model_card"]),
        float(row["datasheet"]),
        float(row["risk_register"]),
        float(row["change_log"]),
        float(row["appeal_documentation"]),
    ])
    documentation_risk = float(row["stakes"]) * (1.0 - quality)

    status = "pass"
    if (
        completeness < config.low_completeness_threshold
        or quality < config.low_quality_threshold
        or documentation_risk >= config.high_documentation_risk_threshold
    ):
        status = "review"
    if documentation_risk >= config.high_documentation_risk_threshold and artifact_coverage < 0.80:
        status = "escalate"

    return {
        "system_id": row["system_id"],
        "required_fields": int(required),
        "completed_fields": int(completed),
        "documentation_completeness_score": round(completeness, 6),
        "accuracy": round(float(row["accuracy"]), 6),
        "specificity": round(float(row["specificity"]), 6),
        "timeliness": round(float(row["timeliness"]), 6),
        "accessibility": round(float(row["accessibility"]), 6),
        "actionability": round(float(row["actionability"]), 6),
        "artifact_coverage_score": round(artifact_coverage, 6),
        "documentation_quality_score": round(quality, 6),
        "stakes": round(float(row["stakes"]), 6),
        "documentation_risk_score": round(documentation_risk, 6),
        "status": status,
    }


def documentation_register() -> list[dict[str, str]]:
    return [
        {"artifact": "model_card", "review_question": "Does the model card state purpose, intended use, evaluation, limits, and governance?", "status": "required"},
        {"artifact": "datasheet", "review_question": "Does the datasheet record dataset motivation, composition, collection, processing, uses, and maintenance?", "status": "required"},
        {"artifact": "risk_register", "review_question": "Are risks, controls, owners, and escalation triggers documented?", "status": "required"},
        {"artifact": "change_log", "review_question": "Can system, data, model, threshold, and governance changes be reconstructed?", "status": "required"},
        {"artifact": "appeal_documentation", "review_question": "Can affected people understand, challenge, and correct outcomes?", "status": "required"},
        {"artifact": "maintenance_plan", "review_question": "Is documentation reviewed and updated after changes or incidents?", "status": "required"},
    ]


def main() -> None:
    config = DocumentationConfig()
    records = documentation_records()
    audit = [score_record(row, config) for row in records]
    register = documentation_register()

    summary = {
        "article": config.article,
        "timestamp_utc": timestamp_utc(),
        "systems_reviewed": len(audit),
        "systems_passed": sum(1 for row in audit if row["status"] == "pass"),
        "systems_requiring_review": sum(1 for row in audit if row["status"] == "review"),
        "systems_escalated": sum(1 for row in audit if row["status"] == "escalate"),
        "mean_documentation_completeness_score": round(mean(float(row["documentation_completeness_score"]) for row in audit), 6),
        "mean_documentation_quality_score": round(mean(float(row["documentation_quality_score"]) for row in audit), 6),
        "mean_artifact_coverage_score": round(mean(float(row["artifact_coverage_score"]) for row in audit), 6),
        "mean_documentation_risk_score": round(mean(float(row["documentation_risk_score"]) for row in audit), 6),
        "documentation_artifacts": len(register),
        "interpretation": "Documentation review should connect model cards, datasheets, risk registers, change logs, appeal documentation, accuracy, specificity, timeliness, accessibility, and actionability.",
    }

    write_csv(TABLES / "documentation_records.csv", records)
    write_csv(TABLES / "documentation_audit.csv", audit)
    write_csv(TABLES / "documentation_register.csv", register)
    write_csv(TABLES / "documentation_audit_summary.csv", [summary])

    write_json(JSON_DIR / "documentation_config.json", asdict(config))
    write_json(JSON_DIR / "documentation_audit.json", audit)
    write_json(JSON_DIR / "documentation_register.json", register)
    write_json(JSON_DIR / "documentation_audit_summary.json", summary)

    print("Documentation, model cards, and datasheets audit complete.")
    print(TABLES / "documentation_audit_summary.csv")


if __name__ == "__main__":
    main()

This workflow turns documentation into a reproducible governance artifact: completeness, quality, artifact coverage, documentation risk, and escalation status are reviewed together.

Back to top ↑

R Workflow: Documentation Diagnostics

The R workflow reads the generated CSV outputs, summarizes documentation quality and risk, visualizes documentation components, and writes an additional diagnostic table.

# documentation_model_cards_datasheets_summary.R
args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

audit_path <- file.path(tables_dir, "documentation_audit.csv")
summary_path <- file.path(tables_dir, "documentation_audit_summary.csv")

if (!file.exists(audit_path)) {
  stop(paste("Missing", audit_path, "Run the Python workflow first."))
}

audit <- read.csv(audit_path, stringsAsFactors = FALSE)
summary <- read.csv(summary_path, stringsAsFactors = FALSE)

png(file.path(figures_dir, "documentation_quality_components.png"), width = 1200, height = 850)
score_matrix <- t(as.matrix(audit[, c("documentation_completeness_score", "accuracy", "specificity", "timeliness", "accessibility", "actionability", "artifact_coverage_score")]))
barplot(score_matrix,
        beside = TRUE,
        names.arg = audit$system_id,
        las = 2,
        ylim = c(0, 1),
        ylab = "Score",
        main = "Documentation, Model Card, and Datasheet Quality Components")
legend("bottomright",
       legend = rownames(score_matrix),
       cex = 0.68,
       bty = "n")
grid()
dev.off()

png(file.path(figures_dir, "documentation_risk_by_system.png"), width = 1000, height = 750)
barplot(audit$documentation_risk_score,
        names.arg = audit$system_id,
        las = 2,
        ylim = c(0, 1),
        ylab = "Documentation Risk Score",
        main = "Documentation Risk by Algorithmic System")
grid()
dev.off()

r_summary <- data.frame(
  systems_reviewed = summary$systems_reviewed[1],
  systems_passed = summary$systems_passed[1],
  systems_requiring_review = summary$systems_requiring_review[1],
  systems_escalated = summary$systems_escalated[1],
  mean_documentation_completeness_score = summary$mean_documentation_completeness_score[1],
  mean_documentation_quality_score = summary$mean_documentation_quality_score[1],
  mean_artifact_coverage_score = summary$mean_artifact_coverage_score[1],
  mean_documentation_risk_score = summary$mean_documentation_risk_score[1],
  documentation_artifacts = summary$documentation_artifacts[1],
  diagnostic_note = "Documentation review should connect model cards, datasheets, risk registers, change logs, appeal documentation, accuracy, specificity, timeliness, accessibility, and actionability."
)

write.csv(r_summary, file.path(tables_dir, "r_documentation_diagnostic_summary.csv"), row.names = FALSE)
print(r_summary)

The R layer turns documentation completeness and quality into visible diagnostic summaries that support governance, audit, maintenance, contestability, and remediation planning.

Back to top ↑

GitHub Repository

The companion repository contains reproducible workflows, synthetic data, audit outputs, calculators, documentation, and multilingual examples for this article.

Back to top ↑

A Practical Method for Algorithmic Documentation

Algorithmic documentation should be created before deployment, reviewed before use, updated after change, and tested during governance review.

This method treats documentation as living governance infrastructure.

Back to top ↑

Common Pitfalls

Documentation can fail when institutions treat it as a static form rather than an accountability tool.

Documentation should be evaluated by whether it prevents misuse and supports correction.

Back to top ↑

Why Documentation Must Support Accountability

Documentation, model cards, and datasheets for algorithms show why responsible algorithmic systems require more than code, metrics, and deployment pipelines. They require records that explain purpose, data, assumptions, evaluation, limitations, risks, intended uses, prohibited uses, ownership, monitoring, incidents, appeals, and remediation.

Good documentation does not make a system safe by itself. But without documentation, safety, fairness, accountability, contestability, auditability, maintenance, and repair become much harder. Documentation is the connective tissue between technical systems and institutional responsibility.

Model cards and datasheets help algorithmic systems remain reviewable as they move across teams, contexts, and time. They should reveal uncertainty, limit misuse, guide human judgment, support affected-person challenge, and make governance possible. AI belongs in the toolkit, not in control.

Back to top ↑

Related Articles

• Algorithmic Risk Management and AI Governance
• Algorithmic Accountability and Audit Trails
• Transparency, Explainability, and Interpretability
• Features, Labels, and the Politics of Measurement
• When Algorithms Should Not Be Used

Back to top ↑

Further Reading

• Mitchell, M. et al. (2019) ‘Model cards for model reporting’, Proceedings of the Conference on Fairness, Accountability, and Transparency, pp. 220–229.
• Gebru, T. et al. (2021) ‘Datasheets for datasets’, Communications of the ACM, 64(12), pp. 86–92.
• Bender, E.M. and Friedman, B. (2018) ‘Data statements for natural language processing: toward mitigating system bias and enabling better science’, Transactions of the Association for Computational Linguistics, 6, pp. 587–604.
• Holland, S. et al. (2020) ‘The dataset nutrition label: a framework to drive higher data quality standards’, Proceedings of the 2020 Conference on Human Factors in Computing Systems.
• Raji, I.D. et al. (2020) ‘Closing the AI accountability gap: defining an end-to-end framework for internal algorithmic auditing’, Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency, pp. 33–44.
• National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: NIST.
• International Organization for Standardization and International Electrotechnical Commission (2023) ISO/IEC 23894:2023 Information Technology — Artificial Intelligence — Guidance on Risk Management. Geneva: ISO/IEC.

Back to top ↑

References

• Bender, E.M. and Friedman, B. (2018) ‘Data statements for natural language processing: toward mitigating system bias and enabling better science’, Transactions of the Association for Computational Linguistics, 6, pp. 587–604. Available at: https://aclanthology.org/Q18-1041/.
• Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J.W., Wallach, H., Daumé III, H. and Crawford, K. (2021) ‘Datasheets for datasets’, Communications of the ACM, 64(12), pp. 86–92. Available at: https://doi.org/10.1145/3458723.
• Holland, S., Hosny, A., Newman, S., Joseph, J. and Chmielinski, K. (2020) ‘The dataset nutrition label: a framework to drive higher data quality standards’, Proceedings of the 2020 Conference on Human Factors in Computing Systems. Available at: https://doi.org/10.1145/3375627.3375813.
• International Organization for Standardization and International Electrotechnical Commission (2023) ISO/IEC 23894:2023 Information Technology — Artificial Intelligence — Guidance on Risk Management. Geneva: ISO/IEC. Available at: https://www.iso.org/standard/77304.html.
• Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I.D. and Gebru, T. (2019) ‘Model cards for model reporting’, Proceedings of the Conference on Fairness, Accountability, and Transparency, pp. 220–229. Available at: https://doi.org/10.1145/3287560.3287596.
• National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: NIST. Available at: https://www.nist.gov/itl/ai-risk-management-framework.
• Raji, I.D., Smart, A., White, R.N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D. and Barnes, P. (2020) ‘Closing the AI accountability gap: defining an end-to-end framework for internal algorithmic auditing’, Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency, pp. 33–44. Available at: https://doi.org/10.1145/3351095.3372873.

Back to top ↑