Model cards, lineage, and audit trails
Lesson 1 of 3 in Governance and Responsible AI.
Governance is the ability to answer hard questions with evidence: what did the system say, why, under which configuration, built from which data, approved by whom? Each question has a named instrument, and knowing which answers which is the whole of this topic.
The documentation anchor is SageMaker Model Cards — the model's factsheet: intended uses, limitations, expected performance, evaluation results, and a risk rating (unknown, low, medium, high) your org can gate deployments on. The exam's adjective is programmatic: cards are created and updated from the pipeline via API/SDK, auto-populating training details for SageMaker-trained models and accepting bring-your-own-information for everything else — including the FM-based systems this certification is about. Two properties make them governance-grade rather than a wiki page: versions are immutable (any content change creates a new version — tamper-evident history), and the status workflow (draft → pending review → approved) emits EventBridge events, so "nothing unapproved reaches production" becomes an automated gate instead of a meeting.
Two of those links deserve the professional footnotes. Lineage: the Glue Data Catalog is the registry — data sources for your KB corpora and tuning sets get registered, tagged, and crawled there. Lineage capture is increasingly automatic: data-source runs record lineage as crawlers ingest, and Glue jobs can emit OpenLineage-compatible events, rendered as a versioned, column-level graph in the SageMaker/DataZone catalog. Metadata tagging for source attribution extends the chain into the model's output: tag documents with source IDs at ingestion, carry those IDs through chunk metadata, and make the application cite them — an FM answer that names doc-4471 is traceable; one that names nothing is folklore.
Audit splits into two instruments the exam loves to swap: CloudTrail records API activity — who created the guardrail, who changed the agent, who read the bucket (management events by default, S3/data events opt-in). Model invocation logging records content — the prompts and responses themselves. "Who modified the configuration?" is CloudTrail; "what did the model actually say?" is invocation logging; a complete audit story needs both.
| The auditor asks… | Instrument | Enabled by |
|---|---|---|
“What exactly did the model say?” | Model invocation logging + CloudWatch decision logs | Opt-in account setting; destinations S3 and/or CloudWatch Logs |
“Under which instructions?” | Prompt Management versions | Authoring prompts as managed, immutably versioned artifacts |
“What is this model for, and how risky?” | Model card — intended uses, limitations, risk rating | Programmatic card creation in the pipeline; status workflow + EventBridge |
“Built from which data?” | Glue Data Catalog + lineage graph | Source registration, crawler/data-source runs, OpenLineage events from jobs |
“Who changed the configuration?” | On by default for management events; data events opt-in |
Key terms: SageMaker Model Cards, Data lineage, Model invocation logging, AWS CloudTrail
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.