Risk tiers and use-case thinking

A risk tier does not announce that a product is good or bad. It tells the team how much evidence and control may be expected. A high-risk classification can mean “permitted with substantial safeguards,” not “automatically banned.” A lower tier does not mean “no rules.” Privacy, consumer protection, contracts, security, accessibility, and sector duties can still apply.

A useful generic map is:

• Prohibited or unacceptable: a narrow practice conflicts with protected rights or public policy so strongly that safeguards are not considered enough.
• High impact or high risk: the system can materially influence safety, employment, education, credit, essential services, law enforcement, or similar interests.
• Transparency-sensitive: people should know they are interacting with AI or viewing generated or manipulated content in defined circumstances.
• Lower impact: the use has limited consequences but still needs honest claims, security, quality checks, and appropriate data handling.

Do not copy this map into a legal conclusion. Actual definitions, exemptions, thresholds, and responsibilities are jurisdiction-specific.

Avoid labels such as “AI assistant” or “prediction platform.” Write:

The system uses inputs to produce an output, which a named actor uses to take an action affecting a population.

For example: “The system uses résumés and job criteria to produce a candidate score, which recruiters use to decide who receives an interview.” This sentence reveals decision influence and affected people. “Recruiting copilot” does not.

Then separate stages. Drafting interview questions, summarizing a résumé, ranking candidates, and automatically rejecting candidates are different uses. A team cannot safely assign one risk level to an entire product when its features have different powers.

Use these lenses for a first pass:

1. Purpose: Is the goal creative, administrative, persuasive, diagnostic, evaluative, or decision-making?
2. Decision power: Does AI provide information, make a recommendation, determine an outcome, or trigger an action automatically?
3. Affected interest: Could it influence safety, liberty, employment, education, housing, health, credit, insurance, or essential services?
4. Population: Are children, patients, workers, applicants, or otherwise vulnerable people affected?
5. Data: Does it process personal, biometric, health, financial, location, or other sensitive information?
6. Scale and frequency: How many people are affected, how often, and can one error spread?
7. Contestability: Can a person learn about the decision, correct bad data, reach a qualified human, and obtain a remedy?

Reversibility and detectability cut across all seven. A wrong internal tag that can be changed instantly differs from a denial that someone discovers after a deadline.

Documentation often emphasizes intended purpose because purpose shapes testing and controls. But teams should also examine reasonably foreseeable use. If a “writing aid” includes a button that scores employee tone and managers use that score in performance reviews, calling it a writing aid does not erase the employment context.

Boundaries should be real. Product copy, permissions, interface design, training, contracts, monitoring, and technical restrictions should align. A disclaimer that says “not for decisions” is weak if the product exports a ranked decision list.

Changes can trigger reclassification. Revisit the review when the system:

• gains a new user group or jurisdiction;
• moves from recommendation to automatic action;
• adds sensitive data;
• becomes part of a consequential workflow;
• changes model, objective, threshold, or integration;
• scales from a limited pilot to broad deployment.

Teams sometimes multiply likelihood by severity and stop. That can hide rare but catastrophic outcomes, unequal impacts, or uncertainty caused by weak evidence. Keep separate notes for severity, likelihood, exposure, detectability, reversibility, and distribution across groups.

A system with infrequent errors may still need strong controls if one error can deny urgent care. A system with mild individual harm may become serious at massive scale. A system with unknown performance should not receive a low-risk label merely because no incidents have yet been observed.

Classification is useful only when it changes action. A lower-impact drafting tool might need access controls, a clear user interface, and routine testing. A consequential recommendation may require representative evaluation, data documentation, trained human review, logs, appeal paths, and ongoing monitoring. Automatic adverse action may be disallowed by internal policy or require specialist analysis.

The goal is proportionality: stronger evidence where consequences are greater, without pretending every use needs the same process.