Blog · Review Essay · Last reviewed June 25, 2026

A Prehistory of the Cloud and the Infrastructure That Pretends to Disappear

Tung-Hui Hu's A Prehistory of the Cloud is a media-theory genealogy of an infrastructure that succeeds by vanishing from attention. Its AI-era value is direct: models, agents, assistants, and synthetic memory systems feel placeless because cloud systems have trained users to experience remote institutions, energy, labor, security, and data capture as a smooth local interface.

For this review, cloud means a dependency regime: remote compute, storage, networking, identity, policy, logging, billing, security, and update authority made to feel like a local service. The question is not whether cloud computing is real. It is which physical, legal, operational, and political dependencies become hard to see once the interface works.

The governance test is simple: if an institution cannot name where its data, model calls, logs, credentials, backups, and exit paths live, then it has not adopted a cloud service. It has accepted an invisible operating environment.

The Book

A Prehistory of the Cloud was published by MIT Press in 2015, with the paperback following in 2016. MIT Press lists the paperback at 240 pages and describes the book as an account of the digital cloud's militarized legacy: how cloud computing grew from older network technologies, older metaphors, and older forms of power. Internet Archive's bibliographic record separately lists the 2015 hardcover as xxix plus 209 pages, with subjects in computer-network history and the social aspects of the internet.

Hu is especially useful because he writes from both technical and literary positions: a former network engineer, a poet, and a scholar of media. The result is not a conventional business history of cloud computing. It is an archaeology of the cloud as image, infrastructure, security fantasy, control system, and way of producing the person who interacts with it.

NIST's standard definition of cloud computing emphasizes on-demand network access to a shared pool of configurable resources, rapid provisioning, service models, and deployment models. Hu's contribution is not to refute that engineering definition. It is to ask what such a definition leaves outside the frame: older transport and media systems, military and security inheritances, jurisdiction, labor, capital, and the cultural desire for infrastructure that appears to need no place.

The book belongs beside The Stack, The Metainterface, Cloud Empires, The Costs of Connection, and the site's data-center essay. Those works ask how platforms, interfaces, extraction, and physical sites become political arrangements. Hu adds the missing prehistory: the cloud did not arrive as a clean break. It grafted itself onto older systems of transport, broadcast, storage, command, surveillance, and security.

Vanishing Infrastructure

The cloud's first trick is aesthetic. It presents itself as atmosphere: light, remote, available, elastic, and strangely nowhere. Hu keeps pulling that metaphor back toward material things: data centers, cooling systems, fiber routes, time-sharing computers, television circuits, military bunkers, network diagrams, security checkpoints, and the practices that make all of this feel ordinary.

That matters because invisibility is not just a user-experience choice. It is a governance condition. When infrastructure disappears into a friendly icon, ordinary political questions become harder to ask. Where is the data? Who owns the machine? Which jurisdiction applies? What happens during failure? Who pays the electricity bill? Who is excluded by latency, price, verification, or terms of service? What institutions can inspect the system?

The disappearance has layers. The facility disappears behind the region name. The region disappears behind the API. The API disappears behind the app. The contract disappears behind the account. The account disappears behind the user's sense that the file, model, assistant, or memory is simply "mine." That chain is powerful because each layer can be technically convenient while the whole arrangement becomes politically opaque.

Hu's strongest move is to show that virtualization does not mean unreality. It means a real physical arrangement has been made operable through a representation that hides most of its conditions. A cloud drive, a sync button, a streaming service, or an AI assistant is not less real because it is virtualized. It is more politically slippery because the interface lets distant systems act as if they were immediate.

The User as Political Form

The book also clarifies the word user. A user is not simply a person with access. A user is the form of person a system can address, authenticate, meter, profile, isolate, support, monetize, suspend, and blame. LARB's Kevin Driscoll highlights Hu's argument that cloud systems train people to understand shared infrastructure as personalized service rather than common terrain. That shift weakens the move from private convenience to public claim.

This is one reason the cloud remains politically underdescribed. People experience it as their files, their account, their feed, their cloud, their saved history, their private backup, their assistant. But the same infrastructure aggregates user action into data streams, platform dependency, security policy, advertising systems, model training, procurement markets, and state access.

The individual interface can be sincere and useful while the aggregate system becomes a machine for enclosure. A person uploads, syncs, tags, prompts, saves, searches, and shares. The system turns those acts into storage demand, behavioral records, access control, recommendation inputs, and evidence. The public problem is assembled through private acts that were designed to feel like service use rather than citizenship.

Current Context

As of June 25, 2026, Hu's cloud genealogy has become a live governance map. The International Energy Agency's 2025 Energy and AI report estimated that data centers used about 415 terawatt-hours of electricity in 2024, around 1.5% of global electricity consumption, and projected about 945 terawatt-hours by 2030 in its base case. In the United States, the Department of Energy's Lawrence Berkeley National Laboratory report estimated that data centers used 176 terawatt-hours in 2023, about 4.4% of total U.S. electricity, with a projected range of 325 to 580 terawatt-hours by 2028.

