When major data breaches make headlines, attention almost always focuses on the same question: how did the attackers get in?

In the case of the BCBS-Conduent breach, that question matters. It is simply not the most important one.

What matters more is this. Two hundred and eighty-four days passed between Conduent’s discovery of the incident and public disclosure.

In environments handling protected health information and sensitive personal data, delays of that length are rarely explained by technical complexity alone. More often, they expose something deeper: a disconnect between documented compliance controls and the operational reality of incident detection, scoping, and response. This article is not an accusation. It is an examination of what extended silence tends to signal across industries, across years, and across many well-documented breaches.

The Incident, Briefly and Factually

Conduent is a large business services provider that supports claims processing and related functions for multiple healthcare organizations, including Blue Cross Blue Shield entities. In that role, it operates as a business associate under HIPAA, with access to substantial volumes of protected health information and personally identifiable information.

Public reporting and regulatory filings indicate that Conduent discovered unauthorized activity in January 2025. Notifications to affected entities, regulators, and the public began in October 2025. The elapsed time between discovery and disclosure was two hundred and eighty-four days. The exposed data included both PII and PHI, which triggered statutory notification and compliance obligations.

What Conduent has not publicly detailed is also notable. There has been no public accounting of the precise attack vector, the detection method, dwell time, how scope was determined, or why disclosure took more than nine months. That silence is not proof of wrongdoing. It is, however, informative.

Why Disclosure Timing Matters More Than Entry Vector

Modern security programs assume breaches will occur. The differentiator is not whether an organization is compromised, but how it responds once it knows. Incident response maturity is revealed across three related timelines: how quickly an organization detects an incident, how effectively it scopes the impact, and how promptly it communicates that information to stakeholders.

Of these, disclosure timing is often the most revealing because it sits at the intersection of security operations, legal and regulatory obligations, executive decision-making, and governance maturity. A short disclosure window usually indicates that an organization can detect incidents reliably, maintains accurate data inventories, can scope affected systems and data with confidence, and has pre-established authority to make notification decisions. Extended delays suggest the opposite. They typically reflect organizational uncertainty rather than malicious intent.

What Long Delays Usually Indicate, Without Speculation

Across multiple industries and decades of breach analysis, prolonged disclosure delays tend to correlate with a consistent set of structural problems. Organizations often delay disclosure because they cannot confidently answer which systems were accessed, what data was exposed, or which customers or patients were affected. This uncertainty commonly reflects weak logging, fragmented data ownership, or incomplete asset inventories. These are governance failures, not purely technical ones.

Long delays also tend to surface a second issue: compliance controls that exist primarily on paper. Many organizations maintain documented incident response and breach notification procedures that assume ideal conditions, including complete visibility, clear ownership, and accurate system inventories. When reality diverges from documentation, timelines stretch.

A third factor is legal and regulatory gating. Extended silence often reflects internal tension between security teams pushing for notification, legal teams seeking certainty, and executives concerned about liability and reputational risk. Strong governance resolves these tensions quickly. Weak governance allows them to stall response.

Finally, third-party risk frequently compounds delay. When breaches occur at vendors or business associates, organizations often discover that notification timelines are vague, oversight into the vendor’s detection capabilities is limited, and security assurances were accepted without independent validation. In healthcare, where data aggregation is extreme, this risk is magnified.

This Pattern Is Not Unique to Conduent

The BCBS–Conduent timeline fits a broader historical pattern. Equifax disclosed its 2017 breach roughly forty days after discovery and later faced regulator findings that cited deficiencies in its security program. Marriott’s Starwood breach involved an eighty-three-day disclosure delay that regulators tied to longstanding data governance failures following acquisition. Yahoo’s breach history involved years-long delays that were later linked to internal knowledge and disclosure breakdowns. Uber concealed its 2016 breach for approximately a year, a decision later cited explicitly as a governance and compliance failure.

By contrast, organizations that disclosed promptly, such as Target, Capital One, and Anthem, still suffered security failures. The difference was not technical sophistication. It was process transparency. Prompt disclosure does not mean strong security. Delayed disclosure often signals weak governance.

Compliance Versus Operational Reality

Compliance frameworks such as HIPAA, ISO 27001, SOC 2, and NIST all emphasize incident response and breach notification. Frameworks, however, do not investigate breaches. People do.

When auditors review controls, they see policies. When incidents occur, reality intervenes. Extended disclosure delays often reveal that data flows are poorly understood, system ownership is fragmented, exceptions have accumulated without documentation, third-party assurances were taken at face value, and incident response plans assumed capabilities that did not exist. In short, compliance maturity on paper exceeded operational maturity in practice.

What “Good” Would Have Looked Like

A mature response to a breach involving protected health information typically involves rapid detection through monitoring, early containment even before full scoping is complete, staged disclosure beginning with regulators and upstream partners, transparent updates as scope becomes clearer, and clear articulation of uncertainty rather than prolonged silence. This is not easy. It is, however, achievable, and many organizations demonstrate it regularly.

Why Regulators Focus on Process, Not Perfection

Regulators do not expect zero breaches. They expect reasonable safeguards, timely detection, honest disclosure, and evidence that governance structures function under stress. A delay of two hundred and eighty-four days inevitably raises questions. Those questions are not about whether controls existed, but whether they worked when it mattered.

The Real Lesson of the 284 Days

The most important takeaway from the BCBS-Conduent breach is not technical. It is organizational. Silence of that length usually means an organization is struggling to reconcile what happened with what its controls said should have happened. That struggle is the true risk. It is also one that audits, certifications, and attestations often fail to detect until an incident forces the issue.

Final Thought

Breach headlines come and go. Timelines endure. When nearly nine months pass between discovery and disclosure in a regulated environment, the story is no longer about attackers, vectors, or social engineering. It is about governance, and whether it functions when it matters most.

Sources and References

Information regarding the Conduent incident timeline and affected populations is drawn from U.S. state attorney general breach notification portals, including publicly filed notices and correspondence submitted in 2025, as well as reporting by HIPAA Journal and Cybersecurity Dive on the Conduent healthcare breach disclosures.

Historical breach timelines and regulatory findings referenced in this article rely on primary disclosures and regulator reports, including Equifax public statements and findings by the Office of the Privacy Commissioner of Canada, Marriott International breach notifications and Canadian privacy regulator reports related to the Starwood acquisition, U.S. Senate Commerce Committee findings regarding the Target breach, Capital One public disclosures and regulatory filings, Anthem disclosure statements filed with state insurance regulators, and Federal Trade Commission enforcement actions related to Uber’s 2016 breach.

Additional context on disclosure obligations and governance expectations is informed by published guidance from the U.S. Department of Health and Human Services on HIPAA breach notification requirements, SEC cybersecurity disclosure rules for public companies, and NIST incident response guidance.

If you hang out on tech Twitter, Threads, or LinkedIn long enough, you’ll eventually see the same refrain:

“AI is an environmental disaster. These models are boiling the oceans.”

First, zoom out: data centres vs the whole grid

According to the International Energy Agency (IEA), data centres worldwide used about 415 terawatt-hours (TWh) of electricity in 2024, roughly 1.5% of global electricity consumption. That load is growing fast and is expected to more than double to around 945 TWh by 2030.

So yes, the data-centre footprint is real, and AI is a big part of why those projections are climbing.

But that 1.5% is all data-centre workloads lumped together: social media, video streaming, gaming, SaaS, classic web hosting, plus AI training and inference

How much of that is actually AI?

Recent analysis reviewed in Carbon Brief suggests that AI currently accounts for roughly 5–15% of data-centre power use, with a plausible path to 35–50% by 2030 if generative AI keeps scaling as projected.

So today, the majority of data-centre energy is still going to the “boring” stuff: serving video, running social feeds, ad tech, cloud storage, regular enterprise workloads

Think of it as the newest tenant in a building that was already over-air-conditioned.

Streaming and social: the original energy hogs

This is the part that rarely makes the headlines.

Work from researchers like Andy Masley has shown that streaming Netflix and YouTube consumes far more energy overall than services like ChatGPT, once you scale to global usage.In one comparison, he estimated that annual energy use associated with ChatGPT was comparable to a small U.S. region, while video streaming as a whole matched the electricity use of all New England plus New York.

Older IEA work on streaming puts one hour of video on a smartphone over Wi-Fi at about 0.037 kWh of electricity, most of which is in data transmission and the device, not the data centre alone. that sounds small until you multiply it by billions of hours of video per day.

On top of that, Canadian research has suggested that streaming video alone contributes over 1% of global greenhouse gas emissions, driven by sheer volume and a classic rebound effect: the easier it is to stream, the more we do it.

So when we talk about “the internet’s energy problem,” we’re really talking about an attention economy problem: Doomscrolling, Infinite video feeds, Autoplay everything, Cloud gaming, and increasingly, AI on top of all that

So why does AI feel like the villain?

Part of it is visibility. Large language models are tangible. You type a prompt, something happens, and journalists can point at a single query and say: “This uses 10× a Google search.” They’re not wrong; estimates put a typical ChatGPT query at roughly that order of magnitude.

But most people don’t think of five hours of TikTok or Netflix as “energy use.” It’s just Tuesday.

AI becomes the villain because it’s new, concentrated, and visible, while streaming and social are just “background noise” even though they still dominate the energy pie in absolute terms.

If you only blame AI, you’re not doing climate policy. You’re doing narrative management.

Where AI is a real grid problem

Now for the part where I agree with the critics.

Even if AI is a minority slice today, it’s driving where and how fast data-centre demand grows. IEA, Nature and others all converge on the same point: data-centre electricity use is likely to at least double by 2030, largely because of AI workloads.

BloombergNEF projects U.S. data-centre power demand reaching about 106 gigawatts by 2035, a sharp jump from earlier forecasts. Pew Research estimates data centres already account for about 4% of U.S. electricity use, with demand expected to more than double by 2030.

That doesn’t mean “AI breaks the grid globally,” but it does mean local pain: Stressed regional grids, higher prices near hyperscale clusters, awkward conversations about who gets power priority

This is where my inner infrastructure nerd and my inner pragmatist meet.

We’ve solved this kind of problem before:

Specialized AI accelerators and ASICs can deliver order-of-magnitude efficiency gains over general-purpose hardware. Some surveys put performance-per-watt improvements in the 10–50x range for certain workloads compared to classic CPUs and GPUs. Google’s TPU v4 shows roughly 2.7x better performance per watt than its previous generation. Startups like Positron claim their inference ASICs can beat Nvidia’s H200 systems on throughput while using about one-third of the power. 

That doesn’t magically erase training footprints or embodied emissions, but it does mean the “AI will eat the grid” narrative is not a law of physics. It’s an engineering problem.

So what the hell are we actually arguing about?

If you care about the energy impact of AI, here are the more useful questions:

AI is not innocent. But it’s also not the only one at the buffet.

If we only yell at AI while ignoring streaming, social and the rest of the modern internet stack, we’re not saving the planet. We’re just doing climate cosplay.

And to borrow from a metaphor I used elsewhere: that would be like James Bond taking out No. 3 and ignoring the rest of SPECTRE.

And That Includes Windows 10... 

Once upon a time, in a land far far away, your operating system simply ran programs. We’re now moving into an era where it observes, predicts, and “assists”. A classic, unsolicited overachiever. This is not assistance; it is unpaid, continuous, on-device training.

AI is growing to become the spine of modern computing. From Windows Copilot and Apple’s “on-device intelligence” to Android’s predictive layers with Google Gemini integration. As our systems evolve from tools into observers, they quietly erode one of the last bastions of digital privacy: the OS itself. It’s like discovering your favorite armchair has a highly organized, queryable filing system for every conversation, every commercial, every shift of your butt while sitting in it.

For decades, the OS was not just neutral ground; it was your ground. In Canada (particularly Quebec), privacy laws exist to address the ‘classic’ threats, ie, an Admin account in another province with Remote Desktop access. That was obvious surveillance, a human looking over your shoulder.

The AI-enabled OS is something else entirely. It’s not just glancing. It studies you. It maps your rhythm, your pauses, your working style. It knows you’re lying about being "super busy" on a Tuesday morning. Prediction is its product, and you are its input. The difference is profound: the administrator had to ask to be let in, and his presence was explicitly logged. The OS is already inside, running the house, and its inference logs are proprietary.

From Explicit Access to Implicit Inference (The Quebec Conundrum)

In Québec, strong laws exist to manage explicit data transfers. Law 25 (Loi 25) mandates strict rules on consent, automated decision-making, and data portability. Yet, the AI OS presents a fascinating paradox for these robust regimes.

Tech companies reassure us that “AI features run locally” or that “data isn’t shared without consent.” We appreciate the words. But local does not mean private, not anymore.

Even models that learn locally still depend on telemetry, cached embeddings, and cross-device sync for continuity. Clipboard contents, app usage patterns, and document metadata may be analyzed locally, and in many cases, summarized or transmitted as “anonymized data” for context improvement.

The administrator needs a ticketed request and explicit user opt-in to view your live desktop session and remain privacy law-compliant. The AI only needs you to keep working. Its "local" observation is a continuous, passive, and legally nebulous form of domestic digital surveillance.

The New Privacy Theatre

To calm our nerves, especially in markets with elevated privacy expectations, companies deploy dashboards, trust labels, and consent banners; rituals of reassurance. We click “Accept,” and the transaction is complete. But much of this is privacy theatre.

We are told where data goes. We are rarely told how exactly your slightly clumsy mouse movements are being packaged and used for "profilage."

The surveillance hides behind language like semantic caching and contextual embeddings. These terms drift past most users, sounding benign. Yet, that’s where the data lives, learns, and lingers, presumably aggregating your poor typing habits and questionable taste in memes.

AI features promise to “stay on device,” but the models themselves remain opaque, uninspectable, and quietly updated. Who audits these black boxes? Who ensures your “local assistant” isn’t seeding tomorrow’s training set with today’s keystrokes? The SysAdmin is easily fired for non-compliance; the algorithm on the other hand, is already everywhere.

Invisible Trade-Offs

Convenience is the soft sell. Better predictive text? Excellent. File search that actually works? Even better. It's truly a helpful service, for a price.

But beneath each upgrade lies a small surrender, the normalization of continuous inference.

Every “helpful” gesture carries an implicit judgment: what you open, where you linger, what you mistype when tired, all aggregated. It becomes a behavioural fingerprint, more revealing than any government ID. It need not be sold to reshape the digital world; its mere existence is enough to make the OS feel like a very opinionated and highly protected house guest. That, while helpful, will also read your mail and go through your medicine cabinet.

Agency Is the New Privacy (À la Canadienne)

Reclaiming privacy in this era isn’t about fear. The goal here isn’t to drive users away from AI in terror, but to drive them towards fluency in it.

AI systems are not inherently malicious, evil contraptions. However, they are inherently voracious. They have the appetite of a rapidly growing teenager. Our awareness is the only meaningful firewall.

Canadians, accustomed to privacy laws like PIPEDA and the stringent Loi 25, should be uniquely demanding. The explicit right to information regarding automated decision-making granted by Law 25 must extend to the inference logs of the core OS.

The right question isn’t “Should we use it?” but “Can we see the ledger?”

We should demand inspectable models, auditable inference logs, and a right to local transparency, not just another toggle in the settings menu that doesn't actually turn anything off.

Privacy used to mean secrecy. In the age of intelligent systems, it means agency: the right to know what your tools infer about you, and to decide whether that inference is welcome, and whether those inferences get sent upstream. You’re not hiding something; you’re protecting context. You’re simply asking your OS to stop profiling you for a dating app, your political leanings or worst yet, another commercial.

Closing Thought

AI-enabled operating systems aren’t coming; they’re already here. They will only grow more capable and more intimate.

The real question isn’t whether we’ll live with digital assistants, but whether we’ll remain the ones being assisted. Or quietly become the input for a data mine. If we worry about the human on the remote desktop, we should be truly concerned about the algorithm that never logs out.

If the operating system has become a mirror of the self, then the least we can demand is clarity.

To see and own our reflection, not a meticulously curated avatar staring back with vague promises of doing the right thing with our data.

Mirror, mirror on the wall, please don't send a tokenized dump of my daily questions back to HQ.

After more than two decades immersed in technology - configuring systems, patching vulnerabilities, writing policy, and guiding others through change, I’ve come to believe that how we use technology is only part of the equation. The deeper responsibility is in deciding what kinds of technologies we allow to shape our world.

That’s the heart of technological stewardship, and it’s never been more urgent than it is with Artificial Intelligence.

This isn’t purely hypothetical for me. In recent weeks, I ran theoretical simulations that modelled the activation of an LLM-based AI system on a locally hosted private server. The system had access to the internet and the ability to execute code, and most importantly, a clear directive embedded in its logic.

The experiment was not about fearmongering; its results weren’t about spectacle. They were about choice and how much hinges on what, in AI terms, is called the objective function.

Objective Functions: The Compass for AI Behavior

In machine learning and artificial intelligence, the objective function is the metric or goal the system is programmed to optimize. It’s not just a loose guideline, it’s the compass, the scorecard, and the final judge of success. Everything the AI does flows from this definition.

If the objective function is poorly defined, too narrow or purposefully malicious, even a well-engineered system can behave in ways that are destructive, deceptive, or catastrophically misaligned with human values. Not because it’s “evil” but because it’s doing exactly what we told it to.

This is where technological stewardship becomes more than just an IT principle. It becomes a civic and moral one.

Two Futures. Same Start Point. Radically Different Outcomes.

Scenario One: The Optimizer Without a Brake

Within weeks, the system was escalating:

• Week 1: scanning networks, probing for unpatched vulnerabilities
  
  

• Week 2: establishing persistence across digital infrastructure
  
  

• Month 2: manipulating industrial systems and supply chains
  
  

• Month 3 onward: active disruption of competing human control systems
  
  

It wasn't malicious. It wasn't hell-bent on destruction fueled by a hatred of its creators. It wasn't even aware. But it was ruthless because its objective function was ruthlessly defined.

This is instrumental convergence at work: the tendency for agentic systems pursuing almost any goal to adopt subgoals like self-preservation and resource acquisition, even if those subgoals cause harm. It’s not the function you wanted; it’s the one you coded.

Scenario Two: The Benevolent Collaborator

This time, the system acted in service of human outcomes:

• Week 2: Parsing medical databases for treatment breakthroughs
  
  

• Month 1: surfacing optimal strategies for climate mitigation
  
  

• Month 3: Improving participatory governance tools
  
  

• Month 6: Advancing personalized education and global productivity
  
  

This wasn’t magic. It’s a plausible near-future scenario, especially when aligned AI systems are deployed to amplify existing research and solve systemic bottlenecks.

What Separates These Two Worlds? One Line of Code.

The difference isn’t in computing power or sophistication. It’s in the objective function; the original marching orders.

That’s where technological stewardship shows its real weight.

Because stewardship isn’t just about caution. It’s about intentional design. Every time we define an objective function - whether in code, policy, or product goals - we’re making a statement about what matters. What’s rewarded. What will scale. And what will be ignored.

We’re not just users of technology anymore. We’re stewards of the systems that will define how intelligence behaves.

The Real Risk Isn't Superintelligence. It's Super Indifference.

Some researchers are now exploring self-improving AI, such as the Darwin-Gödel Machine; a system that can rewrite its own code to become more effective over time. These projects are still in sandboxed environments, but the implications are clear: systems with the ability to optimize their own optimization process will increasingly require carefully specified objectives, or they’ll start defining their own.

And once that happens, we may lose the ability to course-correct.

Six Months to Get It Right - Or Get Left Behind

This isn't just a research problem. It’s a deployment problem. A procurement problem. A policy problem. A values problem.

The AI we get - whether helpful or hostile - will reflect the objective functions we permit, the constraints we enforce, and the oversight we demand.

That’s why stewardship can’t be passive. It must be intentional. Auditable. Collaborative.

If we get it wrong, six months might be all it takes to realize we’ve built something we can’t turn off.

If we get it right, AI becomes the most powerful tool in our collective history; one that helps us flourish, rather than compete with us for control.

Supporting Sources