AI System Types: 3 Critical Distinctions
The fastest way to lose an AI governance question is to treat every system as the same animal. AI system types decide which obligations bite, which risks matter and which questions you put to a vendor. The AIGP exam rewards candidates who place a system in the right category before reaching for a control. So the first skill to build is not memorising the EU AI Act article by article; it is reading AI system types accurately and saying what follows from each. Get the type right and the governance answer usually falls out of it.
Why AI system types are a governance skill, not a luxury
Governance professionals do not build models. Their job is to judge them, and that judgement starts with classification, because the duties attached to a system flow from what the system is and what it does. The IAPP publishes a Body of Knowledge (BoK) for the AIGP exam, the document that defines every topic candidates are tested on, and it opens with the foundations of AI for exactly this reason. The recent restructuring of that syllabus made the point sharper; you can see the shape of it in the move to a leaner four-domain structure. Classification of AI system types is the hinge the rest of the exam turns on.
The question underneath every scenario
Scenario questions look like they are testing law. Most are testing whether you can name the system first. Is this a model that sorts inputs into categories, one that produces new content or one that takes actions on its own? Answer that and the lawful basis, the oversight duty and the documentation burden stop being a guess. The OECD's definition of an AI system, now used across EU, US and other frameworks, is the reference point worth knowing cold; it describes a machine-based system that infers how to generate outputs from the inputs it receives.
Distinction one: how the system learns
The first cut is the learning paradigm. Supervised learning trains on labelled examples, so its governance weak point is the labels; biased or thin training data produces confident, biased output, and the accountability question lands on data provenance. Unsupervised learning finds structure in unlabelled data, which makes its groupings hard to explain after the fact; the consequence is an explainability and purpose-creep problem, because a cluster built for one aim is easily reused for another. Reinforcement learning optimises toward a reward, and the risk sits in the reward itself; a system rewarded for engagement will chase engagement past the point a human would stop. Each paradigm hands you a different first question to ask.
Distinction two: what the system produces
The second cut is output, and this is where the control surface widens. A classical system predicts or classifies, and you can usually check its answer against a known right answer. A generative system produces text, images or code, and there is often no single correct output to test against, which is why provider documentation and content transparency carry more weight; the obligations for general-purpose models are a clear worked example, summarised in the guidance for general-purpose AI models. The control problem grows because you are no longer validating a label; you are governing an open-ended generator.
When the system starts to act
Agentic systems are the third step, and they change the picture most. An agent does not just answer; it plans and executes, calling tools, moving money or booking resources with limited prompting. Oversight written for advisory systems strains here, because the human oversight obligation assumes a person can understand, monitor and stop the system in time. With an agent acting at speed across several steps, that assumption needs real infrastructure behind it: logging, escalation triggers and a workable stop. The newer syllabus reflects this by naming agentic architectures as a deployment topic, and the same logic runs through the AI development lifecycle. The pattern across all three outputs is simple; the more the system acts, the wider the surface you must control.
Mapping AI system types to risk and to vendor questions
Type is not trivia; it sets the risk tier. The EU AI Act's risk-based classification does not ask what the model is made of; it asks what the system does and in what context, then attaches obligations to that. The same model summarising meeting notes and screening job applicants sits in two different worlds. This is also why the NIST AI Risk Management Framework organises the work around mapping and measuring a system before managing it; a free EU AI Act fact sheet is a quick way to keep the tiers handy. Once you can name the AI system types in front of you, the vendor conversation writes itself: training-data provenance for a supervised classifier, content and documentation transparency for a generative model, and action scope, logging and override for an agent. Walk in knowing the type and you stop accepting a brochure as an answer.
A short self-check before exam day
Run a system you meet through these prompts and you will rarely misclassify under pressure:
- How does it learn: from labels, from unlabelled structure or from a reward?
- What does it produce: a prediction, new content or an action in the world?
- How far does it act on its own, and what could it set in motion before a human steps in?
- Which obligation follows from that answer, and what would you ask the supplier to prove?
If you can run those four prompts quickly, the foundations are doing their job. For a structured way to build the rest of your preparation around them, PSG's AIGP study roadmap is a sensible next stop, and you can pressure-test where you stand at 22academy.com/study.
