An AI risk assessment is a structured process for finding out which AI tools and uses in a business could cause harm, and deciding what to do about each one. It works best as a maintained six-step cycle, moving through inventory, classification, assessment, registration, control, and monitoring in turn.

AI risk management is the ongoing practice of finding out where AI could go wrong in a business and doing something about it before it does. If you deploy a high-risk AI system, three duties will eventually apply to you directly. You will need to name someone to oversee how it is used, keep watching how it actually behaves, and hold onto its logs for at least six months, where those logs are under your control.[1] Under Article 26 of the EU AI Act, these obligations apply to Annex III high-risk systems from 2 December 2027, the date set by the 2025 to 2026 AI Omnibus amendments. Building the underlying process now is good practice regardless of the exact legal start date. Most Irish SMEs use AI tools built by others (deployer) rather than building their own (providers), which means the legal weight sits on how AI is used day to day. A risk assessment is how you find out, concretely, what that means for your business.

If knowing which of your AI tools actually carries risk feels like guesswork right now, that is precisely the gap an AI Readiness Assessment is built to close.

What counts as AI risk, and where do you start?

AI risk covers every AI tool and use case actually operating in the business, approved or not, including the free chatbot a colleague uses on their own initiative to draft emails. The written policy will not tell you what belongs on it. Most AI use in a business grows informally, tool by tool, rather than through any formal rollout, so the policy is usually the last place it shows up. The starting point is a list, however rough it is at first. To build the list properly, speak directly with each team and ask them plainly which AI tools they are already using, for which tasks, and how often. Accountancy practices, marketing teams, and warehouse operations all tend to turn up AI use that was never centrally approved, things like drafting emails, summarising meetings, building spreadsheet formulas, generating images, and replying to customers. Record each use as its own line rather than lumping everything together under a single generic heading of "AI use," because a register that just says "various AI tools" cannot be assessed or controlled in any meaningful way. Ten or more distinct uses recorded on a spreadsheet is a genuinely working inventory. An empty list is itself a signal worth taking seriously. It almost always means nobody has asked the question yet, even though AI use is very likely happening somewhere in the business already.

The AI Readiness Assessment does this inventory work formally, across six dimensions, for a business that wants a professional first pass instead of a DIY start. Either way, the inventory is where every risk process has to begin. You cannot assess what you have not listed.

In summary

List first. Judge later.

How do you classify AI risk in your business?

Classification sorts each use case by what the AI actually does and who is affected if it gets something wrong. The tool it runs on matters less than the job it is doing. The same tool can land in different places depending on that job. Microsoft Copilot drafting an internal meeting summary is a low-stakes use. The same tool feeding an automated flag on staff performance ratings sits much higher on the scale, closer to the kind of high-risk use the EU AI Act names directly in its four risk tiers. Article 9 of the Act sets out what a risk management system will have to do, once it applies from 2 December 2027 for Annex III systems, for the providers who build these systems. It has to identify risks, estimate how likely and severe they are, and keep the process running throughout the system's use. It is not a single sign-off.[2] The shape is worth borrowing even where the legal duty sits elsewhere.

In summary

Would this use case embarrass you if a customer asked about it directly?

How do you assess and score AI risk?

Scoring does not need much machinery to be useful. A simple two-axis check, how likely is this to go wrong, and how bad would it be if it did, sorts a long list into something you can actually act on. Low likelihood and low impact uses, an AI tool drafting a first pass at a blog post, checked before it goes anywhere, need little more than a note. High likelihood and high impact uses, an AI tool shaping a decision about a customer or an employee, with limited human review, need a proper look.

Somewhere in that assessment, ask a second question. Is this processing personal data in a way likely to result in high risk to the person concerned? If so, a Data Protection Impact Assessment under GDPR Article 35 is required, and the DPC treats it as a core tool for identifying and reducing exactly this kind of risk before it causes harm.[3] The AI Act does not itself create this DPIA duty, but Article 26(9) explicitly ties deployer use of provider-supplied information to DPIA compliance under GDPR Article 35, linking the two regimes directly rather than leaving them as separate tracks. Most businesses running an AI risk assessment for the first time find at least one use case that should have triggered a DPIA months ago. A business that would rather have this whole process run externally, as a paid, one-off diagnostic, is describing an AI Act and GDPR audit, a different engagement from the internal process covered here.

In summary

The DPIA question is often the one nobody thought to ask.

What should an AI risk register actually contain?

A risk register is not a document you file. It is a routine you run. Most businesses can cover this in six columns. Each row needs the use case, who owns it, the classification from the previous step, the score, the control applied, and the date it was last reviewed. Keep it in whatever your team will actually open; a shared spreadsheet is enough for most SMEs under fifty people. The software matters less than the habit of opening it. Someone should be able to answer "what AI risk does this business carry right now" in under a minute, from one document, instead of reconstructing the answer from memory.

A business that wants formal ownership structures and a wider policy layer around this needs a governance and workflow blueprint. A standalone spreadsheet register is a genuinely sufficient starting point for a smaller team. Businesses further along sometimes formalise this discipline against ISO/IEC 42001, the international AI management system standard, though certification is a separate decision from simply keeping a working register.

In summary

Six columns. One spreadsheet. Five minutes to update each quarter.

How do you control AI risk once you have found it?

Controls should match what the assessment actually found. A low-risk drafting tool needs a light touch. A tool shaping a decision about a person needs real oversight before it goes further. For the higher-risk end, Article 26 outlines what good control will look like for deployers once it becomes applicable on 2 December 2027 for Annex III systems, and is a useful template to build toward now: a named person with the authority and competence to oversee the system, input data checked for relevance where you control it, and a habit of watching how the tool actually behaves, without assuming the vendor already has it covered.[1] The full six-item obligation list, and how it changes depending on whether the AI stays internal or reaches a customer, is covered in using AI yourself versus deploying it for customers.

For most SME use cases below that threshold, proportionate control is simpler. A human checks the output before it is used, or sensitive data is kept out of the tool entirely. For anything riskier than that, the use case is paused until someone senior has looked at it properly.

In summary

Size the control to the actual finding.

How often should you review and monitor AI risk?

Quarterly is a reasonable default for a small team, with an extra check whenever a new tool is adopted or an existing one changes what it is used for. Annual review is too slow once AI use is spreading through a business, and most businesses running their first assessment are surprised by how much changes in three months. A new tool gets trialled by one team, or an old one is now used for something riskier than when it was approved.

Article 26 will build ongoing monitoring into the deployer's legal duty directly, once it applies from 2 December 2027 for Annex III systems, including a requirement to suspend use and escalate without undue delay if a system starts presenting a risk it was not expected to.[1] Build that same instinct into the internal process now. If something goes wrong with an AI-assisted decision, a calm, structured post mortem fixes the immediate problem and feeds what was learned straight back into the register, so the incident does not simply disappear once the immediate fire is out.

In summary

Three months is long enough for a lot to change.

A risk assessment only holds its value if it keeps being updated. The AI Policy and Governance Pack is built to help with exactly this. It turns a first-pass register into a formal, maintained document with real ownership behind it, built around the AI your business actually uses rather than a generic template.