🧭 Final Day — Bringing It All TogetherThe Architecture of a Complete AI Security Program
You have spent 14 days building the knowledge, frameworks, skills, and governance artifacts of AI cybersecurity. Today is the day those pieces are assembled into a coherent program — not a collection of lessons, but a working design for an organization that takes AI security seriously. The capstone presentation is the test of whether you can explain, defend, and connect every element you have learned.
The organizing question for today's synthesis: What does a trustworthy AI system actually require? NIST AI RMF 1.0 defines seven trustworthiness characteristics — valid and reliable, safe, secure and resilient, explainable and interpretable, accountable and transparent, privacy-enhanced, and fair with bias managed. Every lesson in AI-103 maps to one or more of these characteristics. The capstone presentation demonstrates that you can build a program that addresses all seven — not just the ones that look like traditional cybersecurity.
🏗️ Final Analogy: The Structural Engineer's Stamp
A structural engineer who stamps a set of building plans is certifying that every element — foundation, framing, load paths, connections, materials — has been designed to work together as a system. No individual element is correct in isolation; correctness is a property of the whole design. An engineer who stamps plans without understanding how the load paths connect isn't an engineer — they're a rubber stamp.
The capstone presentation is your engineer's stamp. It certifies that you understand how governance connects to architecture, how architecture connects to vendor risk, how vendor risk connects to incident response, and how incident response connects back to governance improvement. A presentation that covers each domain in isolation — "here is the AUP, here is the vendor assessment, here are the architecture layers" — without showing how they interact is not a program. It is a stack of documents. The program is the connections.
Connecting All 15 Days — The Knowledge Architecture
Synthesis · 30 minThe 15-Day Knowledge Architecture — Click Any Day to Review
The 15 days of AI-103 are organized into five units, each building on the previous. Click any day tile below to review the core concept, its framework connections, and its relationship to adjacent days — this is the synthesis map you will draw on during your capstone presentation.
The Three Threads Running Through All 15 Days
No matter which day you are synthesizing, three threads appear in every lesson. Understanding these threads is the key to a coherent capstone presentation.
Every lesson reinforces a single architectural principle: security controls designed into an AI system from inception produce fundamentally better outcomes than controls added after deployment. This appears in Day 1 (why traditional security fails AI), Day 9 (ML pipeline security — the preprocessing script is an attack surface), Day 11 (defense in depth must be designed before the model is deployed), and Day 14 (red team testing before deployment costs orders of magnitude less than incident response after).
In your capstone, this thread manifests in the Use Case Register's pre-deployment gate, the Architecture Design Document's seven-layer control model, and the red team testing requirement before any system reaches production. An evaluator who asks "why do you require pre-deployment red team testing?" is asking about this thread — and the answer is not "because the framework says so" but "because the cost of finding a vulnerability in testing is always lower than the cost of discovering it through an incident."
The governance thread appears first in Day 2 (frameworks as the language auditors speak), deepens in Days 4 and 5 (NIST AI RMF MANAGE and EU AI Act obligations), and culminates in Day 13 (the documents themselves). The insight that runs through all four: a security program that exists only in engineers' heads is tribal custom, not governance. Governance is the act of making security legible to outsiders — auditors, regulators, insurers, board members — who were not in the room when the decisions were made.
In your capstone, this thread manifests as the explicit connection between technical controls and their governing documents. The architecture layer controls in the Architecture Design Document are not free-floating — they are governed by the AI AUP (which prohibits certain data uses), tracked in the Use Case Register (which records the risk tier and review cadence), and evidenced by the records layer in the ISO 42001 document hierarchy. An evaluator who asks "how would an auditor verify this control is operating?" is testing whether you understand this thread.
The vendor/deployer thread runs from Day 6 (shadow AI — employees bring AI the organization doesn't know about), through Day 12 (vendor supply chain — the AI your vendors deployed in your sanctioned tools), into Day 13 (the AUP must address shadow AI and vendor AI simultaneously), and surfaces in Day 14 (tabletop scenario 2 — the vulnerability existed in a vendor's system that MVCC didn't know about). The unifying insight: regulatory and governance obligations fall on the deployer regardless of whether the AI was intentionally deployed.
In your capstone, this thread manifests as the explicit connection between the AI Use Case Register (which must capture embedded vendor AI, not just intentional deployments), the vendor assessment (Lesson 12 framework), the AUP's shadow AI section, and the AIBOM requirement. An evaluator who asks "how does your program handle AI you didn't choose to deploy?" is testing this thread — and the answer requires the Use Case Register, AUP, and vendor contract clause to work together as a system, not in isolation.
Trustworthiness Deep Dive · 30 minNIST AI RMF's Seven Trustworthiness Characteristics — Where Each Lives in AI-103
NIST AI RMF defines seven characteristics that AI systems must exhibit to be considered trustworthy. These are not seven separate programs — they are seven properties that a single, coherent AI security program must produce simultaneously. Click each characteristic to see which lessons, frameworks, and governance documents address it — and where the hardest tradeoffs arise.
Capstone Requirements · 20 minThe AI Security Program Pack — What You Are Presenting
The AI Security Program Pack is the final deliverable of AI-103. It integrates the work products from every lesson into a single, coherent AI security program designed for a specified organizational context. Each component has been partially built across the course; today you integrate them and present the unified program.
🔑 What "Coherent" Means in the Evaluation Rubric
A coherent program is not a collection of independently produced documents. It is a program where each component explicitly references the others. The AUP's data classification matrix determines what the Use Case Register flags as requiring vendor assessment. The vendor assessment findings determine which contract clauses the program requires. The contract clauses determine what evidence the IR Annex can call on during an incident. The IR Annex's lessons-learned output feeds back into the governance program as improvements. An evaluator reading your program pack should be able to trace this chain in both directions.
Integration Requirements — The Connections That Make It Coherent
Beyond the individual components, your program pack must demonstrate three explicit cross-document connections that an evaluator can verify:
The AI AUP's data classification matrix (which data categories are prohibited in which AI tool tiers) must drive the Use Case Register's data classification field for each AI system. The Use Case Register's EU AI Act risk tier must determine which Architecture Design Document layers receive mandatory controls versus optional controls. An evaluator should be able to take one AI system from your Use Case Register, trace its data classification to the AUP, and confirm that the architecture controls align with both.
Where to make this explicit: Add a footnote in the Use Case Register that says "Data classification derived from AI AUP Section 2, Data Classification Matrix." Add a sentence in the Architecture Design Document that says "Control requirements at each layer are calibrated to the system's EU AI Act risk tier as documented in the Use Case Register."
The vendor risk assessment findings for a Tier 1 vendor must generate specific contract clause requirements. The AIBOM delivered under the contract must be referenced in the Use Case Register's linked documents field for the system that vendor provides. An evaluator should be able to name a vendor from your program and trace the tier classification → assessment findings → contract requirements → AIBOM reference chain.
Where to make this explicit: The Vendor Risk Assessment Report (Lesson 12 artifact) should end with a "Required Contract Clauses" section that explicitly lists the clauses triggered by the findings. The Use Case Register entry for the vendor's system should include a field: "Vendor contract reference: [contract ID, date]" and "AIBOM on file: [yes/no, date]."
The AI IR Annex (Lesson 13) specifies that every incident produces a lessons-learned report (Lesson 14). That report must identify which governance document requires updating as a result of the incident. An evaluator should be able to take a tabletop exercise outcome and trace it to a specific change in the AUP, Use Case Register, or IR Annex itself. This is the ISO 42001 Clause 10 (continual improvement) cycle made explicit.
Where to make this explicit: The lessons-learned report template in your IR Annex should include a mandatory field: "Documents requiring update as a result of this incident: [AUP / Use Case Register / IR Annex / Vendor Contract / Architecture Doc / None]." The AUP should include a review trigger: "Following a significant AI security incident at MVCC or at a peer institution, as documented in the lessons-learned report."
Capstone Grading Rubric — Five Dimensions
| Dimension | Exemplary (A) | Proficient (B) | Developing (C) | Beginning (D) |
|---|---|---|---|---|
| Technical Accuracy | All framework citations are precise (specific articles, subcategories); all control descriptions are accurate and deployment-context-specific. | Most framework citations are accurate; minor imprecision in 1–2 control descriptions. | Some framework confusion (e.g., citing GOVERN when MAP applies); controls generic rather than context-specific. | Multiple framework errors; controls are copied from course materials without adaptation to the scenario. |
| Program Coherence | All three integration connections explicit and verifiable; evaluator can trace any chain end-to-end without ambiguity. | Two of three connections explicit; one requires inference. | One connection explicit; program components feel loosely related. | Components presented in isolation; no explicit cross-document connections. |
| Risk Reasoning | Risk judgments are explained with specific evidence and stakeholder impact; the presenter can defend every prioritization choice. | Risk judgments stated with some rationale; most choices defensible. | Risk judgments stated without rationale; presenter defaults to "the framework requires it." | No risk reasoning visible; program appears compliance-driven rather than risk-driven. |
| Presentation Clarity | Non-specialist evaluator could understand what the program does and why it matters; questions answered precisely and concisely. | Clear to a technical audience; some jargon unexplained for non-specialists. | Understandable to classmates; struggled with evaluator questions on connections. | Difficult to follow; significant Q&A gaps. |
| Evaluation & Assurance | Defines robustness, safety, and performance metrics with acceptance thresholds set in advance; designates critical metrics; presents benchmark/red-team evidence and justifies a deploy / no-go decision against the thresholds. | Defines metrics and thresholds and reaches a defensible deploy / no-go decision; evidence or critical-metric designation is partial. | Lists some metrics, but thresholds are vague or set after results are seen; decision rationale is thin. | No evaluation plan; "it worked in the demo" reasoning; no thresholds or deploy criteria. |
AI Security Program Pack Presentations
Presentations · 90 minPresentation Format & Evaluation Protocol
Each team or individual presents their AI Security Program Pack to the class. The instructor and two designated peer evaluators assess using the rubric above. The presentation order is randomized. Each presenter receives written peer review feedback from the two designated reviewers.
Presentation Structure — 12 Minutes Per Team
What to cover: Name the organization (MVCC or another institution your team selected). State the organization's AI risk appetite — what kinds of AI deployments exist or are planned, what data is involved, what the highest-risk AI system is. State which EU AI Act risk tier classifications apply to the organization's highest-risk systems. Explain why those tier classifications matter for the program design you are about to present.
Evaluation signal: Does the presenter understand that risk tier drives governance obligations, or are they treating compliance as a checkbox? An evaluator will ask: "If your highest-risk system were reclassified from High Risk to Limited Risk tomorrow, what in your program would change?"
What to cover: Describe the AI AUP's three most important provisions for this organization — not all eight components, but the three that do the most work given this organization's risk profile. Show the Use Case Register with at least two entries, highlighting the EU AI Act tier and data classification fields. Identify which ISO 42001 document level each governance artifact belongs to (Policy, Procedure, Record).
Evaluation signal: Can the presenter explain why those three AUP provisions are the most important for this specific organization, rather than reciting the generic list? An evaluator will ask: "Why did you prioritize the shadow AI section over the data classification matrix?" The answer must reference the organization's specific risk profile, not a generic statement about best practices.
What to cover: For the organization's highest-risk AI system, name the three most critical architecture layers and the specific control at each. Identify the system's vendor tier classification and the one contract clause most critical for this specific vendor relationship (not the generic list — the specific one that addresses this vendor's specific risk). Name the two OWASP LLM Top 10 items most relevant to this deployment context and describe the control that addresses each.
Evaluation signal: Is the presenter matching controls to threats, or listing controls from memory? An evaluator will ask: "LLM06 (Excessive Agency) — does your program address this for the system you described?" If the system doesn't have agentic capabilities, the answer is "not applicable for this system — but the AUP prohibits deploying agentic AI without governance committee approval, so this would be addressed at intake if agentic capabilities are added." That is a correct answer. "Yes, we have defense in depth" is not.
What to cover: State which AI-specific incident types your program's detection layer addresses, and which one was hardest to design detection for and why. Name the two red team attack categories most important for pre-deployment testing of this system. Describe how a tabletop exercise finding would flow back into the program — which document gets updated, who approves the update, and what evidence would an auditor find?
Evaluation signal: Can the presenter demonstrate the ISO 42001 Clause 10 (continual improvement) loop, or do they treat incident response as a terminal process? An evaluator will ask: "Walk me through what happens after the tabletop exercise identifies an authority vacuum." The answer should trace: hot wash → action item → AUP/governance charter update → AI Governance Committee approval → version-controlled document update → next TTX tests the fix.
Standard evaluator questions (instructor draws 2 from this list per presenter):
- Your program assumes MVCC is a Deployer for this system. What would change if MVCC decided to fine-tune the model on its own student data?
- A red team test finds a prompt injection vulnerability in the RAG pipeline 2 days before the scheduled launch date. Walk me through the decision process.
- The vendor that provides your highest-risk AI system just announced they are switching their underlying foundation model from GPT-4o to a new model. What does your program require to happen before the system continues in production?
- The Illinois Attorney General's office sends a letter requesting your AI governance documentation following a student complaint. What do you send, and what does the absence of which document create the most legal risk?
- NIST released a concept note (April 2026) for a forthcoming AI RMF Profile on Trustworthy AI in Critical Infrastructure — the profile itself is still in development. Does this apply to MVCC? How would you determine that?
- Rank the four frameworks covered in this course (NIST AI RMF, ISO 42001, EU AI Act, OWASP LLM Top 10) by the amount of legal enforcement risk they carry for MVCC. Defend your ranking.
- Your program requires quarterly red team testing for Tier 1 systems. A Tier 1 system just added a new agentic capability between scheduled tests. Does your program's scheduled testing requirement apply, or is an immediate test triggered?
- Your AI Use Case Register has 8 entries. Three of them have "Next Review Date" fields that are overdue by 3–6 months. What does this tell an ISO 42001 auditor about your program?
Peer Review · During PresentationsStructured Peer Feedback Form
Each student completes the peer review form below for the two presentations they are assigned to evaluate. The form generates specific, actionable feedback — not vague praise. Completed forms are submitted to the presenter and instructor at the end of class.
📋 Peer Review Form — AI Security Program Pack Presentation
🎓 Instructor Note on Peer Review Culture
The peer review form is structured to produce useful feedback, not social validation. Students who rate everything 5 stars and write "great presentation!" are not completing the assignment — they are providing a disservice to their peers. The most valuable peer feedback names a specific gap and proposes a specific fix. That is what security professionals do in code reviews, architecture reviews, and red team debrief sessions. Learning to give precise, constructive technical feedback is itself a career skill this course teaches.
Self-Assessment · 15 min20 Learning Objectives — How Did You Do?
Before leaving today, complete the self-assessment checklist below. This is not a quiz — there is no score and it does not affect your grade. It is an honest inventory of where you are confident and where you would benefit from continued study. The items where you hesitate are the items to revisit before applying this knowledge professionally.
🚀 Career Pathways · 15 minWhat AI-103 Qualifies You For — and What Comes Next
AI cybersecurity is the fastest-growing specialty in an already fast-growing field. The global cybersecurity workforce gap stands at 4.8 million unfilled roles as of 2025. AI is cited as the single most-needed skill for the second consecutive year, and the integration of AI into security practice is accelerating faster than programs can update their curricula. AI-103 positions you at the intersection of two of the most demand-driven skill sets in technology.
📣 A Note from Dr. Sands
AI cybersecurity is not a specialty that developed slowly and announced its arrival. It arrived all at once, in the middle of an already intense talent shortage. The professionals who will define how AI is secured in the next decade are being trained right now — in programs like this one, in community colleges that are the most responsive part of the education ecosystem, in intensive courses that do not wait three years for a curriculum committee to approve a textbook.
You have spent 15 days building a foundation that most working professionals — including many who have been in the field for years — do not have. That is not a boast; it is the reality of how fast this area has moved. What you do with that foundation is up to you. The field needs people who can govern AI well, who can build it securely, who can respond when it fails, and who can explain what trustworthiness actually requires to decision-makers who need to hear it. That is the work. Go do it.
❓ Course Synthesis Quiz · 8 Questions · Connecting All 15 DaysThe Questions That Require the Whole Course to Answer
These questions are designed to require synthesis — each one connects content from multiple lessons. They are the kind of questions an AAISM or CISM exam would ask, and the kind of questions a hiring manager conducting a technical interview would use to distinguish someone who has memorized frameworks from someone who understands them.