When should an AI system spend more intelligence?

The system, not just the model

Which language model is best? Chaymaa Abbas, Kareem Hassani and Mariette Awad argue that this familiar question misses much of what determines whether an AI deployment works responsibly.

Their RADE framework—risk-adjusted deployment efficiency—evaluates the deployment policy: the rules that decide which model handles a request, what evidence it retrieves, what information it remembers, whether its answer gets checked and when a human takes over.

The paper is an arXiv preprint, version 1, posted on November 8, 2026. It presents a conceptual framework and reporting proposal, not a newly tested system or empirical benchmark.

The motivation is straightforward: mistakes have unequal consequences. A clumsy meeting-note rewrite and an unauthorized account action should not count as equivalent errors merely because both reduce an accuracy score.

A ledger with limits

RADE starts with the value of correctly completed work, including requests completed after escalation. It subtracts the costs of running models, retrying failed attempts, obtaining human review and failures whose consequences can defensibly be expressed in common units. Those failure costs combine the probability of an event with the damage it causes.

But the authors explicitly reject putting every harm into that ledger. Severe harms without a defensible price, such as certain clinical errors or sensitive-data disclosures, instead receive maximum tolerated probabilities. Privacy exposure, latency and computing resources also have limits. A system must satisfy these constraints before its net value becomes relevant: cheaper operation cannot compensate for breaking a declared safety boundary.

The framework is not a training recipe. It is a way to compare operational choices while making their assumptions visible. Where costs and benefits use different units, comparisons depend on an explicitly chosen conversion factor.

Why the cheapest answer can mislead

A hypothetical example illustrates why the authors favor net value over a benefit-to-cost ratio. Suppose one system correctly completes 20% of requests at one cent per request, while another completes 90% at ten cents. Each correct completion is worth one dollar, with no additional priced failure damage.

The first system looks better by benefit per dollar spent: 20 versus nine. Yet its net value is only 19 cents per request, compared with 80 cents for the second. The example is arithmetic, not an experimental result. It shows how a ratio can reward doing very little very cheaply.

Likewise, a cheap initial model may become expensive if it repeatedly triggers retries or human checks. A stronger model may earn its higher cost on difficult requests without being necessary for routine ones.

Different settings, different routes

The authors examine five illustrative deployment regimes. Research assistants may prioritize inexpensive routing and fresh evidence. Enterprise systems may need local processing and tightly governed memory. Customer-support systems that take actions must separate generating an explanation from permission to execute a transaction. Offline clinical assistants need restricted scope, attention to evidence freshness and escalation to clinicians. General knowledge-work assistants face varied tasks and changing behavior across updates.

Across these settings, routing should consider consequences as well as difficulty. Escalation must remain possible after an initial answer—for example, when retrieved sources conflict or a check raises uncertainty.

Retrieval means consulting external documents rather than relying solely on information encoded during training. It can improve freshness, but a citation is not proof: sources may be stale, mismatched or poisoned. Persistent memory similarly offers continuity while creating exposure risks. The paper recommends explicit rules for storing, retrieving, retaining and deleting information, with slower, tested model updates reserved for more stable knowledge.

What would count as evidence?

The proposed reporting protocol combines task success, total costs, failure severity, human workload, evidence quality, memory governance and behavior after updates.

A central measure is the risk-coverage curve. Coverage is the fraction of requests answered automatically; selective risk measures error or loss among those answered. Reducing coverage should reduce risk if the system is successfully identifying cases that need help. Evaluation should also examine unfamiliar inputs and high-consequence cases, not just averages.

What remains unresolved

The paper does not establish that RADE improves safety or saves resources in a real deployment. Routers, uncertainty estimates and verification systems can themselves fail when conditions change.

Its recommendations also depend on contested judgments: whose benefits count, whose harms are included and who sets acceptable failure limits. The authors warn that average safety can hide worse outcomes for particular groups, and that abstention can transfer unfinished work to users rather than eliminate it.

RADE therefore offers an explicit accounting framework, not a safety certificate. Its strongest contribution is the question it makes unavoidable: when does spending more capability genuinely improve the outcome, and when should the system seek evidence, seek help or stop?