Accept the Risk or Delay the Launch: Comparing the Options

Before comparing options, answer the same five questions for every gap on the list. They are ordered so that a "no" on an early one short-circuits the rest.

1. Who is exposed? Name the population: internal staff, a pilot cohort, all customers, a regulated data set, a third party. "Users" is not a population. Write the number and the category.

2. How detectable is the gap in production? Detection is the difference between a bad afternoon and a bad quarter. A gap you can see in logs, metrics or a canary check within minutes is a different decision from one that only surfaces when a customer complains weeks later. OWASP's mitigation guidance leans on monitoring and logging for exactly this reason in RAG systems, where poisoned or cross-tenant retrievals are otherwise invisible the OWASP vector and embedding guidance.

3. What is the blast radius if it fails? Distinguish recoverable from unrecoverable. A wrong recommendation in a shopping cart is recoverable. A wrong answer delivered to a clinician, an irreversible financial transfer, or a data disclosure to another tenant is not. The OWASP entry on excessive agency makes the same point from the architecture side: damage scales with what the system is allowed to do, not with how clever the model is the OWASP excessive agency write-up.

4. What does delay cost? Put a number on it: revenue shifted, a partner commitment missed, a hiring plan stalled, a competitor's window. A delay cost with no number is a feeling, and feelings lose every argument to a launch date.

5. What monitoring and rollback make acceptance safe? If you cannot answer this with specifics (an alert, an owner who reads it, a feature flag, a documented reversal), acceptance is not on the table.

Compensating controls belong here, and they must be tested, not merely listed. A defensible record names the control, its owner, its most recent test result and date, and what it actually reduces rather than what it is supposed to reduce the SC Media explainer on acceptance records. For an AI feature, a compensating control might be a hard scope limit, a reduced permission set for the tool-calling layer, or mandatory human approval on any action that changes state, which is the posture OWASP recommends for high-risk operations the OWASP prompt injection guidance.

Acceptance is legitimate, common and often correct. It is also the option most often faked. The test is whether you can produce a record a skeptical outsider could interrogate.

Acceptance is defensible when all five of these hold:

• The gap is detectable in production, with a named alert and a named reader.
• A single named owner is accountable for the residual exposure, not a team or a committee.
• A rollback exists and has been exercised, not just designed.
• The exposed population has agreed in writing, which for internal exposure means the business owner and for external exposure means someone with the authority to speak for those users.
• The acceptance has an expiry date and a closure plan.

If any of those is missing, you are not accepting risk. You are accumulating undocumented drift, which is the failure mode mature programs explicitly warn against: exceptions that quietly become permanent architecture the product security handbook on exceptions.

A worked example shows why the numbers matter. Suppose a customer support assistant has a known prompt injection gap: indirect injections arriving through uploaded attachments are blocked in the main chat path but not in the attachment summarizer. The tool has read access to the ticket system but no write access and no external send capability. Detection is a filter on outbound text that flags any ticket content appearing in a summarizer response. Blast radius is a disclosure of one ticket's contents to the person who uploaded the file, which is recoverable but embarrassing. Delay cost is a contractual commitment to a support partner. That is an acceptance you can defend: detectable, bounded, reversible, with a named security owner and a ninety-day closure date tied to the fix.

Now change one variable. Give the same tool the ability to send email. The blast radius becomes a data exfiltration path, and OWASP's "lethal trifecta" reasoning applies: access to private data, ingestion of untrusted content and the ability to communicate externally together create a path an attacker can walk the Anaconda guide to OWASP checks. Acceptance is no longer the right call. Cut the send capability or delay.

Delay is expensive and unpopular, which is why it is usually chosen too late rather than too often. The decision rule is narrow and worth memorizing: delay when the gap is undetectable after release, or when a failure is unrecoverable for the people exposed.

Two conditions make delay close to mandatory.

Undetectable gaps. If you cannot tell whether the failure is happening, you cannot bound the harm, and you cannot decide when to stop. A RAG system that leaks one tenant's documents into another tenant's answers is the canonical case: the retrieval looks normal, the answer looks plausible, and nothing in the response flags that the source belonged to someone else the a10networks RAG security explainer. Unless you have per-tenant retrieval assertions and an audit trail, you will learn about the leak from the affected customer.

