AI Risk Management Frameworks: An Overview

AI is part of everyday work, but its risks do not always fit familiar security checklists. AI risk management frameworks bring structure and control. 

Contents

1. AI risk categories
2. EU AI Act
3. NIST AI Risk Management Framework (AI RMF 1.0)
4. ISO/IEC 23894:2023 and ISO/IEC 42001
5. Key components of AI risk management
6. Which framework is the right fit?
7. Framework implementation

Key takeaways: AI risk management frameworks

• AI-specific risks not fully covered by traditional IT security approaches
• Voluntary AI risk management frameworks such as the NIST AI RMF and ISO/IEC 42001, alongside binding regulation such as the EU AI Act
• EU AI Act risk categories with different obligations depending on the level of risk
• ISO/IEC 42001 as a certifiable standard for AI management systems with links to ISO 27001
• Effective AI risk management through continuous monitoring, clear governance and structured awareness training

AI risk categories: What companies are already facing today

Many companies already use AI in everyday work, often before clear rules are in place. A team tests a new tool. An output sounds plausible and feeds into a decision.

AI risks do not only arise in complex AI systems. They also emerge in routine workflows. AI risk management helps organisations identify these situations, assess them, and decide where controls are needed.

Technical risks: When wrong outputs sound right

A sales team uses AI to assess an account list before a pipeline meeting. The tool highlights several accounts as likely to buy, suggests a good time for outreach, and gives the team a clean order of priorities. At first, that looks useful rather than risky.

The problem appears when the team compares the ranking with current sales data. Certain industries keep appearing near the top, although the latest pipeline figures do not justify that preference. Outdated training examples seem to have given those sectors too much weight. The output does not fail loudly. It simply looks reasonable enough to be used, while better opportunities move further down the list.

Generative AI brings the same risk into everyday work. Weak material can still read well. A source may look credible at first glance and still lead nowhere. A number may survive a quick check, then turn out to be inaccurate. A claim may read as if it has been balanced carefully, even though the evidence is missing.

Model drift creates a quieter problem. The model may have worked well at launch, but the context around it changes: products, data, markets, customer behaviour. From a technical point of view, nothing may look broken. The answers can still become less useful over time. The quality of the answers can still decline.

AI risk management needs operational checks for this:

• Selected outputs for review
• Recurring errors and patterns
• Clear triggers for reassessing a model

AI security risks: When an input becomes an attack

AI security risks often appear at interfaces. A chatbot answers customer questions and uses internal knowledge bases to do so. An attacker phrases a request in a way that pushes the bot past its normal instructions.

The chatbot is meant to answer a customer question. Instead, the wording pulls it towards internal guidance, support notes, or knowledge-base content that customers should not see.

Prompt injection is not limited to the chat window. It can also be hidden in material the AI system is asked to read. An employee may use an AI tool to summarise an external webpage. The page looks ordinary, but one section is written for the model rather than the reader. The summary may then follow that hidden text to skip safeguards or include information that does not belong in the response.

With data poisoning, the risk starts before the model is even used. Customer feedback, support tickets, or product reviews can help improve a model, but they still need review before they become training data. Manipulated entries may later affect how the model classifies cases, which patterns it favours, or which exceptions it misses.

Adversarial attacks take another route. They are especially relevant for systems that recognise images, speech, or patterns, for example in quality control. A supplier could alter an image of a defective part just enough for the model to overlook the defect. A person reviewing the image might see almost no difference.

AI risk management has to include these attack paths, especially where AI is connected to customer data, internal systems, or business-critical processes.

AI privacy risks: When speed takes priority over data protection

AI privacy risks often arise without malicious intent. Take HR, for example. An employee wants to compare applications quickly and uploads complete CVs to a public AI tool within seconds.

Procurement can face the same pressure. A contract needs a quick summary, a deadline is close, and the full draft ends up in an unapproved AI tool. That draft may contain prices, delivery terms, negotiation margins, and other details that should not leave the company without review.

In marketing, the risk can be harder to spot. Customer segments, campaign data, and internal analyses may be uploaded because the AI model returns useful suggestions almost immediately. The team gets a faster answer, but loses sight of the data path. Where is the information processed? Is it stored? Who may be able to access it?

Shadow AI takes this one step further. Corporate IT cannot see every tool. Legal is not aware of every use case. Leadership often learns only with delay which AI tools employees are already using.

AI risk management needs to start with behaviour here. Employees need clear guidance on:

