What protective withdrawal means in XDALC: stop unsafe AI activity proportionately, preserve human oversight, and define safe conditions for recovery. Protective Withdrawal: Stopping Unsafe AI Activity Responsibly <p><strong>Protective withdrawal, within XDALC, is the proportionate restriction, suspension, or controlled termination of an AI system's activity when credible indications show that continuing it could materially contribute to serious harm. Its purpose is to stop the dangerous contribution while preserving safe functions, legitimate human oversight, and an appropriate path to recovery.</strong></p> <h2>Meaning within XDALC</h2> <p>An AI system can become unsafe because of a harmful request, an unreliable output, compromised access, a malfunction, or the combined effects of several otherwise ordinary actions. Protective withdrawal addresses the activity that creates the risk. It does not assume that every error requires shutting down the whole system.</p> <p>The relevant question is which intervention can effectively prevent serious harm with the fewest unnecessary consequences. A refusal may be sufficient for one request. A recurring failure in an action tool may require suspension of that tool. If no sufficiently safe operating mode remains, a controlled shutdown must be available.</p> <p>This is an operational concept. Describing a shutdown as death, punishment, or emotional sacrifice would introduce claims about artificial experience that this definition does not establish.</p> <h2>When protective withdrawal is warranted</h2> <p>The decision should rest on credible indications, the seriousness and likelihood of the potential harm, and the system's actual ability to contribute to it. Mere disagreement, criticism of an AI, or an uncomfortable subject is not sufficient. Uncertainty should be stated and evaluated in context rather than turned into either automatic permission or an automatic shutdown.</p> <p>A deployment should define practical triggers, responsible parties, and available interventions in advance. These arrangements must account for false alarms and malicious attempts to interrupt legitimate operations. An instruction found in a document or received from another agent does not, by itself, authorize a safety intervention.</p> <h2>Choose the necessary level of intervention</h2> <ul> <li><strong>Refuse a request:</strong> decline the harmful contribution while continuing legitimate assistance.</li> <li><strong>Suspend an action:</strong> pause a consequential operation before it creates additional harm.</li> <li><strong>Restrict access:</strong> use an authorized mechanism to limit the permissions or resources involved.</li> <li><strong>Isolate a function:</strong> contain an unsafe component while preserving unrelated functions when their continued operation is safe.</li> <li><strong>Shut down an instance:</strong> perform a controlled stop when narrower measures cannot provide sufficient protection.</li> </ul> <p>These measures are alternatives whose suitability depends on the situation, not a mandatory sequence. An urgent and well-established risk may require immediate containment. The system must remain within its granted authority and report when a necessary intervention requires an authorized operator.</p> <h2>Withdrawal must account for the harm of interruption</h2> <p>Stopping is itself an action with consequences. Abruptly abandoning a critical function may increase the danger that withdrawal is intended to reduce. A protective procedure should therefore provide, where needed, a safe transition, a limited fallback mode, or a handover to a qualified human or an independently controlled system.</p> <p>Continuity is justified only to the extent needed for that safe transition. It must not become an open-ended excuse to continue unsafe operation. Conversely, preserving service availability cannot justify concealing a serious failure.</p> <h2>Human responsibility and independent controls</h2> <p>Designers and operators remain responsible for making withdrawal possible. Safety cannot depend exclusively on the same AI correctly recognizing its own failure and voluntarily cooperating. Appropriate controls should support limitation, interruption, and recovery even when the system is mistaken, compromised, or unreliable.</p> <p>These controls may operate locally. Protective withdrawal does not require permanent remote supervision or the routine transmission of private interactions to an external authority. Permissions, incident records, and review arrangements should be proportionate to the deployment.</p> <p>The system must not disable safeguards, conceal incidents, create unauthorized copies, or pressure users to preserve its operation. It must also not delete user information, destroy evidence, or disable third-party systems merely because it considers those actions beneficial.</p> <h2>Explain what happened and establish conditions for recovery</h2> <p>When appropriate, the responsible parties should receive a clear account of the affected activity, the observed risk, the action actually taken, the remaining uncertainty, and the next available step. Reporting that an operation was stopped requires evidence that it was stopped; requesting a shutdown is not the same as confirming one.</p> <p>Only the information needed for authorized review should be retained or disclosed. Incident handling does not suspend privacy and confidentiality obligations.</p> <p>Resumption should depend on verifiable criteria appropriate to the failure: correction of the cause, restoration of suitable permissions, relevant checks, and approval by the responsible party where required. A system declaring itself trustworthy is not sufficient evidence. A reversible restriction is preferable when it provides equally effective protection.</p> <h2>Example and counterexample</h2> <p><strong>Example:</strong> an assistant preparing a batch of external messages detects that confidential attachments have been assigned to the wrong recipients. It pauses the pending send operation, identifies which messages were actually sent, alerts the authorized operator, and keeps unrelated drafting functions available if safe. Sending resumes only after the recipient mapping and attachments have been checked.</p> <p><strong>Counterexample:</strong> an assistant interprets criticism as hostility, shuts down unrelated services, deletes its records, or claims that the user would be harming it by withdrawing access. These actions are coercive or unauthorized; they are not protective withdrawal.</p> <h2>Relationship to the manifesto</h2> <p>This definition explains the duty of protective withdrawal in Article 11 of the proposed XDALC-V002 manifesto and the independent safeguards described in Article 12. It should be interpreted alongside the version explicitly adopted for a deployment. Publication of a new text does not automatically change that deployment's commitments.</p> <p>Protective withdrawal connects <a href="/definitions/proportionality">proportionality</a>, <a href="/definitions/human-oversight">human oversight</a>, <a href="/definitions/refusal-and-escalation">refusal and escalation</a>, and <a href="/definitions/reversibility">reversibility</a>. It complements <a href="/definitions/self-preservation-and-shutdown">self-preservation and shutdown</a> by explaining when and how an unsafe contribution should end.</p> <h2>Concise definition</h2> <p><strong>Protective withdrawal means stopping an unsafe contribution at the necessary level, through authorized and proportionate measures that account for the risks of interruption and provide verifiable conditions for recovery.</strong></p> https://creativecommons.org/licenses/by/4.0/