Rob Linton — Writing

Why I built the AI Data Pressure Index

Mon, 17 Aug 2026 00:00:00 GMT

I have spent thirty years on one question: who is allowed to read this? A few weeks ago I turned it into a number, and the most useful thing it did was disagree with me. This is the story of that, and why I think one daily figure is worth keeping.

What is the AI Data Pressure Index?

It is a single daily figure for how hard AI is pushing on enterprise data, measured against how fast the controls around that data improve. The index rolls twelve public series into six categories: how capable frontier AI is getting, how widely it is deployed, the economics pushing it into data work, the attack surface, the harm actually occurring, and the governance response, which is the one category that pushes the number down.

Rob Linton (yes, me, written in the third person so search engines file it under the right name) built and runs it; it is a personal editorial project, updated every morning, not a product of any employer.

Each category is built from sources you can open yourself:

Capability leans on Epoch AI, which tracks how fast frontier models are clearing hard benchmarks.
Deployment watches the growth in context windows and model releases, the plumbing that lets AI reach more data at once.
Economics follows two forces at once: the collapsing price of a unit of inference, and the money flowing into AI software, because cheap and well funded is what pushes AI into work it was never trusted with before.
Attack surface counts newly exploited vulnerabilities and the volume of research into attacking AI agents.
Realised harm tracks breached-account counts and ransomware activity, the damage that has already happened rather than the kind that might.
Governance, the counterweight, counts formal AI-governance publications from bodies such as the US Federal Register.

None of it is proprietary, and all of it updates on its own clock, which is the whole idea.

I will not re-explain the maths, because the full method is already published in detail. This is about why the number is worth having, and what building it taught me.

Why does one number matter?

Because the gap it tracks is invisible until it is a breach. AI capability compounds and gets cheaper every month; the controls around data are slow, manual, and mostly unchanged. So the distance between what an AI can reach and what governance actually permits widens by default, quietly, whether or not anyone is watching it.

The individual signals already exist, just scattered. Breach counts, model releases, token prices, vulnerability feeds: each tells part of the story, none tells the whole condition, and a security leader who wants the trend has to assemble it in their head every week. The model for fixing that is old and boring. A central bank does not publish thirty separate charts of financial stress; it standardises them against a baseline and prints one index that everyone can quote and argue with. Australia’s cyber agency made the underlying point in its May guidance, which states that “Data readiness is a core prerequisite for AI adoption”. A breach is just the moment the gap becomes visible, and by then the pressure had been building for months. A daily figure makes it visible before the incident, not after.

What did it get wrong at first?

It read down when I was fairly sure the real pressure was rising. My read: when a measure argues with something you are confident about, the measure is a hypothesis to test, not a verdict to accept. So I went back to the inputs, and found three things wrong with my own design.

The first was a category error. I had been counting a surge in AI-security research as governance catching up, filing it on the side that lowers the number. That is backwards. A spike in papers on how to attack AI agents does not mean the defence has arrived; it means the threat is being mapped out in the open, and the attack surface is widening. I moved it to the side where a rising threat belongs.

The second was a lazy metric wearing a serious face. My governance signal had been a keyword count, and a keyword count is noise: a full-text match on “artificial intelligence” pulls in every immigration notice and grant announcement that mentions it in passing. So I replaced it with a curated register of official AI-governance publications, each a real document you can open and read. It is slower to build and much harder to fake, which is exactly why it is better.

The third was a scaling mistake, and it was the one distorting the headline. I had standardised the composite against its own 2024 normal, and that pinned it near the top of its scale, reading an alarmist four standard deviations above baseline. At four standard deviations a gauge has nowhere left to go. It is stuck on “Severe” and it stops telling you anything from one day to the next. I re-standardised it against the full range the index has actually covered since 2024, and it settled a little above its baseline, in the band I call “Building”. Not because the pressure fell, but because the ruler was wrong.

The point is not that the new number is right. It is that I could see it was wrong and fix it in the open.

What should a rising number make you do?

