Definition: AI risk management is a set process for the risks of your AI tools. You find the risks, rate them, treat them and keep watching them. It goes beyond information security. It also covers legal, ethical and day-to-day risks, such as wrong outputs, discrimination, data leaks and too much reliance on one vendor.
Why AI needs its own risk management
Many small and mid-sized firms use AI without ever treating it as a project of its own. Typical examples:
- the chatbot in customer service
- the translation feature in the office suite
- automatic receipt scanning in accounting
- the language model staff signed up for privately and now use for work
Classic IT risk checks often just list these as "software". They miss traits that are specific to AI:
- Probabilistic outputs: AI gives answers that sound right but are not sure to be right. Made-up facts (hallucinations) are not a bug in the usual sense. They are part of how the technology works.
- Data dependency: The quality and bias of training data shape how the AI behaves. And what users type in may contain confidential data.
- New attack surfaces: Prompt injection, poisoned training data and model theft are only partly covered by classic security controls.
- Change over time: Vendors update models without notice. Quality can also slowly drop as input data changes (drift).
Frameworks to build on
SMEs do not need to invent their own method. They can combine proven frameworks:
- ISO/IEC 23894:2023 applies the ISO 31000 risk process to AI. It describes sources of risk that are specific to AI.
- NIST AI RMF 1.0 splits the work into four functions: Govern (who is in charge, and culture), Map (context and planned use), Measure (rating and testing) and Manage (treatment and monitoring).
- The EU AI Act (Regulation (EU) 2024/1689) uses risk classes. They decide which duties apply at all.
- ISO/IEC 27001:2022 gives you a management framework. You can add AI risks to it instead of building a second system.
A seven-step approach
- Build an AI inventory: List every AI feature in use. Include features built into standard software and tools nobody approved (shadow AI). For each one, note the purpose, vendor, data used and owner.
- Find your role and risk class: Is your company a provider or a deployer under the AI Act? Which class does the use case fall into: banned practice, high risk, transparency duties or minimal risk? High-risk examples under Annex III include screening job candidates or rating staff performance.
- Rate the risks: For each relevant tool, estimate likelihood and impact. Do this one by one for confidentiality, correct outputs, availability, legal compliance and effects on the people concerned.
- Set controls: Use technical controls (access limits, data classes, logging) and rules (an AI policy, a sign-off process for new tools). Keep a human in the loop for decisions with real impact.
- Check vendors: Where is data processed? Are your inputs used for training? Which certifications and contract terms exist? How does the vendor announce model changes?
- Build skills: Art. 4 AI Act has applied since 2 February 2025. As amended by the Digital Omnibus (in force since 27 July 2026), providers and deployers must help their staff build AI literacy. Training should fit roles and use cases. Keep a record of it.
- Monitor and adjust: Log incidents and wrong outputs. Keep the inventory up to date. Repeat the risk check when new tools or model changes come along.
Typical risks and matching controls
| Risk | Example | Control |
|---|---|---|
| Data leak | Draft contracts pasted into a public chatbot | Approved business tool, policy, data classes |
| Wrong outputs | AI-written product details have wrong technical values | Four-eyes check, labels, spot checks |
| Discrimination | Automated pre-screening puts some applicant groups at a disadvantage | High-risk check, human decision, bias tests |
| Manipulation | Prompt injection tricks a customer chatbot into false promises | Limited rights, output filters, monitoring |
| Vendor lock-in | Vendor changes model, prices or terms of use | Exit plan, contract terms, tests after updates |
Keeping it proportionate
Good AI risk management does not have to be heavy. For most firms, this is enough:
- an inventory that you keep up to date
- a clear AI policy
- a simple sign-off process
- a deeper check for the few tools that could do serious harm
Do you already run an ISMS based on ISO 27001? Then add AI to your risk catalogue, asset register and supplier management. Is your organisation in scope of NIS2? Then AI systems belong in the risk management that Section 30 of the German BSI Act (BSIG) requires anyway. This holds even though NIS2 does not name AI. If personal data is involved, check whether you need a data protection impact assessment under Art. 35 GDPR.
Conclusion
AI risk management starts with a clear view of how AI is really used. It works once it is part of your existing management processes. SecTepe helps mid-sized firms add AI risks to their ISMS in a practical way, for example as an external information security officer.
Frequently asked questions
Do we need AI risk management if we only use off-the-shelf tools?
Yes, in a light form. Even with standard tools, you decide which data goes in and how you use the outputs. That is where most risks arise.
Who should be responsible?
Senior management holds overall responsibility. For the daily work, a small team works well. It should include people from information security, data protection, IT and the business. That way, technical, legal and business risks are rated together.
More terms in “AI & Machine Learning”
- Adversarial Machine Learning
- AI Backup and Model Recovery
- AI Certification
- AI Data Protection Impact Assessment (AI DPIA)
- AI Forensics
- AI Governance for Managing Directors
- AI Governance Framework
- AI Incident Response Playbook
- AI Monitoring and Anomaly Detection
- AI Penetration Testing
- AI Phishing Detection
- AI Poisoning