Course tracks and pages
Talk to an advisorReach the academy
© 2026 Rob in Hood Digital
A track for people who build with AI models and for the people who have to sign off on them. Work through the same systems twice: once to make them run, once to explain how they are governed, measured and limited.
AI governance and AI threat modelling sit beside the build work, not after it. Every module ends with the risk question your reviewer will ask.
Read the module list, then compare how this track is taught before you commit.
Most AI training splits into builders and reviewers, and the two groups end up describing the same model in different words. This track keeps them in one room. If you write prompts, wire up retrieval, or ship a model behind an internal tool, you will learn where the governance questions come from. If you own risk, policy, audit or procurement, you will learn what the build actually does before you review it.
You will work with model APIs, retrieval over your own documents, evaluation runs and prompt patterns that hold up outside a demo. The governance modules then ask you to document what the system can and cannot be trusted to do, in language a non-technical reviewer can follow.
You will learn how models fail, what evidence a review can realistically ask for, and how to read a model card or an evaluation report without taking it at face value. No coding background is assumed for the governance path, though the labs are open to you if you want them.
Five modules, each one pairing the build work with the oversight question that follows it. You can take the whole track or start with the governance modules alone.
A plain-language pass over models, training data, inference and the places where a system quietly stops matching its description. You leave able to explain a model pipeline to someone who has never opened a notebook, and able to spot the assumptions a vendor deck usually skips.
You wire a model to your own documents, write prompts that survive contact with real users, and set up an evaluation set so you can tell whether a change helped or just felt better. The lab work covers retrieval, prompt structure and how to record results you can hand to a reviewer later.
The centre of the track. You map who owns a model, what it is allowed to decide, how it gets reviewed and what happens when it drifts. Topics include internal AI policy, data handling, human review steps, logging and the difference between a rule you can enforce in code and one you can only enforce in process. This is the module reviewers tend to start with.
Prompt injection, data leakage through retrieval, model and dataset tampering, and the slower failures where a system is technically working but quietly wrong. You build a threat model for a realistic internal assistant, then argue it down with the mitigations you would actually be able to ship.
You pick one AI system you already work with, or a documented public one, and produce the set of documents a review would ask for: what it does, who owns it, what it must not do, how it is tested and how you would notice it going wrong. Reviewers can bring this back to their own teams as a starting template.
Governance work stalls when the reviewer has no picture of the machine in front of them. The build modules exist so the oversight modules have something concrete to argue about. When you write an AI policy in this track, you have already broken a retrieval pipeline and watched it return the wrong document with total confidence.
The track is self-paced, so the weeks below describe a sequence rather than a calendar. Work through them in order and each one gives you the vocabulary for the next.
Foundations and a short writing task: describe one AI tool you already use, in your own words, without the vendor's language.
A retrieval assistant over a handful of your own documents. Small on purpose — the point is to hit the failure cases while the stakes are low.
Draft an internal AI policy for the system you built. Decide what is enforceable in code, what needs a human step, and what you would simply refuse to automate.
Threat modelling on the same assistant: prompt injection, retrieval poisoning, quiet wrong answers. You keep a written record of what you found.
Assemble the capstone pack: scope, ownership, limits, test evidence and known weaknesses. This is the document you keep after the course ends.
Three common starting points. Read the one that sounds like your week, then check the format notes before you decide.
You need to ask better questions about models arriving through procurement, and to write policy that holds when a tool changes underneath it. Start with the governance and threat modelling modules.
You can already call an API. What you want is evaluation that means something, failure cases you can describe, and the ability to answer the review question without improvising.
You come from IT support, data work or a related role. Take the modules in order — the foundations and build work first, so the governance material has something to stand on.
If your question is not here, the team answers email during working hours, Monday to Friday, 9:00 AM – 6:00 PM.
ContactNot for the governance modules. They are written for people who review, own or procure AI systems and assume no programming. The build and threat modelling labs do expect you to be comfortable running a command or editing a script; if that is new to you, the foundations module is the place to start and the team can point you at what to review first.
Self-paced. The week sequence on this page is the recommended order, not a timetable — you work through it when your schedule allows. Most learners keep the same working pattern they already have and add a few focused hours rather than blocking out a full course week.
The material teaches a governance method rather than a single rulebook: how to define scope, assign ownership, set limits, collect evidence and review a system over time. It is written so the method survives when the rules around your industry change, and so you can map your own obligations onto it. Check your organisation's specific requirements with your legal or compliance team.
Yes, if you already have some exposure to how models and retrieval pipelines behave. The module assumes you can picture the system you are modelling; if that is a stretch, the foundations and build modules come first for good reason. Ask the team if you are unsure which entry point suits you.
A machine you can install tools on, a small set of non-sensitive documents to test retrieval against, and a spare hour to write the short description of an AI tool you already use. Keep the documents boring and public — the lab is about the pipeline, not about your employer's data.
If the governance side is your reason for being here, say so when you write — the team can tell you which modules to start with. If you are still choosing between tracks, the course list shows all three side by side.
1200 Cyber Security Way, Reston, VA 20190
+1-703-555-0826
Monday–Friday, 9:00 AM – 6:00 PM
