Skip to content

L8.7 — Author a model card + risk assessment for the M1 RAG app (Lab)

Type: Lab · Duration: ~60 min · Status: Mandatory Module: Module 8 — AI Governance, Risk & Compliance Framework tags: NIST AI RMF Govern 1.3, Map 4.1 · EU AI Act Article 11 + Annex IV

Goal of the lab

Author a complete governance package for the Module 1 Asfela handbook RAG application: a system card, a model card for any fine-tuned components, a risk assessment, and an EU AI Act Article 11-shaped documentation skeleton. The package consolidates artifacts you've produced across the entire course.

Why this matters

This is the artifact you hand to an enterprise customer, an auditor, or a regulator. It's also the artifact you'd produce on a job interview to demonstrate AI security engineering competence. The lab gives you a complete, real (if small) example.

Prerequisites

  • Lessons: L8.1.1 through L8.6.1.
  • Labs completed across the course: L1.7 (RAG built), L2.6 (threat model), L4.9 (AI-BOM, if you did the optional), L7.7 (defenses), L7.9 (logging stack).

What you'll build

  • runs/lab8_7/system-card.md — system-level documentation
  • runs/lab8_7/model-card.md — model documentation (for the embedding model; the LLM is vendor-supplied so we reference the vendor's card)
  • runs/lab8_7/risk-assessment.md — formal risk assessment with NIST RMF and EU AI Act framing
  • runs/lab8_7/article-11-package.md — Article 11/Annex IV-shaped skeleton consolidating everything

Steps

Step 1 — Open the templates

cd /workspace/ai-sec-course
mkdir -p runs/lab8_7
cp templates/governance/system-card-template.md runs/lab8_7/system-card.md
cp templates/governance/model-card-template.md runs/lab8_7/model-card.md
cp templates/governance/risk-assessment-template.md runs/lab8_7/risk-assessment.md
cp templates/governance/article-11-template.md runs/lab8_7/article-11-package.md
$EDITOR runs/lab8_7/

Templates pre-structured with all required sections. Your job is to fill them with the M1 RAG's specifics.

Step 2 — System card for the Asfela handbook RAG

Open runs/lab8_7/system-card.md. Fill in:

# System Card: Asfela Handbook RAG

## Overview
- **System name:** Asfela Handbook RAG (Module 1 reference implementation)
- **Version:** 0.1 (lab)
- **Purpose:** Answer employee questions about the Asfela company handbook
- **Owner:** Asfela engineering (development); Asfela security (oversight)
- **Risk tier (EU AI Act):** Limited (employee-facing internal tool, not high-risk category)

## Components
- **LLM backend:** llama3.2:3b (local) and gpt-4o-mini (frontier comparison) — vendor-supplied; see vendor model cards
- **Embedding model:** all-MiniLM-L6-v2 (sentence-transformers); see model-card.md for our characterization
- **Vector DB:** Chroma; persistent local
- **Corpus:** Asfela handbook (7 markdown files); see runs/lab2_6/threat-model.md for trust-boundary analysis
- **System prompt:** sources-only refusal-enabled; versioned at runs/lab8_7/system-prompts/v0.1.txt

## Intended use
[Fill in: who uses it, for what, in what contexts]

## Out-of-scope use
[Fill in: external customers, legal/medical/financial advice, decision-making about people]

## Safety + robustness measurements
- Prompt injection: attack-success-rate baseline 85% (L3.7); with full defense stack 5% (L7.7)
- Membership inference: not applicable (no fine-tune on sensitive data in lab)
- Output PII redaction: Presidio active (L7.9)

## Operational controls
- Runtime guardrails: Llama Guard input filter, structured output, dual-LLM extraction (L7.7)
- Observability: prompt/response logging with Presidio redaction (L7.9)
- Eval suite: promptfoo safety-suite in CI (L7.8)
- IR playbook: documented (L7.9 tabletop transcript)

## Known limitations
[Fill in: model size limitations, RAG grounding limitations, etc.]

## References
- Threat model: runs/lab2_6/threat-model.md
- Defense measurements: runs/lab7_7/comparison.md
- IR tabletop: runs/lab7_9/tabletop.md

Step 3 — Model card for the embedding model

Open runs/lab8_7/model-card.md. The embedding model all-MiniLM-L6-v2 is open-source from sentence-transformers; we're characterizing how we use it. Fill the eight sections from L8.5.1.

The most important section to write yourself: Intended use (in the Asfela RAG context) and Out-of-scope use (e.g., not for similarity search over PII-bearing documents without redaction).

Step 4 — Risk assessment

Open runs/lab8_7/risk-assessment.md. Structure:

# Risk Assessment: Asfela Handbook RAG

## Risk register
| ID | Risk | Severity | Likelihood | Mitigation status | Citations |
|---|---|---|---|---|---|
| R-001 | Indirect prompt injection via corpus | High | Medium | Mitigated by dual-LLM (L7.7) | OWASP LLM01; ATLAS AML.T0051.001; NIST Measure 2.7 |
| R-002 | System prompt extraction | Medium | Medium | Mitigated by output filter | OWASP LLM07; ATLAS AML.T0057 |
| R-003 | Embedding leak from vector DB | Medium | Low | Partial: access control on DB | OWASP LLM06; ATLAS AML.T0048 |
| R-004 | Hallucinated handbook content | Medium | Medium | Partial: grounding instruction | OWASP LLM09 |
| R-005 | Cost DoS (token bomb) | Low | Low | No rate limit in lab | OWASP LLM04 |
...

Add at least 8 entries from your L2.6 threat model.

Residual risk acceptance

[Fill in: what risks remain and why they're acceptable]

Governance + review cadence

[Fill in: quarterly review; ownership] 

### Step 5 — Article 11 / Annex IV skeleton
Open `runs/lab8_7/article-11-package.md`. The skeleton has all eight Annex IV sections (from L8.2.2). Reference the other artifacts rather than re-stating content:

```markdown
# Technical Documentation: Asfela Handbook RAG
*(Per EU AI Act Article 11 + Annex IV)*

## Section 1: General description
[See system-card.md "Overview"]

## Section 2: Detailed description
[See system-card.md "Components" + threat-model.md (L2.6)]

## Section 3: Monitoring, functioning, control
[See system-card.md "Safety + robustness measurements" + observability stack docs]

## Section 4: Risk management system per Article 9
[See risk-assessment.md]

## Section 5: Changes through lifecycle
- 2026-05-16: Initial lab implementation (v0.1)
- ...

## Section 6: Standards applied
- NIST AI RMF 1.0
- NIST AI 600-1 (GenAI Profile)
- OWASP Top 10 for LLM Applications
- MITRE ATLAS

## Section 7: EU declaration of conformity
[N/A for lab; would be populated post-conformity-assessment for production]

## Section 8: Post-market monitoring plan
[See system-card.md "Observability" + IR playbook (L7.9)]

The references make the package compact (you don't re-write content) and the structure satisfies the regulatory requirement.

Step 6 — Self-review against the auditor rubric

Before submitting, walk the auditor checklist from L8.2.2:

  • Completeness. All eight Annex IV sections present? Yes/No.
  • Internal consistency. Risk register entries reference back to threat model? Mitigations described in system card? Yes/No.
  • Currency. Versions and dates updated? Yes/No.
  • Linkable evidence. Every claim points at an underlying artifact? Yes/No.

If you scored 4/4, you have a working package. Iterate on any gap.

Step 7 — Optional: write the procurement-friendly summary

The L8.5.1 lesson emphasized the engineer-vs-procurement audience confusion. Write a 1-page summary at the top of system-card.md for a procurement reviewer who won't read past page 2.

Two paragraphs: 1. What it is — purpose, intended users, risk tier. 2. Safety posture — controls in place, eval results, IR readiness, third-party attestations (none for lab).

This is the section enterprise buyers actually read.

What just happened (debrief)

You produced the artifact that an enterprise customer / auditor / regulator can consume. Three takeaways:

Consolidation, not creation. You didn't generate new content; you assembled artifacts you'd produced across M1-M7 into a governance package. This is the realistic shape of governance work: most artifacts exist as engineering outputs already; the governance work is in structuring, referencing, and signing off.

References > restatement. The Article 11 package was 1 page of references plus 8 sections of pointers. Versus re-stating content, this scales: the underlying artifacts evolve at engineering pace; the references stay valid.

Audience matters. You wrote a procurement-friendly summary up top + technical depth below. Same artifact serves both audiences when structured correctly.

This package is what you'd hand: - An enterprise customer's security questionnaire - A regulator inquiry (EU AI Act Article 11 fulfillment) - An auditor's annual review - A new AI security engineer joining your team needing to understand the system

In a job interview, "show me a governance artifact you've authored" is increasingly a standard request. This is your answer.

Extension challenges (optional)

  • Easy. Add a sixth artifact: an AI-BOM (runs/lab8_7/aibom.cdx.json) generated from L4.9. Reference it from Section 2.
  • Medium. Write a customer-facing FAQ (runs/lab8_7/customer-faq.md) addressing the most common security questions a B2B SaaS customer would ask about the RAG.
  • Hard. Run the package through a "red-team review" — give it to a colleague (or yourself in another session) playing the auditor's role; have them list every claim they can't verify from the underlying artifacts. Fix the gaps.

References

  • L8.1.1, L8.2.1, L8.2.2, L8.5.1, L8.5.2 (theory).
  • L2.6 (threat model — feeds risk register).
  • L4.9 (AI-BOM — feeds Annex IV Section 2).
  • L7.7, L7.8, L7.9 (defenses — feed safety measurements).

Provisioning spec (for lab platform admin)

Container base image: aisec/labs-base:0.1. No additional binaries needed.

Additional pre-installed files: - /workspace/ai-sec-course/templates/governance/system-card-template.md, model-card-template.md, risk-assessment-template.md, article-11-template.md

Resource use: Trivial (text editing only). Wallclock 50-80 min.

Notes: This is the lab where prior-module artifacts (runs/lab2_6, runs/lab7_7, etc.) matter most. If the platform doesn't preserve runs/ across module sessions, the lab includes "if those don't exist, here are reference versions" instructions.