How should Artificial Intelligence (AI) and low-code use cases be classified…

Research Question

What structured risk classification framework is appropriate for AI and low-code use cases in enterprise environments, specifically, how should categories such as informational, decision-support, and autonomous action systems be defined and bounded, and how should required governance controls, oversight intensity, and approval thresholds be mapped to each risk tier?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

• The most workable enterprise classification for AI and low-code use cases is a four-tier operating model, informational, decision-support, bounded action, and autonomous or critical action, with a separate no-go overlay for prohibited or out-of-appetite uses, because the reviewed frameworks all scale controls by impact, autonomy, and context rather than by one universal rule set.
• The AI Act supplies legal trigger points for prohibited and high-risk cases, but it does not provide a complete internal taxonomy for routine enterprise-internal use cases, so firms need an internal tier model that maps to those trigger points rather than copying its labels verbatim.
• The decisive boundary questions are whether the system can take direct action, whether it affects critical operations or rights-significant outcomes, whether humans can competently override it, and whether errors are reversible at low cost.
• Governance should therefore escalate from registration and standard controls at Tier 1 to documented human review at Tier 2, deployment gating and least-privilege machine authority at Tier 3, and formal approval, continuous monitoring, and safe-halt design at Tier 4.

Key Findings

1. High confidence. No reviewed framework provides a ready-made internal enterprise taxonomy for every AI and low-code use case, so regulated firms need an internal operating tier model that adapts legal and risk-management principles into day-to-day intake decisions.
2. High confidence. The best primary classifier is the combination of action authority and consequence, because the strongest reviewed signals are autonomy, human oversight, impact magnitude, and operational materiality rather than vendor, interface, or model type.
3. High confidence. Informational systems should remain in the lowest positive tier only when they are effectively read-only, do not materially shape consequential decisions, and produce errors that ordinary human work can detect and reverse cheaply.
4. High confidence. Decision-support systems enter a higher tier as soon as they materially influence credit, workforce, fraud, or critical-operation judgments, because effective human review and limitation documentation then become control necessities rather than optional good practice.
5. Medium confidence. Bounded-action systems deserve a distinct tier because once a system can write, trigger, publish, or modify records inside a pre-approved scope, oversight logic from NIST and the AI Act combines with prior completed architecture work to make deployment gates, least privilege, rollback, and action telemetry the minimum credible controls.
6. High confidence. Autonomous or critical-action systems require the highest positive tier, because multi-step action against critical operations or rights-significant outcomes demands formal approval, independent validation, continuous monitoring, and safe-stop capability.
7. High confidence. Tier assignment cannot be a one-time event, because changes in intended purpose, autonomy, connected systems, data sensitivity, or business criticality alter context and residual risk even when the interface remains unchanged.
8. Medium confidence. Over-classifying every use case as high risk would likely increase friction and shadow tooling, so a proportional model is not merely efficient but also more likely to preserve real governance coverage across the estate.

Assumptions

• Assumption: The specific tier labels, informational, decision-support, bounded action, and autonomous or critical action, are enterprise design choices rather than mandated external terms. Justification: the reviewed frameworks provide principles and trigger criteria but do not prescribe one canonical internal label set for all enterprise use cases.
• Assumption: A business analyst can apply the model reliably if the intake process forces explicit answers about action authority, impact, data sensitivity, overrideability, and reversibility. Justification: the frameworks require those facts to be documented, but they do not prove that every organization's intake form will capture them cleanly without local design work.

Analysis

• The synthesis weights NIST most heavily for internal classification mechanics, because NIST explicitly decomposes context, risk tolerance, human oversight, impact magnitude, and go or no-go decisions, while the AI Act and APRA provide stronger legal and prudential escalation triggers.
• The AI Act is treated as a mandatory overlay rather than as the whole taxonomy, because its legal classes are essential for prohibited and high-risk cases but are too coarse for routine internal enterprise uses that still need differentiated controls.
• The sharpest control boundary is the transition from influence to execution, because that is the point where release controls, least-privilege machine authority, rollback, and action telemetry become the only credible ways to constrain harm.
• The model also balances control against adoption reality, because an enterprise that assigns every use case to the highest tier is likely to recreate the shadow-tooling dynamics that previous completed items identified as a governance failure mode.
• Tier 0, no-go: reject any use case that falls into a prohibited legal category or still sits outside risk appetite after mitigation and oversight design.
• Tier 1, informational: allow use cases that are read-only in effect, low consequence, and easily reversible under standard ownership, inventory, approved data scope, basic testing, transparency, and standard telemetry controls.
• Tier 2, decision-support: require documented limitations, an assigned human reviewer, evidence logging, and periodic validation once outputs materially shape consequential human decisions.
• Tier 3, bounded action: require a deployment gate, segregated environments, least privilege, rollback, and action-level telemetry once a system can change state inside a pre-approved blast radius.
• Tier 4, autonomous or critical action: require formal approval, independent validation, staged rollout, continuous monitoring, and safe-halt capability for multi-step or high-impact action.

