AI risk acceptance — who actually signs
Risk acceptance for AI systems is often attributed to a committee rather than a named individual. When something goes wrong, no one is accountable. This piece defines who should sign risk acceptance for AI systems and what that signature requires.
Risk acceptance records for AI systems frequently contain one of two accountability failures. The first is attribution to a group — “approved by the AI Committee” or “accepted by the security team” — rather than a named individual. The second is the absence of any named acceptor at all: the record documents the risk and lists the controls, but no one is identified as having accepted the residual risk.
Both failures have the same consequence: when something goes wrong, there is no accountable person. The accountability is diffused across a committee that may no longer exist in the same composition, or it is absent from the record entirely. This is not a documentation problem — it is a governance design problem.
The accountability problem
The accountability problem in AI risk acceptance is structural. It arises from the design of governance processes that route AI deployment decisions through committees rather than to named individuals. Committees are appropriate for deliberation — bringing multiple perspectives to a complex decision. They are not appropriate as the final accountability unit, because committees cannot be held accountable in the way individuals can.
The resolution is not to eliminate committee review — it is to distinguish deliberation from acceptance. The committee deliberates and recommends. A named individual accepts. The record documents both: the committee's deliberation and recommendation, and the named individual's acceptance of the residual risk.
Risk acceptance roles — what they accept and what they must not accept
| Role | What they accept | What they must NOT accept |
|---|---|---|
| CISO | Residual technical risks in security controls — gaps in authentication, transport, tool scope, or monitoring where the control is partially implemented and the residual risk is within the defined risk appetite. | Regulatory non-compliance risks (GDPR, EU AI Act). Risks that require business-decision authority (data monetisation, customer impact). Risks where the business owner has not been informed. |
| DPO | Data protection risks where processing is lawful but creates residual privacy risk — for example, a longer-than-ideal inference data retention period justified by a documented operational need. | Processing without a lawful basis. Risks that require board-level approval under Article 35 DPIA. Technical security risks outside the DPO's competence (infrastructure, model behaviour). |
| Head of AI | Model behaviour residual risks — alignment limitations, known failure modes, capability boundaries — where the risk is documented and the deployment scope is appropriate given the risk level. | Regulated-data processing risks (DPO authority). Customer-facing risks that require business owner sign-off. Supply-chain risks that the Head of AI cannot independently verify. |
| Business Owner | Operational and commercial risks — the risk that the AI system will underperform, produce unexpected outputs in business processes, or require additional human oversight that has cost implications. | Technical security risks outside their competence. Regulatory risks without confirmed DPO or legal sign-off. Risks that require board approval under the organisation's risk framework. |
What risk acceptance means
Risk acceptance is a specific act: a named individual with the authority to do so confirms that they have reviewed the residual risk, that the residual risk is within acceptable bounds under defined conditions, and that they are accountable for that determination.
Risk acceptance is not:
- An acknowledgment that a review was conducted.
- A sign-off on the controls being in place.
- Agreement that the system can proceed to the next review stage.
- Attendance at the governance committee meeting where the decision was made.
It is the specific act of accepting responsibility for the residual risk — the risk that remains after controls are applied — under the conditions described in the disposition record. The acceptor is not accepting the risk of control failure; that is the responsibility of the control owners. They are accepting the residual risk that exists even when the controls are working as designed.
The named acceptor requirement
The named acceptor requirement is that every risk acceptance record must contain: the full name and role of the acceptor, the date of acceptance, and the specific condition under which the acceptance holds.
Name, role, date, condition. These four elements are the minimum content of a valid risk acceptance. A record missing any one of them is not a risk acceptance — it is documentation of an intention to accept risk, which is not the same thing.
The condition is the element most often missing. Risk acceptance without a condition is open-ended — the acceptor is accepting the risk regardless of how the system changes over time. A condition bounds the acceptance to the state of the system as assessed: “Residual risk accepted on the condition that [named control] remains in place and [named scope limitation] is not exceeded.”
Conditional acceptance
Most AI risk acceptances in practice are conditional — the acceptor accepts the residual risk on the condition that specific controls are in place and the system operates within a defined scope. The conditions are the substance of the acceptance.
Conditions that work: specific, verifiable, with defined owners. “Human review of all model outputs before they are presented to customers, maintained by the product operations team, verified through the weekly audit process.”
Conditions that do not work: intent-based, vague, or without an owner. “Appropriate controls will be implemented before launch.” This is not a condition — it is a future commitment. A future commitment is not risk acceptance; it is risk deferral.
Accountability over time
When the named acceptor leaves the organisation, changes roles, or is no longer the appropriate accountability holder for the system, the risk acceptance must be updated. Acceptance does not transfer automatically to a successor.
The governance process should include a trigger for reviewing risk acceptance assignments when relevant roles change. The new holder of the role should be asked to confirm their acceptance of the residual risk — after reviewing the current state of the system and its controls. A new acceptor who does not review the system before accepting responsibility has accepted accountability without adequate basis.
The governance record
The risk acceptance entry in the governance record should contain:
- The name and role of the acceptor.
- The date of acceptance.
- The residual risk being accepted — specific, not just a category.
- The conditions under which the acceptance holds.
- A reference to the evidence pack that supported the acceptance decision.
- The re-assessment trigger that will invalidate the acceptance if conditions change.
The record should be signed — digitally or with a documented approval workflow — by the named acceptor. An acceptance attributed to a person who has not actively confirmed it is not an acceptance. For the broader governance record structure, see What makes an AI decision record defensible.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Build accountable AI governance records
Drel structures AI dispositions with named acceptors, specific conditions, and re-assessment triggers — so risk acceptance records hold up when they need to.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.