AI risk management in practice.

Know what AI you run

You cannot manage risks you cannot see. The first step is an AI inventory: a single list of every AI system the organisation builds, buys or uses.

For each system, record at least:

• What it does and which business process it supports.
• Who owns it: a named person accountable for it.
• Where it came from: built in-house, bought from a vendor, or AI inside a product you already use.
• Which model and version it runs, and who can change them. For bought products, ask the vendor.
• What data it uses, especially personal or confidential data.
• What it can do: advise only, or take actions such as sending messages or changing records.
• Who is affected by its outputs: staff, customers, the public.

Look beyond obvious projects. AI often arrives unannounced, as a new feature in office software, a customer-service platform or a supplier's service. Staff may also use free public AI tools on their own. Ask vendors directly, make "does this use AI?" a standard question when buying anything, and ask teams what tools they actually use.

Sort systems by risk

Not every AI system needs the same scrutiny. A tool that suggests email subject lines carries far less risk than a model that scores mobile loan applications. Risk tiers let you match the effort to the stakes.

Useful questions for sorting a system:

• Impact on people: does it affect someone's money, job, access to services, health or legal position?
• Autonomy: does a person review every output, or does the system act on its own?
• Scale: how many decisions or people does it touch?
• Data: does it use personal, sensitive or confidential data?
• Reversibility: can a wrong result be easily noticed and undone?
• Law and regulation: does a specific rule apply, such as data protection law or sector regulation?

A common approach uses three or four tiers, for example low, medium, high and not permitted. Each tier has its own required reviews, approvals and controls. Record the tier and the reasons in the inventory, and revisit it when the system or its use changes.

Assess a system before it goes live

Systems in higher tiers get a structured assessment before launch, and again after significant changes. A good assessment asks:

• Purpose: what problem does it solve, and is AI the right way to solve it?
• Data: where do the training and input data come from, is their use lawful, and do they represent the people affected?
• Performance: how accurate is it, on which tests, and does accuracy differ between groups of people?
• Failure: what happens when it is wrong, who would notice, and how would the harm be put right?
• Oversight: where do people review or approve, and do they have the time and information to do it properly?
• Security: how could it be misused or attacked, for example through prompt injection or data leakage?

Data protection law may require its own assessment. Under section 31 of Kenya's Data Protection Act, 2019, a data protection impact assessment (DPIA) is needed before processing that is likely to result in a high risk to people's rights and freedoms. The Data Protection (General) Regulations, 2021 list examples that include automated decision-making with legal or similarly significant effects, and innovative use of new technology. Many AI systems that profile people or make decisions about them will therefore need a DPIA. The Act says DPIA reports are to be submitted 60 days before processing starts. Where both assessments apply, combine them into one piece of work.

The assessment ends with a clear decision, approve, approve with conditions, or reject, signed by the right person for the tier. For a fuller method, see ISO/IEC 42005:2025, international guidance on AI system impact assessment.

Controls and documentation

The assessment identifies risks; controls reduce them. Common AI controls include:

• Human review or approval at the points where errors would do most harm.
• Limits on what the system can access and do, enforced in code, not only in instructions.
• Testing before release, including checks for fairness between groups and deliberate attempts to break or misuse the system.
• Fallbacks: a manual route when the system is unavailable or unsure.
• Clear notices telling people when AI is used and how to reach a person or challenge a decision.

Documentation lets you explain the system to an auditor, regulator or customer long after it was built. Keep:

• a description of the system, its purpose, data, model version and limits (often called a model card);
• the assessment, the risk tier and the approval;
• test results for each release;
• a log of changes, incidents and decisions.

Bought AI needs the same care. Ask vendors for their documentation, test results, data-handling terms and how they will tell you about model changes, and put these in the contract. Where a vendor processes personal data for you, the Data Protection Act, 2019 requires a written contract that limits it to your instructions.

Monitor, respond and review

Risk does not end at launch. Data changes, models are updated and people find new ways to use, or misuse, a system.

• Monitor the measures that matter for each system: accuracy, errors, complaints, how often people overrule it and any differences between groups.
• Set thresholds that trigger an agreed action, such as pausing the system, extra review or reassessment.
• Have an incident process for AI: how problems are reported, who can pause a system, how affected people are helped, and when regulators or individuals must be told. For personal data breaches with a real risk of harm, Kenya's Data Protection Act, 2019 requires the Data Commissioner to be notified within 72 hours.
• Review on a schedule, with higher-risk systems reviewed more often. Confirm each system is still needed, still performs and still has an owner.
• Retire deliberately: when a system is switched off, deal with its data, its records and anything that depended on it.

Report regularly to senior management on the inventory, risk tiers, incidents and open actions. AI risk management works best as routine: part of how systems are bought, built and run, not a one-off project.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.