Your low-risk AI tool shouldn't take six weeks to approve

Part 9 of When AI Governance Meets Reality.

When every AI system faces the same approval process, governance stops being risk-based and becomes bureaucracy.

A business team wants to deploy an AI tool that summarizes internal meeting notes.

The system doesn't make employment decisions. It doesn't evaluate customers. It doesn't determine eligibility for financial products or influence access to essential services.

It summarizes meetings.

The team submits the use case for governance review, and the familiar sequence begins:

Six weeks later, the team is still waiting.

Meanwhile, another business unit is proposing an AI system that will evaluate job applicants. It enters essentially the same workflow.

Two very different risk profiles. One approval process.

The organization has AI governance. But has it built risk-based AI governance?

Most organizations start with a centralized process. Every AI use case is registered, assessed, reviewed, and approved before deployment.

Initially, this makes sense. Centralization creates visibility, standard assessments create consistency, and formal approvals help demonstrate accountability.

As AI adoption accelerates, a weakness emerges. The governance process treats the presence of AI as the trigger for scrutiny, rather than the nature and magnitude of the risk.

A tool that helps employees summarize documents can receive the same attention as a system influencing consequential decisions about people.

The result is predictable. Governance teams become overwhelmed, approval queues grow, and business units grow frustrated. Some teams start looking for ways around the process, often because it seems disconnected from the actual risk.

That creates a paradox: an organization can become so focused on governing every AI system that it loses the capacity to govern the systems that matter most.

Risk-based governance doesn't exempt certain AI systems from accountability. It means the depth of assessment, level of oversight, and intensity of monitoring reflect the risks the system creates.

Consider three hypothetical deployments.

Scenario A: Internal productivity assistant

An AI tool summarizes internal documents for employees. It runs in an approved enterprise environment, processes permitted information, and doesn't make consequential decisions.

The main concerns are data confidentiality, accuracy, access controls, and appropriate use. A proportionate approach might require:

A full committee review would add little value if the system stays within established boundaries.

Scenario B: Customer-facing AI assistant

An AI assistant answers customer questions and provides product information directly.

Its outputs could mislead customers, expose sensitive information, or create regulatory and reputational exposure.

The EU AI Act also establishes transparency requirements for certain AI systems that interact directly with individuals. Under Article 50(1), providers must design and develop these systems so that individuals are informed they are interacting with AI, unless that is apparent from the circumstances and context of use, taking into account the characteristics of the individuals concerned. Specific exceptions also apply.

This use case warrants additional scrutiny: testing response quality, evaluating escalation paths, verifying applicable transparency requirements, setting monitoring expectations, and defining appropriate human oversight.

Scenario C: AI-assisted hiring

An AI system evaluates job applicants and influences hiring decisions.

The risk profile changes substantially. Under the EU AI Act, AI systems intended for recruitment and selection, including evaluating candidates, are identified in Annex III as potentially high-risk. Whether a particular system qualifies as high-risk depends on its intended purpose and the applicable classification provisions, including the conditions and exceptions established under Article 6.

For systems classified as high-risk, the AI Act establishes requirements concerning areas such as risk management, data governance, technical documentation, transparency, and human oversight. Importantly, these obligations differ depending on whether an organization acts as a provider or deployer.

The timing also matters. The EU AI Act follows a phased implementation schedule, and the applicability of specific high-risk requirements depends on the relevant provisions and transition arrangements. Other applicable employment, privacy, and anti-discrimination laws may already impose obligations.

A more rigorous governance pathway is therefore justified by the potential consequences of the system, independently of whether every AI Act high-risk obligation is already applicable.

The point isn’t that one system deserves governance and another doesn’t. Governance should scale with the consequences of getting the decision wrong.

The EU AI Act illustrates why proportionality matters, but legal classification and internal risk ratings serve different purposes.

The Act establishes different regulatory requirements depending on the nature of the AI system, its intended purpose, and the role of the organization involved. Certain practices are prohibited. Other systems may qualify as high-risk and become subject to additional requirements. Some systems trigger specific transparency obligations, while general-purpose AI models are addressed through a separate regulatory framework.