Those figures cover data centers broadly, not only AI, and they should not be turned into a universal energy-per-prompt claim. Their relevance is infrastructural: cloud demand is now large enough that the interface cannot be separated from power planning, cooling design, land use, water governance, grid interconnection, and who pays for capacity.

The regulatory record is moving in the same direction. On June 18, 2026, FERC ordered all six regional grid operators under its jurisdiction to justify or reform tariffs for data centers and other large energy users. NERC's 2026 reliability guidance treats emerging large loads as a planning and operations problem that needs better data, models, coordination, and event records. In Europe, the Data Act has applied since September 12, 2025 and includes switching rules for cloud and edge services, while the proposed Cloud and AI Development Act frames data-center capacity, energy, land, water, financing, procurement, and sovereignty as one policy problem.

This is the current form of Hu's argument: abstraction is administrative. The provider abstracts locality into a region. The utility abstracts a data-center campus into load. The contract abstracts dependency into service terms. The dashboard abstracts water, energy, latency, and carbon into metrics. The account abstracts public power into a private user relation. Good governance has to reverse those abstractions.

The AI-Age Reading

Read in 2026, A Prehistory of the Cloud looks like a prehistory of AI infrastructure. Generative systems make the old cloud metaphor even more persuasive. The answer appears in a chat window. The image appears in a panel. The meeting summary arrives in the workspace. The agent takes an action through a browser or connector. The experience is intimate, but the machinery is planetary.

That machinery includes data centers, chips, interconnects, power contracts, cooling, training data, contractor labor, model weights, safety filters, logging, retrieval systems, identity layers, compliance tooling, and vendor roadmaps. The interface does not show that machinery because the product depends on a feeling of immediacy. The user asks; the system answers. Hu's book teaches that this immediacy is an achieved illusion, not a neutral fact.

A cloud-backed AI system is not merely a model hosted somewhere else. It is a service chain: model endpoint, inference provider, cloud region, identity layer, telemetry store, prompt and response logs, retrieval index, file store, safety filter, tool connector, admin console, billing system, and update channel. Any one of those layers can change what the system remembers, what it can do, what evidence remains, who can inspect it, and how an institution exits.

The AI turn also intensifies the problem of memory. Cloud storage made remote records feel permanent, private, and recoverable. AI systems make remote records actionable: searchable by embedding, summarized by assistants, routed through agents, retained as context, and recombined into new outputs. The issue is no longer only where information rests. It is what information can be made to do after it has been captured.

This is why cloud politics cannot be separated from AI governance. A model platform is not merely software hosted somewhere. It is a cloud institution that can observe work, mediate public services, become the procurement path for states, and turn organizational memory into a service dependency. The question is not whether the cloud is physical or virtual. It is how the virtual layer lets physical institutions act at a distance while users experience the action as a local answer.

The failure mode is operational capture. A school, clinic, newsroom, nonprofit, city office, or company thinks it has adopted a tool, while quietly outsourcing search, memory, identity, records, moderation, security updates, incident response, audit trails, and institutional continuity. The AI may be impressive, but the deeper transfer is administrative: who now controls the environment in which the institution knows and acts?

Governance and Safety

The safety unit for cloud-backed AI is the whole dependency chain, not only the prompt box or the model card. A serious review should name the cloud provider, model provider, inference provider, region, data classes, subprocessors, identity system, admin roles, logging path, retention period, model-improvement terms, encryption and key custody, backup plan, deletion route, export format, incident notice, and fallback procedure.

For agentic systems, the record should also name tool permissions, payment authority, write access, credential scopes, rate limits, human-approval thresholds, revocation paths, and audit logs. An agent with cloud memory and tool access can turn a user account into an operating position. The question is not whether the agent is conscious. The question is who can prove what it did, stop it, repair harm, and recover the institution's records afterward.

High-consequence use needs stronger conditions: procurement terms that limit unilateral model or retention changes, independent audit access where feasible, human appeal for affected people, public-record preservation for public bodies, export and deletion tests before renewal, and a defined suspension trigger for security incidents, provider failure, unexpected data use, unacceptable latency, harmful output patterns, or loss of legal compliance.

Infrastructure review belongs in the same safety case. If a system is sold as essential AI capacity, then its cloud layer should be readable as civic infrastructure: power, water, reliability, data residency, vendor lock-in, security posture, public subsidies, and exit rights. A smooth assistant can still be a fragile institution if the dependency record is missing.

The Dependency Register

The practical artifact is a cloud dependency register. It should translate "cloud service" into a record of control: provider, product, region, data classes, model endpoint, identity provider, key custody, subprocessors, backup and replication paths, telemetry, log retention, support access, model-improvement terms, incident notice, export format, deletion test, fallback mode, and the official who can pause or leave the service.

