One AI. Different Rules.

On the Weight of Risk in an Organization

AI portfolios grow faster than an organization’s ability to govern them.
Each system carries a different level of risk, responsibility, and regulatory obligation.

Applying a single, universal rule set creates a double cost.
It overloads low‑impact systems while weakening oversight where AI affects people, money, or operational continuity.

The organizing decision is straightforward:
the risk class belongs to the system, not to a document.

In this article, I describe a mechanism in which a risk class stored in the system record connects regulations into a single operating model, in the spirit of our approach to Controlled Autonomy.

One AI, Four Regulatory Perspectives

AI systems often fall under multiple regulations at the same time.
The same system can be assessed in parallel from different regulatory angles.

• The AI Act classifies systems using a risk pyramid, from prohibited use cases through high‑risk systems to limited and minimal risk.
  The classification depends primarily on the system’s purpose and the impact of its decisions.
• NIS2 focuses on the criticality of the digital service supported by AI.
  The same model may become part of a critical service if it affects continuity, security, or availability.
• DORA concentrates on ICT resilience, dependencies on external providers, and incident response capability.
• GDPR evaluates whether a system makes automated decisions about individuals, particularly when those decisions produce legal or similarly significant effects.

These perspectives apply to the same system at the same moment.
A single risk class stored in the system record does not replace regulatory classifications. Instead, it organizes them into one operational representation and triggers the correct obligations.

Classification as a System Attribute

Classification starts working only when it stops being a spreadsheet.

In large organizations, the number of categories quickly becomes unmanageable. Each regulation introduces its own concepts, and each team adds additional labels. The result is more terminology, but less actual control.

The Risk Class Stored in the System

The risk class should live in the system record, where decisions, accountability, and evidence are created. This provides a single reference point for multiple classifications. The system has one risk class instead of several parallel assessments maintained in silos.

The system record shows the risk class, the Business Owner, the obligations derived from that class, and an evidence trail of changes with justification.

1. Auditors see the current system state rather than a reconstructed history from spreadsheets.
2. Teams see their scope of responsibility.
3. Executives see where risk truly concentrates.

One Decision, Many Obligations

A single risk class can trigger obligations across multiple regulations at once.
The mapping exists in one place, and teams receive only the tasks relevant to their system.

A Class That Evolves

Risk changes over time. Retraining, new data, market expansion, or changes in user groups can alter the risk profile. Each of these changes should trigger reassessment.

When This Layer Is Missing

The early stages usually look familiar.
A new system follows an established process, and controls and interpretations are rebuilt from scratch.

Compliance begins to live in multiple places at once.IT holds logs.
Legal holds justifications. Risk maintains requirement lists.
During a crisis, the organization manually assembles a single response.

A single rule package is always designed for the average, not for extremes.
As the number of systems grows, costs rise: the same questions return, the same decisions repeat, and evidence scatters across locations.

The Incident as a Moment of Truth

In an incident, time and consistency matter.
First, the organization must determine what the incident concerns.
Then it must identify which obligations and reporting timelines apply.

Delays increase the risk of formal errors and inconsistent communication.

A uniform rule set produces excessive control.
Low‑impact systems receive safeguards that are too heavy, while high‑impact systems receive safeguards that are too light.
Costs increase, risk spreads unevenly, and AI development slows under growing complexity.

From System to Risk Class

Classification must be embedded in the workflow.

Assessment Before Production

Every system should undergo assessment before going live.
Without an assigned risk class, it does not enter production.

The class is derived from five variables: system purpose, data sensitivity, decision impact on people or finances, level of autonomy, and the affected user group.

These variables define the risk class, and the class determines inherited controls and required evidence.

Inheritance of Obligations

The class translates into regulatory obligations.
Each obligation has an owner and required evidence.
Higher classes require broader oversight, while lower classes operate under lighter regimes.

Reclassification Over Time

System changes should trigger reassessment. Moving to a higher class requires Business Owner approval, and everything remains visible in a single system record.

When the Class Starts the Clock

During an incident, multiple regulatory clocks run in parallel.
The same event may trigger different reporting obligations: AI‑related reporting, ICT incident reporting, critical service notifications, or personal data breach reporting.

These are distinct obligations, sent to different recipients, and supported by different evidence.

When the risk class is part of the system record, the correct protocol activates automatically.
Notifications reach the right owners, and the evidence trail grows with each action.

The goal is for technical and regulatory tracks to start in parallel, without improvisation.

Four Questions That Bring Order

Before an AI system enters production, the organization needs four answers:

• What is the system’s risk class?
• Which regulations apply?
• What controls result from this combination?
• Who has the authority to change the classification?

These answers become the entry condition for production and the reference point for every system change.

Each regulator looks at the same AI from a different angle. Classification connects these views into a single mechanism: the system has a class, the class triggers obligations, and obligations create evidence.

Where This Lives in the Platform

This is exactly the kind of mechanism ServiceNow’s risk and resilience tools are built to operationalize. Integrated Risk Management (IRM) connects regulatory frameworks to controls and continuously monitors risk across critical services, so a single risk class can map to obligations under the AI Act, NIS2, DORA, and GDPR without four separate tracking efforts. The Smart Assessment Engine pre-qualifies AI systems at intake and can auto-approve low-risk cases, freeing governance teams to focus on the systems that actually carry weight. And AI Control Tower extends this further, giving organizations a single place to monitor AI system health, scoring, and risk posture across the entire AI portfolio.

In other words, the system record this article describes isn’t a theoretical construct. It’s the natural shape of GRC and IRM on the Now Platform, when AI governance is treated as a workflow rather than a document.