DEV Community: Da

When Power Costs Rise, Data Centers Need to Know Where Every Megawatt Is Going

Da — Sun, 06 Sep 2026 21:01:28 +0000

Electricity is becoming one of the defining operating constraints of the AI data center expansion.

Recent reporting around the PJM Interconnection highlighted a 76 percent year over year increase in wholesale power costs in the first quarter of 2026. How much of that increase should be attributed specifically to data center demand is disputed. Gas prices, weather, generation retirements, transmission constraints and market design all affect wholesale prices, so the number should not be reduced to a simple claim that data centers caused the entire increase.

The operating lesson remains important even without resolving that argument.

Power is no longer a background utility expense for many data centers. It is becoming a capacity constraint, an operating cost driver and a business risk that infrastructure teams need to understand at much finer granularity.

The electricity bill is too late

Traditional energy management often starts with utility invoices or facility level meters.

Those numbers are useful for accounting, but they do not tell operators what to change.

If a monthly bill rises, the data center team still needs to answer a series of operational questions.

Which rooms consumed more energy? Which racks are running at the highest density? Which servers or GPU clusters increased their load? Which projects were using those accelerators? How much power is being consumed by idle or underutilized equipment? Is cooling overhead rising with the IT load? How much electrical capacity remains safe to deploy?

Without that level of detail, energy is visible as a cost but invisible as an operating behavior.

AI infrastructure makes this problem more acute because large GPU deployments can change both power demand and cooling demand quickly.

Energy visibility needs to follow the physical hierarchy

A useful energy model should allow operators to move from the facility level down through the physical infrastructure.

The hierarchy may include:

site
data hall
row
rack
power circuit
server
GPU or accelerator node

This makes it possible to identify where energy is concentrated and where constraints are emerging.

Rack level visibility is particularly important.

A rack can have spare U positions while having little safe power headroom. Conversely, a rack may show significant electrical headroom while its cooling zone or network connectivity prevents additional deployment.

This means power capacity must be considered alongside other infrastructure constraints.

The correct question is not simply, “How many racks do we have left?”

It is, “How much deployable capacity remains once power, cooling, space and operational reserve are considered together?”

GPU utilization changes the economics of every kilowatt

An idle enterprise server wastes electricity.

An idle high end GPU server wastes electricity while also tying up expensive accelerator capacity, rack power, cooling capacity and capital.

This is why AI infrastructure needs an operating model that connects energy with utilization.

Operators should be able to identify low utilization or idle accelerator resources, determine how long they have remained underused and understand which project or tenant owns them. That creates the basis for resource reclamation, scheduling changes and capacity optimization.

The result is not simply lower energy consumption.

It can also delay the need for new infrastructure.

Recovering stranded accelerator capacity is equivalent to creating additional usable supply inside the existing facility. In an environment where power availability is scarce, that can be more valuable than a small improvement in headline efficiency.

Cost attribution changes internal behavior

Energy becomes easier to manage when it can be connected to responsibility.

If all electricity is treated as a shared data center overhead, individual projects have little incentive to optimize their consumption. The infrastructure team sees the bill, while the workload owner sees only compute allocation.

Connecting GPU hours, energy consumption and project ownership changes that relationship.

A project can then be evaluated not only by the number of accelerators allocated to it, but by how those accelerators are used. A model service can be compared with another model service. A training workload can be evaluated against the energy and time it required. Idle resources can be assigned a visible cost.

This creates a more useful internal conversation.

The question moves from “How much electricity did the facility use?” to “Which services and projects consumed it, and what value did that consumption produce?”

For AI data centers, that is the beginning of true operating economics.

Electricity price variation can influence scheduling

Energy prices are not always constant.

In environments where electricity costs vary by time, workload scheduling can potentially become part of the energy strategy. Flexible training jobs may be shifted toward lower cost periods when operational requirements allow. Less urgent workloads can be prioritized differently from latency sensitive inference services.

This does not mean every workload should chase the cheapest power hour.

Business priority, service commitments, training deadlines, resource availability and reliability all matter. But when energy data and workload data are connected, operators gain an additional scheduling input.

The same principle applies across sites.

If an organization operates multiple data centers, differences in available capacity, energy cost and infrastructure conditions can become part of placement decisions where architecture and policy permit.

The important point is that energy information needs to become actionable.

Sensaka can connect energy with infrastructure operations

Sensaka DCOS is designed to monitor physical infrastructure including power, racks, environmental conditions and hardware. Its energy capabilities include real time consumption visibility, efficiency analysis, PUE monitoring and forecasting.

For AI infrastructure, the broader operations model can connect these physical signals with compute resources, GPU utilization, projects and services.

That creates a path toward several practical operating views:

current power consumption by infrastructure area
rack power density and remaining headroom
energy trends over time
abnormal consumption patterns
idle GPU energy
project or tenant energy attribution
forecast capacity saturation
energy related deployment constraints

These views help turn power from a monthly financial surprise into a continuously managed operational resource.

The power debate will continue. The measurement requirement will not.

Whether data centers are responsible for a specific percentage of wholesale electricity price increases will remain a political and economic argument.

Operators do not need to wait for that debate to be settled.

The direction of the infrastructure market is already clear. AI deployments are increasing power density, grid access is becoming harder in many markets, and electricity costs can materially affect both facility economics and community acceptance.

That means every serious operator should be able to explain where power is going inside the data center.

They should know how much is consumed by facilities and IT equipment, which racks are approaching limits, which GPU resources are productive, which are idle and how much deployable capacity remains.

The most valuable megawatt may not be the next one purchased from the grid.

It may be the megawatt already inside the data center that is currently being used inefficiently.

Sources

Originally published on the Sensaka blog.

At 1% Vacancy, the Next Data Center Capacity May Already Be Inside Your Existing Facility

Da — Wed, 02 Sep 2026 11:31:41 +0000

North American data center vacancy has remained around 1 percent while AI demand continues to absorb new capacity.

Industry reporting cited approximately 25 GW of absorption in the first half of 2026, with a large share of capacity under construction already precommitted. Those numbers are being used in the broader debate over whether AI infrastructure is being overbuilt.

For data center operators, there is a more immediate question.

If external capacity is scarce, expensive and increasingly constrained by power availability, how much additional capacity can be recovered from the infrastructure already in operation?

The answer is often larger than a simple rack count suggests.

Empty U space is not the same as available capacity

A common capacity view begins with rack occupancy.

If a rack has ten empty U positions, it appears to have room for more equipment. But those ten U positions may not be deployable.

Power could already be near the rack limit. Cooling conditions may not support another high density server. The available electrical circuits may not provide the required redundancy. Network ports may be unavailable. The rack may sit in a zone with limited cooling headroom.

