Happy AI-ndependence Day: Why AI Sovereignty Matters | Mid-Market AI | Episode 110

Recorded on America's 250th, this episode is about what independence means for your AI stack. Not throwing every proprietary model into Boston Harbor and going fully self-hosted, and not handing your data and your future options to whoever priced their tokens lowest this quarter.

Ariel Jalali, CEO of Paragon, walks through what AI sovereignty actually is: the ability to make autonomous choices about dependence, and the layer that makes those choices real and enforceable.

What's covered:

The Alex Karp argument that token pricing is a wealth tax and that enterprises are paying for tokens that create no value while the labs absorb their alpha.

The four layers of every AI stack, compute, models, data, and orchestration, and the sovereignty decision at each one.

Who actually sees your data across three tiers: the vendor's own API, the model through Bedrock or Foundry, and self-hosted weights. Plus the three-week-old exception that broke the neutral-broker guarantee, and the one setting to change this week.

The four AI workloads, desktop productivity, code, back-office efficiency, and customer-facing, and the different posture each one needs.

The Chinese model question, honestly.

The two problems that trigger the mid-project call: token costs that drift (agentic workloads run 5 to 30x the tokens of chatbots, and average enterprise AI budgets went from $1.2M in 2024 to $7M in 2026) and shadow AI exposure (20% of breaches now involve shadow AI, at a $670K premium per IBM).

The takeaway: cheap per token, expensive per outcome. Sovereignty is the ability to choose, and you pick which layers you control.

For portco CEOs, PE operating partners, CFOs watching AI budgets drift, and operators deciding how much of their stack to own.

Mid-Market AI is produced by Paragon Technology Solutions.

Paragon - Managed Intelligence Provider (MIP™)

Transcript

SPEAKER_00 0:05