Unrecoverable blast radius. Some failures cannot be undone by a rollback: a regulatory filing made on bad data, a clinical recommendation acted upon, a payment sent, a defamatory statement published. Delay is the only option that preserves the option to think.

Delay also deserves a fair accounting on the other side. The literature on risk and delay trade-offs treats the two as comparable costs rather than a hard priority: people trade a certain delayed reward against a probable immediate one, and the exchange rate is measurable rather than rhetorical the discounting framework study. In practice, the useful move is to price both sides in the same units before the meeting, because a delay argument that never states the delay cost will lose to a launch date that does.

One discipline keeps delay from becoming drift: give the delay a defined end state. "Two weeks to add per-tenant retrieval assertions plus an audit log" is a delay. "Until we feel better about it" is an open-ended halt that will be relitigated every week.

Cutting scope is the option teams underuse, because it feels like admitting the product is incomplete. It is often the only move that lets you ship the core promise on time while removing the part you cannot make safe.

The decision rule is concrete: cut scope when the affected feature can be removed and the core promise still holds. The test is a sentence. Write the one-sentence promise of the release, then ask whether it survives the removal. If it does, cut. If removing the feature empties the promise, you are not cutting scope, you are delaying under a different name.

Scope cuts work best when they remove capability rather than visibility. Dropping a tool-calling integration removes the blast radius entirely; hiding the button that invokes it does not, because the endpoint still exists. The OWASP guidance on prompt injection is blunt about this: constrain what the model can reach and enforce privilege at the code layer, because prompt-level instructions are not a security boundary the OWASP prompt injection guidance.

Three scope cuts that usually preserve the promise:

That third row is where many AI features quietly break: the upload button stays, the summarizer is removed, and the failure appears as a support ticket rather than a bug. Whatever you cut, cut the entry point too.

Launch readiness frameworks make the same distinction in general terms: high-consequence conditions should be hard requirements, while other issues may be acceptable if the exposure is understood, mitigation is credible and leadership consciously accepts the residual risk the Umbrex launch readiness guide. Cutting scope is how you convert a hard requirement you cannot meet into a smaller product you can.

If you choose acceptance, the safety comes from three artifacts, and all three should exist before the go/no-go meeting rather than after it.

Monitoring that someone reads. An alert with no owner is decoration. Tie every detection to a person and a response window. For AI systems, this means logging the inputs and outputs of the risky path, not just error rates. OWASP lists monitoring and logging among the core mitigations for RAG weaknesses precisely because retrieval problems do not announce themselves the OWASP vector and embedding guidance.

A rollback you have exercised. "We can turn it off" is a hypothesis until someone turns it off in staging. Note who has the authority to pull the switch and how long it takes.

A decision record with the right fields. A minimal acceptance record answers: what is the gap, what is the failure scenario in plain language, what reduces it today and how was that tested, why proceed now, what are the conditions and expiry, and who approved the vendor risk acceptance memo template. Keep inherent and residual exposure as two separate ratings rather than one average, because an average can hide a mandatory failure the vendor risk acceptance memo template.

Governance details that keep the record honest: every exception carries an expiry date, every renewal requires evidence the blocker still exists, and leadership reviews exception age and concentration rather than raw counts the product security handbook on exceptions. A quarterly report that says "we have forty exceptions" tells you nothing. One that says "six exceptions are past expiry and three belong to the same service" tells you where the rot is.

Bring this table to the go/no-go meeting with the middle column already filled in. The right-hand column is where the decision gets argued, and it should be argued once, in writing.

Run the table in a fixed order. Detectability and blast radius first, because a "no" plus "unrecoverable" ends the discussion. Then the scope cut test, because it is usually cheaper than either of the other two. Then delay cost against expected loss. Acceptance is the residual option, and it wins whenever the first questions come back favorable.

One more discipline: separate the decision from the person pushing the date. The authorizing official's job is to understand what they are accepting, and a record they cannot explain is not a valid acceptance no matter whose signature is on it the SC Media explainer on acceptance records. If the person signing cannot answer "how would we know if this went wrong," the answer is no.

When the gap sits in an AI feature and the team lacks a second opinion on detectability or blast radius, a structured review with someone who has shipped similar systems shortens the argument considerably. That is the kind of conversation a free 30-minute AI discovery call is built for: bring the table, leave with a recommendation you can defend.