Most people worry that AI gets things wrong. The harder problem is that it now gets things right, using data you forgot it had.
On 28 October 2026, Chrome started reading your Gmail — not summarising it, but extracting flight confirmations, order numbers, membership IDs, tracking numbers, addresses, phone numbers and credit card numbers from your inbox, and offering them as autofill values on whatever form you happen to be on. It is opt-in, it lives in Chrome settings, and Google says sensitive data is encrypted. All of that is true and none of it is the interesting part. The interesting part is that the feature works because the model got good enough to know which email contains your passport number.
How to read this, and what it is not. This is written by the team that builds a private AI workspace, so treat it as an argument with an interest, not as a survey. Three things keep it checkable: every claim about a Google, Anthropic or industry announcement links to a dated source you can open; the limitations are stated in the section headed what this does not solve, including one design problem we have not solved; and where a number comes from our own documentation and cannot be verified from outside, we say so.
01What a private AI workspace is, and what it isn't
A private AI workspace is a place where AI agents do your work while the material they touch — your files, your price sheet, your client contracts, your inbox — stays somewhere you control, and where the actions that require a human decision are stopped by the system rather than requested by a prompt. It does not answer you; it hands back an artifact, and records what it did and what it refused.
Three terms get used interchangeably and are worth separating. Local describes where the model runs. Self-hosted describes whether the thing can be installed in your own environment. Data sovereignty describes who can reach the material and under whose rules — and with a loose enough connector list you can satisfy the first two and still leak on the third. The real dividing line: the boundary lives in the infrastructure, not in the paragraph at the top of your chat window.
Worth noting the inverse of this argument: putting the whole stack — model, skills and connectors — behind one vendor is itself an exposure. On Single-vendor AI dependency, and on what the word "sovereignty" actually buys and does not buy, we go deeper in a separate piece.
02Four things happened in eight days, and they point the same way
None of these were secret. All four were announced publicly, inside the same week, and each one on its own reads like ordinary product news.
Businesses can build apps that surface directly inside Search and Gemini, connecting through cloud-hosted MCP servers or Android's MCP AppFunctions. 50+ apps already integrated, including Adobe, Experian, Peloton and Calm.
Same company, same day, opposite direction: not pushing services into the assistant, but pulling your inbox into the form.
Name, logo, GitHub organisation and domain handed to a Linux Foundation entity. Published only in Dec 2025, already adopted by 70+ platforms, ~1M skills and ~280M installs.
Shows enterprises what each workflow cost, what it produced and where it broke down. Announced days after the S-1 filing on 26 October.
Read them as one line: capability is being given away while the boundary quietly thickens. The dates are public fact; the grouping is the author's.
Put the four in one frame and the shape is obvious. Connectors are becoming a standard. Skills are becoming a standard. The protocol layer is becoming a standard. And the billing layer is becoming a service you buy from the model vendor, priced per workflow.
Put another way: capability is becoming public infrastructure. The premium you used to pay for "the smartest agent" is being standardised, donated and given away by the organisations with the most to gain from making it a commodity. Your competitor will have your skills, your connectors and your model within a quarter or two — because everyone shipping this week explicitly intends that.
If capability is no longer the moat, what is? Only the things that do not improve when the model does.
Each announcement checked against the three things that were supposed to be yours. Capability and surface both moved; the boundary column went untouched across all four — which is precisely what is left.
03Three things intelligence doesn't improve
1. Where the data physically is
A smarter model reaches further. That is what "better" means — a model that can find a passport number in your inbox is more useful than one that cannot, and it is also the model that has already touched your passport number. Capability and reach are the same variable. You cannot buy more of the first and less of the second, which is why "we made it smarter" and "it now reads your email" show up in the same changelog.
Location is different. Where the data sits is a property of the deployment, and it does not move when the model gets better or worse. That is why it still belongs on a procurement checklist after everything above it has been commoditised. What changed recently is that the location can now be a machine in your office — or the computer already on your desk — rather than a rack. That changes who can afford it.
For readers operating under a data-residency regime, there is another layer. Where data sits is not a technical preference but a compliance position — how cross-border transfer is assessed, which certification applies, whether a regulator sets a hard retention period. These are written into policy, not into preference. Which means "private" is often not "I would feel better" but "I am required to."
| Where the AI runs | What it can reach | Available today? |
|---|---|---|
| Vendor cloud | Everything you upload or authorise | Yes |
| A device in your own office | Local files, your LAN, your knowledge base | Yes — hardware is sold |
| The computer you already have | Local files, the browser, logged-in sessions | Supported (macOS / Windows / Linux / mobile) |
The three modes are not one product at three prices. They are three different ceilings, and the ceiling is set by what can be reached — not by how good the model is.
The column that matters is the second one, and it is the one most people skip. A cloud deployment sees what you uploaded. The machine on your desk sees your files, your browser and your logged-in sessions — which is precisely where, as Chrome just demonstrated, the useful data actually lives.
There is an uncomfortable corollary. The configuration that makes an agent most useful is also the one that gives it the most room to get things wrong. How much it can reach and how much it can break are the same number. The next two sections are not optional extras — they are the cost of choosing the third row.
2. Who approved what
On 8 October 2026, Anthropic updated its usage policy. Most of the update concerns influence operations and election content, but one line deserves wider attention: AI connected to physical equipment requires a qualified operator able to observe that equipment and stop it when needed, and the equipment itself must be able to hold a safe state. Effective 12 November 2026.
Read it as a leading indicator. "A human can see it and a human can stop it" is moving from a feature you admire to a condition you are expected to meet. Which raises an awkward question: can you stop it? Not whether you told it not to — whether you can stop it. This is why the most important tier in a permission model is not "ask me first" but "the capability does not exist."
Our own permission model has three tiers, all enforced at the system layer: do it (read, compute, draft, produce), ask first (send outward, publish, change the calendar, record a transaction — an approval card is generated and nothing runs until you tap it), and never (spend, order, pay, sign, commit on your behalf). The third tier is not a prompt-level prohibition; the capability does not exist in the system. Our piece on 19 AI Coworkers, Ready on Day One lists all nineteen avatars and which tier each falls into.
Grouped from each avatar's published "what it won't do" clause. The clauses are verbatim; the four buckets are the author's classification and overlap by design.
The distinction is not wordplay. A guardrail the model reads is a property of the model you happen to be running this month — and you will change models. Everyone does, often, because the capability layer is exactly the layer being commoditised and therefore moving fastest. A guardrail written into a permission table is a property of your deployment, and it survives the swap.
This is what the Connected Apps announcement quietly changed. When third-party services pour into your assistant through a standard connector, what your agent can reach grows with the number of vendors you have authorised — and not one of those vendors' permission prompts is written in the language of your boundary. The question shifts from "is this connector safe" to "what happens when the connector is fine and the agent uses it in a way I did not anticipate."
3. Whether you can prove what happened
This is the gap the Smart Reports announcement throws into relief. A billing report answers what a workflow cost and roughly what it produced. That is genuinely new and genuinely useful — CFOs were guessing before. But there is a second question it cannot answer, and it is the one that matters when something goes wrong: what did the system do, to which thing, under whose authority.
These are two different ledgers. One is denominated in money, the other in actions. A $4,000 monthly total tells you nothing about whether the agent read the payroll sheet or merely opened it.
Precision matters here, because "there is a log" and "it can serve as evidence" are different claims. The documentation promises who, when and what was decided, covering the four classes of action that cross the boundary: send, publish, spend, delete. It does not promise a full reconstruction of every read. If you are evaluating this for a regulated process, that scope is worth pinning down in writing: which actions are logged, with what fields, retained how long, exportable to what format. The same standard applies to us.
04What this does not solve
Written as a list, because the most valuable part of a piece like this is where it stops.
Removes one class of exposure — someone else's policy change, outage or acquisition becoming your problem. It does nothing about an agent competently executing against a rule you wrote badly.
A human tapping a card is a human deciding. If the card is unreadable or forty arrive a day, you have added a step and removed nothing — while manufacturing a consent record that does not hold.
Knowing precisely what happened is a different thing from whether it was a good idea. A record is for the post-mortem; it does not stop the incident.
None of the three makes capability private. The model is still someone else's, the skills were just donated to a foundation, and the connectors are already a standard. What you are choosing is where the work runs and who authorises it — not whose intelligence you are using. Anyone claiming otherwise is selling you the wrong layer.
The spread comes from routing and caching strategy, not from whether the model is smarter. The point of the axis: what you save picking a model does not cover one thing done wrong.
The risk that remains after all three layers is specific and worth naming: a well-specified task, correctly executed, against a permission rule you wrote too broadly. No product in this category fixes that. It is a scoping problem, and it is yours.
05One failure, walked through all three layers
Abstract risk is easy to nod along to and hard to act on, so here is a concrete one. A sales avatar is asked to quote a coffee subscription for a 30-person office. The price sheet is connected; usage data arrives as a spreadsheet. The avatar computes, drafts a quote with terms, and sends it to the customer's procurement contact. That chain breaks in at least four distinct places, and the three layers above fix exactly one of them.
| Where it breaks | Why the layers miss it |
|---|---|
| The price sheet is stale — edited in March, the avatar read the February version. | The data is yours and correctly located, and the content is wrong. Ownership helps with none of it. |
| The usage input had a column shift — row 14's headcount landed in the cups-per-person column. | The arithmetic is flawless against garbage. Nothing unauthorised happened: the read, the computation and the draft were all permitted. |
| The quote implied a commitment — terms and a validity date went into a customer-bound document. | This is the one place the tier model earns its keep: it should have produced an approval card. If it didn't, your rule was too narrow — the product offered three tiers and you wrote two. |
| Nobody could reconstruct it later — two weeks on, the customer disputes the cups-per-person figure. | The log says the sheet was read at 14:02 and the quote drafted at 14:11. It does not say row 14 was shifted, because the shift was in the input, not the action. What you needed was a snapshot of the artifact at read time — a different guarantee from an action log. |
Four failures, three layers, one caught. That ratio is the honest state of this category in October 2026.
06Who this is for, concretely
One hairline per playbook. The more procedure is written down, the more likely someone has already thought through the boundary for you — and the more you need to check whether they thought it through correctly.
Small teams whose output goes to someone else — quotes, contracts, reconciliations, decks, copy that ships. In those workflows "where did this number come from" has an answer, and sooner or later somebody asks. Organisations with a retention requirement already written into policy are now the easiest case: a requirement written against hardware you already own can be satisfied on the computer already on your desk. And anyone who has watched an agent come close to touching something expensive — if you know that specific discomfort, the tier you are buying is "never," and the rest is secondary.
Not for: exploratory thinking, where a gate between you and the answer is pure friction and a chat window is cheaper. Not for anyone who needs it right the first time — that is not on offer. And not for anyone shopping for an install-and-you're-safe switch. None of the three deployment modes sells that; safety is a function of how precisely you wrote the boundary.
Procedural depth is unevenly distributed. The chart also illustrates the design problem from the previous section: the thinner the written procedure, the more it falls to you to specify the boundary.
07The part I think is still wrong
One more thing, since a piece that only argues for its own conclusion isn't worth your time. Every claim above depends on your being able to specify your own envelope — what counts as inside, what needs approval, what is forbidden. That is a real skill, and it is not evenly distributed.
Most people, handed a three-tier permission system, write the same rule the first time: something like "anything client-facing needs approval." That is not machine-evaluable. Nearly everything is client-facing, so nearly everything queues — and a queue you read daily stops being a control and becomes a second job.
The system will enforce what you wrote. It cannot enforce what you meant, and it will not tell you your rule was too broad. A permission model whose quality is a function of the user's ability to write policy is a permission model with a hidden prerequisite — we have not solved how to surface that, and we have not seen anyone in this category solve it either. It is the thing we most want to fix, and it is less a feature request than a design problem the whole category is avoiding.
08What to ask before you decide anything
None of the four below is about benchmarks, because benchmarks are the part being given away this week. We are writing them out as they stand, including for anyone evaluating us — if we cannot answer one of them, that is information you should have too.
Which actions are logged, with what fields, retained how long, exportable to what format? Ask for a sample record, not a description.
Which tiers are enforced server-side? Ask to see the enforcement rather than the setting — a settings page is a promise, an architecture description is a claim you can test.
When the underlying model changes, what re-runs and what tells you behaviour didn't regress? A product with a regression suite is in a different category from one without, because a suite implies a definition of correct behaviour.
On the machine you already own, what does the system refuse to do — and is that refusal enforced by the system or requested by the prompt? "There is a setting for that" is a different answer from "the capability does not exist."
09Questions people actually ask
Is "private AI" the same as "local AI"?
No, and the difference is the useful part. Local describes where the model runs. Private describes who can reach the material, which is a property of both the model's location and the connectors you have authorised. You can run a model locally and still leak everything through a cloud connector; you can run in a vendor cloud with a narrow connector list and expose less.
So what should I actually look at for AI data privacy?
Three things you can put in a contract: which storage in which jurisdiction the data lands on; which actions leave the machine and through which connectors; and what record those actions leave, for how long, exportable or not. All three can be accepted or rejected on inspection. "We take your data security seriously" cannot.
Doesn't standardising everything make this easier?
It makes capability easier and the boundary harder. When skills are donated to a foundation and connectors become a protocol, the number of things your agent can touch grows without anyone updating your permission list. Standards are good for capability and neutral-to-negative for scoping.
Can I meet a data-residency requirement today?
Yes, in all three deployment modes: a vendor cloud, a device you own, or the computer already on your desk. The third is the one that changes what teams can commit to, because a requirement written against hardware you already own needs no purchase order.
Does keeping data on your own hardware make the AI correct?
No. It removes a class of exposure to someone else's decisions. It does nothing about an agent doing the wrong thing competently against a rule you wrote badly. Those are separate failures and only one of them is bought with hardware.
What is the audit log actually for?
Answering "what did it do, to which thing, under whose authority" after the fact, for actions touching send, publish, spend or delete. It is not a prevention mechanism and it is not a billing report — a monthly cost total tells you what you spent, not what was touched.
10The short version
Capability is being standardised in public, this week, by the companies with the most to gain from making it a commodity. That is good news, and it removes your differentiator at the same time.
What remains is unglamorous: where the data sits, who has to click, and whether you can reconstruct afterwards what was done. None of those get better when the model gets better. All three get worse if you don't specify them.
So the useful question isn't which assistant is smartest. It's this: when the agent you're about to trust does something you didn't anticipate, which of those three would have caught it — and do you have it?