That means the facility contains several different kinds of capacity.

There is physical space.

There is power capacity.

There is cooling capacity.

There is network capacity.

There is operational reserve.

Deployable capacity is the intersection of those constraints.

For AI environments, this distinction becomes critical because a relatively small number of GPU servers can consume substantial power and create concentrated heat.

Stranded capacity is becoming financially important

Stranded capacity is infrastructure that exists but cannot currently be used because another dependency is limiting it.

A rack may have space but no power.

A data hall may have electrical capacity but insufficient cooling.

A facility may have both, but its existing asset data may be too inaccurate to support confident deployment decisions.

In a market where external data center capacity is scarce, every stranded resource becomes more valuable.

Recovering one rack of usable capacity can delay a new build. Improving power distribution can unlock equipment placement. Correcting asset data can reveal space that was thought to be occupied. Rebalancing workloads may release underused GPU resources.

This is why capacity optimization is increasingly becoming an operating discipline rather than an annual planning exercise.

Accurate asset data is the starting point

Capacity decisions are only as reliable as the inventory underneath them.

If rack location, U position, equipment configuration or power information is outdated, the calculated capacity will also be wrong.

Manual asset records struggle in environments where equipment is added, moved, replaced and upgraded continuously.

Operators therefore need continuous reconciliation between the physical environment and the management system.

Sensaka DCOS is designed to support automatic physical asset discovery, rack and U position management, equipment inventory and infrastructure monitoring. This provides a stronger baseline for capacity planning than a static spreadsheet.

The objective is simple.

Before deciding where new infrastructure can go, the operator needs to know what is actually there.

Power may be the real capacity unit

For many AI deployments, electrical capacity matters more than floor space.

A facility can have room for another row of racks and still be unable to energize them.

This changes the meaning of data center capacity.

Instead of measuring only racks or square meters, operators increasingly need to understand usable kilowatts and megawatts, with the appropriate redundancy and cooling support.

Rack power density should therefore be visible continuously.

Operators should be able to compare current consumption with configured limits, understand available headroom and identify where power is unevenly distributed.

That information can inform equipment placement.

A new GPU server should not simply be assigned to the nearest rack with open U positions. It should be placed where space, power, cooling and connectivity align.

Cooling creates another layer of stranded capacity

Cooling can strand capacity even when power is available.

This is becoming more common as high density AI systems are introduced into facilities designed around lower density enterprise equipment.

One area of the data hall may have electrical headroom but insufficient thermal margin. Another may support higher density because of containment, airflow design or liquid cooling infrastructure.

Without thermal visibility, both areas may appear identical on a rack map.

This is why capacity planning needs to incorporate real operating conditions.

Temperature, cooling zones, rack density and equipment health should inform deployment decisions. In liquid cooled environments, CDU and cooling loop status also become part of the capacity picture.

The operator needs to know whether a location can support the equipment over time, not only whether the equipment can be installed today.

Intelligent predeployment reduces expensive mistakes

When capacity is scarce, placement mistakes become more costly.

Moving equipment after deployment creates labor, risk and downtime. Discovering after installation that a rack cannot support the expected power or cooling load can delay projects. Deploying into a location with poor network connectivity can create another bottleneck.

A better process is to evaluate the deployment before the equipment arrives.

An intelligent predeployment workflow can compare the server requirements with available rack space, power, cooling and other infrastructure conditions.

This makes capacity planning closer to constraint solving.

The system can identify locations that satisfy the deployment requirements and reject locations that appear physically available but fail another condition.

The result is a more defensible answer to the question, “Where should this server go?”

Capacity should also include the compute already installed

Physical facility capacity is only part of the picture.

AI operators should also look for stranded compute.

A GPU pool can be fully allocated on paper while containing resources that are idle or poorly utilized. Fragmentation can leave capacity unavailable to large workloads even when total free accelerator count appears sufficient.

This creates a parallel between facility capacity and compute capacity.

At the facility level, power and cooling can strand rack space.

At the compute level, allocation and fragmentation can strand GPUs.

A modern AI data center therefore needs both views.

The operations team should be able to see the physical capacity supporting the compute and the actual utilization of the compute itself.

Scarcity changes the business case for better operations

When vacancy is high and new power is easy to obtain, imperfect capacity management is inconvenient.

When vacancy is around 1 percent and new data center power can take years to secure, the economics change.

Finding additional deployable capacity inside an existing facility becomes strategically valuable.

This does not mean every data center can avoid expansion. Many organizations genuinely need more infrastructure.

It means expansion should begin with a more rigorous question.

How much capacity is already present but hidden by poor asset data, uneven power distribution, cooling constraints, conservative rack rules or underutilized compute?

Sensaka's role is to help make those constraints visible.

DCOS provides physical infrastructure visibility across assets, racks, power, cooling and hardware. iDCOS can add configuration relationships and operational workflows. For AI infrastructure, broader resource management can connect physical capacity with compute pools and workload demand.

The result is a capacity model based on what can actually be deployed.

The most valuable new capacity may not be new

The debate over AI overbuild will continue.

Vacancy, precommitment and hyperscaler spending will be interpreted differently by investors depending on their view of future demand.

Data center operators have a more practical problem.

Capacity is scarce today.

That makes every unused U position, every unbalanced rack, every underutilized GPU and every unrecognized constraint worth investigating.

The first step in the next expansion project should therefore be a capacity audit of the infrastructure already in service.

Before building the next megawatt, find out whether part of it is already there.

Sources

Originally published on the Sensaka blog.

Meta Is Testing Data Center Robots. The Bigger Shift Is Toward Autonomous Operations.

Da — Wed, 02 Sep 2026 11:31:04 +0000

Meta is experimenting with robots for physical data center work, including tasks such as cable handling and equipment interaction.

The experiments are interesting because they challenge an assumption that has existed throughout the AI automation debate. Many people expected software work to be automated first while physical infrastructure work remained largely human. Data centers may prove that the distinction is temporary.

Robots still face significant limitations. Physical environments are messy, equipment layouts vary, cables resist neat automation and safety requirements are strict. Human technicians remain essential.

But the more important story is larger than robotics.

Data center operations are gradually moving toward a model in which machines can observe infrastructure, identify problems, recommend actions and increasingly execute approved work. Physical robots represent the mechanical end of that shift. Software automation, AIOps and AI agents represent the operational intelligence behind it.

A robot without operational context is just a pair of automated hands

Consider a simple physical task: restarting a server.

The mechanical action is easy. The operational decision is difficult.

Before a machine should restart anything, the system needs to know which server is involved, what business service depends on it, whether the server is part of a cluster, whether another node is already degraded, whether a maintenance window is active, whether a recent configuration change might explain the problem and whether restarting the device is an approved response.

That context does not come from the robot.

It comes from the operations platform.

The same is true for replacing a cable, reseating hardware or isolating a node. Physical execution is only the final step in a much longer chain of detection, diagnosis, risk assessment, authorization and verification.

This is why autonomous data center operations will depend as much on software relationships as on robotics.

The automation ladder starts long before robots arrive

Most data centers can automate many activities today without installing a single robot.

The progression can begin with asset discovery.

Infrastructure is automatically detected and added to inventory. Hardware configuration and component information are collected continuously instead of relying on manual spreadsheets.

The next step is automated inspection.

Servers, storage, network devices, power systems and environmental equipment can be checked on a schedule. Abnormal conditions can be identified earlier and routed to the appropriate team.

Then comes remote operation.

Out of band interfaces can provide remote power control and management access even when the operating system is unavailable.

Provisioning can also be automated.

Bare metal servers can be discovered, configured and installed using standardized templates. Operating systems, drivers and policies can be applied through controlled workflows.

After that, event driven automation becomes possible.

A detected condition can trigger a workflow, create a ticket, collect diagnostic data, recommend a runbook or execute a low risk action under predefined guardrails.

Robotics extends this ladder into the physical world.

Autonomous operations require reliable infrastructure data

AI agents are only as useful as the context they receive.

If the asset inventory is wrong, relationships are incomplete or monitoring data is fragmented, an AI system may generate a plausible answer based on an incorrect picture of the infrastructure.

This is particularly dangerous in data centers because operational actions can affect production systems.

A credible autonomous operations model therefore needs a strong data foundation.

That includes accurate physical inventory, configuration information, topology, business dependencies, current health data, incident history, change history and clear ownership.

Sensaka's architecture follows this progression.

DCOS provides physical infrastructure and hardware visibility. iDCOS adds configuration relationships, CMDB, workflows and automation. SmartBSM adds service context, event correlation, root cause analysis and AI assisted operations.

Together, those layers can provide the context required before an AI agent should recommend or execute an action.

The safest autonomous system will not automate everything

Autonomy should not mean removing human control from every decision.

Different actions carry different levels of risk.

A low risk inspection task may be suitable for full automation. Collecting diagnostic information can often happen automatically. Restarting a noncritical service might be automated under defined conditions.

Other actions should remain gated.

Firmware upgrades, production network changes, destructive commands and actions affecting critical services may require approval, change workflows or staged execution.

This suggests a practical three level model.

At the first level, the system observes and recommends.

At the second level, it prepares an action and asks for approval.

At the third level, it executes preapproved low risk actions automatically and records the result.

This approach makes autonomous operations more realistic because it introduces intelligence without pretending that every infrastructure decision has the same risk profile.

Physical automation and software automation will converge

Imagine a future hardware incident.

A monitoring platform detects an abnormal server component through out of band telemetry. The event is correlated with recent changes and the service topology. The system determines that redundancy is available and identifies the likely failing component.

An AI agent recommends isolating the node and moving the workload.

The approved workflow drains the node, updates the ticket, creates a maintenance task and verifies that service health remains normal.

Only then does a physical robot receive an instruction to perform the required hardware task.

After the work is completed, the system rechecks hardware health, returns the server to service and closes the operational loop.

The robot performs the physical action.

The operations platform provides the reasoning, relationships, workflow, safety controls and evidence.

That combination is much closer to autonomous operations than either technology alone.

Automation also changes the role of data center technicians

The labor discussion around Meta's experiments is understandable.

Reporting on the trials has included claims that successful robotic automation could remove a large share of repetitive workload in some specific technician roles. That should be treated as a scenario described in reporting, not a forecast for the entire data center workforce.

Data centers are also expanding quickly, infrastructure is becoming more complex and skilled operations personnel remain difficult to replace.

The more plausible near term shift is in the composition of work.

Technicians may spend less time on repetitive inspection, simple resets and routine physical tasks. More time may move toward exception handling, automation supervision, reliability engineering, capacity planning and complex troubleshooting.

Software has followed a similar pattern.

Automation tends to remove repeated steps before it removes the need for expertise.

The autonomous data center will be built in layers

Robots make the future visible because they are easy to photograph.

The deeper transformation is happening in the operating model.

Automatic discovery replaces manual inventory. Continuous monitoring replaces periodic inspection. AIOps reduces alert noise and helps identify probable root causes. Workflows standardize response. Remote control reduces the need for site visits. Automated provisioning accelerates deployment. AI agents can increasingly coordinate these capabilities.

Physical robots can eventually become another execution channel inside that system.

Sensaka's opportunity is in this software layer.

The objective is not a science fiction data center with no people. It is an operations environment where humans no longer need to perform every repetitive step manually, and where machines can take on more work without losing control, context or auditability.

That is a much more achievable definition of autonomous operations.

Sources

Originally published on the Sensaka blog.

d-Matrix Raptor Uses 3D DRAM to Attack AI Inference’s Memory Bottleneck

Da — Sat, 29 Aug 2026 17:12:11 +0000

d-Matrix presented its Raptor 3D-DRAM accelerator at Hot Chips 2026 with a design built around stacking DRAM and compute logic rather than relying on conventional external high-bandwidth memory. ServeTheHome’s live coverage describes the architecture as an attempt to bring very high memory bandwidth directly into a generative inference accelerator. The company’s reported figures are ambitious. Technical coverage describes a 32 GB 3D-DRAM design delivering more than 100 TB/s of internal bandwidth with very low energy per bit. Those are vendor claims presented around the Hot Chips disclosure, so they should be evaluated through independent benchmarks and production deployments before being treated as universal performance results. The architecture is still worth paying attention to because inference is increasingly constrained by memory movement, not only raw compute. Mr.PlanB’s guide to AI and GPU workloads on Kubernetes explains the surrounding infrastructure problem: accelerator utilization depends on scheduling, storage throughput, networking, drivers and data movement across the stack.

Inference has a different bottleneck from model training

Training receives much of the attention in AI infrastructure because it requires large clusters and enormous capital investment. Inference is different. Once a model is deployed, the system repeatedly moves model weights and working data through memory while generating output for users. Large language models can therefore become memory-bandwidth intensive. A processor may have enough arithmetic capability to calculate the next token but still wait for data to arrive from memory. HBM has become the standard answer in high-end accelerators because it provides much more bandwidth than conventional server memory. The disadvantage is cost, packaging complexity and power. d-Matrix is arguing that a different memory architecture can improve the economics of inference by placing DRAM much closer to the compute fabric. Whether Raptor can deliver that advantage at scale remains to be proven. The important architectural idea is that inference hardware does not have to copy the same memory design used by every training accelerator.

Specialized inference hardware changes cluster design

If inference accelerators become more specialized, infrastructure teams may end up operating more heterogeneous clusters. Training nodes, general GPU nodes and inference-optimized accelerators can have different driver stacks, scheduling requirements, networking profiles and failure behaviors. Kubernetes can provide a common orchestration layer, but it does not make every accelerator interchangeable. Device plugins, node labels, workload placement, model formats and runtime software still have to match the underlying hardware. Mr.PlanB’s comparison of managed Kubernetes and bare metal is relevant because accelerator-heavy workloads often force teams to decide how much hardware control they need. A managed environment can reduce operational burden, while bare metal can provide more direct control over devices, network topology and performance tuning. New accelerators increase the importance of that decision. A platform designed around one dominant GPU stack may need additional engineering before an alternative inference architecture can be introduced cleanly.

Memory innovation does not remove storage and networking requirements

Raptor is focused on memory bandwidth inside the accelerator. Model deployment still requires data to reach the node in the first place. Weights may come from object storage, shared filesystems or local caches. Requests enter through network services. Outputs may be logged, ranked or passed to other applications. A fast accelerator can still sit idle if the surrounding system cannot supply work reliably. This is why infrastructure architecture needs to separate the memory wall inside the accelerator from the data pipeline around it. Solving one bottleneck can simply expose the next one. Mr.PlanB’s guide to Kubernetes business workloads emphasizes storage, networking, security, observability and recovery alongside orchestration. Those considerations apply to AI inference even when the hardware is highly specialized. The practical test is end-to-end throughput per unit of cost, power and operational effort, not the peak bandwidth of one component.

Alternative accelerators create a portability question

The AI infrastructure market is increasingly interested in alternatives to dominant GPU platforms, but hardware choice is only one layer of portability. Applications depend on model runtimes, compiler stacks, kernels, libraries and observability tooling. If an accelerator requires substantial software changes, the migration cost can offset part of the hardware advantage. That does not mean specialized hardware is unattractive. It means buyers need to evaluate the full operating model. How easily can workloads move? Which model formats are supported? How are failures surfaced? What tools exist for monitoring utilization and memory pressure? How difficult is capacity expansion? These questions are familiar from every infrastructure transition. A benchmark can prove that a component is fast. Production readiness requires evidence that teams can deploy, operate and recover it repeatedly.

Raptor is evidence that the AI memory architecture is still unsettled

The most interesting part of d-Matrix’s Hot Chips presentation is that the industry has not converged on one permanent answer to the memory problem. HBM will remain important because it offers proven bandwidth and a large ecosystem. At the same time, 3D stacking, near-memory compute and specialized inference architectures are creating alternatives that may be better suited to specific workloads. For infrastructure teams, the safest assumption is that future AI clusters will become more heterogeneous. That makes orchestration, observability and workload portability more important, not less. Mr.PlanB’s broader Kubernetes hub is useful for understanding the control layer that sits above changing hardware choices. The hardware underneath may evolve quickly, but production teams still need repeatable deployment, scaling, networking, storage and recovery. d-Matrix Raptor should therefore be treated as a technical signal rather than a settled replacement for HBM-based accelerators. It shows that vendors are attacking AI inference from the memory side, and that the next competitive gains may come from changing how data is physically placed around compute.

Originally published on the Mr.PlanB blog.

Stop Recommending Ceph to Everyone

Da — Sat, 29 Aug 2026 17:11:35 +0000

Ceph is one of the most impressive open-source infrastructure projects available.

It can provide distributed block, file, and object storage, replicate data across failure domains, recover from failed devices, scale across large clusters, and integrate with platforms such as Proxmox and Kubernetes through Rook.

That capability makes it easy to recommend.

It also makes Ceph one of the technologies most likely to be proposed in environments that do not need it.

A 2025 data center reference architecture from Sidero Labs described Rook plus Ceph as appropriate for more complex use cases while explicitly warning that it is significantly more complex and not well suited to small clusters. The architecture recommended Longhorn for simpler general Kubernetes workloads and noted that Ceph operations such as rebalancing can materially affect network, memory, and CPU resources.

That is the nuance many infrastructure discussions skip.

Ceph solves a difficult problem extremely well

Traditional shared storage can become a central dependency. A SAN, NAS system, or storage array may be reliable, but it is still a distinct platform with its own controllers, network paths, expansion limits, and lifecycle.

Ceph distributes storage responsibilities across multiple nodes and devices. Data placement, replication, recovery, and scaling are handled by the cluster rather than one central appliance.

A good Ceph overview shows why the architecture is attractive: monitors, managers, OSDs, pools, placement logic, replication, erasure coding, and self-healing create a powerful storage substrate.

For large environments with the right failure domains and operational skills, that complexity buys real resilience and flexibility.

For three small servers in a rack, the calculation can look very different.

Distributed storage does not remove storage operations

Ceph reduces dependence on proprietary storage appliances, but someone still has to understand the cluster.

Capacity must be planned. Failure domains must be correct. Networks need enough bandwidth and low enough latency. Recovery behavior must be understood. OSD performance, placement groups, pool configuration, scrubbing, rebalancing, and hardware health all require attention.

When a drive fails, Ceph can rebuild automatically. That is good.

When several constraints interact during a degraded state, automatic recovery can also create heavy network and disk activity at exactly the moment the infrastructure is already stressed.

The technology is resilient because it is sophisticated, not because it is effortless.

Proxmox makes Ceph easy to start, which can hide the long-term question

Proxmox integrates Ceph directly into its management interface, making deployment much more approachable than building a distributed storage system manually.

That convenience is useful, but installation simplicity should not be confused with operational simplicity.

A Proxmox and Ceph guide should be read as a design decision, not a checkbox. Network separation, hardware selection, node count, replication, capacity overhead, and failure behavior still matter.

For some clusters, ZFS with replication, external NFS or iSCSI, or a dedicated storage appliance may be easier to understand and recover. In Kubernetes, Longhorn or external CSI-backed storage may offer a better balance for smaller environments.

The “less sophisticated” option can be the more reliable option if the team actually knows how to operate it.

Small clusters pay a disproportionate complexity tax

Distributed systems become more useful as scale increases because the coordination overhead is spread across more capacity and more workloads.

Small clusters experience the opposite effect.

Three nodes provide limited failure domains. Storage traffic competes with application or virtualization traffic unless networks are designed carefully. Memory and CPU overhead matter more. Maintenance can reduce redundancy quickly. A single bad design decision can affect a large percentage of the environment.

Ceph may still be correct. It just should not be automatic.

Recommend requirements before products

Before recommending Ceph, ask what problem needs to be solved.

Does the environment require shared block storage? How much usable capacity is needed after replication? What failure scenarios must be tolerated? How quickly must the cluster recover? Is there dedicated networking? Can the team diagnose distributed storage problems? How will the system be backed up? What happens during upgrades?

If the answers justify Ceph, use it confidently.

If the main reason is that Ceph is open source, highly available, and integrated into the platform, keep evaluating.

Good infrastructure design is not a competition to deploy the most capable technology. It is the discipline of choosing the least complicated system that still meets the required failure model.

Ceph deserves respect. It does not need to be everyone's default.

Originally published on the Mr.PlanB blog.

Should Brands Admit Their Ads Were Made by AI?

Da — Sat, 29 Aug 2026 17:10:44 +0000

AI is rapidly becoming an ordinary production tool for advertising. Copy, product images, voice, video, translations, backgrounds, and campaign variations can all be generated or modified with AI.

That creates an awkward question for brands: when should the audience be told?

Google moved further toward disclosure in July 2026 by introducing a “How this ad was made” section in My Ad Center. Ads created with Google's own generative tools can be identified automatically, while advertisers can indicate when outside AI tools were used. The Google announcement reflects a wider shift toward making synthetic media easier to identify.

In Europe, the issue is no longer only voluntary. AI Act transparency obligations began applying on August 2, 2026, including requirements around machine-readable marking and disclosure for specified kinds of AI-generated or manipulated content. The European Commission guidance makes clear that transparency rules are becoming part of the operating environment.

But “AI was involved” still covers an enormous range of activity.

A label can be useful and meaningless at the same time

Imagine three advertisements.

One uses AI to remove a background from a real product photograph. Another creates a fictional model wearing a real product. A third generates a fake customer testimonial from a person who never existed.

Calling all three “AI-generated” treats fundamentally different situations as equivalent.

That is the weakness of blanket labeling. AI is becoming embedded in editing tools, cameras, design software, ad platforms, and marketing workflows. Eventually, asking whether AI touched an advertisement may become as broad as asking whether Photoshop touched it.

The more important question is whether AI changed something a reasonable customer would consider material.

Disclosure should follow the risk of deception

Marketing already has a useful principle: do not mislead people about what they are buying.

AI makes that principle harder to apply, but it does not make it obsolete.

If generative tools create a fictional lifestyle scene around a real bottle of shampoo, a visible disclosure may add little. If they generate a spokesperson who appears to be a real doctor, fabricate a product demonstration, invent a customer, alter a before-and-after image, or simulate an event that never happened, disclosure becomes much more meaningful.

Brands that already think carefully about omnichannel marketing should apply the same consistency to AI provenance. A customer should not receive one level of transparency on a website and another in a paid social advertisement simply because different production tools were used.

Trust may become a competitive advantage

There is a fear that AI labels reduce performance because they remind people that an image or message is synthetic. That may be true in some contexts.

The opposite effect is also plausible. As synthetic media becomes more realistic, brands that explain how content was created may appear more trustworthy than brands that force audiences to guess.

This is particularly relevant when building long-term brand visibility in AI and search. Trust signals increasingly matter across channels because customers encounter a brand through search results, AI answers, social ads, creator content, and automated campaigns before they ever speak with the company.

Transparency can become part of that brand system.

Not every AI edit needs a warning label

A useful policy is to disclose AI when the synthetic element could materially change what the customer believes.

That is stricter than saying disclosure is never necessary and more practical than labeling every resized image or rewritten headline.

Brands should also keep an internal record of how major creative assets were produced. Regulation will evolve, platforms will change their disclosure rules, and customers may ask questions later. Knowing what was generated, what was altered, and what was real is becoming basic marketing governance.

The strongest brands will probably use AI heavily. They will also understand that efficiency does not remove responsibility.

The question is therefore less “Did AI make this ad?” and more “Would a reasonable person interpret this ad differently if they knew how it was made?”

When the answer is yes, tell them.

Originally published on the Mustard Seed blog.

Proton's Frankfurt Outage Shows How Fast Cooling Failure Becomes a Service Failure

Da — Sat, 29 Aug 2026 16:20:17 +0000

A data center cooling problem can become an application outage much faster than many infrastructure teams expect.

On August 27, Proton reported a critical cooling failure in its Frankfurt data center and began shifting traffic to backup sites. The company's public status page recorded the incident, while Data Center Dynamics later reported that Proton services returned after the company carried out a slower than expected recovery process.

The most striking detail came from Proton founder and CEO Andy Yen. He said temperatures rose from roughly 30°C to 60°C in about 20 minutes after the cooling failure. He described the speed of the temperature increase as frightening.

For data center operators, the incident is a useful reminder that cooling is part of the service dependency chain. CloudSino's data center operations approach emphasizes visibility across hardware, environment, energy, capacity and business services, because a facility alarm matters most when operators can see what equipment and services depend on it.

The failure was serious because the data center was only partially dead

A complete site failure can be easier for automation to interpret than a degraded site.

According to Data Center Dynamics, Proton said automatic failover did not immediately take over because the Frankfurt environment was only partially unavailable. Staff initially focused on restoring cooling before servers suffered permanent damage.

That distinction is operationally important.

Failover logic often depends on clear health signals. If power disappears, a site can be declared unavailable. If a network path fails, routing systems can detect loss of reachability. A cooling failure can be less binary. Servers may still be running while thermal risk rises rapidly.

The infrastructure can therefore remain technically "up" while becoming unsafe to operate.

This is the kind of condition that requires multiple signals to be correlated. Cooling alarms, inlet temperature, server thermal readings, workload status and service impact should be evaluated together. A single green application check can create false confidence if the physical environment is deteriorating underneath it.

Twenty minutes is a very short operational window

The reported rise from 30°C to 60°C in about 20 minutes demonstrates how little time operators may have when cooling stops in a high power environment.

Modern servers are designed to protect themselves. Components may throttle performance as temperatures rise, fans may increase speed and systems may eventually shut down. Those protections reduce hardware damage, but they do not guarantee service continuity.

In a dense environment, the thermal event can affect many devices at once. That creates a common mode failure that is very different from losing one power supply or one server.

Operations teams therefore need alarms that are early enough to support a controlled response. They also need the ability to determine which racks, devices and services are inside the affected cooling zone.

CloudSino's product platform is designed around unified infrastructure and business monitoring, including hardware status, capacity, energy and service views. Incidents like Proton's show why these layers should not remain isolated.

Known failure modes still need prioritization

Yen said the particular failure mode was known, but mitigations had not been prioritized because the scenario was considered extremely unlikely.

That statement may be the most important lesson from the incident.

Risk registers often contain low probability events. The difficulty is deciding which ones deserve engineering work. A failure can be unlikely and still justify mitigation if the impact is severe and recovery is difficult.

Cooling deserves special treatment because it can create a cascading condition. A fault in one part of the environmental system can threaten many otherwise healthy servers at once. If automatic failover also depends on a cleaner failure signal, the combination can produce a gap between facility degradation and service recovery.

The practical question is not whether every theoretical scenario can be eliminated. It is whether known high impact failure modes have an explicit response path, tested thresholds and owners.

Failover should be tested against degraded states

Disaster recovery exercises often simulate clean failures. A site is considered unavailable, traffic moves, and recovery procedures begin.

Real incidents are often messier.

A cooling system may fail while network and compute remain online. One room may overheat while another remains stable. Some services may degrade before others. Operators may need to decide whether to continue running, shed workload, shut down equipment or force a site failover.

That means failover testing should include degraded states, not only complete outages.

Teams should ask how their systems behave when the site is alive but unsafe. They should define which thermal thresholds trigger workload movement and which conditions require controlled shutdown. They should also test whether monitoring systems can show the business impact quickly enough for incident commanders to act.

Physical telemetry belongs in business continuity

Proton is a cloud service company, but the immediate cause of this incident was physical.

That is the larger point for modern digital services. Software resilience ultimately depends on power, cooling, network paths and hardware. A business service map that stops at the virtual machine or application layer misses part of the failure chain.

CloudSino focuses on connecting infrastructure monitoring with process and business service context. The goal is to help operations teams see whether an environmental or hardware event is simply a local alarm or the beginning of a customer facing incident.

The Frankfurt outage lasted hours, but the most consequential part of the story happened in minutes. Once the cooling stopped, the time available for decision making compressed rapidly.

For data center teams, that is a strong reason to treat cooling health as a first class service reliability signal.

Originally published on the CloudSino site.

Mid Market Companies Account for 73 Percent of Disclosed Ransomware Incidents in Black Kite Analysis

Da — Wed, 26 Aug 2026 14:21:41 +0000

Mid market companies are carrying a disproportionate share of publicly disclosed ransomware and data extortion incidents. Help Net Security reported on August 24, 2026 that Black Kite analyzed 13,336 incidents with known company revenue across North America and Europe between January 2023 and June 2026. Companies with annual revenue between $10 million and $1 billion accounted for 73 percent of those incidents, and their share remained between 72 percent and 75 percent throughout the period.

The consistency matters. This is not one unusual quarter caused by a single campaign. It suggests that ransomware operators repeatedly find the economics of mid sized organizations attractive. These companies often have valuable data and meaningful ability to pay, but may have smaller security and infrastructure teams than the largest enterprises. Recovery therefore has to be treated as an engineering capability rather than an assumption. Mr.PlanB’s guide to the 3 2 1 1 0 backup rule provides a useful framework for separating production data from protected recovery copies.

The smaller end of the mid market is heavily represented

Help Net Security reported that more than half of the mid market victims in the analysis had annual revenue between $10 million and $50 million. Manufacturing accounted for more than a quarter of mid market victims, followed by professional, scientific and technical services and construction.

That profile makes sense from an attacker’s perspective. Many companies in these sectors depend heavily on operational systems, shared files, ERP platforms, virtual machines and third party services. Downtime can stop production, delay projects or prevent staff from serving customers. The resulting business pressure can make an extortion demand more effective.

The important defensive conclusion is that smaller infrastructure teams should prioritize resilience around the systems that stop the business when unavailable. A complete inventory of every possible asset is useful, but recovery planning needs to identify which services must return first and what dependencies they require.

Exposure before encryption is part of the ransomware problem

The Black Kite analysis also found widespread weaknesses in public facing systems. Help Net Security reported that 54.7 percent of more than 120,000 assessed mid market organizations had at least one significant patch management issue affecting an internet facing system. More than a quarter had a vulnerability already known to be exploited by attackers. Nearly one third had at least one stealer log finding, indicating exposed credentials collected by information stealing malware.

These signals show why ransomware defense cannot begin at the moment encryption starts. Attackers often need initial access, credentials, discovery and administrative control before they can damage large parts of an environment. Backup servers, hypervisors and identity systems can become targets during that preparation.

The recovery architecture should assume that production credentials may eventually be compromised. Independent backup identities, restricted deletion rights and separate storage paths make it harder for one stolen administrator account to destroy both production and recovery data.

A successful backup job is not the same as a successful recovery

Mid market teams often have backup software because it is an obvious requirement. The harder question is whether those backups can rebuild business services under pressure. A green job status says that data was copied. It does not prove that the copy is complete, clean, accessible or fast enough to meet the organization’s recovery objective.

Mr.PlanB’s guide to backup testing recommends moving beyond file checks toward application recovery, isolated restore environments and full system testing. For ransomware scenarios, isolated testing is especially valuable because teams need to know whether a restored system can be trusted before reconnecting it to production networks.

Recovery time should also be measured. Restoring several terabytes of data may be technically possible while still taking too long for the business. That gap should be discovered during a test, not during an incident.

Disaster recovery has to include dependencies and decision making

Ransomware can affect more than files. Identity services, DNS, virtualization, network management and backup infrastructure may all be unavailable at the same time. Restoring a server is not useful if the authentication or network services it depends on are still offline.

Mr.PlanB’s disaster recovery plan guide treats recovery as a coordinated process involving service priorities, dependencies, roles, contact paths, infrastructure rebuilds and testing. That broader model is particularly important for companies with small teams because the same administrators may be responsible for several systems during the incident.

The 73 percent figure should not be interpreted to mean every mid market company will be attacked. It shows where a large share of publicly disclosed incidents is already concentrated. Organizations in that range should therefore assume ransomware is a normal business continuity risk and test their infrastructure accordingly.

The strongest defense is not a promise that attackers can never get in. It is a combination of reducing exposure, protecting credentials, isolating recovery copies and proving that critical services can be rebuilt when preventive controls fail.

Originally published on the Mr.PlanB blog.

Do Communities Have a Right to Say No to AI Data Centers?

Da — Wed, 26 Aug 2026 14:21:06 +0000

The AI infrastructure boom is colliding with local politics.

On August 19, 2026, Indianapolis approved a moratorium on new data center development through 2027 after significant community opposition. The Axios report described an overwhelming local vote in favor of the pause, while one opposing councilor argued for standards instead of a moratorium.

That disagreement captures the larger controversy surrounding AI data centers. Developers see urgent demand for compute capacity, grid connections, land, cooling, and network infrastructure. Residents increasingly ask what they receive in exchange for hosting facilities whose energy and infrastructure requirements can be enormous.

Do communities have the right to say no even when national technology strategies say build faster?

Data centers are local infrastructure before they are global infrastructure

AI can feel abstract until a project arrives beside a town, industrial park, farm, or residential district.

Then the questions become physical. How much electricity will it require? What transmission infrastructure must be added? Will the cooling system consume local water? How much noise will backup generators and cooling equipment create? How many permanent jobs will remain after construction? What tax concessions are being offered? Who pays if utility infrastructure needs to expand?

These questions are not anti-technology. They are infrastructure planning questions.

A serious project should be able to discuss the same practical constraints covered in AI data center operations: power, cooling, hardware density, network requirements, environmental conditions, and operational risk. Those constraints do not disappear because a project has national economic importance.

The case for saying yes is also strong

AI infrastructure is not optional if societies want large-scale model training, inference, cloud services, scientific computing, and new digital industries.

Communities can benefit from construction spending, property tax revenue, infrastructure investment, skilled employment, and the economic activity that follows large technology clusters. Regions that refuse every project may find that investment simply moves elsewhere.

There is also a strategic argument. Countries competing for AI capacity increasingly treat data centers and electricity generation as critical economic infrastructure. Local restrictions can therefore conflict with national industrial policy.

That is why a blanket “no data centers” position can be as simplistic as a blanket “approve everything” position.

The real dispute is about who carries the externalities

Much of the political anger comes from situations where the project benefits appear concentrated while the costs feel socialized.

If a new facility requires grid upgrades, consumes scarce generation capacity, increases pressure on water systems, or changes land use, residents naturally ask whether the developer is paying the full cost created by its demand.

Operators can make these discussions more concrete by publishing credible numbers. Tools such as a data center power calculator illustrate the discipline required even at rack level: load, circuit limits, utilization, headroom, and energy costs should be measured rather than discussed in vague capacity language.

At community scale, the same principle applies. The project should state what it needs and who pays.

Consent requires information, not slogans

Communities should have the ability to reject projects that do not fit local infrastructure, environmental constraints, or development priorities.

But the process works better when “yes” and “no” are not ideological identities.

Developers should disclose power demand, water strategy, backup generation, expected tax contribution, permanent employment, noise characteristics, construction impacts, grid responsibilities, and contingency plans. Local governments should evaluate those facts against zoning, economic development, utility capacity, and long-term community goals.

Moratoriums can be useful when rules have not caught up with a new development pattern. They can also become a substitute for doing the harder work of creating enforceable standards.

The best outcome is not unlimited construction or unlimited obstruction. It is a permitting system strong enough that communities can approve projects they understand and reject projects that cannot justify their local cost.

AI may be global. Every data center still has an address.

Originally published on the Sensaka blog.

Does Your Client Have a Right to Know You Used AI?

Da — Wed, 26 Aug 2026 13:22:54 +0000

Lawyers use technology constantly without giving clients a tool-by-tool disclosure. Firms do not normally announce that a lawyer used Westlaw, spell-checking, document comparison software, e-discovery tools, or a spreadsheet.

Should generative AI be different?

The American Bar Association's Formal Opinion 512 does not create a universal rule requiring lawyers to tell clients every time generative AI is used. It says disclosure and informed consent may be required depending on how the tool is used, particularly where client information is being provided to systems that create confidentiality risks or where the client's instructions require communication. The ABA opinion also emphasizes competence, supervision, candor, and reasonable fees.

That gives firms room to use AI. It also means “we never disclose AI” is too simple a policy.

The tool itself is not always the material fact

Suppose a lawyer uses an approved enterprise AI system to summarize a long internal document, verifies the output against the original, and uses the summary only as a working aid.

The client may not need a special notification any more than the client needs to know which search interface the lawyer used.

Now change the facts.

The lawyer uploads confidential client material to a consumer AI service with uncertain retention terms. Or uses an AI system to perform a substantial part of an analysis the client expected a specialist to perform personally. Or passes a separate AI charge through to the client. Or agrees to a client guideline prohibiting specific AI tools.

In each case, AI use becomes more material.

The disclosure question should therefore follow the risk and the engagement, not the novelty of the software.

Confidentiality is the first test

Law firms should start with the information being processed.

MIRA's guide to attorney-client confidentiality emphasizes that the duty extends broadly across client-related information, including technology workflows. If a tool receives sensitive material, the firm needs to understand its security, retention, access, training, and contractual controls.

A client may reasonably care whether confidential information leaves the firm's controlled environment or becomes available to a third-party model provider.

Disclosure is particularly important when the lawyer cannot confidently conclude that the intended use is consistent with confidentiality obligations.

Billing is the second test

AI creates unusual billing questions because it can compress work.

If a client is billed hourly, the firm should not charge fictional time that the lawyer did not spend. If the firm charges separately for AI tools, the client should understand the basis for the charge. If the work is priced as a flat fee, the engagement should still comply with applicable reasonableness and communication requirements.

Accurate legal billing descriptions remain useful here. The narrative should tell the client what legal work was performed without exposing unnecessary confidential detail or using vague technology language to disguise the nature of the service.

The client is buying professional legal work. AI should not become a mechanism for making that work harder to understand.

Client instructions can settle the issue

Some clients will set explicit AI policies.

Corporate legal departments may prohibit certain consumer tools, require prior approval for processing confidential information, mandate specific security terms, or ask firms to disclose material AI use. Other clients may actively prefer AI-enabled workflows because they want lower costs and faster turnaround.

Those instructions should become part of matter governance.

A firm that can explain its AI architecture, review process, approved tools, confidentiality controls, and billing approach will be in a stronger position than one relying on an informal “everyone uses it now” assumption.

Routine AI will become less remarkable, accountability will not

Eventually, generative functions will be embedded so deeply into legal software that a binary “AI used: yes or no” disclosure may become meaningless.

The enduring questions are more practical.

Did the technology create a material confidentiality risk? Did it change the service the client reasonably believed it was buying? Did it affect fees? Did client instructions require disclosure? Was a lawyer still responsible for checking the work?

When the answer to one of those questions is yes, the client may have a legitimate right to know.

AI can become routine without becoming invisible where it matters.

Originally published on the MIRA blog.

Are We Building Too Many AI Data Centers?

Da — Wed, 26 Aug 2026 13:22:15 +0000

The AI data center boom is usually discussed as a shortage problem. There is not enough power, not enough transformers, not enough land with grid access, not enough cooling capacity, and not enough GPU infrastructure.

But infrastructure cycles have another failure mode: building too much of the wrong thing.

That concern is moving into financial markets. Reuters reported in August 2026 that U.S. AI-related corporate debt issuance had reached roughly $220 billion during the year, compared with $12.5 billion the year before. Investors were beginning to demand wider spreads as the volume of technology debt increased. The Reuters analysis did not say the boom was collapsing. It showed that capital is no longer treating every AI infrastructure requirement as an uncomplicated bet.

