The Risk Was Accepted. Who Authorized the Action?
← Back to Articles
AI Governance11 min read

The Risk Was Accepted. Who Authorized the Action?

Why regulatory tolerance for residual risk cannot substitute for pre-execution authorization

Accepting residual AI risk has a foreseeable human cost. It does not authorize the next consequential action, and cars and airplanes do not close the gap.

FERZ, Inc.October 28, 2026
AI risk acceptancepre-execution authorizationAI accountabilityresidual riskFAA dispatch releaseSEC Rule 15c3-5chase and cancelNIST AI RMFruntime authorization boundaryauthorization artifact

Version 1.0 · DOI: 10.5281/zenodo.23745812

1. The cost of accepted risk

Risk acceptance is usually written in percentages, confidence intervals, and expected losses. The figures are abstract. What they describe is not.

When a decision-maker accepts an operating model whose risk assessment anticipates serious harm, the accepted exposure includes that foreseeable human cost. Calling it residual risk does not remove the people who may bear it.

For autonomous AI systems, the distinction that matters sits at the execution boundary.

Some risks remain even when every consequential action is properly authorized. The release of an action without established permission is a separate, controllable failure mode. Within a declared scope, a correctly implemented, non-bypassable authorization boundary prevents that release.

Accepting the residual risks of authorized operations is not a justification for allowing actions to proceed without authorization.

2. Why cars and airplanes are not an answer

The familiar objection is that society already accepts deaths from driving and flying. If zero fatalities were the condition of permission, much of modern life would be impossible.

The objection answers a question no one asked. Pre-execution authorization does not promise that a permitted action is harmless. It establishes whether the action was permitted before its consequences were imposed.

Driving does not place a gate on every maneuver. It relies largely on licensed, legally accountable human operators who respond to sanctions and personal consequences. An AI agent does not respond to those incentives in the same way. Its operators and deploying institution remain accountable, but liability imposed on them after execution does not establish that the agent's particular action was authorized before execution.

Aviation, where the decision to operate is an institution's and the exposure falls on passengers and the public, is the clearer comparison. Two requirements apply to domestic and flag operations under 14 C.F.R. Part 121. The dispatching-authority rules, §§ 121.593 and 121.595, require specific aircraft-dispatcher authorization before domestic and flag flights begin, with distinct provisions governing intermediate stops. The dispatch-release rule, § 121.663, separately requires a release for each covered flight, signed by the pilot in command and an authorized aircraft dispatcher only when both believe the flight can be conducted safely. The release carries flight-specific information, including applicable weather reports or forecasts, and is retained as a record [Part 121].

This is an authorization requirement governing whether an operation may begin. It is not a guarantee that the operation will be free of harm.

The FAA has also declined to let a general affirmation substitute for the specific one. In a 2018 notice, since expired, it withdrew guidance that had treated a dispatcher's signature on a daily duty roster, combined with identifying information printed on each release, as the dispatcher's signature. The notice stated that signing a single daily duty log is "not equivalent to an authorized dispatcher signing each dispatch release" [N 8900.462].

Neither example claims that AI actions need a human signature, or that a dispatch release satisfies the requirements of AI runtime authorization. Their relevance is narrower. Driving and the covered aviation regime are different regulatory arrangements, but neither establishes that an aggregate risk assessment grants permission for every consequential action.

For an autonomous AI system operating within a declared action-specific authorization scope, the relevant question is whether each governed release depends on the applicable authorization verdict. The fact that other industries accept unavoidable accidents does not answer it.

3. Risk acceptance is not permission

Regulatory risk management necessarily involves trade-offs. A technology may offer substantial benefits while retaining a nonzero probability of failure. Refusing every technology that cannot guarantee perfect outcomes would itself impose costs, including harms from forgone benefits.

There is nothing inconsistent about accepting residual risk while demanding rigorous authorization. The inconsistency arises when evidence that a system's aggregate risk is tolerable is treated as sufficient evidence that its individual actions are permitted.

Risk acceptance asks whether the residual exposure of a defined activity or class of operations is tolerable. Authorization asks whether a particular proposed action is permitted under the applicable policy, governed state, and authority.

An authorized risk decision may establish operating conditions and may also grant or accompany standing authority for a defined class of operations. Accepting the exposure does not itself establish whether a proposed action falls within that authority. Where release requires an action-bound authorization verdict, the risk decision cannot substitute for that verdict.