Risks, Gaps, and Uncertainties

• The full normative text of ISO/IEC 42001 was not accessible in this session, so ISO-backed claims are limited to the official public summary rather than clause-level interpretation.
• UK and Basel supervisory materials support proportionality and governance scaling, but they provide less detailed tier-boundary language than the AI Act or the NIST AI RMF Core.
• Borderline cases between Tier 2 and Tier 3 will usually turn on whether a system merely recommends an action or can actually commit, publish, trigger, or write that action into an enterprise system.
• None of the reviewed official sources specifies universal numeric approval thresholds, review cadences, or sample sizes by tier, so those thresholds still need local policy design.

Open Questions

• What evidence should count as proof that human oversight is genuinely effective rather than nominal for Tier 2 and Tier 4 systems?
• What minimum telemetry set is sufficient to prove that a system has stayed within its approved tier in production rather than drifting into a higher-risk operating pattern?
• Which promotion and re-certification cadence should attach to Tier 3 and Tier 4 systems once the enterprise converts the tier model into an operating procedure?

sources

• [x] European Commission AI Act overview — - official overview of prohibited, high-risk, transparency, and minimal-risk classes, plus applicability timeline
• [x] AI Act Service Desk, Article 9 — - official text for continuous lifecycle risk management and targeted mitigation for high-risk AI systems
• [x] AI Act Service Desk, Article 14 — - official text for human oversight measures commensurate with risk, autonomy, and context of use
• [x] AI Act Service Desk, Article 26 — - official deployer duties for monitoring, logging, and competent human oversight
• [x] NIST AI RMF 1.0 publication page — - official statement that the framework is voluntary, use-case agnostic, and intended to be operationalized at varying degrees
• [x] NIST AI RMF Core — - authoritative Govern and Map categories for risk tolerance, human-AI configurations, impact magnitude, and go or no-go framing
• [x] NIST AI RMF Playbook — - current official playbook entry page used in place of the seeded dead link
• [x] ISO/IEC 42001:2023 — - public summary of the Artificial Intelligence Management System standard
• [x] APRA Prudential Standard (CPS) 230 — - official prudential standard for operational-risk materiality, critical operations, internal controls, and monitoring
• [x] APRA Prudential Practice Guide (CPG) 230 — - official APRA guidance on proportionality, stronger practices for significant financial institutions, and operational-risk profiling
• [x] Bank of England Discussion Paper 5/22, Artificial Intelligence and Machine Learning — - official UK supervisory discussion paper on AI benefits, risk amplification, and governance challenges
• [x] Basel Committee newsletter on artificial intelligence and machine learning — - Basel Committee statement that governance, transparency, and resilience should be commensurate with the risk of the activity being supported
• [x] Financial Stability Institute (FSI) Insights 63, Regulating AI in the financial sector — - official synthesis that most financial authorities rely on existing frameworks plus stronger governance for higher-risk uses
• [x] Business-led low-code agent governance — - prior completed repository item on proportional low-code governance and shadow Information Technology (IT) pressure
• [x] Where should governance enforcement points be implemented within enterprise architecture? — - prior completed repository item on control placement across enterprise architecture
• [x] Deployment pipeline as the enforceable control gate for citizen-developed agents — - prior completed repository item on promotion controls for action-capable systems
• [x] What lifecycle management model is required for AI models, prompts, and low-code applications? — - prior completed repository item on re-tiering triggers, promotion states, and retirement controls
• [x] What observability and telemetry model is required to govern AI and low-code systems at scale? — - prior completed repository item on evidence and monitoring depth by control surface