The register matters because the cloud hides power through working convenience. A school may see a tutor. A clinic may see a transcription tool. A city may see a dashboard. A newsroom may see a research assistant. Underneath, the institution may have accepted a remote memory system, credential boundary, audit trail, search layer, security dependency, and update channel. If those dependencies are not named, the institution cannot reliably explain decisions, preserve records, honor deletion, maintain public access, or recover when the vendor changes terms.

This is not only a procurement concern. It is a safety concern. Cloud-backed AI can fail by outage, model update, data leak, prompt-log retention, region transfer, vendor lock-in, billing shock, degraded latency, policy change, credential abuse, or loss of exportability. The useful test is operational: before renewal, can the institution export records, restore from backup, rotate keys, verify deletion, preserve audit logs, run a manual fallback, and notify affected people without the vendor's goodwill?

The dependency register should sit beside an AI system inventory, procurement file, data-residency assessment, audit-trail record, and change-management log. Together, those records reverse the cloud's main abstraction: they make the smooth interface cast an institutional shadow.

Where the Book Needs Friction

The book's breadth is also its risk. The cloud can become too elastic a term, especially when it is made to cover networks, storage, platforms, data mining, surveillance, security architecture, military power, and user identity at once. Driscoll's LARB review is helpful on this point: Hu is strongest when the analysis stays specific, and less convincing when the cloud expands into a general name for digital society.

Critical Inquiry's Steven Shaviro raises another useful limitation: the book could say more about surplus extraction and capital accumulation. That matters even more now. The AI cloud is not only a security and media system. It is also a market structure built around hyperscale capital expenditure, model access pricing, cloud credits, enterprise lock-in, procurement dependency, and private ownership of the means of cognition.

The book also predates the current generative-AI buildout: frontier-model data centers, specialized accelerators, model APIs, agent platforms, sovereign-AI procurement, and the electricity politics of inference demand. That does not make it obsolete. It makes it a grammar. Readers still need newer work on platform monopoly, data labor, energy, chip supply chains, and AI procurement to finish the picture.

Hu should also not be asked to do the work of a cloud-security framework or procurement checklist. The book explains why disappearance matters. It does not by itself answer how to write a service contract, test an export path, assess a data-processing region, verify deletion, model large-load reliability, or govern AI tool access. Its best use is diagnostic: it tells readers where the audit should begin.

What This Changes

The practical lesson is to govern the cloud as infrastructure, not as ambience. If an AI system depends on remote compute, remote memory, remote identity, and remote policy, then governance has to follow those dependencies into the places where they are actually controlled.

That means data-center permitting, water and energy disclosure, public procurement rules, audit access, source and retention controls, clear incident reporting, exit rights, portability, contestability, worker protections, and public options where basic services should not depend on a private platform's continued favor. It also means asking whether a system is creating users where a public needs citizens, members, patients, students, workers, or residents with rights.

A Prehistory of the Cloud remains valuable because it gives readers a disciplined suspicion of seamlessness. The smoother the interface, the more important it becomes to ask what has been hidden for the smoothness to work. In the AI era, that question reaches from the chat window to the power grid, from the account page to the bunker, and from the personal assistant to the institutions that decide what the assistant is allowed to remember, say, and do.

The practical method is to make every cloud abstraction answerable. Translate "region" into jurisdiction and energy system. Translate "memory" into records, retention, and deletion. Translate "agent" into credentials, actions, logs, and liability. Translate "sovereignty" into audit rights, exit rights, public compute access, and actual capacity to operate without a single private provider's permission.

Source Discipline

This review separates four source layers. Book facts come from MIT Press, the author's official page, Internet Archive records, and reviews. Technical definition comes from NIST's cloud-computing publication. Current infrastructure claims come from primary energy, regulator, reliability, and European Commission sources. Interpretive claims about AI infrastructure are analogies from Hu's media theory to current cloud-backed AI systems, not evidence that any AI system is conscious, divine, or AGI.

Cloud claims need units and boundaries. A data-center electricity forecast is not an AI-only forecast. Facility capacity in megawatts is not annual electricity use in terawatt-hours. A cloud region is not proof of data residency unless the contract, subprocessors, backup paths, support access, and legal-transfer terms say so. A vendor dashboard is not an audit. A service-level agreement is not an exit plan. A sovereignty label is not democratic control.

For cloud-backed AI, the source trail should preserve the difference between a provider announcement, a contract, a regulator filing, a standards document, an audited report, a public permit, a security attestation, and an independent evaluation. The cloud's political power often begins when those different kinds of evidence are collapsed into one comforting word: service.

Current claims were rechecked on June 25, 2026. The relevant status can change quickly because grid tariffs, reliability guidance, cloud-switching rules, data-center policy proposals, and cloud-provider terms move through different institutions on different timelines.

Sources

Book links are paid affiliate links. As an Amazon Associate I earn from qualifying purchases.

Buy on Amazon Browse Books

Return to Blog · Return to Books