Consider a hospital that accepts the residual risks of an AI-enabled clinical workflow after weighing expected benefits, failure modes, and mitigations. The decision may justify operating that workflow. It does not establish that a particular modification to a patient's care falls within the workflow's delegated authority.

A tolerable error rate describes the class. Permission attaches to the act.

Statistical reliability cannot resolve the distinction. A system with an exceptionally low historical rate of harmful actions may still attempt an unauthorized transaction, exceed a cumulative limit, act under an outdated policy, or exceed its delegated authority.

Conversely, an action may be properly authorized and still cause harm. Authorization governs permission, not the certainty of a favorable outcome.

FERZ's technical note Layering Is Not Authorization addresses the architectural counterpart: aggregated non-objection does not become an action-bound ALLOW merely because more controls are added. Insurance may redistribute financial losses, but it cannot supply authorization.

4. Correction is not prevention

Aviation shows risk management coexisting with an operation-specific authorization requirement. Securities regulation addresses a different shortcut: correcting an action after release instead of conditioning its release.

SEC Rule 15c3-5 requires broker-dealers with market access to maintain risk management controls reasonably designed to prevent the entry of orders that exceed pre-set credit or capital thresholds. As the Commission explained when adopting the rule, those controls must be applied on an automated, pre-trade basis, before orders are routed to an exchange or alternative trading system [Rule 15c3-5].

Staff of the SEC's Division of Trading and Markets have addressed the obvious shortcut. Asked whether a control could permit a violative order to be entered and then immediately submit its cancellation, the "chase and cancel" approach, the staff answered that a control permitting entry with an attempt to cancel quickly is not reasonably designed to prevent entry. Such a control, the staff explained, could create a risk of execution [FAQ Q16].

Correction after release and a condition on release are different controls.

The Part 121 dispatching requirements and the market-access controls are binding requirements. The rejection of post-entry cancellation comes from nonbinding staff guidance interpreting the market-access rule. Neither regime establishes every property required by FERZ's Authorization Artifact Test [AAT], and neither is presented here as an implementation of it.

The same distinction applies to autonomous AI. When an institution accepts residual risk, what control prevents a system from acting beyond the permission the institution actually granted?

Observational inputs can inform a pre-execution authorization verdict when they are appropriately bound and evaluated. Monitoring alone, however, does not establish the policy-grounded, action-bound ALLOW that FERZ's authorization model requires for release.

Rapid intervention after release presents a different limitation. It may reduce consequences, but it cannot retroactively prevent the initial release. The SEC Division of Trading and Markets staff addressed precisely that distinction when rejecting the chase and cancel approach as a substitute for preventive market-access controls.

5. Whose risk is being accepted?

Risk acceptance is also an exercise of authority. Federal AI policy treats it as one: OMB Memorandum M-25-21 requires agency policies to enable agency heads to delegate "responsibilities and accountability for risk acceptance" to appropriate officials [M-25-21].

Risk acceptance has two sides. Someone holds the authority to accept the risk. Someone else may bear it: patients, applicants, customers, or members of the public who had no part in the decision and cannot see the threshold set on their behalf.

The governing authority matters. So do the affected parties, the applicable legal constraints, and the conditions attached to the decision.

Consider the hypothetical defense of an ungated system: it saves a hundred lives and costs one. That may justify operating the system. It is not sufficient for evaluating a potentially feasible authorization control.

Where it is technically feasible, the relevant alternative is the same system with its consequential actions subject to pre-execution authorization. If that alternative preserves the benefit while preventing unauthorized release, the resulting reduction in exposure is not a sacrifice of the technology's benefit.

Whether that alternative is technically feasible, what delays or denials it introduces, and how those effects compare with the risks of ungated execution are questions requiring evidence.

The burden is to justify the control decision, not to assume that authorization must be abandoned to preserve the benefit.

Delays, denials, and the time taken by authorized resolution can cause harm of their own. An action held for authorized resolution may delay help, and a denial may withhold something a person needed. These are empirical questions, not assumptions to be dismissed in either direction. An institution must account for both the risks of execution and the harms that authorization delays or denials may cause.

Authorization also does not require a human signature for every automated operation. It can be automated where governing rules, inputs, authority, and release conditions support it. In FERZ's authorization model, the verdict space is ALLOW, DENY, and ABSTAIN. Unresolved permission produces ABSTAIN: the proposed action is blocked, and it proceeds only if authorized resolution yields a boundary-emitted ALLOW.

