{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifgiowwvqa6ktfpsidhgyomu5jr27ubwcza63hkkvqk55axgfngdq",
    "uri": "at://did:plc:akauiygo3cboznlozms62vqw/app.bsky.feed.post/3mjz5dndjsl62"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreielqpzfukkkmhduz2ns4uvgy3fr6im63o2rqkj4pw72ojtyjp7ztq"
    },
    "mimeType": "image/jpeg",
    "size": 162034
  },
  "description": "AI sovereignty does not stop at infrastructure. It shows up in product architecture: where inference runs, how data flows, whether models can be replaced, and how much of your product depends on someone else’s roadmap.",
  "path": "/build-ai-products-you-can-still-control/",
  "publishedAt": "2026-04-21T13:59:16.000Z",
  "site": "https://julie.beliao.fr",
  "tags": [
    "article"
  ],
  "textContent": "AI sovereignty does not stop at infrastructure. It shows up in product architecture: where inference runs, how data flows, whether models can be replaced, and how much of your product depends on someone else’s roadmap.\n\nThis piece picks up where my previous article on AI as infrastructure left off: at the point where dependency stops being abstract and starts shaping product architecture.\n\n## From features to architecture\n\nMost AI product teams still think they are making feature decisions.\n\nChat. Summarization. Classification. Generation.\n\nOften, they are making dependency decisions.\n\nEvery time a product relies on a third-party AI API, something leaves your control. Sometimes that tradeoff is acceptable. Sometimes it is the right one. But very often it is not really a decision at all. It is the path of least resistance, wrapped in a demo that works and a team that wants to move faster.\n\nThat is how dependency gets in: quietly, conveniently, and usually with a roadmap attached. Not yours.\n\nIf you want to build AI products that users, and frankly, builders too, can actually control, the question is not only what the feature does. It is what control you lose by building it this way.\n\n## Sovereignty at the product layer\n\nA lot of people still talk about sovereignty as if it were only an infrastructure question. Cloud versus on-prem. Local versus hosted. Open versus closed.\n\nThose distinctions matter, but they are not enough.\n\nSovereignty also lives at the product layer.\n\nYou can host a model yourself and still design a product that is tightly coupled to assumptions you cannot move easily. You can use external infrastructure and still preserve meaningful control if the architecture keeps the right layers portable, observable, and replaceable.\n\nThat is why product architecture matters so much here. Sovereignty is not only about where the compute sits. It is about whether your product can still function, adapt, and be governed on your terms.\n\nAt product level, sovereignty means being able to answer basic questions without hand-waving:\nCan we replace the model?\nCan we move the workload?\nCan we keep data inside boundaries we actually control?\nCan we inspect what is happening?\nCan we keep the product running if the provider changes the rules?\n\nIf the answer to all of those questions is no, then you do not really have sovereignty. You have convenience.\n\n## What designing for control actually means\n\nWe do not need one perfect solution. We need a set of deliberate choices.\n\nFirst: **where does inference run?** There is a spectrum, from third-party APIs to managed cloud with region, VPC, or data residency constraints, to self-hosted models, to fully local execution. Control generally increases as you move toward environments you control more directly. That does not make one end morally superior. It just makes the tradeoff clearer.\n\nSecond: **can the model be replaced?** If switching models requires surgery on your whole product, you are locked in, no matter how many abstraction layers your architecture diagram claims you have. Designing for control means separating the application layer from the model layer as much as possible, with interchangeable backends, compatibility layers, routing across providers, and support for portable formats.\n\nThird: **where does data go?** This is not just about storage. It is about flow. Does user data leave your system? Can it be retained or reused externally? Are the boundaries enforced technically, or only contractually? There are different ways to strengthen this layer. Sometimes that means local inference, where the data never leaves the environment. Sometimes it means on-prem deployments or tightly controlled cloud environments. Sometimes it means federated approaches that avoid centralizing sensitive data in the first place.\n\nFourth: **what happens when the network fails?** A surprising number of AI products are designed on the assumption that connectivity is forever, outages are for other people, and nobody will mind if the core capability disappears for a while. Reality is usually less accommodating. Field tools, hospital systems, developer workflows, regulated environments, air-gapped contexts: these do not always get the luxury of permanent external calls. If core functionality collapses without them, that is an architectural choice too.\n\nFifth: **can you inspect and audit the system?** If you cannot answer what model is running, what version it is, how it was configured, or what inputs it saw, then no, you do not really control it. This is where open-weight models, reproducible environments, observable inference layers, and transparent runtimes start to matter. Without them, accountability gets fuzzy very quickly, and fuzzy is rarely the adjective you want in production.\n\nAnd finally: **who controls updates?** A surprising amount of fragility comes from silent change: model updates, API behavior changes, pricing shifts, policy changes, and provider-side feature changes your product quietly started to rely on. Control does not eliminate change. It just stops change from showing up disguised as an unpleasant surprise.\n\n## Different products, different tradeoffs\n\nNot every product needs the same level of control.\n\nA legal tool may run models on client infrastructure to reduce exposure. A healthcare product may require on-prem inference for compliance and auditability. A developer tool may embed a local model to avoid leaking code or making core workflows dependent on external services. A global SaaS product may use region-specific deployments to respect data boundaries while still relying on external infrastructure.\n\nThe common pattern is not the tool.\n\nIt is control over where and how inference happens, how much of the system can be moved, and how much of the product depends on external decisions you do not control.\n\n## More control is not free\n\nMore control often comes with cost: more infrastructure to manage, more engineering effort, sometimes smaller or less optimized models, and fewer plug-and-play conveniences from provider platforms.\n\nAPI-based systems optimize for speed and convenience. Systems designed for more control optimize for flexibility, resilience, and independence.\n\nYou do not get to maximize everything at once. That is not a tragedy. That is just engineering.\n\nThe point is not to reject one model in favor of the other. It is to choose deliberately, and to understand what you are optimizing for before your architecture optimizes it for you.\n\n## Start with your architecture, not your feature list\n\nIf you are building AI into your product, start by mapping your current system.\n\nWhere does inference run?\nWhere does data go?\nWhat depends on external services?\nWhat breaks if those services change or disappear?\nWhich parts of your product rely on provider-specific features rather than capabilities you actually control?\n\nThen decide what actually matters for your product, and in what order: data sensitivity, compliance, cost, availability, portability, auditability, user control.\n\nYou do not need to move everything.\n\nBut you should know what you could move if you had to.\n\nThat is what control looks like in practice.\n\n## Closing\n\nMost AI products today are built in conditions where speed is rewarded and hesitation is penalized. Under those conditions, convenience often wins, and in AI convenience frequently means dependency.\n\nIn practice, that means relying on someone else’s models, features, and roadmap before anyone has really stopped to ask what that changes.\n\nSometimes that tradeoff is acceptable. Sometimes it is even the right one. But when speed starts making architecture decisions by default, control usually disappears before anyone names it.\n\nYou do not need to control everything. But you should know which parts of your product you can still move, replace, inspect, or keep running when someone else changes the rules.\n\nThat is what building for control looks like in practice.",
  "title": "Build AI products you can still control",
  "updatedAt": "2026-05-04T15:08:45.670Z"
}