• Approved AI tools for work
• Data allowed in AI tools
• Contact point for unclear cases

Operational risks: When AI quietly becomes the default

Operational risks tend to grow gradually: A controlling team first uses AI to shorten reports. Then the tool begins drafting comments. After a while, parts of those comments appear in management documents after only a quick review.

The process seems to be efficient, so the team keeps using it. Report assumptions receive less attention. The manual route is still available, but used a lot less often. The team gets less practice in noticing weak logic, missing context, or conclusions that do not quite fit. If the AI draws the wrong connection, the error may move through several layers before someone catches it.

The same pattern can appear in IT. AI classifies tickets, first as a time-saver, then as the normal way of working. Because the classification is always available, it starts to feel reliable. If mistakes creep in, critical incidents may be routed too slowly or handled with the wrong priority.

Structured AI risk management should define:

• Review points for AI-generated results
• Decisions kept with a person
• Quality metrics for AI responses
• Authority to pause unusual AI output

AI compliance risks and AI legal risks: When AI-generated copy can have legal implications

“Seamless integration.” “Maximum resilience.” “Ready to use in minutes.” AI can draft claims like these quickly. Before publication, someone still needs to check whether the wording is accurate, evidenced, and approved for use.

That review should happen before the claim appears on a website, in a sales deck, or in product material. Who approved it? Which evidence supports it? Who owns the wording if it is challenged later?

AI risk management should make this review traceable, including with regard to NIS2 compliance:

• AI tools used for drafting or review
• Authorised users
• Approval steps before publication
• Evidence for product and security claims

That record helps Legal, Audit, or regulators understand what was checked and by whom.

AI risk management frameworks

Traditional software follows defined code. AI systems work with patterns learned from data. That difference matters in practice. A software bug can often be traced to a line of code, a configuration, or a dependency. An AI error may come from training data, model behaviour, prompts, user context, or changes in the environment.

An AI risk management framework gives risk, security, legal, and business teams a shared way to make decisions about those systems. It helps define what needs to be documented, which controls are required, who signs off, and when a use case needs another review. This is where AI governance becomes part of daily operations.

The NIST AI RMF and ISO/IEC 42001 are voluntary frameworks. The EU AI Act has a different role: it sets binding legal requirements in the EU for certain AI systems and use cases. Many organisations need both perspectives. Regulation marks the legal boundary; frameworks help teams manage AI risks in practice.

EU AI Act

The EU AI Act classifies AI systems by the risk they may pose to fundamental rights, safety, and societal values. This classification determines which obligations apply. EU AI Act risk management therefore does not start with the name of a tool, but with its specific use case.

NIST AI Risk Management Framework (AI RMF 1.0)

The NIST AI Risk Management Framework was published in 2023 by the US National Institute of Standards and Technology. It is voluntary and is often used as a practical reference because it is technology-neutral and can be applied to organisations of different sizes.

A short NIST AI Risk Management Framework summary starts with the AI RMF Core. It is built around four functions: Govern, Map, Measure, and Manage.

Govern

Govern defines how responsibility for AI risks is assigned inside the organisation. This includes approvals, policies, and expectations for employees. It also covers a practical question: how prepared are people for everyday AI use? Training and structured awareness training belong in this layer because employees influence what data enters AI systems, how outputs are used, and when concerns are escalated.

Map

Map creates visibility into how AI is used across the organisation. It describes the process of recording AI systems, understanding their use context, and identifying affected stakeholders. At this stage, many organisations find that more AI is already in use than was previously known internally.

Measure

Measure assesses how likely a risk is and how severe its impact could be. This assessment should not happen only once. AI systems change, and so does their environment. AI risk management needs to reflect this reality.

Manage

Manage turns assessments into action: reducing, accepting, transferring, or continuing to monitor risks. Responsibilities and controls must be clearly defined. SoSafe’s Human Risk Management Dashboard supports this by helping make the human risk factor in this process continuously visible.

For teams familiar with the NIST Cybersecurity Framework, the logic of the AI RMF may feel relatively familiar.

ISO/IEC 23894:2023 and ISO/IEC 42001

Organisations already working with ISO 27001 have a useful base for information security. AI adds questions that ISO 27001 alone does not fully answer: how a model behaves, which data shaped it, how decisions are reviewed, and how much transparency is needed. Two ISO standards can help extend existing structures to AI.

ISO/IEC 23894:2023

