az9713 /generate-eu-ai-act-system-card
Generates a per-service EU AI Act system card. The August 2026 deadline applies to organizations operating AI systems in the EU — documentation requirements vary by risk level but the practice of documenting AI usage is good hygiene regardless.
What a system card is and why it matters
The EU AI Act requires organizations to maintain technical documentation for AI systems describing: intended purpose, capabilities and limitations, data used, performance metrics, human oversight mechanisms, and identified risks. For most teams using AI-assisted code generation, the obligation attaches not to the LLM tool itself but to what the service does with AI assistance — especially if AI contributes to decisions that affect users.
A system card answers the question: "If a regulator asked how AI is used in this service, what would you tell them?" Writing it before you're asked forces an honest accounting of AI usage and identifies oversight gaps before they become compliance problems.
Arguments
path/to/service— required; the service directory to document--risk-level limited|general|high— optional; if omitted, ask the user
Phase 1: Read context files
Read MODULE_MANIFEST.md and BEHAVIORAL_CONTRACTS.md from the target service directory (and parent directories if the service has sub-modules). Extract:
- Service purpose and scope
- Data types processed (data classification fields)
- External services and dependencies
- Owner / responsible team
- Any existing AI-related notes
If no MODULE_MANIFEST.md exists for the service, say so before proceeding:
No MODULE_MANIFEST.md found for [service]. I can still generate a system card from the
interview, but the documentation will be less complete. Consider running
/context-layer-generator on this service first.
Continue anyway? (yes/no)
Phase 2: Determine risk classification
If --risk-level was provided, use it. Otherwise, present the classification framework:
EU AI Act risk classifications:
PROHIBITED — systems banned entirely (manipulation, social scoring, real-time biometric surveillance)
HIGH-RISK — specific sectors: biometric ID, critical infrastructure, education/employment decisions,
essential services, law enforcement, migration, justice (requires conformity assessment)
LIMITED RISK — chatbots, deepfakes, emotion recognition (transparency obligations)
MINIMAL/NO RISK — most software tools, code generation, recommendation systems
For this service ([service name]):
- If AI contributes to employment or hiring decisions → likely HIGH-RISK
- If AI contributes to credit, insurance, or benefits decisions → likely HIGH-RISK
- If AI is used for code generation, testing, or internal tooling → likely MINIMAL RISK
- If the service exposes an AI chatbot to users → likely LIMITED RISK
What is the risk classification for [service name]?
Note: the classification of the tool (e.g., the LLM) and the classification of the service may differ. A minimal-risk code generation tool can produce a high-risk system. Document what the service does, not what model it uses.
Phase 3: Interview
Ask these questions. Phrase them plainly — the answers go into a document that a non-technical regulator may read:
AI usage:
- Which AI tools are used in [service name] and for what purpose? (Code generation / content generation / decision support / automated processing / other)
- Are AI tools making or contributing to decisions that directly affect users — approvals, rejections, rankings, recommendations? If yes, what decisions?
- Is there a human review step before AI-assisted decisions are applied to users?
- Can the service's AI-assisted behavior be explained to an affected user on request?
Performance: 5. How was the AI-assisted functionality tested before deployment? 6. Are there known cases where the AI produces incorrect, biased, or unexpected outputs? 7. What monitoring is in place to detect degraded AI performance in production?
Human oversight: 8. Can a human override or reverse an AI-assisted decision? How? 9. Is there a process for users to request human review of an AI-assisted decision? 10. Who is accountable for monitoring this system's AI behavior?
Incident history: 11. Has the AI produced incorrect, unexpected, or harmful outputs in this service? If yes, what happened and what safeguards were added?
If the user can't answer a question, mark it [OPEN QUESTION — requires input from responsible party].
Phase 4: Write the system card
Write to docs/compliance/eu-ai-act-system-card-<service-name>-YYYY-MM-DD.md. Derive <service-name> from the directory name — strip path separators, use hyphens.
# EU AI Act System Card: [Service Name]
**Risk classification:** [Minimal / Limited / High]
**Regulation basis:** EU Artificial Intelligence Act, [relevant articles for risk level]
**Last updated:** [today's date]
**Responsible party:** [owner from MODULE_MANIFEST.md, or from interview]
**Status:** DRAFT — requires legal review
> **This document was generated from code context files and a structured interview. It requires
> legal review before use as an EU AI Act compliance document.** EU AI Act obligations vary
> significantly by risk classification and use case. Engage legal counsel with EU AI Act expertise
> before submitting this as compliance documentation.
---
## 1. System Description
### Intended purpose
[What the service does and why AI is used in it — from MODULE_MANIFEST.md purpose + interview]
### AI tools used
[Which AI tools, for what purpose, at what stage of the workflow — from interview Q1]
### Capabilities
[What the AI-assisted parts of the service can do]
### Limitations
[Known limitations, failure modes, edge cases — from interview Q6]
---
## 2. Data
### Input data
[What data is provided to AI tooling — from MODULE_MANIFEST.md data classification and interview]
### Output data
[What the AI produces — from BEHAVIORAL_CONTRACTS.md and interview]
### Training data (if applicable)
[If a custom or fine-tuned model is used: what data was it trained on. If using a third-party model: note that training data is governed by the model provider's documentation.]
---
## 3. Performance
### Evaluation methodology
[How AI-assisted functionality was tested before deployment — from interview Q5]
### Known performance gaps
[Cases where the system is known to perform poorly — from interview Q6]
### Monitoring in place
[How ongoing performance is tracked — from interview Q7]
---
## 4. Human Oversight
### Override mechanism
[Can a human reverse AI-assisted decisions? How? — from interview Q8]
### User recourse
[Can affected users request human review? — from interview Q9]
### Responsible personnel
[Who monitors this system and is accountable for its behavior — from interview Q10]
---
## 5. Risk Assessment
### Risks identified before deployment
[What risks were identified before deployment]
### Mitigations in place
[What safeguards address each risk]
### Residual risks
[Risks that were identified but not fully mitigated]
---
## 6. Incident Log
[Summary of any AI-related incidents, outcomes, and remediation steps — from interview Q11.
If none: "No AI-related incidents recorded as of [date]."]
---
## 7. Open Questions
[Fields that could not be populated — require input from responsible party or legal review before
this document is considered complete]
After writing
Report:
- Service name and risk classification documented
- How many open questions remain
- Whether MODULE_MANIFEST.md was available (affects completeness)
- Path to the generated file
If the risk classification is HIGH-RISK, note explicitly:
HIGH-RISK classification: This service may require a conformity assessment under the EU AI Act.
Conformity assessments for high-risk AI systems require a notified body in some cases.
Legal review of the classification and assessment requirements is strongly recommended.