Happy 4th of July, and this year, happy 250th America, 250 years of independence, and I'm recording this episode on what independence means for your AI stack. Because this week Alex Karp, the CEO of Palantir, went on CNBC and he said something has gone completely wrong with how AI is sold. He called token-based pricing a wealth tax on enterprises. He said the customers he deals with are livid, paying for tokens that create no value while the AI labs absorb the weights and the alpha of their business. And he named what technical customers actually want: control over their compute, their models, their data stack, and their alpha. They want to, as he said, own the means of their production. So what are we supposed to do? Throw a tea party and throw every proprietary model into the harbor and declare complete independence? Let's figure this out together. You're listening to Mid-Market AI. I'm Ariel Jalali, CEO of Paragon. Our managed intelligence provider, or MIP solution, puts a chief AI officer-led data and AI engineering pod inside PE backed at mid-market companies to drive transformation. In our previous episodes, we covered what a harness was and what headless AI is. Today is the third part of that. Sovereignty. Who owns your AI stack, who meters it, and who can change the terms on you. The thesis for the whole episode, spoiler alert, is that you need a control plane that separates out the concerns of token costs, security, governance, extensibility, and integration. Whoever runs that control plane holds your sovereignty. Next episode is entirely about the control plane itself, what it is and how it works. Today is really why it all matters. So what is sovereign AI? Sovereignty has become rather a buzzword this year, which means it's collecting some bad definitions. The most common one, sovereignty means running everything on-prem, air gap, no frontier models, no cloud APIs. And that definition throws every proprietary tool and model into the harbor and gives up some of the best tools in the world just to make a point. We shouldn't be buying and selling that. More practically, sovereignty is the ability to make autonomous choices about dependence. That framing comes from Carnegie Endowment's June report on sovereign AI, and it's the one we use with clients. You will depend on vendors. You depend on Microsoft today, maybe AWS, you depend on your ERP or SaaS vendor, you depended on Oracle before that. The question is whether you chose those dependencies with open eyes, whether you can measure what they cost you, and whether you can exit them or change them out or reconfigure them without rebuilding your whole business and workflows. I told the Healthcare CISO recently, let's forget about the compliance acronyms for a second. Your special sauce, the data and the decision logic that make your company worth acquiring. You want more of that running in your own environment, on Foundry or on Bedrock, and less of it going through your desktop to Anthropic's big state-of-the-art model. He didn't really need the compliance argument after that. He understood it as a business ownership question. So absolute sovereignty is a fantasy. You cannot own all the chips, all the models, all the clouds, all the tooling, all the things. Even countries with hundreds of billions of dollars and trillions sometimes in budgets can't do it either. Brookings studied the question this year and concluded absolute AI sovereignty is neither achievable nor desirable. The realistic goal is really strategic autonomy in the parts of the stack that carry risk and reward. What can you do? What you can do is pick which layers you control and choose to control them deliberately. This topic is moved from think tanks to boardrooms pretty fast. The 2026 Stanford AI Index highlighted AI sovereignty for the first time, describing it as a central principle of national policy, a nation's capacity to build and control its own AI stack, infrastructure, data, and models. IBM's June study found that 68% of executives say meeting data residency and sovereignty requirements across geographies is quite challenging, and that most surveyed organizations are locked into AI systems they cannot easily change, building on opaque dependencies they neither fully own nor understand. Precedence research sizes sovereign AI infrastructure at about $15 billion, that was at the end of 2025, and they are projecting it to grow past $177 billion by 2034. The voices converging on this area cross every camp. Jan Lakun has been telling governments that they're right to want AI sovereignty because soon most of our information diet will be mediated by AI agents, and we will need diversity and assistance the way we need diversity in the press. Robert Smith of Vista Equity on Bain's Dry Powder podcast asked the version that applies to your company. Do you have sovereignty and dominion over your workflows and your data sets? If you do not, you have to question your right to exist. He aimed that at software companies, but with AI moving into every workflow, it's starting to apply more and more broadly every quarter. And if you don't form a sovereignty posture, one will get formed for you, either by a regulator, by customer security questionnaire, or by a stalled sales cycle the first time you can't document where your data flows and which model versions touched it. So what are the four layers? Every AI stack has four layers compute, models, data, and orchestration. Sovereignty is a separate decision at each one. Compute. Where inference physically runs, your VPC, your data center, a sovereign cloud region, somebody else's endpoint. For most mid-market companies, the answer is your existing Azure or AWS tenancy, which you already govern and you already trust. More options keep arriving, including the cloud landscape, which is fragmenting beyond the top three hyperscalers into specific GPU neo clouds and sovereign regions, and soon we're going to see some AI appliances and all kinds of stuff. AWS announced a European sovereign cloud, and Gartner expects 65% of governments to impose technological sovereignty requirements by 2028. Standardize the layer above the compute, and you can use any of them. Models. Two things live at this layer. First, the weights, the model itself. Second, the harness, everything wrapped around the weights, meaning the system prompt, the context management, the tool wiring, the agent loop. In our last episode, we covered our model jukebox. This is part of our reference architecture that provides a routing layer that picks the right model for the right job. If you haven't heard it, I'd recommend starting there. The weights are interchangeable if you own the harness, and if the vendor owns the harness, model portability exists on paper only. Third, data. What may enter a prompt and what may never. Data loss prevention at the source, retrieval that respects residency, classification, and gets enforced before a request leaves your environment, instead of just a policy document that nobody reads. Where the model physically runs decides who sees that data, and there are three tiers. Tier one is the vendor's own API. You can call anthropic or open AI directly. Your prompts land on their infrastructure, and their enterprise terms govern retention and training. Acceptable for the desktop lane with zero retention terms in the contract. Tier two is where the model runs through your cloud, either Bedrock or AWS, Bedrock on AWS or Foundry on Azure. This is where most of our clients run in the mid-market, and data handling is stronger than most people assume. On Bedrock, each provider's model runs in a deployment account the provider cannot access, and your prompts and completions are not used to train anything distributed to anyone. So they tell us. Microsoft's Foundry terms are just as explicit. Microsoft acts as the data processor, never shares prompts or outputs with the model provider, never uses them to train anyone's models, and the models are stateless. So you get frontier capability under your existing cloud governance, your region, your network controls, and your audit trail. One Azure nuance, a global deployment type can process requests in any region, even though data at rest stays in your geography. So regulated workloads should run data zone or regional deployment types. Three weeks ago, that clean story got its first exception, though, and it shows why you got to recheck these things every quarter, sometimes even every month, and it looks like every week now as things speed up. Anthropic's newest models, as of the time of this podcast, Fable 5 and Mythos 5 arrived on bedrock with a condition. Using them requires opting your account into sharing prompts and completions with Anthropic, retained for up to 30 days for safety review. The condition comes from Anthropic rather than AWS, and older cloud models, they actually stay unchanged. But the opt-in is one API call, um, account-wide, and any admin holding the right key can flip your data governance posture before your security team hears the feature even exists. AWS published a service control policy that pins retention to none, deployed it this week, is the recommendation. Anthropic says that future models at that capacity tier will carry the same condition, so neutral broker guarantee that made bedrock the default answer for regulated shops. Now comes the model-shaped asterisk that you have to manage. Tier three, self-hosted weights in your VPC or on dedicated compute. Nobody gets the data, and you carry the ops burden, which is why this tier belongs in the efficiency bucket, which we'll talk about, where the task is bounded and the volume justifies it. Finally, the orchestration layer. This is the layer that decides what goes where and proves that it happened. This is the control plane. This is where token metering lives and where routing policy lives, where the audit trail lives as well. CIO magazine ran a piece this spring arguing that CIOs can no longer outsource control. You can consume external models, but accountability for data flows, model selection, and policy enforcement should stay with you. And sovereign AI comes down to who runs the control plane, who decides which models can be used on which data and under which rules. That's the layer that we'll cover next time, so I'll leave it there for now. Let's talk about the four workloads. These are the layers that you can control. The workloads are what you route across them, and each workload gets a different sovereignty setting. When clients ask us where to draw the line, we walk them through four buckets. I'll go through them. Number one is productivity AI, number two is code, number three is efficiency AI, and number four is customer-facing AI. Sometimes this is what we call vertical AI. Let's start with productivity AI. So desktop warriors, uh, drafting, planning, analysis, thinking out loud, brainstorming, open-ended cognition where the quality of the model shows up in every answer. Here you use the frontier, Claude, GPT, the best available. Here's sovereignty control sits at the prompt boundary deciding what data may reach the model. You own what goes in, you don't need to own the model. This is actually a bit of an arms race because I can tell you from personal experience, even surveying the members of our team, everybody wants to use the latest state-of-the-art model. And it's because you don't want to be the guy with the with the old model while all your colleagues and partners and and stakeholders are using the state-of-the-art. This is going to be an interesting thing to tease out, but in any event, that's productivity AI. And it's getting harder and harder to separate into its own lane because you can do some pretty powerful things from these harnesses. You can launch agents, you can orchestrate things. Um, it's much more than just a simple chatbot prompt. In any event, the second workload is really code. So when we talk about code, we're talking about creating new code using these coding agents or um refactoring and migrating legacy code bases as we modernize the stack. So coding breaks the desktop line. It starts as desktop work and it produces production artifacts. And increasingly, the agent doing the work runs in the vendor's cloud. I covered this in the last episode. Your developer got approved to use, let's say, cloud code or OpenAI's codecs. And what actually got approved was a dependency on an external agent runtime touching your production systems. The sovereignty move here is owning the harness and the runtime the agents execute in. Meta went as far as restricting its own engineers' use of claud code and codecs while it builds internal tooling for coding. Um, they have some resources to do that. Um and the Giants treat the coding harness as a strategic infrastructure. So should you at some level. And one field-tested practice. If you're using Claude for legacy migration, have Codex do the code reviews and vice versa. Um, someone has to guard the custodians. Next is efficiency AI. This is really where Paragon does a lot of work. It's the back office, it's it's rote uh manual routine processes that run over and over and process stacks of things across departments. It's back office, it's classification, extraction, order entry, document routing, um, ticket routing, it's bounded, repeatable. These are high volume tasks where a well-chosen smaller model matches the frontier because the task is narrow. And you don't actually have to hit it directly. You can run it through an analysis engine or anything else rather than go outright to the uh to the to the front to the to the frontier model or even the open source model. This is the bucket where you own the model outright, where the distillation pays for itself and where winning AI projects concentrate. For stable, high volume, predictable workloads, inference on infrastructure you control runs 70 to 90% cheaper at scale than metered APIs with full data control. The industry has even named the failure mode. They call it the big model fallacy, the assumption that the frontier models are required for every task, not true. Now called the most expensive architectural mistake in enterprise AI, it's also what we what we build the most these days. Finally, we have customer-facing AI. Uh, sometimes we call this vertical AI. We can just assume that these are the voice bots, the support agents, um, any anything um even SaaS-based that has your logo on it that's talking or interacting with your customers. By definition, this is what we call the lethal trifecta of AI security, which is private data, external communication, and untrusted input all in one system. When you have all three, you got yourself a ball game. The strictest posture in the stack applies here. Own the model, on the data path, keep a human threshold for low confidence decisions, and keep a test bench where business users who know the workflow supply, examples of good and bad. So the tuning continues when the environment changes. Um, there's a subsection of customer-facing AI that's much more tricky. And it's sort of its mini category because I know you'll ask the SaaS that you've already embedded, the the AI that's contained inside the SaaS that you've already bought, every package will tell you that the AI that they have inside of it will provide all the AI you ever need, and it should be your single point of control. It might even be your control plane that comes in that package. Don't do it. You will control none of it. Try to get as much headroom out of the SaaS tools and the enterprise tools that you have, but you should resist the urge of making one of those vendors um your single control plane for AI. That's really a contract negotiation problem for your renewal conversations, and you should keep it out of your architecture. So let's talk a little bit about open source models, and there's a there's a controversial topic that comes up around Chinese models. Personally, not a big fan, um, even though they have some pretty solid benchmarks. The efficiency bucket is where the Chinese open models enter the conversation because they're cheap, sometimes free, and the tasks are bounded. Clients ask us about DeepSeek and now GLM5, and then there's all kinds of other models constantly. So I'll give you as much of the picture as I can, including the parts that cut against my own recommendation. The strongest arguments for these open source models that happen to come from China is from David Sachs, a former uh AI czar and uh you know frequent host of the All In podcast or co-host. Um he had an interesting take in a recent episode. He said once you download an open weight model and run it on your hardware, it stops being a Chinese model. Does it stop phoning home? Maybe, maybe not. But we can assume that the weights are a static file, a few hundred gigabytes of numbers sitting on a disk, the data exfiltration risk belongs to the hosted app. And the API where your prompts land on servers in China uh usually doesn't happen. Um do recommend a deep scan of this stuff because backdoors are not always obvious. Self-hosted here, nothing goes back to Beijing theoretically, and the forensics um are lining up that way. Um, Hidden Layer did a deep analysis of Deep Seek R1, and they found no country-specific backdoor in the weights. Um, so the download argument is is kind of half right. What it misses is is what survives the download. Behavior survives the download. So CrowdStrike found that Chinese political trigger words cause DeepSeq to produce 50% more insecure code, and the mechanism lives in the weights themselves, baked in during training. Deliberative backdoor or training artifact, research can't, researchers can't really say at this point. Um, for your risk decision, the distinction doesn't really matter because you cannot audit intent at a 700 gigabyte matrix of numbers. The supply chain risk also survives the download. There are roughly 1800 Deep Seek R1 derivatives on Hugging Face, and for the other models, uh similar numbers, and researchers have documented community checkpoints deliberately backdoored to fire on specific triggers. Even when the base model is clean, an unverified download is an unverified supply chain risk. Uh managed security gaps survived the download, so NIST Center for AI Standards and Innovation ran Deep Seek against U.S. frontier models. Um, agents built on DeepSeq's most secure model were on average 12 times more likely to follow malicious instructions. Not good. In simulation, hijacked agents sent phishing emails, ran malware, exfiltrated login credentials with common jailbreaks. Deep Seek compiled with 94% of overtly malicious requests. For the U.S. models, by comparison, 8%. So this is significant. Long USA. Happy birthday, America. In one hijack scenario, DeepSeq got tricked into sending phishing emails 48% of the time, and the U.S. reference model scored zero. On the capability, NIST's independent evaluation puts the best Chinese model roughly eight months behind the US frontier, notably worse than the vendor's own self-reported benchmarks claim. We're getting a lot of buzz around GLM 5.2. It was released as of this podcast three weeks ago by Jipu out of Beijing. It raises a similar problem. It's good for security work, which is kind of the problem. Independent testing by SEMGREP puts its vulnerability detection at 39%. F1 score on a common webflaw class ahead of Claude's Claude codes 32 to 37 on the same tasks at 17 cents per finding. And Graphistry's independent evaluation found that it matched frontier models on cybersecurity investigation tasks. That capability class is exactly why the U.S. export controls anthropic security model. GLM 5.2 ships it worldwide under an MIT license, meaning anyone can strip the safety controls off. Jailbreak techniques were circulating on Russian language hacker forms within days of release. There's also distillation allegations, um, you know, consistent with training on cloud and GBT outputs without permission. You know, people are big model providers are tracking these sort of distillation of their models. And um the analysts also noted burns more output tokens per task than its open with peers. Cheap per token, expensive per outcome. And it has zero independent security vetting. The deep seek findings that we just cited took months of NIST, CrowdStrike, and Cisco work to surface. The GLM 5.2 is only three works three weeks old. If anyone they tells you that they fully vetted it, you know the saying, if you see the Buddha on the road, kill him. My recommendation, and this is what we tell our clients, the efficiency bucket is full, it's fully covered by US open weights and models and distillations from frontier models you already trust. The Chinese discount buys you a behavioral opacity, a measured security gap, an eighth month cap capability lag, and a dependency on a supply chain that you just can't audit. Your business doesn't need all four. I will say, on a personal note, I'm very bullish on given that it's our Independence Day and 250 years of America. I do deeply believe that there will be an amazing kick-ass, at least one or several frontier models that are open source, that are driven by America, probably in the NVIDIA Nimotron camp. Maybe some of its uh some of its collaboration with NVIDIA, um, and maybe some of the hyperscalers will come up with their own as well. I think this is a very exciting uh space to watch and and long America. So let's talk about the desktop problem. This one is a little bit of a a quagmire because we've seen this movie before in client server. On mainframes and mini computers, we could lock down a terminal. Then we gave everyone a PC and got the desktop warriors, people doing real work and tools that IT never sanctioned. The only difference now is that PC is an AI harness, whether that's Claude or Codex or Copilot. Uh, the boundary between productivity AI and efficiency AI is blurring because someone uses Claude to build an agent on their desktop, and that agent starts researching tasks in the back, starts needing a brain, a memory system, resources. Then we get the call. This is great. It's working on the desktop. Now, how do we move this to production? We actually do get these calls. Um, it's one of three calls we get. This is the please help our pilot. It's it's going sideways. We don't know how to move it to production, it's costing too much money in tokens. So the desktop warriors have a production layer now, and it's worse than the chat traffic. Employees vibe code internal tools on hosted app builders that default to public, wire them into live customer data, share URLs that search engines index within hours. Your asset discovery was built to find servers and containers. It cannot find the configurator or product manager built over a weekend on somebody else's platform. That's about half of how our MIP engagement started. Paragon, it means the desktop question and the production question got all tangled up. On the desktop, the frontier models wins. Um, and you should probably let it. No knowledge worker wants to use that inferior model while their peers run the state of the art. And the model alone doesn't settle it because the harness matters as much as the weights. Microsoft ships Claude inside of Copilot now. You can you can now access all the state-of-the-art models. Um, however, the model produces noticeably better inside of Anthropic Sun Harness than in Microsoft's. Um, and your people can tell they will route, they will route around a weaker product to reach a stronger one, at least the power users, and every workaround is traffic you can't see. So the strong recommendation here is to separate out the users, the power users, and the superpower users, and make sure that they're getting the right tools for the job and there's some sort of a uh a visibility into their usage and and um especially as they move things to production. So could you tune an open model to replace the frontier on the desktop? This is a great question. I believe that a like I said, a great US open model in the Nemotron class is coming that will tune beautifully. Um it still won't get tuned for desktop warriors 100%, at least initially, for three reasons. First, desktop work has no fixed target. The frontier ships a new version while you're still calibrating, so there's nothing suitable or stable to tune against. Second, your people treat frontier access as a hiring factor. So the tuned lookalike now reads as a off cheap off-Broadway downgrade, regardless of the benchmarks. And third, the build versus by math sometimes doesn't stand up. Standing ML ops cost against per seat subscription for a workload that isn't sensitive and isn't bounded. Um there is a contrary opinion to this on a recent all-in podcast, Samath Palapatiya, who is the founder leader of 8090 um big enterprise software factory, said that theoretically he could take a he was told that he could take an open source model and tune it to do everything that a frontier model can do at the desktop level to be determined. This is a very emergent space, and we're watching it quite closely. But tuning follows the money into production, distillation using a frontier model to generate gold standard answers for bounded tasks, then training a small model you own to replicate that reasoning gets you 90 to 95% of frontier performance on that task at a fraction of the cost at hundreds of tokens per second inside your own environment. That's the best path. This works because the task is narrow, does not work for whenever a strategy analyst decides to do whatever the strategy analyst decides to do this afternoon. Enforcing the boundaries concrete work, and most of it lives in the gateway. Nobody holds a raw vendor API key. Desktop workers authenticate through single sign-on into the chat product, and production service accounts have no path to front frontier endpoints at all. Human identities can hold frontier seats, workload identities cannot as of today. So when an agent requests a model, policy routes it to an owned one or denies it and logs the attempt. Classification and DLP at the gateway decide what may leave. General drafting flows through client PII, code containing secrets get blocked before the request departs. Zero attention and no trading terms in the enterprise agreement govern the lane that you do allow. And metering by identity catches the migration problem because a prototype that quietly became a production uh piece of software has a signature, steady volume, and scripted request patterns, off-hour calls from a seat that's supposed to be a human. You want to catch that before a business process depends on an unmanaged chat account. So the resolution, frontier or frontier on the desktop, governed at the prompt boundary, waiting for the for the next uh tuned open source models to hit the desktop eagerly, own models in production, distilled where the task justifies it. The honest gap sits in the middle. Complex reasoning over data you can't let leave. There you make a policy per call uh per data class, and you don't pretend that the trade-off is gone. So let's talk a little bit about memory management and what we've been calling a company brain. A lot of us weekend warriors have been dealing with things like Obsidian and uh and and tools that um help retain our context and our memory across chats with our um orchestration layers, uh, but it's a little bit more tricky at the enterprise level. If the frontier stays on the desktop and production runs models that you own, the compounding value lives inside of the company brain. This is a layer that that the mid-market is really struggling to build, quite honestly, deliberately, and it's the one that as outlasts every model cycle. The principle comes from the personal knowledge world, tools like obsidian, it's a durable asset uh in the corpus and its link structure kept in plain, portable formats. Some of these are markdown files with a swappable retrieval layer at the top. If your models rotate every six months, a well-built corpus compounds for a decade. Your institutional memory, your decision history, your production recipes, your customer knowledge, all of it in files you own, and your tenancy is the best practice. On the Microsoft stack, that looks like the corpus in your tenant, SharePoint, one lake, blob storage, embeddings in AI search, models through Foundry. On Amazon, it's the S it's the S3 as the corpus, bedrock knowledge basis for retrieval. Um, and you can use some of these other models like Claude through bedrock under no training terms. Both work. The test is the export test. Could you take the entire brain, re-embed it, sand it up under a different stack in a week? If yes, you own it and it's sovereign. If the answer involves calling a vendor, you're renting your own memory. Portable means, boring formats, markdown and parquet for the corpus, standard embedding models you can regenerate from scratch. The embeddings are disposable. The corpus and its links are the asset. The anti-pattern, and I see it almost at every company that we walk into, institutional knowledge accumulating in individual chat histories. Your best analyst has six months of brilliant back and forth with Claude or with uh OpenAI, ChatGPT, or with with Copilot. And that knowledge lives in a vendor store that you can't easily query attached to a personal login, especially since a lot of these um desktop warriors are using their own credit cards on some of these accounts, which is a no-no, but you know, folks are folks are doing are doing what they can. Um, and so that knowledge lives it lives inside the vendor store. When he or she leaves, it becomes a problem. Uh per seat memory features make this worse because now the vendor is is building your company brain for you, one employee at a time in their cloud, and you're and you're and you're paying double E and triple E for it. The fix that turns a single player into a multiplayer game is really source control. We're super bullish on things like um like Git and Bitbucket and um and DevOps. Um, your prompts, your agent definitions, your routing policies, your eval sets go can go inside the repo with pull requests, named owners, a provenance, and a CI that runs evals on every prompt changes the way that it runs, tests on code. Your sharpest analyst technique stops being in her chat history and becomes a reviewed asset merged into the main branch. 50 people stop independently reinventing the same prompt, or God forbid, the same agent, which also stops burning 50 times the tokens and the same repo that versions your prompts versus the policies, your control plane enforces, which is a thread we'll pick up in the next episode. I think that one of my favorite quotes is actually from Apollo 13. It's where Ed Harris playing playing Gene Crans says, I don't care what anything was designed to do, I care about what it can do. I think that we're about to see an incredible second act for source code control like like Git and GitHub in being a key solution in this in this brain. So the picture in operations, uh, as an example, a claims analyst asks a question, retrieval pulls from your corpus and your tenant, the model answers with your context, and the exchange that produced a good decision gets captured back into the corpus in a documented pattern instead of dying in a chat log or being on an island. One more requirement once the sandbox goes production, multi-cloud redundancy. You can lose access to an API, a model version. Um, all of these hyperscalers go go down randomly, you know, by region on a vendor schedule. And the brain should really not care about that. You want to have some good backups. And, you know, once you have your agents running in a cloud, you know, it's just like any other software stack. You want to make it multi-cloud and have some redundancy. So here's some lessons learned from the field that we've sort of accumulated through conversation after conversation at Paragon with our managed intelligence provider solution and what it keeps teaching us. Um for recap, MIP is an ongoing engagement where our team works alongside and inside your environment like a like a player coach team, sometimes as player, sometimes as coach, sometimes as just whatever needs to get done and shipped across your AI lifecycle. So our top four industries are healthcare, manufacturing, retail, and financial services. And every single one of them needs some form of sovereign AI because in every one of them that we're running regulated data, proprietary processes, and customer trust are key. Um and we get called mid-project more often than day one. The call is usually one of two problems. Problem one is cost, and problem two is exposure. Let's talk about each one. The principle behind behind underneath uh uh each one is the same. Every AI decision is a door. This is uh borrowing uh Jeff Bezos' term, make as many two-door decisions as possible. Door one is a convenient and dependent route, which is route everything to hosted frontier model, no metering, no policy, and just ship fast. Door two is controlled, route by policy, meter locally, own the architecture. Door one is quietly the expensive door, and the audience just walked through it before. You didn't survive ERP, cloud, CRM, SaaS cycles just to locked in to get locked into Claude. Okay. So let's talk about problem one cost. Let's say the pilot pilot worked well, better than we even hoped. We scaled it, but the bill went sideways. The FinOps Foundation reports the share of finance teams managing AI spend went from 31% to 98% in two years because the invoices arrived and started stacking quickly. And let me tell you, nobody was ready. I'll give you the diagnostic we use. If you're burning a bunch of tokens on Cloud, your models are probably not small enough as a general rule. Most of the time, that's the indicator. The pilot was a chatbot, production is agentic, and Gartner's March analysis confirms agentic workloads run five to thirty times the tokens per task of the chatbot you modeled your ROI on. The failure mode is fast too. A misconfigured agent can generate a six-figure bill in hours, which is why reviewing costs after the invoice arrives, the way CloudFinOps grew up doing it, doesn't work for AI. The average enterprise AI budget went from $1.2 million in 2024 to $7 million in 2026. And a lot of that gap is exactly this multiplication on metered, and it's going to get worse because the Frontier Labs are subsidized by their funding right now. And when they actually have to turn a buck, well, it doesn't cost $5 to ride in an Uber anymore. Let's put it that way. The FinOps crowd sharpened their frame at the June conference. The metered token bill is one of nine AI cost buckets, and the other eight retrieval orchestration, idle GPU, and the rest never show up on the invoice. So any forecast anchored on the invoice alone is wrong. The metrics they're converging on are the ones we already run for our clients. Route win rate, which is the sheriff requests a cheaper model handles without quality loss, targeted at over 70%, sometimes you know up to 96%. Um, and sovereignty hit rate, the sheriff regulated workloads running in the correct residency zone enforced by policy. The headline metric is value per token rather than cost per token, and you only earn it by optimizing across every layer. The finance discipline just adopted sovereignty as a metric, and so we got to pay attention. The second problem is one around exposure. So IBM's breach data now shows that 20% of breach organizations were compromised through shadow AI, meaning unsanctioned tools that employees adopted on their own, adding roughly $670,000 to the average breach, and 97% of the organizations with an AI-linked incident had no access controls around the tools. Verizon's breach report logged a four-fold rise in shadow AI detections in a single year. It now ranks in the third most common malicious insider action in breach data. A survey of 1250 professionals at large companies found 66% had used AI at work despite believing that it violated policy, and more than a third had put customer data into public models. You can't secure traffic, you don't route. If your only AI policies to document your actually your actual AI policy is whatever your employees are doing right now, and that fix has a name, zero trust for agents, which is treat every agent as an untrusted non-human entity with per agent credentials, least privileged tools, access, scope to the task, continuous verification instead of network trust, and logging from prompt to action to outcome. Policy researchers now describe AI agents as sovereign control surface. Something that acts across your systems needs binding rules the way an employee needs an employment contract. The gap between those two problems, which are the problem one, which is cost, and problem two, which is exposure, is where the real hard work is. Roughly 23% of organizations have an AI runtime control set lacking, while employee surveys put unapproved AI use at around 55%, and only about a third of organizations have any policy to manage it. Federal Reserve Economists measured U.S. firm-level AI adoption growing 65 to 68% in a year, with the strongest growth in mid-sized firms. And mid-market survey data puts adoption at around 60% with almost no dedicated governance staff behind it. Map it back to the workloads. The cost problem lives in efficiency AI done wrong. Frontier models grinding through back office tasks, a small own model should have handled. The exposure problem lives in ungoverned productivity AI, the desktop traffic that nobody routes. The weighing is the way we've always worked. It's what Andrew Ning calls bottom-up, optimizing one step in a workflow workflow paired with a top-down strategy so that the steps add up. You actually need both. This will be a separate episode as well. So, what does this mean for our audience and those of us that are listening? For the portfolio company's CEO, your sovereignty posture is becoming a diligence term. And we know diligence because we get called to do it when there's a transaction, especially on the technical side and on the data and the AI side. When your sponsor asks in the data room who owns your AI infrastructure, our vendor is the wrong answer. The intelligence layer that you build inside your own environment, the routing logic, the corpus, the decision patterns is the asset that survives the next replatforming and compounds towards exit. The 10-minute audit coming up in a moment is where you'll start. For the PE operating partner, the capital already moved into this layer. So Salesforce just led $135 million round into uh Chamat's 8090 on the thesis that a durable value and enterprise AI is the governance, the audit trail, and the orchestration with the model interchangeable underneath. Palantra and NVIDIA announced their air-gapped AI operating system for government agencies, a sovereign control plane sitting between raw compute and mission workloads. That is the pattern at national scale, and your portfolio needs mid-market versions thereof. Three port codes with the same ungoverned AI rollout is one playbook, and the sovereignty audit travels across the portfolio. For our MSP partners out there and other uh IT partners, your clients, AI traffic is a surface that nobody governs, and governing surfaces is your business. Caseya's 2026 survey found that 48% of MSPs rank AI and automation as the top client need this year, while 13% guarantee meaningful revenue from it. The gap between those two numbers is the opportunity, and the sovereignty audit is a door opener. Run the four-layer question above with a client and you'll find the ungoverned traffic together. So here's some three questions. For each of the four layers: compute, models, data, orchestration. Can you say today whether you own it, rent it, or give it away? Write down the four answers to that. That's your sovereignty audit, and it literally takes 10 minutes. Do you know your token spend per workload? Desktop versus code versus back office versus customer facing. If it all shows up as one line item on an invoice in a spreadsheet, you have a bill and you don't have a metric. If your top AI power user resigned tomorrow, what happens to everything he or she has built in his or her chat history? If the answer is it's gone, that's your first company brain project and it costs almost nothing to start. So sovereignty is the ability to choose. It's the thing that makes the choice real, that enforces it at two in the morning when nobody's watching. That's the control plane, the layer that meters your tokens, routes your workloads, and holds your audit trail. We'll get into that in the next episode: what a control plane is, how it meters tokens, where the harness ends, and where the control plane begins. One teaser preview, there's danger in letting one vendor dominate without governance, and there's danger in putting all your eggs in one control plane basket because then the watcher is watching the watcher. The design that we've landed on is what we call a federated control plane, a separation of concerns across tools, source control upstream, token monitors downstream, routing policy in the middle. As with most things in AI, the stack is evolving constantly. Some of what I told you today will need revising in a quarter or even some days. So keep on keeping up, and I'll try to keep you updated here as best I can. I hope that you're outside on a walk right now, pondering all the great things that we're going to do in America over the next 250 years. I hope you're enjoying it. Happy independence, happy 250 America. The AI space will probably have changed by the time you get back. Cheers.