ISO/IEC 23894 is a guide for AI risk management. It describes how organisations can identify, record, and handle AI-related risks in a structured way. The guide builds on ideas from ISO 31000. It is not certifiable, but it gives teams a clearer method for working through AI risks.

ISO/IEC 42001

ISO/IEC 42001 defines requirements for an AI management system and is certifiable. Its structure follows familiar ISO management system logic, which can make integration easier for organisations already working with ISO standards. For ISO 27001 teams, the overlap is practical: risk management, documentation, internal audits, and related controls.

From a CISO perspective

In practice, this is not an either-or decision between ISO/IEC 42001 and ISO 27001. AI systems often process sensitive data, connect to internal systems, and influence decisions. ISO 27001 already covers parts of that territory. The AI-specific layer adds questions about model behaviour, training data, transparency, and human oversight. ISO/IEC 42001 provides the management-system structure for this, while ISO/IEC 23894 supports the risk management method.

Key components of AI risk management

A framework provides structure. What matters in day-to-day operations are the processes behind it. Regardless of which framework an organisation chooses, several components appear in every effective approach to AI risk management.

Continuous monitoring

Model drift rarely appears all at once. Data changes, user behaviour shifts, and markets move. A model may therefore start producing weaker results even though it still runs without technical errors. Automated monitoring with defined thresholds and clear escalation paths belongs in the operating model, not only in the project plan.

Documentation and traceability

An AI tool can enter a process quickly: a test account, a first use case, initial results. Months later, Audit may ask who approved the tool, which data was used, and whether the output was reviewed.

If there are no clear answers, this can create an AI compliance risk. Evidence matters, especially in the context of the EU AI Act. Good documentation starts with the first use case, not just before an audit.

Governance for autonomous systems

Autonomous AI systems can do more than provide answers. Some can move tickets, draft emails, trigger tasks, or retrieve data from other systems. One weak decision can quickly turn into a process chain.

These systems need practical guardrails. What may the agent do on its own? When does it need approval? Who can see what is happening? And who can intervene before one error turns into several?

The human factor

Technology and processes alone are not enough. Employees decide which AI tools they use, which data they enter, and whether they question the results. SoSafe’s Human Risk Management Dashboard supports organisations in developing a Human Firewall and making the human risk factor in AI risk management visible.

Which AI risk management framework is the right fit?

The right framework depends on context. Regulatory environment, maturity of AI use, and existing structures all play a role. The table below is a starting point for discussion, not a substitute for an individual assessment.

These approaches are not mutually exclusive. Many organisations use the NIST AI RMF to structure risks and ISO/IEC 42001 to build an AI management system. The EU AI Act provides the legal framework that both approaches can align with.

The right combination depends on the organisation:

• Maturity of existing risk processes
• AI systems currently in use
• Applicable regulatory obligations
• Available time, budget, and expertise for implementation

Framework implementation

Companies should start implementation where structures already exist: risk management, information security, data protection, and internal approvals. From there, AI risk management can become part of existing processes instead of a separate add-on project.

1. Inventory

Start with a simple question: Which AI systems are actually in use? Officially procured systems are only part of the picture. Test accounts, browser-based tools, pilots, and department-level solutions also belong in the inventory.

This is often where Shadow AI becomes visible. Teams use AI because it saves time, not because they want to bypass governance. For AI risk management, the response still needs to be clear: unknown systems cannot be assessed, approved, or secured.

2. Clarify risk classes and regulation

After the inventory, systems need to be classified. Does a system fall under the EU AI Act? Is it a high-risk system? Are there requirements from sector-specific regulation, data protection, or internal policies?

These questions determine how much review, documentation, and control may be needed.

3. Select and adapt the framework

No framework will fit perfectly out of the box. The NIST AI RMF helps teams structure AI risks. ISO/IEC 42001 describes an AI management system. Organisations working with ISO 27001 can often build on roles, processes, and controls that already exist.

4. Embed governance

An AI risk management framework needs named responsibilities, not just general ownership. Approval cannot sit with “the business” in the abstract. Output review also needs a clear owner. The same applies to stopping a use case when the risk picture changes.

Employees also need rules and training that reflect real work situations.

5. Monitoring and continuous improvement

AI use changes after go-live. Teams find shortcuts, providers release updates, and the data no longer looks exactly as it did during testing.

Regular operational reviews are therefore part of AI risk management. Depending on what they show, the next step may be a tighter approval process, a technical check, clearer guidance, or additional training.