What it means
An AI system taxonomy separates capabilities, learning methods, autonomy, deployment context, and intended purpose so teams use the same language when describing a system.
Why it matters
Without a shared taxonomy, requirements, risk ratings, vendor claims, and oversight decisions can refer to different things while appearing consistent.
Practical focus
- Define the approved purpose, accountable owner, users, operating environment, and acceptable risk for ai system taxonomy before implementation or procurement
- Implement a documented classification for capability, learning approach, autonomy, users, environment, and prohibited assumptions through documented architecture, policy, configuration, and change control
- Collect approved system profiles, terminology decisions, architecture records, and classification changes and compare the results with approved requirements, risk thresholds, and expected outcomes
- Exercise this failure scenario as a planned test: a product is marketed as general-purpose or autonomous even though its approved profile and operating limits say otherwise
Common mistakes
- Using the label ai system taxonomy without defining the exact system boundary, decision, data, and people in scope
- Treating a model response or vendor claim as sufficient evidence without testing the surrounding application and operating process
- Failing to preserve approved system profiles, terminology decisions, architecture records, and classification changes in a form that lets reviewers reconstruct decisions and changes
- Testing only the normal path and never rehearsing what happens when a product is marketed as general-purpose or autonomous even though its approved profile and operating limits say otherwise
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: