Blog

Own your data, own your AI

The philosophical arguments for data ownership are compelling, but at some point the question becomes architectural: what does it actually mean, in practice, to own your data in a world where AI is processing it?

This post is about the practical version. How bring-your-own-storage works, why model choice matters, what open protocols change about the relationship between your knowledge and your tools, and why the architecture of your system determines who benefits from the intelligence it produces.

The history of not owning your data

The pattern of losing control over your own information has repeated so consistently that it's worth recounting briefly, because the AI version of it is playing out right now and the moves are identical.

AOL's walled garden in the 1990s kept users inside a proprietary ecosystem where their content, contacts, and customisation were locked to the platform. When the open web made AOL irrelevant, users who'd spent years building up their online presence within AOL's walls discovered that none of it was portable. The content stayed behind.

The MySpace-to-Facebook migration in the late 2000s saw millions of users lose years of posts, photos, and social connections because the data lived in MySpace's systems and couldn't be transferred. The cost of switching platforms was the loss of everything you'd built.

Google Reader's shutdown in 2013 eliminated the central hub of many people's information workflow overnight. Evernote's slow decline left millions of notes in a proprietary format that other tools struggled to import cleanly. Photobucket held users' images hostage behind a sudden paywall. Sunrise Calendar, Wunderlist, Inbox by Gmail, Google+: each one took accumulated user data with it when it closed.

The consistent lesson is that data stored in a platform you don't control is data that exists at the platform's discretion. The terms can change, the business model can shift, the company can be acquired by someone with different priorities, or the product can simply shut down. In every case, the user's accumulated knowledge, content, and context becomes a casualty of someone else's business decision.

The AI version of this pattern is the same dynamic at higher stakes. The data you accumulate in an AI provider's system isn't just content, it's context: the accumulated understanding of your work, your thinking patterns, your analytical frameworks, your research trajectory. Losing access to that context, or discovering that it's been used to train a model that competes with you, is a loss that's harder to quantify but potentially more consequential than losing a folder of photos.

What ownership actually looks like

Owning your data in the AI era requires three things working together: storage you control, models you choose, and protocols that enforce boundaries.

Storage you control

The most fundamental layer is physical: where do the bits actually live? In the traditional SaaS model, your data lives on the provider's servers, in the provider's database, managed by the provider's infrastructure team. You have access to it through the provider's interface, and you can usually export a copy, but the canonical version lives in their systems.

Bring-your-own-storage inverts this. Your data lives in a cloud storage account that you own: an Amazon S3 bucket, a Cloudflare R2 account, or similar. The application reads from and writes to your storage, but the data itself sits in infrastructure under your control, encrypted with your keys, governed by your policies.

This is a meaningful architectural difference rather than a marketing distinction. If you stop using the application, the data remains in your storage exactly as it was. If the application company is acquired, changes its terms, or shuts down, your data is unaffected. The application is a lens through which you view and interact with your knowledge; the knowledge itself lives somewhere the application can't take it from you.

Models you choose

The second layer is computational: which AI processes your data, and on whose terms?

When you use a proprietary model through an API, your data flows to the model provider's servers, is processed there, and the results flow back. The provider's terms of service govern what happens to your data during and after processing. Some providers commit to not training on your data. Others don't, or have terms ambiguous enough to leave the question open.

Open source models change this equation. A model that runs on your own infrastructure, or on a hosting provider you've chosen specifically for the purpose, processes your data without it ever reaching the model developer. There's no API call to a frontier lab, no terms of service governing what happens to your input, no ambiguity about whether your data contributes to the next training run.

The performance question, whether open source models are good enough, is increasingly settled. Nvidia's Nemotron models, Meta's Llama family, and several others are competitive with frontier models for the vast majority of real-world tasks. The model that was state-of-the-art two years ago was already sufficient for 90% of professional use cases; the barrier was cost, and the cost of running open source models on reasonable hardware has fallen dramatically.

The ability to choose your model also means you can use different models for different purposes. Open source for sensitive work where the data shouldn't leave your infrastructure. A frontier model for general queries where the data isn't proprietary. The choice is contextual rather than all-or-nothing, and the important thing is that it's your choice rather than the provider's default.

Protocols that enforce boundaries

The third layer is interoperability: how does your knowledge connect to the tools and agents you use, without being absorbed by them?

MCP (Model Context Protocol) is an open protocol that lets AI agents read from your knowledge library on your terms. The agent can search your notes, access your documents, and use your context to produce better answers, but the interaction is governed by the protocol rather than by the agent's own terms of service. Your library serves as the memory layer for any compatible agent, and you can switch agents without losing context because the context lives in your library, not in the agent's conversation history.

This is architecturally similar to what the API provides at a more technical level: programmatic access to your knowledge on your terms, allowing you to build integrations, connect to workflows, and use your data across tools while maintaining control over where it lives and how it's accessed.

The combination of these three layers, owned storage, chosen models, and boundary-enforcing protocols, creates an architecture where you get the full benefit of AI-powered knowledge work while retaining genuine ownership of the knowledge itself.

What this means for teams

The argument scales directly from individuals to teams and organisations.

A team's accumulated knowledge is typically more valuable than any individual member's, because it includes institutional memory, client relationships, project histories, and the collective understanding that makes a team effective. When that knowledge lives in a provider's systems, the team's most valuable asset is held by a third party.

Team workspaces with bring-your-own-storage mean the team's knowledge lives in the organisation's own infrastructure. When a team member leaves, the knowledge stays. When a tool is replaced, the data persists. When the organisation's needs change, the knowledge moves with it.

For organisations in regulated industries, lawyers, financial services, healthcare, the data sovereignty question isn't just strategic but legal. Client data processed by AI needs to stay within defined boundaries, and the ability to demonstrate exactly where data lives and which models have processed it is becoming a compliance requirement rather than a nice-to-have.

The cost of waiting

Data ownership has a timing dimension that mirrors the context compounding argument from a previous post.

Every day you spend building context in a system you don't control is a day of accumulated knowledge that lives on someone else's terms. Every day you spend building context in a system you do control is a day of accumulated knowledge that compounds in your favour, portable, searchable, and independent of any individual provider.

The people and teams who move to an ownership architecture now won't just have more control in six months. They'll have six months of compounded context in infrastructure they own, which is a qualitatively different position from starting the migration when the need becomes urgent, typically because something has gone wrong with their current provider.

The best time to take ownership of your data was before you started using AI. The second best time is now.

Frequently asked questions

Is bring-your-own-storage complicated to set up? Setting up an S3 bucket or R2 account takes minutes. Connecting it to your knowledge system is typically a configuration step rather than a technical project. The complexity is comparable to connecting a cloud drive, and once configured, the system works transparently: you interact with your knowledge through the application exactly as before, but the data lives in your infrastructure.

What if I want to use a frontier model for some things? Model choice means exactly that: choice. Use open source models for sensitive work where data sovereignty matters most. Use frontier models for general-purpose queries where the data isn't proprietary. The architecture supports both, and the decision is per-task rather than per-system.

Does this work for regulated industries? Bring-your-own-storage is particularly valuable in regulated contexts because it gives you auditability and control. You can demonstrate exactly where data lives, which models have processed it, and what boundaries are enforced. For law firms, financial services, and healthcare organisations, this can simplify compliance significantly compared to relying on a provider's general-purpose data handling policies.

What about the cost? Cloud storage costs are minimal for most knowledge management use cases, typically a few dollars per month for individual users and modest amounts for teams. The cost of running open source models is falling rapidly. In most cases, the total cost of an owned-infrastructure approach is comparable to or less than the subscription cost of a provider-hosted alternative.