The Vendor You Can't Leave & Data Sovereignty
A few weeks ago, Kevin Guegan, founder of an AI infrastructure company called Scarlet Wolf, posted about moving his product's entire git infrastructure off GitHub.
The reason wasn't performance, or cost, or a feature gap. It was this: for months, he'd been telling clients that their AI should run on infrastructure they control, outside the reach of US law like the CLOUD Act. Meanwhile, his own source code and CI pipeline were sitting on GitHub — a US platform, owned by Microsoft.
Then his GitHub account got flagged. Nothing catastrophic happened, but the exposure stopped being theoretical. A platform he didn't control could freeze the place his company's code lived, overnight, with nothing to negotiate. So he moved: a self-hosted git server on his own European infrastructure, an independent mirror on a European non-profit platform, signed local backups on his own machines, and his own build pipeline end to end. No single vendor left holding the plug. As he put it, sovereignty was never meant to be a line on a sales page.
Most organizations never get the wake-up call. They just quietly carry the exposure until the day something forces the question — a vendor outage, a ToS update nobody read, an account flag that has nothing to do with them. If Guegan's story makes you want to check where you're exposed, good. That's the useful reaction. But before you can check, you need a way to check for what. "Do we control our data?" isn't one question. It's three.
The Three Axes
Data sovereignty isn't a switch you flip. It's three separate axes, and an organization can be solid on one while quietly exposed on another without anyone noticing until it's expensive.
Location. Where does the data physically and legally live, and can you get it back out? This is the axis everyone checks first, and often the least important one — a vendor can host your data somewhere perfectly reputable and you can still lose control of it on the other two axes below. It also shows up in less obvious ways: a system that's just hard to export from, or a vendor that charges you to leave.
Mastery. Who holds the system of record — the one true version of this data? This isn't the same as location. A vendor can host your data while you still hold mastery over it, because you define the schema and you're the source of truth. Or you can self-host and still not really control the structure, because the tool dictates how the data has to be shaped to work at all.
Use Rights. Who's allowed to do things with your data beyond storing it and handing it back? This is the newest and sharpest edge, because it's the one most likely to get signed away quietly — a checkbox in an update nobody reviewed, a default nobody flipped. In the age of AI, this is where the real exposure lives: a vendor with broad use rights can enrich its own data products or train its own models on your information. Once that happens, you don't get it back.
Guegan's move was mostly about the first axis, with the second two riding along — he wanted his code somewhere no one else could freeze, under a legal jurisdiction he trusted, on infrastructure he fully owned. That's one organization's answer, and it's a fairly extreme one. Self-hosting your entire git and CI stack isn't the right call for most companies. But the three questions underneath it apply to everyone, whether you're running your own servers or evaluating your fortieth SaaS tool this year.
What This Looks Like Inside BrightHelm
We don't self-host our infrastructure the way Guegan does. But we apply the same three-axis thinking to every tool decision we make, and we call the resulting posture our Data Moat.
The clearest example is our own knowledge base. When we were choosing where BrightHelm's institutional knowledge should live, the obvious competitor to Salesforce Knowledge was Confluence — mature, well-built, genuinely good software, and it comes with Atlassian's own AI, Rovo, built right in. That's a real sweetener: agentic interaction with your knowledge base out of the box. But it's agentic interaction across whatever modes Atlassian decides to offer, on whatever terms Atlassian sets — and that second part is the part you don't control.
There's no such thing as a free agent. If you're not paying for the tokens, you're paying some other way. In Atlassian's case, starting August 17, 2026, that "other way" has a name: a data contribution policy that feeds customer metadata and in-app content from Jira and Confluence into training Rovo and Rovo Dev. Sprint velocity, story points, project names, ticket content, workflow structure — collected by default. On Free, Standard, and Premium tiers, the metadata piece isn't optional; there's no toggle. Getting both metadata and content collection off by default requires an Enterprise contract. Everyone else is contributing their institutional knowledge to Atlassian's model whether they read the fine print or not.
We picked Salesforce Knowledge instead, and not by default. Salesforce Knowledge data is simple and semi-structured, which makes it cleanly extractable; Confluence pages carry richer formatting and embedded dependencies that are harder to get out without losing fidelity. We also control the schema directly rather than living inside a vendor's page model, and we can query the data with AI tooling without paying per call to access our own information. Confluence is a fine product, and Rovo is a real feature, not a gimmick. It just means the AI convenience and the use-rights exposure arrive as a package deal, and that package didn't clear our bar.
The stakes get higher when the data in question isn't documentation — it's the record of what a client needed, what we built, and why. That triplet is the most valuable thing BrightHelm produces per client. It's what makes us the firm that gets the call when the next question comes up, and aggregated across clients, it's our craft made visible. We looked at a genuinely excellent tool built for exactly this kind of tracking, and passed, because the data it would hold doesn't cleanly extract into anything we control. Handing it over wouldn't just be inconvenient if we ever left. It would mean a vendor gets to mine our client work, at scale, across every consultancy using their product, for their own product improvements and their own thought leadership. That's not a location problem or a mastery problem. It's a use-rights problem, and it's the kind that doesn't show up on an invoice.
A Closer Example: Booking Client Appointments
Say you're a nonprofit choosing how to handle client appointment scheduling — intake sessions, case manager meetings, whatever your program runs on. There's no shortage of scheduling tools that integrate with Salesforce at some level, and the natural instinct is to evaluate them the way you'd evaluate any software: features, price, how it feels to use.
Run the same choice through the three axes and a different risk shows up.
If the tool doesn't give you clean extraction, you're exposed on Location the day you outgrow it or the day it raises prices — every appointment, every client note tied to a booking, stuck in a format you'll spend a consulting engagement getting back out. If the tool holds the master record instead of Salesforce, you're exposed on Mastery — the scheduling data and your case management data live in two systems that can quietly disagree about the same client, and the vendor's system wins by default because it's the one generating the calendar.
And here's the one that's easy to miss because it hasn't happened yet: when — not if — that tool adds an agentic layer to help staff manage the calendar, your usage patterns and scheduling metadata will almost certainly become training material for that agent, even if your clients' actual case data technically doesn't. Booking frequency, no-show rates, which appointment types run long, how your staff actually use the tool day to day — that's exactly the operational exhaust an AI feature gets built on, and it's exactly the kind of data nobody thinks to ask about in a vendor demo.
Compare that to scheduling built natively on Salesforce. You control the data model, so appointments live next to the case record instead of pointing at it from across a vendor's system. You shape your own analytics instead of consuming whatever the vendor's dashboard decides to show you. And nobody else is quietly building their product roadmap — or their AI — on the back of your staff's usage patterns.
The scheduling tool with the nicer interface might still be the right call. Plenty of them are worth the tradeoff. But that's a decision to make on purpose, after you've looked at all three axes, not a default you back into because the demo looked good.
The Actual Ask
You don't need a GitHub flag to find out where you're exposed. Before your next renewal or your next tool decision, walk it across all three axes — not just whichever one is easiest to check. Where you're giving something up, do it on purpose, and put a contract around it. Where you can't get a straight answer to one of the three questions, that's your answer.
Guegan owns his infrastructure end to end because that's what sovereignty means to him. We own our data layer through Salesforce because that's what it means to us. The posture doesn't have to look identical. It just has to be a decision you made, not one you back into.
