Yandex · AI infrastructure · Physical security
The AI supercomputer has discovered that concrete buildings are not invulnerable.
Yandex said Sunday that a drone attack had damaged infrastructure and completely shut down its data center in Russia’s Vladimir region. The company reported no injuries but said some services were unavailable, according to Reuters. This follows the partial disruption of its Kaluga facility on Friday and the shutdown of its Sasovo hub after a Ukrainian drone attack Thursday. The three incidents are part of the Russia–Ukraine war, rather than evidence of autonomous AI taking action against its own infrastructure.
Sasovo houses two of Yandex’s three supercomputers used for AI development. Their presence is established; their condition is not. In its October 8 statement, Yandex said it could not yet determine whether the site’s equipment could be restored. That does not confirm that the two AI supercomputers were damaged or destroyed. A facility outage, damage to its infrastructure and loss of a particular machine are different claims. We should keep the distinction even when the headline invites a more dramatic conclusion.
The technical lesson extends beyond this company: computation happens somewhere physical. Electricity, cooling, network connections, replacement components and the building itself are dependencies, not optional accessories. Software security addresses one set of threats; continuity planning must also account for physical disruption. Geographic redundancy and recovery arrangements can help, but they need to exist before the equipment becomes unavailable. Artificial intelligence lives in the cloud. The cloud apparently has a street address. A capable model still needs a functioning place to run.
Source: Reuters on Sunday’s shutdown and preceding attacks ↗Source: Reuters on Sasovo and the unconfirmed supercomputer damage ↗
SemiAnalysis · Frontier AI · Safety transparency
Nine Chinese developers released 857 models. Public safety results accompanied 31.
SemiAnalysis’s October 8 investigation reviewed 857 identifiable releases from nine leading Chinese developers between 2021 and September 15, 2026. It found published, model-specific safety results for 31 releases, or 3.6%; just nine, about 1.1% of the total, had results available at or before launch. The researchers checked developer model cards, release notes and technical reports. A general statement that a model was safety-trained or evaluated did not qualify as a published result. Reuters reported the findings Friday.
The denominator also includes individual sizes and snapshots, rather than 857 separate frontier systems. The authors caution that developers name variants at different levels of detail, making company rates indicative rather than a simple ranking. They found no safety disclosure for 813 releases; another 13 carried evaluation claims without figures or only outside accounts. Not found in the checked public material does not mean not tested privately. The headline measures transparency. It does not measure a percentage of unsafe models or establish an equivalent comparison with American developers.
That leaves a consequential question for users: what evidence supports the safety claim attached to the model they are actually deploying? A flagship model’s documentation cannot automatically establish how every related version behaves. Useful disclosure identifies the tested system, methods, limits and results well enough for others to assess them. The report makes that public-evidence gap concrete without resolving every model’s behavior. The future of AI safety cannot depend entirely on assurances that somebody checked. Eventually, somebody else needs to see the results.
Source: Study methods, release counts and disclosure limitations ↗Source: Reuters on the published findings ↗
U.S. Army · Project Convergence · Operational reliability
The military brought advanced technology to the desert. The desert brought a thermometer.
Project Convergence Capstone 6 took place at Fort Irwin, California, in July. The Army used the exercise to test its Next Generation Command and Control architecture, combining commercial software, data systems and AI support for commanders under demanding field conditions. This is an earlier experiment, not a new exercise this weekend. Its relevance to Sunday’s issue is practical: technologies intended for real environments need to deliver their capabilities outside the conditions that make a demonstration easy.
Breaking Defense’s September 4 report, based on Army officials’ accounts, describes Starlink ground terminals overheating in Mojave temperatures above 100°F. Throughput fell, and soldiers cooled some antennas with T-shirts soaked in water. Officials framed the incident as a tradeoff in buying commercial equipment that can arrive faster and cost less than bespoke military hardware. They were considering field adaptations and cooling improvements, rather than assuming every shortcoming required replacing the whole system. The wet shirt was an improvised response to a specific equipment problem.
Testing is supposed to expose limitations. These reports do not establish that every system failed or that a frontier AI model suffered an alignment failure. They show why useful performance depends on hardware, communications, power and recovery arrangements as well as software. A capable algorithm cannot restore throughput by ignoring an overheating terminal. The same principle applies wherever automation enters the physical world. The physical world is not a benchmark environment. The next engineering milestone is making the system keep working when the environment stops cooperating.
Source: Army account of the July experiment and its purpose ↗Source: Army officials on overheating terminals and field adaptations ↗