Not every enterprise AI deployment falls within the high-risk category. Nevertheless, obligations under the AI Act or other applicable laws may still apply.

An organization’s internal rating of a system as low-risk does not override its legal classification. Regulatory classification determines applicable legal obligations; enterprise risk assessment helps determine the appropriate level of internal governance and oversight.

The sequence matters: first determine which legal requirements apply, then calibrate internal controls to the system's actual risk exposure.

Proportionality is not permission to ignore mandatory obligations. It means not imposing controls beyond what the law and the system's risk profile require.

The problem usually isn't a lack of risk categories. Many programs already label systems low, medium, or high risk.

The problem is what happens next. A low-risk label appears in the documentation but doesn't change the path. The system still goes to the same committee, through the same package, and the same approvals.

If classification doesn't change the governance pathway, it serves no operational purpose.

A functioning risk-tiered model should influence four things:

These distinctions have to be built into the workflow. Otherwise, proportionality remains a principle rather than an operating model.

Proportional governance gets complicated here. An organization can't let business teams label their own use cases low-risk and skip review. That invites underestimating risk.

Instead, organizations need documented criteria for streamlined governance. Those criteria might consider:

The classification should rest on evidence, not a business owner's assertion. And the streamlined pathway needs boundaries.

An internal summarization tool may qualify for a lighter process when it uses approved information. If the same tool starts processing sensitive employee records or generating recommendations for employment decisions, its original assessment may no longer hold.

Low-risk isn't a permanent property of a product. It is a conclusion about a specific system, purpose, and deployment context, and it has to stay defensible as those change.

A mature program doesn't push every system through one pipeline. It sets pathways based on documented risk criteria:

Pathway 1: Streamlined review. For systems meeting predefined low-risk criteria. Requires basic registration, limited screening, verification of baseline controls, and documented authorization.

Pathway 2: Standard review. For systems with moderate operational, privacy, customer, or reputational risk. Requires detailed assessment, relevant specialist review, documented controls, and a designated approver.

Pathway 3: Enhanced review. For systems with significant risk or subject to demanding regulatory requirements. Requires deeper evidence, formal oversight, specialized assessments, and potentially executive or committee decisions.

A system may warrant enhanced internal governance without meeting the EU AI Act’s legal definition of high-risk. Conversely, a system subject to specific regulatory obligations cannot bypass those requirements simply because an organization assigns it a lower internal risk rating.

These pathways do not replace legal classification. Mandatory requirements apply regardless of internal workflow. Every pathway should allow escalation when evidence is thin, risks are disputed, or a use case falls outside established criteria.

The goal is to reduce friction where risk is limited, so governance capacity concentrates where the consequences are greatest.

Many organizations measure governance through systems reviewed, assessments completed, or approvals issued. Those numbers show activity, not necessarily effectiveness.

More revealing questions:

If the honest answer is that every system follows the same process, governance may be standardized but not proportionate.

Applying the same controls to every AI deployment doesn't make governance stronger. It delays approvals, strains capacity, and erodes business confidence. Meanwhile, consequential systems compete for attention with routine productivity tools.

The objective isn't less governance. It's allocating governance effort according to risk, while always meeting mandatory obligations and baseline safeguards.

Good AI governance doesn't review everything equally. It knows what deserves greater scrutiny, what doesn't, and can defend the difference.

Reply to this email. I read every response. Tell me how your organization handles low-risk AI approvals, or where your process breaks down. I'm happy to discuss how to build risk-based governance in your context.

If this resonated, forward it to someone responsible for AI governance, risk, or enterprise AI adoption.

Disclaimer: This newsletter is for general informational and educational purposes. It does not constitute legal, regulatory, or professional advice. AI governance requirements vary by jurisdiction, industry, system characteristics, and deployment context. Organizations should evaluate applicable obligations and seek appropriate professional guidance before making governance or compliance decisions.