Function Calling and Tool Use: Patterns That Survive Production
The tool call is where the agent meets reality A model that only writes text cannot do much harm or much good. The …
Sourcing starts with a risk register now
For a decade the infrastructure question had one default answer: put it in the public cloud, pick a cheap region, and stop thinking about geography. That default is breaking. In a recent CIO.com piece on sovereignty as a design constraint, Jochen Jaser of SUSE describes the change in one sentence: three years ago a sourcing decision started with total cost of ownership, and now it starts more like a risk register.
That is a different job. Cost optimization asks where a workload runs cheapest. A risk register asks who controls the hardware, which laws reach the data, and what breaks if a vendor contract or a border shifts. For AI, where the inputs are often the most sensitive data an organization holds, the second set of questions now outranks the first.
The article sets out five things CIOs have to do as that shift lands. Read together they describe an architecture, not a policy memo.
Geography is a design variable
The first move is to treat location as a core architectural decision instead of a deployment detail. Luis Pinto of Gartner puts the stakes plainly: where technology is located and who has operational control over it is now a major business risk. Workload placement starts to turn on data sensitivity and regulatory exposure, and dependence on a single hyperscaler gets re-examined rather than assumed.
Vendor concentration is a risk, not leverage
The second move reframes resilience. Pinto’s line inverts a decade of procurement logic: vendor concentration is now treated as systemic risk, not strategic leverage. The consolidation that once won volume discounts now reads as a single point of failure. Jaser adds the practical version of the problem: three- and five-year contracts with usage commitments limit the ability to choose alternatives when requirements change. Concentration is comfortable until the day it isn’t.
Most data does not need protection, so find the part that does
The third move is classification. Shannon Bell of OpenText offers a number that keeps the project sane: more than 90% of enterprise data can safely sit in the public domain, and a small percentage needs protection. Sovereignty runs on a spectrum. Public sites and low-risk services can stay in global cloud, while proprietary models, regulated records, and security telemetry move to controlled environments. Jaser’s advice is to start there and not gold-plate it: classify the workloads, then place them.
Portability has to be built in, not bolted on
The fourth move decides whether the other four hold up. Bell calls it designing for workload portability up front. In practice that means containers, Kubernetes, and open standards so a workload can move across providers and on-prem without a rewrite, plus exit terms written into the contract before signing. Pinto explains why it matters beyond convenience: rigid agreements can lock an organization into an environment that no longer meets its regulatory requirements. Exit by design costs less than exit under pressure.
The perimeter is identity now
The fifth move pushes sovereignty out to the edge. Remote work and mobile access spread data across jurisdictions, and a device can be inspected or seized at a border. Matt Stern of Hypori states the architectural conclusion: identity is becoming the perimeter, and the model is identity-centric rather than device-centric. The thing you defend is access, not the laptop.
The tradeoff the article is honest about
None of this is free. The same piece is candid that more control usually means higher cost, slower deployment, or less immediate access to the newest cloud-only features. A risk register is harder to run than a price comparison, and a team that pretends otherwise will under-budget the work.
Building classification and portability in early shrinks that tax rather than denying it. If a workload runs the same way in a public region, a private cluster, or an air-gapped site, the choice of where to put it becomes reversible, and reversible decisions cost far less to get wrong. The demand is already visible in the numbers. A March 2026 global study found 82% of organizations rate data sovereignty as extremely or very important for AI deployments, and Broadcom and the Cloud Security Alliance report 59% of enterprises adopting hybrid strategies, with 16% moving to fully private infrastructure.
Where this lands for AI tooling
For AI specifically, the five imperatives collapse into one requirement: the platform cannot assume it lives in one place. Tooling that only works while it can reach a single cloud API has already failed the portability test in the fourth imperative, and it concentrates the vendor risk the second one warns about. The interface a team works in and the backend it runs on have to come apart, so the backend can change without retraining anyone or rewriting anything.
That separation is the design Calliope is built around: the same workbench and the same tools whether the backend is a public cloud, a private cluster, a colocation site, or an air-gapped room, with policy enforced in the request path rather than added afterward. We have written before about why one workbench should run across many backends . The CIO.com framing is a useful confirmation from the buyer’s side of the table. The teams treating sovereignty as a permanent design constraint, rather than a compliance task to clear, are the ones who will not have to rebuild when the next jurisdiction, contract, or model restriction arrives.
Sources:
