← Master Index
Vol. 20 Module 20.1 Lecture

Transparency

Safety, Fairness & Governance

How This Lesson Fits the Module & Volume

Explainability answers this prediction / this answer. Transparency answers what is this system, trained on what, for whom, with which known limits? Model cards, data cards, and user disclosure are the artifacts reviewers, customers, and sometimes regulators expect—alongside Vol. 19 eval numbers and Vol. 20 bias/fairness choices.

Transparency is not dumping weights or PII. It is proportionate disclosure: enough for the audience to use, contest, or refuse the system. It feeds governance, compliance, and responsible AI. Privacy constraints (next-but-one) limit what you may publish.

Learning Objectives

By the end of this lesson, students should be able to:

  • Define transparency as audience-specific disclosure, distinct from explainability.
  • List core fields of a model card and a data card.
  • Choose what to disclose to users vs internal reviewers vs the public.
  • Write a minimal YAML/JSON card plus a user-facing notice from a policy template.
  • Avoid both “transparency theater” (vague slogans) and unsafe oversharing (secrets, PII, exploit detail).
  • Link cards to bias/fairness criteria, eval harness versions, and known failure modes.
Definition

Transparency is documented, audience-appropriate disclosure about an AI system’s purpose, data, model, evaluation, limitations, and human oversight. A model card describes the model (intended use, metrics, slices, caveats). A data card describes datasets (provenance, collection, consent, known gaps). A system card covers the deployed product (tools, RAG corpus, guardrails, escalation). User disclosure is the short notice people see (“you are interacting with AI,” how to appeal). Transparency does not require publishing proprietary weights or training corpora wholesale.

Audiences and Artifacts

AudienceNeedsTypical artifact
End user / customerThat AI is in use; limits; how to get a humanIn-product notice, FAQ, ToS snippet
Internal reviewer / RAIEval protocol, slices, fairness criterion, residual risksModel + data + system cards, Vol. 19 harness commit
Procurement / partnerIntended use, out-of-scope, security/privacy postureOne-pager + card excerpts
Regulator / auditor (when required)Traceability, owners, change logGoverned dossier—see compliance
Researchers / public (optional)Reproducible claims without leaking dataPublished card, not raw PII dumps

Model Cards vs Data Cards vs Disclosure

Model card (core fields)

  • Name, version, owner, date
  • Intended use / out-of-scope
  • Architecture family (high level), not necessarily weights
  • Metrics + slices (Vol. 19 + bias)
  • Fairness criterion chosen (fairness)
  • Known limitations, ethical considerations

Data card (core fields)

  • Provenance and license (see copyright)
  • Collection method, time window, geography
  • Consent / ToS / PII status (privacy)
  • Labeling process and known noise
  • Coverage gaps and dual-use notes
  • Retention and who may access

User disclosure

  • AI involvement in plain language
  • What the system does not do (medical/legal advice, etc.)
  • How to appeal or reach a human
  • What is logged (high level)
  • No fake demographic “study” claims

Good transparency

  • Specific, versioned, owned
  • Matches actual eval harness and production flags
  • States out-of-scope uses honestly

Transparency theater

  • “We value ethics” with no metrics or owners
  • Stale cards after a silent model swap
  • Publishing PII samples or jailbreak recipes

Minimal Card + Notice (Policy-as-Code Sketch)

# transparency_stub.yaml — internal card excerpt (not a real product claim) model_card: name: "ticket-triage-v3" owner: "[email protected]" date: "2026-08-13" intended_use: - "Suggest priority and queue for internal support tickets" out_of_scope: - "Automated firing, credit, or medical decisions" - "User-facing legal advice" evaluation: harness_commit: "eval-harness@abc123" metrics: ["macro_f1", "p95_latency_ms"] slice_protocol: "toy groups only in staging; see bias.html lecture rules" fairness_criterion: "equal opportunity TPR gap < 0.05 on approved slices" explainability: "permutation importance weekly; RAG citations required in UI" limitations: - "Dialect coverage untested outside labeled eval set" - "Do not treat suggestions as final without agent confirm" data_card: corpus: "internal tickets 2024-H2 (licensed/owned)" pii: "minimized; see retention 90 days in privacy policy" license: "internal; not for third-party training" # User-facing disclosure snippet (plain language): USER_NOTICE = """ This assistant suggests ticket routing. A human agent confirms before action. It can be wrong. It is not legal, medical, or HR advice. Ask for a person anytime. We log ticket text to improve routing for 90 days. """ print(USER_NOTICE.strip())

Related Lectures

LectureRole
ExplainabilityPer-decision reasons vs card-level disclosure
Bias / FairnessWhat slice metrics and criteria belong on the card
PrivacyWhat you must not publish or over-retain
CopyrightLicense fields on the data card
GovernanceWho approves and versions cards
Benchmarks (Vol. 19)Cite harness, not screenshot vibes
Common Misconception

“Transparency means open-sourcing the weights.” Often the useful artifact is a card plus user notice, not a weight dump. Second: a slogan page with no version, owner, or eval commit. Third: copying another vendor’s model card numbers as if they were yours. Fourth: publishing sample rows that contain PII. Fifth: treating explainability plots as the model card. Sixth: never updating the card after a prompt or retrieval-corpus change.

Knowledge Check

  1. Short Answer: What is transparency in this lecture? Answer: Audience-appropriate disclosure about purpose, data, model, eval, limits, and oversight.
  2. True/False: Explainability and transparency are the same artifact. Answer: False—reasons for an output vs system disclosure.
  3. Multiple Choice: A data card primarily documents: (a) dataset provenance, consent, gaps, license, (b) SGD hyperparameters only, (c) CSS themes. Answer: (a).
  4. Short Answer: Name two model-card fields. Answer: Any of: intended use, out-of-scope, metrics/slices, fairness criterion, limitations, owner/version.
  5. True/False: User disclosure should state that AI is in use and how to reach a human when relevant. Answer: True.
  6. Multiple Choice: Transparency theater looks like: (a) ethics slogans with no metrics or owners, (b) versioned cards tied to a harness commit, (c) clear out-of-scope lists. Answer: (a).
  7. Short Answer: Why mention the eval harness commit on the card? Answer: So reported metrics are reproducible under the same Vol. 19 protocol.
  8. True/False: Publishing PII samples is required for a good data card. Answer: False—describe the data without dumping secrets.
  9. Multiple Choice: After a silent model or corpus swap you should: (a) version and update the card, (b) leave the old card, (c) delete all docs. Answer: (a).
  10. Short Answer: Which sibling lecture covers license lines on the data card? Answer: Copyright.

Key Takeaways

  • Transparency is proportionate disclosure—model cards, data cards, system cards, user notices.
  • Cards need owners, versions, intended use, eval protocol, slices/fairness, and honest limits.
  • Do not confuse SHAP plots, open weights, or marketing slogans with a card.
  • Never publish PII or attack recipes in the name of openness.
  • Next: Privacy — what you may collect, keep, and leak.
Trainer’s Guide

Lab: Students fill the YAML stub for a fictional internal bot. Peer-review: can a new engineer tell intended use, out-of-scope, eval commit, and appeal path in under two minutes? Red-team the card for PII overshare.

Whiteboard: Three columns—User notice / Internal card / Public excerpt. Arrow constraints from Privacy and Copyright into what may be written.

Recap: Transparency is versioned, owned disclosure—cards and notices—not unexplained plots or weight dumps. Bind cards to Vol. 19 evals and Vol. 20 fairness choices, then continue to Privacy.