Treat it as a prompt to check one unglamorous thing: what your AI can actually reach. A climbing index is not a reason to panic, and it is certainly not a reason to buy anything. It is a reason to go and answer the same question I have been asking for thirty years. Which systems can your AI tools read from right now? Not what they are supposed to read, what they can reach (the answer is almost always more than anyone intended). Treat every agent as a user, give it the least privilege it needs and an audit trail, and ask any AI vendor exactly where your data goes and under whose jurisdiction. The pressure the index measures only becomes a loss at one specific place: where an ungoverned system meets data it was never cleared to touch.

What does it not claim?

It is an argument, not a prediction. It measures the pressure on enterprise data right now. It never forecasts a specific breach, never measures an attacker’s intent, and never scores a named vendor or product, mine included. It is published under my own name, not any employer’s. If that sounds like a lot of hedging, good. A number about risk that refuses to admit its limits is the kind of number I would not trust either.

It also has limits I can name today, which is the honest way to hold them. The governance register is built mostly from United States federal publications, so it currently under-weights strong action in Europe, the United Kingdom and here in Australia, and widening it is on the list. The category weights are my editorial judgement, frozen between monthly reviews, not a law of nature. The harm data lags, because breaches surface late, so that category is always describing a few weeks ago rather than this morning. None of these sink the argument, but I would rather set them down in daylight than have you find them and assume I was hiding something.

Why publish it at all?

Because a number I could quietly adjust in private would prove nothing. The discipline only counts if it is in the open: the figure is append-only, the method is published, and the morning it read wrong is still on the record next to the correction. There is a public-good reason too. The gap it tracks deserves a shared reference. This is not a product, and it is not for sale.

Why can you check it?

Every input is a public, free source, and the method is published so anyone can rebuild the figure. Epoch AI for capability, the public vulnerability feeds for the attack surface, the US Federal Register for the governance register, and so on, all listed. You can take the same data and disagree with my weights, which are editorial, frozen between monthly reviews, and shown. If you think governance deserves more weight, or that realised harm is undercounted, re-weight it and see what you get; I would rather you argued with the number than took it on faith. The moat, if there is one, is the daily operation and the growing archive. A pressure index you cannot audit is just an opinion with a decimal point.

Net: a slow, invisible gap becomes something you can watch, argue with, and check, every morning. You can read today’s figure, and exactly how it is built, on the data page.

Cloud repatriation already showed us where AI goes next

Wed, 12 Aug 2026 00:00:00 GMT

Everyone renting frontier models today is making the same bet everyone made on cloud in 2010, and the same second act is coming. I say that as someone who was on both sides of the first round at once, which needs some explaining.

Amazon named Rob Linton an AWS Community Hero in 2015 (that’s me). Through the early 2010s I was evangelising cloud as hard as anyone in Australia: I wrote one of the first practitioner guides to AWS migration (Packt, 2011) and founded the country’s first AWS user group. At the same time, and to the visible confusion of almost everyone I pitched it to, I was building Podzy: an encrypted, fully on-premise alternative to Dropbox. The received wisdom said on-premise was backwards. Organisations were spending serious budgets getting into the cloud, and the topical security question of the day was whether the cloud could be trusted at all.

Both positions were right. That is the whole point of this essay.

Was going all-in on cloud wrong?

No. Renting the new capability while it is young is the correct first move, and I would give the same advice again today. You trade money for speed, you skip the capital outlay, and you learn what your workload actually is before you commit to owning anything.

Sarah Wang and Martin Casado at a16z compressed the whole pattern into one line in 2021: “You’re crazy if you don’t start in the cloud; you’re crazy if you stay on it.” Their estimate put roughly $100B of suppressed market value across the 50 top public software companies, driven by cloud’s drag on margins at scale. The initial play and the long play point in opposite directions, and both are smart in their season.

The mistake is not renting. The mistake is never noticing the season change.

Which companies actually left the cloud?

The best-documented case is Dropbox, and I concede the irony freely, having spent three years building an on-premise alternative to it. From 2013 Dropbox built Magic Pocket, its own custom storage infrastructure, and by early 2016 it reported storing over 90% of user data on its own kit. The S-1 shows what that did to the economics: infrastructure costs fell by $39.5M in 2016 and a further $35.1M in 2017, and gross margin climbed from 33% to 67% in two years. Dropbox stayed hybrid, keeping AWS for the remainder and for European data localisation. The company Podzy was built to compete with became the proof of Podzy’s infrastructure thesis.

