A risk score without an assigned action, control owner and evidence trail is not governance. It is a record of concern. AI risk treatment is the operational discipline that turns identified risks into proportionate, testable measures – and enables an organisation to show a regulator, auditor or board exactly what has been done.
For organisations subject to the EU AI Act, this distinction matters. High-risk AI systems require a documented risk management system throughout their lifecycle. ISO/IEC 42001 similarly requires organisations to plan how they will treat AI risks and assess the effectiveness of their actions. Neither framework is satisfied by a one-off assessment stored in a spreadsheet or shared drive.
What AI risk treatment means in practice
AI risk treatment is the process of deciding what to do about a recorded AI risk, implementing that decision and retaining evidence that the measure works. It begins after risk identification and analysis, but it must remain connected to both. A treatment that is no longer appropriate when a model, dataset, user group or deployment context changes should be revisited.
In practical terms, each material risk needs a defined disposition. The organisation may reduce it through controls, avoid it by changing or stopping the intended use, share elements of it through contractual or technical arrangements, or accept a residual level of risk through an authorised decision. Acceptance is not the absence of action. It requires a clear rationale, an accountable approver and a record that the residual risk falls within the organisation’s risk appetite.
The correct option depends on the AI system and its use. A generative AI assistant drafting internal copy presents a different risk profile from an AI system supporting recruitment decisions, creditworthiness assessment or access to essential services. Applying the same generic control set to each is neither efficient nor defensible.
Risk treatment under the EU AI Act and ISO 42001
Article 9 of the EU AI Act requires providers of high-risk AI systems to establish, implement, document and maintain a risk management system. The process is continuous and iterative across the system lifecycle. It must identify and analyse known and reasonably foreseeable risks, estimate and evaluate risks that may emerge when the system is used as intended or under reasonably foreseeable misuse, and adopt suitable risk management measures.
That obligation creates a practical treatment requirement: teams need to show not only which risks were identified, but why a chosen control is suitable, how it has been implemented and how its performance is checked. Where residual risks remain, they must be judged acceptable in relation to the benefits of the intended purpose and the applicable risk management measures.
ISO/IEC 42001 provides the management-system structure around this work. Its AI risk treatment requirements expect an organisation to select options, determine necessary controls, compare them against an appropriate control framework where relevant, prepare a treatment plan and retain documented information. This is not a request for a larger risk register. It is a requirement for a managed chain from risk to treatment, ownership, implementation and review.
The frameworks overlap, but they are not interchangeable. The EU AI Act contains system-specific legal obligations, particularly for high-risk systems. ISO 42001 establishes organisation-wide governance disciplines. A credible programme maps individual system risks to legal requirements and control objectives while also maintaining the policies, competence, internal audit and management review expected of an AI management system.
Start with the system, not a library of controls
Control libraries are useful, but starting there often produces compliance theatre. First establish the AI system’s inventory record: its purpose, provider or deployer role, intended users, affected persons, model type, data sources, deployment environment, human oversight arrangements and applicable legal classification.
This context determines the risk. Consider an applicant-screening tool that ranks candidates. Relevant treatment may include testing for discriminatory outcomes, restricting features that act as proxies for protected characteristics, defining meaningful human review, logging overrides and establishing an incident escalation route. A generic instruction to “monitor bias” is too vague to implement or audit.
The same discipline applies to third-party AI. Buying a system does not transfer accountability for deployment decisions. Treatment may need supplier due diligence, contractual evidence requirements, configuration restrictions, local impact assessments, acceptance testing and periodic reviews. The organisation should record which party owns each action and which evidence it can realistically obtain.
Build a treatment plan that can be operated
A usable AI risk treatment plan should make implementation unambiguous. For every risk requiring action, record the risk statement, inherent rating, selected treatment option, control or action, accountable owner, due date, target residual risk and evidence expected. Link it to the relevant AI system and, where applicable, the EU AI Act obligation, ISO 42001 control objective or internal policy.
Treatment plans fail when actions are written as aspirations. “Improve transparency” cannot be verified. “Publish a user-facing notice describing the system’s purpose, limitations, human escalation route and data handling before go-live; legal owner to approve; product owner to implement” can be verified.
A well-designed workflow separates the person accountable for the risk from the person implementing a control and the person independently reviewing effectiveness. In smaller teams, one individual may hold more than one role, but the approval route should still be explicit. This matters particularly where a business owner wants to accept residual risk that the compliance or security function considers outside appetite.
Evidence should be defined before the action is marked complete. Depending on the treatment, it may include test results, model evaluation reports, signed approval records, supplier documentation, version-controlled policies, training completion records, access logs, incident records or monitoring outputs. Evidence held in personal inboxes and disconnected folders is difficult to retrieve when assurance is needed quickly.
Controls must address the full AI lifecycle
Treatment is not complete at launch. Data drift, changes in model behaviour, expanded user access, new integrations and altered use cases can invalidate earlier assumptions. A control that was effective in a pilot may not be adequate once the system reaches customers, employees or the public.
For high-risk systems, post-market monitoring is a core operational requirement under the EU AI Act. The organisation needs a route for gathering performance information, investigating serious incidents and malfunction, and feeding findings back into risk management. For deployers, meaningful monitoring also depends on staff knowing what to report and having a workable escalation path.
This is where periodic reviews alone are insufficient. Some risks need event-driven reassessment. Trigger events commonly include material model updates, changes to training or reference data, a new decision-making purpose, a security incident, a complaint alleging harm or discrimination, and a supplier change. The governance process should specify which events reopen the assessment and who can authorise continued operation while treatment is updated.
Measure effectiveness, not activity
Completed actions are not proof of reduced risk. Teams should define indicators that test whether a treatment is working. For example, a human oversight control may be assessed through override rates, reviewer agreement, evidence of reviewer competence and whether escalations are resolved within agreed timescales. A data quality control may be assessed through completeness thresholds, error rates and exception handling.
Metrics must be interpreted in context. A low override rate may indicate a reliable system, but it could also show automation bias or ineffective reviewer training. That is why management review needs both quantitative results and informed challenge from compliance, risk, technical and operational owners.
Where effectiveness is inadequate, the treatment plan should be reopened. The organisation may strengthen the control, narrow the use case, introduce additional human intervention or suspend use. Continuing with a known ineffective measure creates a far more difficult position in an audit or regulatory investigation than documenting a proportionate pause and remediation decision.
Replace fragmented registers with a system of record
Spreadsheets can capture a point-in-time assessment, but they struggle to manage the relationships that make AI governance auditable: one system linked to several use cases, risks, legal classifications, controls, evidence items, incidents, owners and review dates. Manual tracking also makes it easy for an approved treatment to disappear when staff change roles or a system is updated.
A purpose-built system of record makes those dependencies visible. It should preserve the rationale for classification and treatment, route actions to named owners, retain approval history, flag overdue reviews and produce a coherent evidence set for internal audit, customers or regulators. The objective is not to buy a large enterprise platform and create another implementation programme. It is to establish a controlled operating process that the organisation can run.
Endaxi AIG is designed for this practical requirement: connecting AI inventory, EU AI Act classification, risk assessment, control implementation and audit-ready evidence in one governance workflow. That allows teams to move beyond static registers without losing the proportionality that mid-market compliance programmes need.
The strongest treatment plan is one that changes decisions before harm occurs, not one that merely explains them afterwards. Give every material AI risk an owner, a measurable action, a review trigger and evidence that can withstand scrutiny. That is how governance becomes operational.