![\"The](\"https:\/\/solutionsreview.com\/cloud-platforms\/files\/2025\/04\/The-Great-Data-Escape-AI-Local-First-and-the-Cloud-Exodus-768x384.jpg\")
<\/p>\n<\/p>\n
Brian Pontarelli, CEO of FusionAuth<\/a>, provides in-depth commentary on AI agents, local-first computing, repatriation, and more. This article originally appeared in Insight Jam<\/a>, an enterprise IT community that enables human conversation on AI.<\/span><\/strong><\/em><\/p>\n As companies have increasingly moved to the cloud, they\u2019ve handed over vast amounts of critical data to Software as a Service (SaaS) and cloud providers, often without an easy way to get it back. It is surprisingly hard to quantify the value of this data\u2014and how this data is used\u2014to any given organization. But to understand the importance of data to organizations, all we need to do is understand where the data is going, who owns it, and how this is changing.<\/p>\n Today, three trends threaten the cloud’s data moat, which has quickly built up over the last decade: AI agents, local-first computing, and repatriation. Companies are realizing that to innovate, cut costs, and ensure compliance, they need to regain control of their data.<\/p>\n The emergence of SaaS solutions has been great for collaboration and convenience but terrible for data ownership. You can use a loyalty program with an airline to build points and get perks, but try to get the data of your travels out of their system to do something different with it on your end? Good luck.<\/p>\n The same applies to technical teams building using SaaS tools to get their jobs done. You can outsource to a SaaS-only provider for authentication to log users into your app, so you don\u2019t have to build authentication yourself. That\u2019s great, but getting your data back is not always so easy. The Thales group estimates<\/a> that 60 percent of corporate data is stored in the cloud, up 100 percent from 2015. But once it\u2019s there, can you get it back?<\/p>\n There\u2019s some nuance here. It depends on which kind of \u2018cloud\u2019 we are talking about. In the Infrastructure as a Service (IaaS) model, your data is stored in the cloud, and you have a dedicated instance or otherwise \u2018own\u2019 that data; it\u2019s yours. Getting your data back is less of a problem here (though it is still a problem; see the section on repatriation).<\/p>\n Once we start getting into the Platform as a Service (PaaS) model and pureplay SaaS, things get a little more tricky. You could get your data back, maybe, or you could get the metrics and logs from whatever application you\u2019ve built on OpenShift. But you\u2019ve lost control over the way \u2018health\u2019 is measured for your application, or you are dependent on third-party tools for that data. At the end of the day, you are dependent on the tool you have chosen and how they have decided to prioritize data ownership.<\/p>\n SaaS is the extreme situation where you put the data in, and the cloud keeps it, either because of internal rules (like Cognito\u2019s lack of password hashing export) or data gravity (where you simply have too much data to move effectively). Yes, you can generally export your data from a SaaS solution \u2026 but can you? Maybe you can get your data from your Identity and Access Management (IAM) tool, but most certainly not from the hyperscalers. When was the last time you were able to export all the emails you\u2019ve ever written from Gmail? It\u2019s not easy.<\/p>\n With ChatGPT, it was always a huge drawback to give away search and conversation data to OpenAI\u2019s servers in exchange for computing power and convenience. One of the biggest areas of growth and promise in AI is the AI agent, which is a far cry from the original ChatGPT SaaS model.<\/p>\n The value of the AI agent is predicated on direct access to data. For many AI agents, the learning and the data are local, focused on solving a local problem, like, for example, tuning solar panels and wind turbines to maximize efficiency, reducing equipment failures and leaks in chemical processing, or managing robots in an assembly line to optimize for quality. And when the agent works locally, there are no worries about where the data text you\u2019re putting into the LLM is going.<\/p>\n ChatGPT is not an AI agent because it is reactive by definition, responding to user questions and requests based on patterns learned from massive datasets\u2014always only in response to user input (versus learning on its own). And there is that small detail that it can only interact with you while you\u2019re plugged into a WiFi connection and in the app.<\/p>\n With an AI agent, complex problems specific to the situation can be solved, such as allowing a robotic hand to learn different tricks and motions on its own, or in the case of the chatbot, an agentic AI chatbot could fill in any information gaps to respond to the task after assessing how its own tools and resources align to the need. Have you ever wished you could give ChatGPT access to your personal files and ask it a question about your taxes, your travel schedule, or even anything else that you asked previously, and have you come up with an informed response? A local AI agent, theoretically, could help with these challenges.<\/p>\n But where does the AI processing power come from for an AI agent? Doesn\u2019t that require the cloud? The recent launch of DeepSeek from China and Llama, Meta\u2019s LLM, demonstrate how easily AI can be downloaded and used exclusively on your local machine.<\/p>\n Imagine an AI tool designed to organize your emails automatically with smart labels and filters. If your emails live on Gmail or another SaaS platform, that AI tool must rely on integrations provided by the cloud service, limiting its functionality. If the data was local, though, the AI agent would access your email without the layer and burden in between or any of the coaxing of the bigger cloud operators.<\/p>\n To\u00a0be valuable, AI agents must have access to your specific data, whether it lives locally or in the cloud. This is why some agentic AI start-ups, like\u00a0Vella<\/a><\/span>, are also pushing for a local-first world.<\/p>\n Local-first is retro. Twenty years ago, Excel was downloaded onto your laptop. You used it without a network connection, and that was that. The local-first movement aims to recapture that level of control while preserving real-time collaboration. With local-first applications, you use a sync system in place of a backend, and your application code reads and writes data to and from your local database. The app works and can be updated offline.<\/p>\n Local-first gives you the performance, privacy, and ownership benefits of a local app, along with the collaboration benefits of a SaaS app. For example, GitHub would be deemed truly local-first if it could operate on images and things apart from just code and if it had a real-time sync capability.<\/p>\n For local-first to work, there has to be a way to sync up data between local applications once they\u2019ve connected again to a network. Academia has come up with, and continues to improve on, technology that can do just this, called Conflict-free Replicated Data Types, or (CRDTs).<\/p>\n It is telling that many of the apps used by engineers to develop software still revolve around a primary copy of the software on your local filesystem that\u2019s not subordinate to any remote server. Git is a common example, but there are also Integrated Developer Environments (like VSCode), build tools (like Jenkins.io), and runtime environments (like Jupyter). When your data is local, you can control it and work quicker without the risk of a sync issue across to a remote server.<\/p>\n In local-first applications, you own your data. With a SaaS app, when you need to export your data, you rely on the cloud service. Imagine you\u2019ve started a business, and you want to download all of your emails, sort them by various dates and subjects, and export them into a CRM system to understand who might be a potential customer from within your network. Doing that with today\u2019s email systems is nearly impossible because you don\u2019t own your data and are limited by the download functionality and rules of the email provider.<\/p>\n Local-first applications are everything that SaaS applications are not, so long as the syncing issue can be resolved. For many, the reward is worth the work of resolving the outstanding technical challenges to making local-first a broader reality.<\/p>\n Today, local-first development ranges from a set of real-world implementations that act on certain objects to a set of pure-play prototypes.<\/p>\n Linear<\/a> is a tool for feature updates and planning. The founders made a name for themselves by building a real-time sync engine that allows you to handle persistent data, offline changes, and queuing, in-flight changes. It doesn\u2019t use a lot of resources because the data is local. Only data changes require network requests.<\/p>\n GitHub allows developers to manage their code, requests to change the code, and updates to the code. GitHub is built on git, and the git functionality is truly local first. However, key functionality, such as pull requests, is not available without a network connection.<\/p>\n Developer-focused authentication tools you can download, like\u00a0FusionAuth<\/a>, can support local development and local testing, even though in production, the authentication process requires network calls to the authentication server to be useful for users. If you had a local webapp not hosted on the internet, you could use an authentication server like FusionAuth.<\/p>\n Ink&Switch, an independent research lab, has built multiple prototypes of local-first apps, from collaborative drawing to project management boards.\u00a0Each prototype<\/a><\/span>\u00a0<\/a>uses CRDTs and local-first development. They have found conflicting updates to be minimal, experienced great user experience and speed, and had success working with CRDTs.<\/p>\n So far, we\u2019ve seen AI agents and local-first attacking PaaS and SaaS\u2019s stranglehold on your data. But what about IaaS?<\/p>\n Even IaaS, which is the easiest to retrieve data from, is not safe from the move to gain more data control. In 2020, only 43 percent of CIOs planned to repatriate some of their cloud workloads to on-premises. That number jumped to 83 percent in 2024, according to the Barclays CIO Survey.<\/p>\n At first glance, it might appear that the concern around having data locally is a side-effect rather than the primary reason, which has more to do with the impact of cloud costs on overall margins. Andreessen Horowitz famously stated, \u201cYou\u2019re crazy if you don\u2019t start in the cloud; you\u2019re crazy if you stay on it,\u201d when they published an\u00a0estimate<\/a> in 2022 about the cost savings that could result from full repatriation, using public data to infer the resulting change in share price in the 50 top public software companies. Their estimate totaled $100B of market value lost in reduced margins because of a reliance on cloud infrastructure.<\/p>\n![\"\"](\"https:\/\/solutionsreview.com\/cloud-platforms\/files\/2025\/04\/Insight-Jam-Logo-2025-Square.png\"){kind=logo}
<\/a>Data is at the heart of a business\u2019s ability to drive value, meet regulatory requirements, control spending, operate efficiently, and do just about anything else it needs to grow revenue and serve customers. Yet, despite its importance, businesses are losing control of this critical asset.<\/p>\nThe Data Moat of the Cloud<\/strong><\/h3>\n
AI Agents Encroach on SaaS and PaaS<\/strong><\/h3>\n
AI Agents Lead Into Local-First<\/strong><\/h3>\n
The Local-First Movement Wants its Data Back<\/strong><\/h3>\n
How Far Are We On Making Local-First a Reality?<\/strong><\/h3>\n
\u2018Almost\u2019 there: Linear\u2019s sync engine<\/strong><\/h4>\n
Github: very close<\/strong><\/h4>\n
Authentication for devs: still needs the network<\/strong><\/h4>\n
Prototypes<\/strong><\/h4>\n
Repatriation – Going After IaaS<\/strong><\/h3>\n