The uncomfortable question is whether today's capacity shortage could become tomorrow's stranded asset problem.

Data centers last longer than AI hardware cycles

A modern data center is a long-lived physical asset. Utility connections, switchgear, cooling systems, generators, buildings, and network infrastructure are financed over years or decades.

AI hardware evolves much faster.

GPU generations change, rack densities rise, cooling requirements shift, interconnect architectures evolve, and inference workloads may move toward more specialized or energy-efficient hardware. A facility designed around today's power density and thermal assumptions may need major retrofits before the building itself is old.

This is why AI data center capacity planning has to look beyond floor space. Usable capacity is constrained by power, cooling, network, hardware profiles, and operating conditions. A building can have empty rack positions and still be functionally full.

It can also have megawatts available that future hardware no longer wants in the same configuration.

The bull case remains formidable

There are strong reasons to believe more capacity will be needed.

Model training remains compute intensive. Inference demand is expanding as AI features are embedded in software, search, productivity tools, coding, media generation, robotics, and enterprise workflows. Sovereignty requirements may also push countries and regulated industries toward more regional infrastructure.

Even if individual models become more efficient, cheaper inference can increase total usage. Computing history contains many examples where efficiency improvements lowered unit cost and drove much larger aggregate demand.

Under that scenario, today's aggressive construction looks less like a bubble and more like catching up.

The risk is not simply too many megawatts

Oversupply is rarely uniform.

A facility can be valuable in one region and stranded in another. Power cost, grid reliability, water access, network connectivity, tax policy, local regulation, customer concentration, and proximity to demand all influence whether capacity remains useful.

The same is true operationally. Facilities that can support high-density liquid-cooled deployments may age differently from facilities requiring expensive retrofits. Teams that understand AI data center operations will recognize that a nominal megawatt of capacity is not interchangeable across sites.

That makes headline forecasts about global gigawatts less useful than they appear.

Debt makes wrong assumptions less forgiving

When hyperscalers finance projects from enormous operating cash flows, a weak facility can be absorbed inside a larger portfolio.

Debt changes the equation. Interest must be paid regardless of utilization, technology shifts, local opposition, or slower-than-expected AI demand. Special-purpose financing structures can also separate infrastructure from the companies ultimately consuming the compute, making risk harder to understand.

The Bank of England has already highlighted the scale of expected external financing for AI infrastructure and the growing role of debt and private credit.

None of this proves a bubble. It means capital structure deserves as much attention as GPU demand.

Build for adaptability, not one forecast

The safest answer is not to stop building. It is to stop treating one demand forecast as certain.

Developers should stress-test projects against slower utilization, changing rack density, different cooling architectures, customer concentration, higher electricity prices, delayed grid connections, and hardware replacement cycles.

The winning AI data center may not be the one with the largest announced capacity. It may be the one that can remain economically useful when the assumptions made in 2026 turn out to be wrong.

Infrastructure booms become bubbles when capital forgets that demand, technology, and financing can all change at the same time.

Originally published on the Sensaka blog.

Why Should Your Electricity Bill Subsidize an AI Data Center?

Da — Wed, 26 Aug 2026 13:21:36 +0000

AI infrastructure needs electricity at a scale that is forcing utilities to rethink generation, transmission, substations, interconnections, and long-term demand forecasts.

The engineering challenge is difficult. The political question may be harder: who pays for the grid built to serve that demand?

In July 2026, Reuters reported that major technology companies had signed a White House “Ratepayer Protection Pledge” committing to help finance electricity infrastructure required for their AI projects rather than pass those costs to existing customers. The Reuters report also noted concern among regulators, lawmakers, and consumer advocates that households could otherwise subsidize upgrades driven by large data centers.

The existence of the pledge tells us something important. The cost allocation debate is no longer hypothetical.

Electricity infrastructure is shared, but demand is not equal

Utilities have always invested ahead of demand. Homes, factories, offices, hospitals, transit systems, and population growth all require capacity.

Data centers are different mainly because of scale and speed. A single campus can represent an extraordinary new load, while AI facilities can require dense, continuous power with tight reliability expectations.

The basic engineering behind data center power planning is straightforward at small scale: equipment demand must fit within available circuit capacity with appropriate headroom. At utility scale, the same idea becomes far more expensive. New substations, generation, transmission lines, transformers, and reserve capacity may be required.

If those assets exist primarily because one new customer arrived, existing customers reasonably ask why they should finance them.

There is also a case for shared investment

The opposing argument is that electricity infrastructure creates broader economic capacity.

A stronger grid can serve future housing, manufacturing, electrification, transport, and additional businesses. Large industrial customers may also provide predictable long-term demand and tax revenue. For utilities with large fixed costs, new customers can sometimes spread costs across a larger base rather than simply increase them.

This means the correct answer cannot be “data centers must pay for everything connected to the grid.” Some assets genuinely serve multiple users and multiple decades.

The challenge is separating shared infrastructure from infrastructure that exists mainly to accommodate one exceptionally large load.

Rising grid costs make the debate more urgent

This is not happening in a stable power market.

Reuters reported in August that transmission congestion costs on PJM, the largest U.S. grid, reached $6 billion in the first half of 2026, up sharply from the year before. Data centers were among the forces contributing to rapidly growing demand. Another Reuters report from Virginia described residential electricity bills potentially rising as the region's data center boom increases pressure on power supply.

Those figures do not mean every increase is caused by AI. Weather, fuel costs, delayed generation, transmission constraints, electrification, and market design all matter.

But they explain why ratepayers are skeptical of assurances that the next wave of giant loads will somehow be absorbed without consequence.

Full-cost accounting should become the standard

Data center development needs a clearer cost model.

Operators already use measures such as data center total cost of ownership to understand construction, energy, cooling, staffing, software, maintenance, and lifecycle costs inside the facility. Grid impact should be treated with the same discipline.

A credible agreement should identify the generation capacity required, direct connection costs, transmission upgrades, stranded capacity risk if the facility closes or downsizes, and which costs remain useful to the wider grid.

It should also define what happens when demand forecasts are wrong. AI infrastructure can scale quickly, but technology changes quickly too. Utilities should not leave households paying for assets built around capacity reservations that never materialize.

AI growth should not depend on hidden subsidies

There is a strong case for building more AI infrastructure. There is a weaker case for hiding part of its cost inside everybody else's electricity bill.

If a data center creates a grid expense that would not otherwise exist, the default assumption should be that the project bears that incremental cost. Where an upgrade creates genuine shared value, costs can be shared transparently.

That approach does not stop development. It forces the economics to be visible.

If AI data centers are as valuable as their developers believe, they should still make sense when their electricity infrastructure is priced honestly.

Originally published on the Sensaka blog.