Phase 7: Responsible AI, Governance & Risk · 40 min · Model/system cards · Python
Transparency & Explainability
The ML team's model card is written for the next engineer. Your system card is written for the person it affects.
Hiring signal: Enterprise buyers and regulators increasingly ask for user-facing disclosure and a product-level system card as a condition of purchase or launch, separate from any internal ML model card. AI PMs who can write disclosure language that satisfies legal, doesn't scare users, and is still technically honest are a specific, named hiring signal in AI PM interview loops.
What you will learn
- Decide what to disclose to users about an AI feature, and when disclosure is required versus optional
- Distinguish a product-facing system card from an ML team's internal model card
- Write disclosure language that is honest, specific, and doesn't create unnecessary alarm or false reassurance
- Produce a complete product-facing system card for a real AI feature
The Problem
A healthcare scheduling startup launches an AI feature that predicts which patients are likely to no-show an appointment and proactively double-books their slot. It works — no-show losses drop 30%. Then a patient who showed up on time, only to be told their appointment was given away because the algorithm predicted they wouldn't come, posts about it. The company's engineering team has a thorough internal model card: training data, feature list, AUC, calibration plots. None of it says one sentence in language the patient could have understood before it happened to them: "We predict no-show risk and may adjust scheduling accordingly."
The model card wasn't wrong. It was written for the wrong audience. A model card documents a model for the people who build and maintain it — data scientists, ML engineers, auditors. It answers "what data, what architecture, what known limitations." A product-facing system card answers a completely different question: what does a person interacting with or affected by this system need to know, in language they can act on? Conflating the two — assuming the internal model card "covers" transparency because it exists — is the actual root cause of the story above, and it's an extremely common one.
What to Disclose, and When
Not every AI feature needs the same level of disclosure. A useful way to calibrate: disclosure obligation scales with consequence and surprise, not with technical sophistication.
- Always disclose the AI is present when a reasonable person would otherwise assume they're interacting with a human, or when the output looks like it could be human-authored (chat, generated summaries, synthetic voice). This is close to a legal floor in many jurisdictions now (see Lesson 3), not just best practice.
- Disclose the mechanism when a decision is consequential — not the model architecture, but what the system does and doesn't do. "We use an automated system to flag applications for additional review" is disclosure. "We use a gradient-boosted ensemble trained on 40 features" is not disclosure, it's noise that satisfies no one.
- Disclose limitations that change user behavior appropriately — if a system can be confidently wrong (most generative AI features), users need to know that before they rely on it, not as a buried terms-of-service clause. "This summary may omit or misstate details — verify anything you'll act on" is a limitation disclosure that actually changes how a careful user behaves.
- Disclose an appeal or override path if one exists — and if the consequence is high enough (per Lesson 1's severity/reversibility framework), the absence of an appeal path is itself something to disclose, or better, something to build before launch.
Disclosure is not a liability shield if the underlying decision is unfair
A well-written disclosure ("this recommendation is generated by AI and may be imperfect") does not fix a false-positive-parity gap from Lesson 1 — it just tells the affected person the system might be wrong, without telling them it's disproportionately wrong about people like them. Regulators, journalists, and increasingly your own users treat "we disclosed it" and "we disclosed it clearly enough to matter" as different bars. Transparency is a complement to responsible design, not a substitute for it.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers The Product-Facing System Card, Writing Disclosure Language That Actually Works, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy