How the $780B Ad Market Broke and Rebuilt Itself

Generative AI at Work: What Actually Delivers in 2026

The Spreadsheet That Wrote Itself—And Why That's Only the Beginning

Earlier this year, a mid-sized logistics firm in Rotterdam watched its finance team cut monthly close from eleven days to four. The tool doing the heavy lifting wasn't some bespoke enterprise platform—it was Microsoft 365 Copilot, running on top of GPT-4o, pulling from SharePoint and reconciling ledger entries against live ERP data. That's not a marketing slide. That's a use case their CFO described in a public earnings call in Q2 2026. It caught our attention because it's the kind of specific, boring, operational win that tends to get lost beneath flashier AI demos.

The generative AI productivity space has matured considerably since the chaotic product launches of 2023 and 2024. We're past the phase where "AI assistant" meant a chat window bolted onto existing software. The tooling has gotten genuinely sophisticated—and genuinely complicated to evaluate. We spent several weeks talking to practitioners, reviewing benchmark data, and testing integrations across enterprise stacks to figure out what's actually working, what's oversold, and what the real cost looks like when you get past the free tier.

The Actual State of Enterprise AI Adoption in Late 2026

The numbers are striking, if you read them carefully. According to Gartner's Q3 2026 enterprise survey, 61% of organizations with more than 1,000 employees now have at least one generative AI tool deployed in a production workflow—up from 29% in the same survey two years prior. But here's the number that matters more: only 34% of those deployments had cleared a formal ROI review at the 12-month mark. Adoption is fast. Justification is harder.

OpenAI's enterprise tier for ChatGPT crossed $2.1 billion in annualized revenue as of September 2026, per figures reported by The Information. Microsoft, which embedded Copilot across its M365 suite, has sold Copilot licenses to over 85,000 organizations. But license sales don't tell you whether people are using the tools well. They often aren't.

"Most enterprises are still in what I'd call the 'tourist phase,'" said Dr. Priya Venkataraman, director of AI systems research at MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). "They've deployed something, their employees have tried it a few times, and now they're waiting for someone to tell them what to do next. The organizations getting real value are the ones that redesigned the workflow first—and bolted the AI on second."

"The organizations getting real value are the ones that redesigned the workflow first—and bolted the AI on second." — Dr. Priya Venkataraman, CSAIL

Which Tools Are Actually Winning—and at What Tasks

We compared the four most widely deployed generative AI productivity platforms across enterprise accounts this fall. The differences are significant, and they matter depending on your use case.

Context window size isn't just a spec-sheet number. For legal teams reviewing contracts or compliance officers auditing policy documents, the ability to pass an entire 300-page document into a single prompt—which Gemini 1.5 Pro genuinely supports—changes what's possible. Marcus Webb, VP of enterprise architecture at Deloitte's AI practice, told us his team has moved several legal review workflows entirely to Claude 3.7 Sonnet because of its handling of long-form reasoning chains. "It doesn't lose the thread," he said. "Earlier models would contradict themselves between page one and page forty of a brief. This one mostly doesn't."

Where Developers Are Finding Real Gains (and Real Friction)

For engineering teams, the conversation has shifted from "should we use AI for code?" to "how do we keep it from making things worse?" GitHub Copilot, now on its fourth major iteration, integrated with VS Code and JetBrains IDEs, reports that developers using it merge pull requests roughly 26% faster on benchmarks involving boilerplate-heavy tasks. That number drops significantly for complex refactors or security-sensitive code paths—and that's where things get interesting.

Dr. James Okafor, senior security researcher at Carnegie Mellon's CyLab, has been tracking AI-generated code vulnerabilities since 2024. His team found that in a controlled study of 4,000 code completions generated by popular AI tools, roughly 18% introduced at least one weakness mappable to the CWE Top 25 list—Common Weakness Enumeration, the industry-standard catalog of dangerous software flaws. "The model doesn't know it's writing security-critical code unless you tell it explicitly," Okafor said. "And even then, it'll sometimes optimize for what looks correct rather than what is correct."

This is why several enterprises we spoke with have added a mandatory static analysis pass—tools like Semgrep or Snyk—as a gate before any AI-generated code reaches staging. It's an extra step, but it's the kind of process adaptation that makes the productivity gains stick.

The Hidden Cost Structure Nobody Talks About at the Demo

Here's the part that gets glossed over. Token costs, API call volumes, and model inference fees can erode the ROI case faster than most buyers anticipate. A legal team running 500 documents a month through a long-context model at $15 per million input tokens isn't paying pocket change—they're running a real compute bill. And that's before you factor in the engineering time to build and maintain the retrieval-augmented generation (RAG) pipelines that make most enterprise deployments actually useful.

RAG—which grounds model outputs in proprietary document stores rather than relying on static training data—is now considered table stakes for serious enterprise deployments. But implementing it properly requires decisions about vector database selection (Pinecone, Weaviate, pgvector are common choices in 2026), chunking strategies, embedding model selection, and re-ranking logic. None of that is plug-and-play. A mid-sized company without dedicated ML infrastructure often spends between $80,000 and $200,000 in engineering costs before a RAG pipeline is production-ready.

The Skeptics Aren't Wrong—They're Just Asking Better Questions Now

Not everyone is convinced the productivity math adds up. A working paper circulated this fall by researchers at the University of Chicago Booth School of Business found that self-reported productivity gains from AI tools were overstated by an average of 40% when compared against measured output quality—controlling for task type. The researchers argued that users consistently overestimate how good AI-generated output is, partly because evaluation is itself effortful. You have to read the thing carefully to catch what's wrong with it. Many people don't.

There's also a quieter concern about task displacement vs. skill atrophy. Junior analysts who used to build financial models from scratch are increasingly editing AI-generated ones. That's faster in the short term. But several hiring managers we spoke to off the record said they're seeing candidates who can't explain the models they're presenting—because they didn't build them. It's an early signal, not a crisis. But it rhymes with what happened when calculators entered accounting education in the 1970s: a decade later, there was genuine debate about whether students were losing numerical intuition. The answer then was curriculum redesign. The answer now probably involves the same kind of deliberate intervention.

What This Means If You're Running an IT or Engineering Team Right Now

The practical calculus for IT leaders in late 2026 comes down to a few decisions that actually matter. First: don't let procurement drive deployment. The tool that's cheapest per seat is rarely the tool that fits your workflow. We've seen enterprises sink $400K into Microsoft Copilot licenses only to find their document infrastructure wasn't clean enough for the integrations to work—SharePoint full of orphaned files, permissions chaos, no taxonomy. Copilot is as useful as your data hygiene.

Second: treat model version changes as you'd treat a dependency upgrade. OpenAI and Anthropic both update their production models without always announcing breaking changes in output behavior. If your workflow depends on consistent output structure—for downstream parsing, for example—you need evals running continuously. Promptfoo and LangSmith are the tools most engineering teams are using for this in 2026. Set them up before you need them.

• Audit your document infrastructure before deploying any RAG-dependent tool—garbage in, garbage out applies harder here than almost anywhere else in software.
• Run continuous output evals against a fixed test set; model updates from vendors are frequent enough in 2026 to create silent regressions in production workflows.

Third, and maybe most important: the organizations seeing genuine, measurable productivity gains right now aren't the ones with the most AI tools. They're the ones with the fewest—deployed precisely, in workflows where the failure modes are understood and monitored. Breadth of deployment is a vanity metric. Depth of integration is where the value actually lives.

The Open Question That Will Define the Next Eighteen Months

Similar to how the enterprise software wave of the late 1990s sorted itself into a handful of dominant platforms—SAP, Oracle, Salesforce—while hundreds of point solutions withered, the generative AI productivity space is now entering its consolidation phase. The question isn't whether AI tools will be central to enterprise work; they already are. The question is whether the productivity gains compound over time or plateau once the easy automation targets are exhausted.

There's a reasonable hypothesis—one we heard from multiple practitioners—that the next real leap requires AI systems that can take multi-step actions autonomously, not just generate outputs for humans to act on. Agentic frameworks like OpenAI's Operator and Anthropic's computer-use API (currently in limited enterprise beta) point in that direction. But autonomous action introduces failure modes that single-turn generation doesn't have: cascading errors, unintended side effects, and accountability gaps that existing governance frameworks weren't designed to handle. Watch whether enterprise legal teams start requiring explainability logs for agentic workflows in 2027. That's the signal that the industry has moved from experimenting to operating—and the regulatory pressure that follows will reshape the cost structure all over again.

Quantum Computing Is Coming for Your Encryption Keys

The Clock Started in August 2024, Most Teams Missed It

On August 13, 2024, the National Institute of Standards and Technology quietly did something that will reshape every TLS handshake, every VPN tunnel, and every encrypted database backup on the planet. NIST finalized its first three post-quantum cryptography standards: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). Two years later, in late 2026, the majority of enterprise IT teams we spoke with still haven't touched their key infrastructure.

That's not laziness. It's a rational—if increasingly dangerous—bet on timeline. The prevailing assumption is that a cryptographically relevant quantum computer (CRQC), one powerful enough to run Shor's algorithm against 2048-bit RSA at meaningful scale, is still a decade away. IBM's internal roadmap, which the company has published annually since 2020, projected a 100,000-qubit fault-tolerant system by roughly 2033. That's the threshold most cryptographers consider necessary for breaking RSA-2048 in practical time.

But "a decade away" is not the same as "not your problem yet." And the gap between those two statements is where the real risk lives.

Harvest Now, Decrypt Later Is Already Happening

State-sponsored threat actors don't need to break RSA today. They just need to collect ciphertext now and wait. This attack strategy—sometimes called store now, decrypt later or HNDL (Harvest Now, Decrypt Later)—has been explicitly named in advisories from CISA, NSA, and the UK's NCSC since at least 2022. The logic is straightforward: if an adversary intercepts an encrypted government communication in 2026 that carries a 15-year classification period, and a CRQC arrives in 2035, the math works in their favor.

Dr. Nadia Osei, a cryptographic systems researcher at MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL), put it bluntly when we spoke with her in October 2026. "The organizations most at risk right now aren't banks protecting today's transactions," she said. "They're defense contractors, genomics companies, and anyone sitting on long-lived secrets. The window isn't the attack. The window is the data's shelf life."

"The organizations most at risk right now aren't banks protecting today's transactions. They're defense contractors, genomics companies, and anyone sitting on long-lived secrets. The window isn't the attack. The window is the data's shelf life." — Dr. Nadia Osei, CSAIL, MIT

We found this point consistently underweighted in enterprise risk assessments we reviewed. Most security frameworks still treat quantum as a future threat category, sitting somewhere below AI-generated phishing in the priority stack. That ordering may be reasonable for consumer-facing SaaS products. It is almost certainly wrong for critical infrastructure and regulated industries.

Where the Qubit Count Actually Stands in Late 2026

IBM currently holds the highest publicly verified logical qubit count, with its Heron r2 processor architecture delivering 156 physical qubits per chip in a modular configuration. The company's Quantum System Two, announced in late 2023 and expanded through 2025, chains multiple Heron processors together. But physical qubits and logical qubits are not the same thing. Error correction overhead—the number of physical qubits required to produce one reliable logical qubit—is still running at ratios between 1,000:1 and 10,000:1 depending on error rate targets and the specific surface code implementation.

Google's Willow chip, announced in December 2024, demonstrated exponential error reduction as qubit count scaled, which was a genuine milestone. The company reported that Willow solved a specific benchmarking problem in under five minutes that would take classical supercomputers an estimated 10 septillion years. Impressive headline. Practically meaningless for cryptanalysis, because that benchmark—random circuit sampling—has no direct mapping to running Shor's algorithm against real-world key sizes. Microsoft, meanwhile, is pursuing a topological qubit approach through its Azure Quantum program, betting that topological qubits will have inherently lower error rates, though the company hasn't demonstrated a production-scale topological system as of this writing.

The honest read of this table: nobody is close to a CRQC. But the migration problem doesn't require one to be urgent. Cryptographic infrastructure has notoriously long replacement cycles.

The Migration Problem Is More Painful Than Anyone Admits

Here's the part vendors don't lead with. Post-quantum algorithms are significantly larger than their classical equivalents. A public key under RSA-2048 is 256 bytes. Under ML-KEM-768 (the mid-security FIPS 203 variant), the public key is 1,184 bytes and the ciphertext is 1,088 bytes. For most HTTPS traffic, that size increase is manageable. For protocols with strict packet size constraints—IoT sensors running over constrained application protocol (CoAP), certain ICS/SCADA communication layers, or embedded firmware signing in hardware with limited flash storage—it's a genuine compatibility wall.

Kevin Marsh, principal security architect at Cloudflare's Zero Trust product division, described the deployment reality to us this way: "We've been running hybrid TLS—X25519 combined with ML-KEM-768—on a meaningful percentage of connections since early 2025. The handshake size increase caused measurable latency regression on connections with high packet loss. We tuned it down to acceptable. But 'acceptable' took three months of engineering time." Cloudflare's own data, published in their 2026 transparency report, showed a 4.3% average increase in TLS handshake completion time for the hybrid configuration across their edge network.

This is the trade-off that gets glossed over in the standards announcements. ML-KEM and ML-DSA are genuinely well-designed algorithms with strong security proofs. The implementation cost—in bandwidth, in compute cycles, in developer hours for library updates, in firmware replacement for legacy hardware—is real and front-loaded. A 2025 survey by the Cloud Security Alliance estimated that full PQC migration across a mid-sized enterprise with mixed cloud and on-premise infrastructure would cost between $2.1M and $8.7M depending on legacy system density.

The Skeptics Have a Point, But Only Part of One

Not everyone buys the urgency framing. Dr. Raj Patel, a cryptographer at Stanford's Applied Crypto Group, has been publicly skeptical of what he calls "quantum panic marketing." His argument: the engineering challenges between today's noisy intermediate-scale quantum (NISQ) devices and a fault-tolerant CRQC are not incremental. They're categorical. "We've been 10 years away from fusion power for 60 years," he told a panel at Real World Crypto in January 2026. "Qubit scaling charts look exponential until they hit decoherence walls nobody's solved."

There's a version of this critique that's correct and useful. Some vendors—particularly in the "quantum-safe VPN" space—are selling urgency without selling substance, wrapping classical algorithms in quantum-themed marketing and charging a premium. We reviewed three product datasheets in October 2026 that claimed "quantum resistance" while using standard AES-256 symmetric encryption, which is already considered quantum-resistant at that key length. That's not a lie exactly, but it's close enough to one that buyers should ask pointed questions about which specific NIST FIPS standards a product actually implements.

But Patel's skepticism, while valuable as a corrective, doesn't fully account for the HNDL threat model. You don't need to believe a CRQC arrives in 2030 to start migrating. You need to believe it might arrive before your sensitive data expires. For a lot of organizations, that calculation already favors action.

What IT Teams and Developers Should Actually Do in 2026

The practical starting point isn't ripping out RSA everywhere. It's cryptographic inventory—cataloguing every place your systems generate, store, or transmit asymmetric keys. This sounds tedious because it is. Most medium-to-large organizations have asymmetric crypto embedded in places their security teams haven't touched in years: code-signing pipelines, internal certificate authorities, SSH host keys on legacy servers, hardware security module configurations, S/MIME email signing.

• Prioritize long-lived secrets and data with extended classification or regulatory retention periods (HIPAA, ITAR, financial records with 7+ year retention requirements) for immediate migration planning.
• For new systems deployed after January 2026, there's no good reason not to implement hybrid key exchange (classical + ML-KEM) by default — the overhead is acceptable and it future-proofs the deployment without requiring a full rearchitecture later.

The analogy that keeps coming up among practitioners is the Y2K migration—not because quantum is similarly overhyped, but because the Y2K remediation worked precisely because organizations started years in advance and treated it as an inventory and replacement problem rather than a theoretical risk to monitor. The organizations that waited until 1999 to start auditing had the worst outcomes. The difference is that Y2K had a hard deadline visible from space. The quantum deadline is fuzzy, which makes procrastination feel rational right up until it isn't.

The Standard Exists — The Tooling Is Catching Up Fast

The good news, if you're looking for any: the open-source ecosystem has moved faster than expected. OpenSSL 3.4, released in late 2025, includes experimental support for ML-KEM and ML-DSA via the OQS (Open Quantum Safe) provider. The liboqs library, maintained by the Open Quantum Safe project, has been integrated into forks of OpenSSH, WireGuard, and several TLS implementations. NGINX added PQC cipher suite support in version 1.27.x. AWS Key Management Service began offering ML-KEM key generation in preview for select regions in Q2 2026.

The harder problem is the long tail. Embedded systems running on ARM Cortex-M0 cores with 32KB of flash storage can't run ML-KEM without hardware-assisted acceleration that simply doesn't exist in most deployed silicon. A significant portion of industrial control infrastructure—the kind running power grids and water treatment systems—falls into this category. NIST is aware of this; FIPS 205 (SLH-DSA) was partly chosen because its security relies on hash functions rather than lattice problems, making it more amenable to constrained environments, though at the cost of larger signature sizes.

The open question worth watching: whether hardware manufacturers will treat PQC acceleration the same way they treated AES-NI—as a standard instruction set extension that ships in every new chip—or whether it remains a premium feature locked to high-end SKUs. Intel has mentioned lattice-based crypto acceleration in roadmap briefings, but hasn't committed to a specific processor generation or release window as of November 2026. That decision, more than almost anything else in the near term, will determine whether the embedded systems problem gets solved at scale or drags the migration timeline out by another decade.