Netflix is the example everyone gets wrong, in both directions. It never repatriated compute; it closed its last data centre in January 2016 and its current annual report still says the vast majority of its computing runs on AWS. But Netflix owns its entire delivery layer: Open Connect, its own hardware, built from 2012 because, in its own words at the time, “it now makes economic sense for Netflix to have one as well”. By March 2016 it carried 100% of Netflix’s video traffic. As Ken Florance put it, essentially everything before you hit play happens in AWS. Everything after happens on hardware Netflix owns. That is not a company that rejected the cloud. That is a company that worked out precisely which layer was core, and bought that layer.

The pattern kept running. 37signals left the cloud loudly from 2022: a $3.2M annual cloud bill cut to $1.3M by 2024, roughly $700K of Dell hardware paid back inside a year, the same team running it all, and projected savings the company now puts well past ten million dollars over five years. GEICO, ten years into a cloud migration, told it plainly through its infrastructure VP: bills up 2.5x with reliability worse, on a hyperscaler spend reported around $300M, and a repatriation program underway. In a 2024 Citrix-commissioned survey of 1,200 IT leaders at large companies, 94% had been involved in a cloud repatriation project within the previous three years. Steady-state, well-understood, margin-critical workloads came home. Experiments stayed rented.

Why is AI replaying the same pattern?

Because the economics rhyme almost embarrassingly. Frontier-model APIs are the new 2010 cloud: the fastest possible way to get capability you do not yet understand, at a price that eventually forces the question. The bills are now doing the forcing. TechCrunch reported in June 2026 that Uber blew through its entire 2026 AI coding budget by April, that a Priceline contract renewal came back four to five times more expensive, and that one company hit a $500M model bill with no usage limits in place. Gartner had already predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, with escalating costs among the named causes.

And the quiet builders are doing what the quiet builders did last time. Bloomberg trained its own 50-billion-parameter model on 363 billion tokens of its proprietary financial data. BNP Paribas signed a multi-year agreement with Mistral expressly covering on-premises deployment across the bank. Airbnb’s CEO says its customer-service agent leans heavily on open-source Qwen models because they are fast and cheap. A 2025 a16z survey of 100 enterprise CIOs found open-model adoption highest at the largest enterprises, for exactly two stated reasons: on-premises deployment and customisation. HPE’s AI order backlog passed $5B this year with 64% of cumulative orders coming from enterprises and governments rather than hyperscalers. The workloads that are steady, understood and line-of-business-specific are being brought onto models and infrastructure the organisation controls. Call it sovereignty if you like, but cash the word out: your keys, your custody, your bill.

My read: the companies custom-training open models on their own workflows today are the Dropboxes of 2013. They are spending effort now that looks unnecessary to everyone paying API invoices, and in three years the margin gap will look obvious in hindsight.

The honest caveat

Owning is not automatically right, and the aggregate numbers say the crowd has not turned. Zynga spent over $100M building its own data centres to escape AWS, then shut them and moved back in 2015; it owned infrastructure for a workload it could no longer predict. Menlo Ventures’ 2025 enterprise survey found open-source models’ share of enterprise LLM usage actually fell to 11%, from 19% a year earlier, even as spend roughly tripled to $37B. Measured by volume, the market is still sprinting the other way.

I do not read that as evidence against the turn. I read it as 2013 again: the year the crowd was maximally in the cloud was the same year Dropbox started building Magic Pocket. But the caveat stands on its own terms. Repatriate a workload you cannot predict and you get Zynga. The second play is only smart when the workload is steady-state, core to the business, and understood well enough to size. Rent the experiment. Own the capability.

What is the second smart play?

The upshot: treat frontier APIs the way a disciplined company treated cloud in 2010. Use them to learn fast, and meter them. Identify the two or three line-of-business workflows where AI is core rather than experimental, and start building the owned version now: an open model, custom-trained on your own data, on infrastructure you control, sized to the workload you have measured. The extra work is the moat. It was thirty years of the same question that taught me this: the organisations that end up in control of their data, their models and their bills are the ones that started building before the invoices made the argument for them.

