Software patches are routine in IT security. Find the bug, deploy the fix. But what happens when you try that with an AI system? Can you surgically correct a neural network without rebuilding it entirely? And if you can’t, what does that mean for policymakers and enterprise leaders assuming you can?
The illusion of the fix
When you want to fix a bug in traditional software, you have options. Deploy a targeted patch. Update a library. Change a line in a config file. The defect lives in a specific place, and you go to that place and correct it.
A neural network offers no such place. When something in a model misbehaves, you have only blunt instruments: fine-tune it on new data, retrain it from scratch, or reach directly into its weights and start cutting. There is no line to edit. There is no module to swap. The fix you want, which should be precise, contained, and predictable, does not exist as an operation you can perform.
This matters now because policy has started to assume otherwise. A June 2026 executive order directs the Treasury Department, working with the NSA and CISA, to stand up a clearinghouse that coordinates the discovery, validation, and “remediation and distribution of vulnerability patches,” which is language borrowed wholesale from the world of conventional software and now stretched over AI systems. It is a reasonable instinct and a category error. The vocabulary of patch management implies a capability that, for neural networks, we simply do not have. Understanding why requires understanding what a neural network actually is.
We do not have the capability to patch AI systems.
Where the knowledge lives
Traditional software is explicit. It is written by people as sequences of instructions, each doing a defined job in a defined order. When it breaks, the break is somewhere specific, and the logic is legible enough that a human can find it.
A neural network is the opposite. Its behavior is not written; it is grown. Capabilities emerge from billions of weighted connections tuned over training, and no single weight “contains” a fact, a bias, or a skill. Knowledge is smeared across the network, distributed and entangled, with the same parameters participating in countless behaviors at once. Researchers call part of this phenomenon superposition: models pack far more concepts than they have neurons by representing them as overlapping combinations rather than dedicated units (Elhage et al., Toy Models of Superposition, 2022).
That distribution is the whole problem. There is no “the part that does X.” Change a weight to alter one behavior and you have, by definition, altered a parameter that was doing other jobs too. The ripple is real, and it is rarely predictable.
Three blunt instruments
Every real-world attempt to change a deployed model reduces to one of three approaches. None of them is a patch.
Fine-tuning looks like the closest thing to a fix. Take a trained model, expose it to new data, nudge the weights toward the behavior you want. But fine-tuning is a blunt tool wearing a scalpel’s costume. Push a model toward one correction and it tends to lose ground on things it used to do well: a failure mode documented for decades as catastrophic forgetting, the tendency of neural networks to overwrite old competencies when learning something new (McCloskey & Cohen, 1989; Kirkpatrick et al., Overcoming catastrophic forgetting in neural networks, PNAS, 2017). You fix the symptom and pay for it somewhere you weren’t watching.
Retraining from scratch is the nuclear option. It can work, but it is not a patch in any meaningful sense: it is rebuilding the system. The process takes weeks or months, consumes enormous compute, and produces a different model whose behavior must be re-validated from zero. No security team treats “rebuild the entire product” as an incident response.
Ablating and editing weights, reaching in and changing parameters directly, is the crudest of the three, but it is no longer entirely blind. A growing field called mechanistic interpretability is beginning to map what specific components of a network encode and how a change might propagate (Olah et al., Zoom In: An Introduction to Circuits, Distill, 2020; Elhage et al., A Mathematical Framework for Transformer Circuits, 2021). The point is not to guess anymore, but to see.
But seeing the impact is not the same as escaping it. Even with a clear picture of what a connection does, you still face the same trade: remove or alter it, accept the degradation that follows, and decide whether the correction is worth the cost. There will be a cost. The question is only whether you can afford it.
What research is actually trying
Several research directions are chipping away at the problem, and it’s worth being precise about what they do and don’t achieve.
Parameter-efficient fine-tuning makes updates cheaper by freezing most of the model and training only a small set of added parameters. Low-Rank Adaptation (LoRA) is the best-known example, cutting trainable parameters by orders of magnitude while preserving quality (Hu et al., LoRA: Low-Rank Adaptation of Large Language Models, 2021). It makes adaptation more affordable. It does not make it surgical.
Model editing is the research most directly aimed at the dream of a patch. Methods like ROME and MEMIT locate where a specific fact appears to be stored and rewrite the relevant weights to change it (Meng et al., Locating and Editing Factual Associations in GPT, NeurIPS 2022; Mass-Editing Memory in a Transformer, 2022). This is impressive, and instructive in its limits. The authors document failure modes where an edit “bleeds over” onto related facts and where the model begins to over-apply the change, regurgitating the new value even for subjects that were never edited. You can change what the model “believes,” but you cannot fully control what else changes with it.
Mechanistic interpretability and sparse autoencoders attack the root cause: opacity. By decomposing a model’s tangled activations into cleaner, more interpretable features, researchers hope to eventually target interventions with precision instead of force (Bricken et al., Towards Monosemanticity, 2023; Cunningham et al., Sparse Autoencoders Find Highly Interpretable Features in Language Models, 2023; Templeton et al., Scaling Monosemanticity, 2024). This is the most promising long-term path. It is also early. Later work has scaled the approach to millions of features in a production-grade model, yet coverage is still partial, and the gap between “we can interpret this” and “we can reliably fix this in production” remains wide.
Each of these is real progress. None of them, today, is a patch.
Wrapping what you can’t fix
There is a fourth response that never appears on the list above, because it isn’t an attempt to change the model at all. If you can’t repair the defect, you can try to build around it.
Two approaches dominate. The first is guardrails: input and output filters, classifiers, and “firewalls” that sit outside the model and screen what goes in and what comes out. A guardrail can catch a known-bad response before it reaches a user, or block a prompt designed to elicit one. The second is retrieval-augmented generation (RAG), which feeds the model vetted, up-to-date information at inference time so it leans on a trusted external source instead of whatever it absorbed during training.
Both are useful, and for many production problems they are the right tool. But notice what they are not: neither one touches the weights. The flawed behavior is still in the model, fully intact. Guardrails route around it; RAG out-votes it with better context. The moment a guardrail is bypassed, and adversarial prompting is good at finding the gaps, the original behavior is right there, unchanged. Hand the model the correct fact through retrieval and it can still fall back on its own parameters. These are containment strategies, not corrections. They manage the symptom from the outside precisely because the inside cannot be edited.
It is the same wall, approached from a different side.
The tension we’re left with
So here is the uncomfortable truth, stated plainly: we do not have the capability to patch AI systems. Fine-tuning trades one problem for another. Retraining means rebuilding. Editing weights, even with better instruments, still moves things you didn’t mean to move. This is not a temporary gap waiting on next quarter’s release. It is a property of how neural networks store what they know.
Which makes the policy assumption worth sitting with. When a mandate borrows the language of patching and points it at deployed models, picture the moment a real vulnerability surfaces in production. The organization holding that model has three doors, and every one of them is heavy. Retrain over months. Fine-tune and accept the collateral damage. Or take the model offline entirely. That last option, pulling it from service until something better exists, is frequently the only honest answer, and it is the one no patch-management framework is built to recommend.
None of these are patches. None of them are what the language of “hot fixes” leads a board, a regulator, or a CISO to expect. And that distance, between the fix we’ve been promised and the blunt instruments we actually hold, is the thing worth confronting before the next vulnerability forces the question for us.