What a favorable aggregate cannot do is turn an unauthorized action into an authorized one.

6. What regulators should be asking

Risk frameworks already supply much of the vocabulary. NIST's AI Risk Management Framework recognizes mitigation, transfer, avoidance, and acceptance as available risk responses, and calls for documenting residual risks and for processes addressing monitoring, intervention, and recovery [AI RMF]. These are legitimate risk-management functions. But a documented acceptance of risk does not by itself establish a runtime authorization boundary. Neither does a monitoring plan, an incident-response procedure, or an assigned human supervisor.

A framework may address many significant risks without imposing a universal action-level authorization requirement. That is not evidence that the framework endorses unauthorized behavior. It means its control requirements must be examined at their stated scope. Where action-level authorization is required, evidence of system-level risk acceptance cannot establish that the requirement has been satisfied.

FERZ's authorization model specifies what the evidence of action-specific authorization should show. These are the model's requirements, not obligations that current regulation generally imposes. Whether a given scope should carry them is the regulatory question.

For a consequential AI action within a scope requiring action-specific authorization, the evidence inquiry should not end with model performance, supervisory coverage, or incident-response capability. It should establish whether a valid action-bound authorization verdict existed before execution, whether the release path depended on that verdict, and whether an independent party can reconstruct the resulting verdict from the proposed action, the applicable policy and version state, the bound inputs and governed state, and the authority chain.

In FERZ's model, when a consequential action is released through a valid authorization boundary, the governing verdict is represented in an independently reconstructable authorization artifact. The artifact identifies the proposed action, applicable policy and state, authority, and resulting verdict. Establishing that release actually depended on the verdict requires separate evidence drawn from the execution path. A non-bypassable, fail-closed runtime authorization boundary is what creates that dependency.

This does not prove that the policy was wise or that the action was safe. It establishes the basis on which permission was granted. Recording a verdict does not prove that it controlled release, and blocking some actions does not establish that the actions released were authorized.

Where a risk owner has declined an available authorization control, the inquiry should reach that decision too. Which failure modes were accepted? Which could have been prevented at release? What evidence shows that the control was infeasible, ineffective, or outweighed by the harms its delays or denials would cause?

Regulators may reasonably decide that some low-consequence operations do not warrant action-specific authorization. They may also prescribe different controls for different levels of autonomy and consequence. Those decisions should remain explicit choices about scope and requirements, not an assumption that accepted risk or reliable monitoring has established permission.

7. Who answers?

Accepting residual risk may be necessary. Declining an available control over unauthorized release is a separate decision, and it requires its own justification.

The question is not whether regulators can eliminate every possibility of harm. They cannot. The question is why a consequential action should be allowed to take effect without evidence that the governing authority permitted it.

Where that evidence exists, the permission behind the act, its basis, and the authority that granted it can be examined. When an action proceeds without established permission, aggregate risk acceptance cannot supply it afterward.

The risk was accepted. Its foreseeable human cost was part of that acceptance. But who authorized the action?

Related FERZ work

RELATED CONCEPTS

References

CITE THIS PAGE

FERZ, Inc. (2026). The Risk Was Accepted. Who Authorized the Action? Why Regulatory Tolerance for Residual Risk Cannot Substitute for Pre-Execution Authorization. https://ferz.ai/articles/the-risk-was-accepted-who-authorized-the-action

Zenodo edition (PDF): Meyman, E. (2026). The Risk Was Accepted. Who Authorized the Action? Why Regulatory Tolerance for Residual Risk Cannot Substitute for Pre-Execution Authorization. Version 1.0. FERZ, Inc. https://doi.org/10.5281/zenodo.23745812

BibTeX 
@misc{ferz2026riskaccepted,
  author       = {{FERZ, Inc.}},
  title        = {The Risk Was Accepted. Who Authorized the Action? Why Regulatory Tolerance for Residual Risk Cannot Substitute for Pre-Execution Authorization},
  year         = {2026},
  howpublished = {\url{https://ferz.ai/articles/the-risk-was-accepted-who-authorized-the-action}},
  note         = {Zenodo edition: \url{https://doi.org/10.5281/zenodo.23745812}}
}

© 2026 FERZ, Inc. This article is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).