AI Risk Classification for Defensible Governance Decisions

AI risk classification is the structured assignment of an AI system or use case to an applicable regulatory category and an internal enterprise risk tier using evidence about intended purpose, operating context, affected people, decision influence, autonomy, data, deployment role, jurisdiction and potential impact. The output should include the rationale and the governance actions that follow from the classification.

Classification answers the routing question: what category or tier does this AI system belong to and what level of governance should follow? A risk assessment goes deeper into specific hazards, likelihood, impact, controls, residual risk and treatment. Classification can therefore be an early control gate that determines which assessments and approvals are required next.

The scope can include internally developed models, generative-AI applications, AI agents, machine-learning decision systems, embedded AI features, third-party SaaS products, vendor APIs, open-source models and material AI-enabled business processes. The exact inventory boundary is agreed during scoping so unmanaged or duplicate entries are not assumed.

Yes. Classification can cover procured or externally hosted AI as well as internally built systems. Evidence may include the vendor role, intended use, contractual information, model or product documentation, data flows, user groups, decision authority, deployment geography and the controls operated by the client or supplier.

Where the EU AI Act is relevant, the engagement can map the system’s intended purpose, operator role and use context to the Act’s risk-based structure and applicable classification rules. The work can document the evidence and rationale used for the mapping, including relevant exceptions or conditions. This advisory work does not replace legal advice or a formal legal determination.

No. NIST AI RMF is a voluntary risk-management framework and ISO/IEC 42001 specifies requirements for an AI management system. They can inform governance, risk treatment, evidence and lifecycle processes, but they are not substitutes for jurisdiction-specific legal classification rules.

Useful evidence can include a system inventory, use-case description, intended purpose, user and affected-person groups, model or application architecture, data flows, provider and deployer roles, decision authority, human oversight, deployment regions, vendor documentation, policies, prior assessments, incident history and material change records. Missing evidence is recorded as a limitation rather than silently assumed.

Typical outputs can include a classification methodology, scoped AI inventory, classification register, per-system decision records, regulatory and internal-tier mappings, evidence and exception logs, control-routing matrix, ownership and approval recommendations, reclassification triggers, executive readout and handover material. Final deliverables depend on the agreed scope.

Yes. A portfolio approach can establish a repeatable intake and triage method, classify priority systems first, define evidence thresholds, create review and escalation rules and prepare a reusable decision record. Portfolio scale, data quality and the number of jurisdictions materially affect the engagement design.

Reclassification should be considered when intended purpose, model, data, autonomy, user group, decision influence, deployment region, provider, integration, control environment or regulatory context changes materially. Classification records can include explicit review triggers so lifecycle governance is not treated as a one-time exercise.

No. The service is an evidence-led governance and risk-classification advisory engagement. It does not by itself provide legal advice, regulatory certification, statutory audit, conformity assessment or a regulator’s determination. Where specialist legal or certification input is required, responsibilities should be agreed separately with appropriately qualified parties.

A reliable timeline is confirmed after scoping. Timing depends on the number and complexity of AI systems, evidence availability, stakeholder access, jurisdictions, internal approval requirements, whether a new classification taxonomy must be designed and the depth of per-system decision records required.

Pricing is scope-led and confirmed through a Request a Quote process rather than inferred from a generic rate. Key factors include the number of systems or use cases, portfolio complexity, evidence quality, jurisdictions, stakeholder workshops, regulatory mapping depth, internal taxonomy design, required deliverables, review cycles and whether remediation or implementation support is also requested.

Yes. Follow-on work can be scoped separately for governance design, responsible-AI controls, assurance, safety evaluation, privacy and security testing, evidence improvement, monitoring, operating-model changes or implementation support. Classification should make those next steps more targeted by routing systems to proportionate requirements.