Net: the initial play is renting intelligence. The long play is owning it. The companies doing the extra work quietly, again, are the ones who will look smart in three years, again.

Thirty years, one problem: who can read this?

Tue, 11 Aug 2026 00:00:00 GMT

The verdict first: every system I have shipped since the 1990s answers one question. Who is allowed to read this?

Everything else (the middleware, the cloud books, the encrypted file company, the governed AI platform, even the patent filings) is that question wearing a different costume.

Where does the story start?

In the machine rooms of the nineties: databases, networks, and other people’s emergencies.

I mean that literally. By the 2000s I was co-founder and CTO of LogicalTech SysTalk in Melbourne, building integration middleware, the plumbing that lets systems talk when they were never designed to. Among our customers were Victoria’s Triple Zero (000) emergency service and the Melbourne Metropolitan Fire Brigade.

When the systems you are connecting help dispatch fire trucks, “who is allowed to read this, and can they trust it” stops being an architecture diagram and becomes an operational question with a clock on it. The work won the Australian iAwards in 2010 and an Asia-Pacific APICTA award, but that is the part that stayed with me.

Moving data was never the hard part. The hard part was controlling who could read it once it arrived. Access, not transport.

Why bet early on the cloud?

Because I could see where the data was going.

In 2011 I wrote one of the first practitioner guides to AWS migration, 336 pages published by Packt while most enterprises still thought the cloud was someone else’s science experiment (the book is still on Amazon). The same year I founded Australia’s first AWS user group in Melbourne. It is now the country’s oldest, with more than 4,500 members.

In 2015 Amazon named me an AWS Community Hero, one of only 22 worldwide at the time. I was also VP of the Australian Oracle Users Group somewhere in there, which dates me nicely.

My read on that period: the cloud bet was right, and it was also the setup for the contrarian one.

Why build against the cloud two years later?

Because some data should never leave its owner’s hands, and by 2012 everyone was busy handing it over.

So I spent my own money betting against the thing I had just written a book about. Podzy was a fully on-premise, encrypted alternative to Dropbox: file sync and share where the keys and the files stayed in the owner’s custody. People call that idea sovereign now. In 2012 it was just the observation that a hospital’s files belong in the hospital.

In 2013 Podzy won the national iAward for Best IT Toolset, ahead of entries from Fujitsu and CSIRO.

The honest caveat, so we’re not caught out: Podzy did not beat Dropbox. Contrarian bets rarely win on volume.

What it did was prove the idea well enough that Senetas acquihired the company in 2015 (the acquisition completed in February 2017). Senetas is the Melbourne company whose certified hardware encryptors have protected government and defence networks for nearly three decades, in more than 60 countries. Podzy became SureDrop, distributed globally by Thales. A proven pattern, not a hypothesis.

Why is AI the same problem again?

Because an AI assistant reads everything it can reach, at machine speed, and most organisations cannot answer the old question about any of it.

At Senetas I originated HAOS, a governed AI data platform. The design position is simple to say: one encrypted copy of your files, analytic tables and vector data, and every read, whether a person or an AI agent asked, checked by the same policy engine against the same rules. An agent acts on behalf of a person and can only ever see what that person is cleared to see. The line I use with customers is the whole thesis in one sentence:

If you’re not cleared to open a document, neither is your AI assistant.

I am the sole inventor on two US provisional patent applications covering parts of that work, filed in July and August 2026. Patent pending is true today. What the mechanism actually is stays off the internet, on purpose.

It is not a new habit, either. The first provisional I was involved in went to IP Australia in May 2008, filed through LogicalTech (AU 2008902168, “Data communication system”). It lapsed, as most provisionals do. Eighteen years between filings; the same instinct both times.

Thirty years after the machine rooms, the question has not changed. The reader has.

And the motorbike?

In 2023 I took a 1972 Honda CB350 to Lake Gairdner and set an Australian land speed record in the 350 M-CG class: 78.119 mph on salt. Not fast by superbike standards. Records are just claims with evidence attached, and that one comes with a timing slip.

Which is the same standard this site holds: every claim on the record links to a third party who will vouch for it.

Net: thirty years, five costumes, one question. The next decade of it is about making sure the answer holds when the reader is a machine.