What is the difference between high-risk AI systems and excessive-risk AI systems under Brazil’s proposed law?

Why Brazil’s AI law uses two risk bands

Brazil’s proposed law separates systems that can still be deployed under controls from systems that are too harmful to permit. That distinction matters because AI governance is not just about documentation, it is about deciding whether risk can be reduced to an acceptable level at all. High-risk systems are regulated through design, testing, transparency, and oversight obligations. Excessive-risk systems are treated as incompatible with the law’s baseline protections.

For practitioners, the practical question is whether the system’s harm can be bounded, monitored, and corrected without undermining the system’s intended use. The legal category affects product design, release planning, procurement review, and internal governance because it changes whether controls are enough or whether the use case itself must be removed.

In practice, many teams discover the distinction only after a near-final deployment has already been built around a use case that should never have survived the initial policy review.

How it works in practice

High-risk classification usually means the system may operate, but only if the organisation can show structured controls around the full lifecycle. That generally includes documenting intended use, testing for safety and reliability issues, keeping traceability over model behaviour, setting human oversight where needed, and maintaining transparency for affected users or operators. The point is not to eliminate all risk, but to make the residual risk governable.

Excessive-risk classification is different in kind. It is not a request for stronger safeguards, it is a legal stop sign. When the system’s use would produce harms the law considers incompatible with baseline protections, the compliance problem is not how to harden the system further, but whether the activity should proceed at all. That changes the architecture conversation from control design to product prohibition, scope reduction, or a different operating model.

• High-risk systems need evidence that controls were designed before deployment, not added after incidents.
• They also need a clear owner for monitoring, retraining, change approval, and escalation when behaviour drifts.
• Excessive-risk systems require an early classification decision, because late discovery usually means sunk cost and pressure to rationalise a forbidden use case.

Brazil’s proposed AI regime aligns with the broader pattern seen in modern AI regulation: some systems are governable with controls, while others are treated as inherently unacceptable. The EU AI Act regulatory framework follows a similar structure, which is useful for comparative planning even though the legal tests are not identical.

These controls tend to break down when teams classify the business outcome first and the risk tier later, because the deployment architecture is already too advanced to reverse cleanly.

Common variations and edge cases

Tighter classification often increases review overhead, so organisations have to balance speed against the cost of getting the category wrong. The hard part is that some systems are only high-risk in a specific context of use, while the same underlying model may be lower risk in another setting. That means classification has to follow the actual deployment, not just the model family or vendor label.

Another common edge case is mixed-function systems. A platform may contain one feature that is clearly governable and another that pushes the whole use case toward excessive risk. In those cases, teams should not assume that a partial control set can rescue the full design. The question is whether the risky function can be separated, constrained, or removed without changing the product’s core purpose.

Where the law leaves room for interpretation, current guidance suggests treating the most consequential use case as the deciding factor. That approach reduces the chance of downgrading a system into a manageable bucket when its real-world use creates harms the law is trying to prevent.

If a system can only be made acceptable by assuming perfect operator discipline, it is usually a sign that the classification should be revisited before launch rather than after a compliance finding.

Risk and Threat Considerations

The main risk is misclassification. If an organisation treats an excessive-risk use case as merely high-risk, it may spend time implementing controls for a system that should never have been approved. That creates legal exposure, governance failure, and avoidable downstream harm if the system is deployed anyway.

Failure mechanism: The failure usually starts when classification is anchored to technical capability instead of real-world use, impact, and prohibited outcomes. Once that happens, documentation and oversight can give a false sense of safety while the underlying use case still produces unacceptable harm.

Impact: The likely consequence is a forbidden deployment, delayed remediation, regulatory challenge, and loss of trust in the organisation’s AI governance process. In severe cases, the system may need to be withdrawn entirely.

Practitioner Guidance

What to prioritise: Classify the use case before the build becomes irreversible. If the deployment may affect fundamental rights, safety, or other serious protected interests, treat the classification as a product decision, not a post-launch compliance task.

Decision rule: If the system can be made acceptable only by assuming heavy human oversight, exceptional monitoring, or constant policy exceptions, that is a warning that the use case may belong in the prohibited category rather than the controlled one.

What to verify: Confirm that the documented use, target population, and operating context match the actual deployment. Many classification errors happen because procurement language, model marketing, and production use drift apart.

Practitioner takeaway: The real governance test is whether the harm can be reduced to an acceptable level without changing the system into something else, if not, classification should stop the project rather than decorate it with controls.

Related resources from NHI Mgmt Group

• What is the difference between prohibited AI practices and high-risk AI systems under the EU AI Act?
• What is the difference between transparency controls and high-risk AI controls under the EU AI Act?
• What is the difference between pre-deployment evaluation and post-market monitoring for high-risk AI systems?
• What is the difference between high-risk AI systems and low-risk AI systems in regulation?