AI System Card
Document what your deployed model does, where it fails, and who owns it.
A standard system card you publish alongside any model that ships to production. Forces you to name limits, owners, and monitoring before launch.
[SYSTEM NAME] ·[VERSION] ·[OWNER TEAM] ·[OWNER EMAIL] ·[MODEL] ·[DEPLOYMENT DATE] ·[REVIEW DATE]
# System Card: [SYSTEM NAME]
**Version:** [VERSION]
**Deployed:** [DEPLOYMENT DATE]
**Next review:** [REVIEW DATE]
**Owner:** [OWNER TEAM] ([OWNER EMAIL])
---
## 1. System overview
*Fill this in: one paragraph. What the system does, what model powers it, who uses it. Plain words.*
- Base model: [MODEL]
- Wrapper / pipeline: [RAG, agent loop, fine-tune, plain chat]
- Primary interface: [API, web app, internal tool]
## 2. Intended uses
*Fill this in: bullet the 3-5 concrete tasks this system is built for. Be specific. "Summarize claims documents under 20 pages" beats "document understanding."*
- [Use 1]
- [Use 2]
- [Use 3]
## 3. Out-of-scope uses
*Fill this in: what this system must NOT be used for. Name them. Legal advice, medical diagnosis, autonomous decisions on people, classified data, etc.*
- [Out-of-scope 1]
- [Out-of-scope 2]
## 4. Training data summary
*Fill this in: if you fine-tuned, name the dataset, size, source, and license. If you use a base model only, say so and link the vendor's data sheet.*
- Base model training data: [vendor disclosure link]
- Fine-tune data: [source, size, license, date range]
- Retrieval corpus (if RAG): [source, size, refresh cadence]
## 5. Evaluation results
*Fill this in: name the eval set, the metric, and the score. Include date. If you do not have an eval set, that is the first thing to fix.*
| Eval set | Metric | Score | Date |
|---|---|---|---|
| [name] | [accuracy / pass@1 / human rating] | [score] | [date] |
## 6. Known limitations
*Fill this in: where the system breaks. Be honest. "Fails on tables longer than 50 rows." "Hallucinates citations for questions outside the corpus."*
- [Limit 1]
- [Limit 2]
## 7. Bias and fairness
*Fill this in: groups you tested across, what you found, what you did about it. If you did not test, say so.*
- Groups tested: [list]
- Findings: [text]
- Mitigations: [text]
## 8. Security considerations
*Fill this in: prompt injection posture, data handling, PII exposure, auth model, logging policy.*
- Input filtering: [yes/no, what]
- Output filtering: [yes/no, what]
- PII handling: [text]
- Auth: [text]
## 9. Monitoring plan
*Fill this in: what you watch, where it lives, who pages.*
- Metrics: [latency, error rate, refusal rate, cost per call]
- Quality signals: [thumbs, eval drift, sampled human review]
- Alert thresholds: [text]
- On-call: [team or rotation name]
## 10. Owners and points of contact
- Product owner: [name, email]
- Engineering owner: [name, email]
- Security contact: [name, email]
- Incident channel: [#slack-channel or pager]
## 11. Version history
| Version | Date | Change |
|---|---|---|
| [VERSION] | [DEPLOYMENT DATE] | Initial deploy |
---
## How to use
Publish the system card in the same repo as the deployment code. Update it on every model version bump or eval refresh. If a section is empty, that is a finding. Fix it before launch, not after. Pair this with the risk register and threat model for federal reviews.CHECK BEFORE YOU USE IT
- No empty sections at launch. An empty section is a finding, not a formatting choice.
- The eval table holds a real set, score, and date. Not a plan to have one.
- Owner emails are current. Post once in the incident channel to confirm it is live.
- Re-read the limitations section against the latest eval run, not the launch run.