Blog

Jensen Huang has been making a specific argument at conferences for two years now: AI infrastructure isn’t just a business advantage — it’s national security. Countries that don’t build sovereign AI capabilities will find themselves dependent on foreign nations for the intelligence layer that powers their economies. The geopolitical version of this argument is provocative. The product version of it is something most product leaders haven’t fully processed.

Here’s the product version: most AI product decisions are constrained by infrastructure choices that product leaders didn’t make and don’t fully understand. That constraint is getting more expensive as AI becomes more central to every product’s value proposition.

The Infrastructure Stack Nobody Talks About in PM Reviews

Most product leaders focus on the application layer — which model to use, how to prompt, whether to build or buy an AI feature. Huang is talking about something beneath that: the compute layer, the data center geography, the inference infrastructure, the energy capacity required to run large models. That lower layer determines what’s possible at the application layer, and most PMs have never mapped their dependency on it.

The practical version for a product organization: your AI capability roadmap is constrained by what your infrastructure stack can support, what your providers will make available to you, and what regulators in your operating markets will permit. When those constraints change — and they will change — your product decisions change with them, whether you’ve planned for it or not.

Serving users across multiple geographies makes this concrete quickly. Latency requirements for AI features vary by region. Data residency regulations vary by country. Provider availability varies by market. A product decision that works in one deployment context may be impossible in another. The infrastructure layer isn’t just an engineering concern — it’s a product strategy constraint.

The Hidden Costs of Inference Dependency

When you integrate a frontier AI model via API, the visible cost is the per-token or per-call pricing. The hidden costs are the ones that show up when things change: migration cost when you need to switch providers, renegotiation leverage you don’t have because you’ve built deep dependencies, the engineering cost of adapting when the API changes, and the product cost of capabilities being deprecated or repriced.

I’ve been working through three specific changes to how I think about AI infrastructure because of this:

Inference sovereignty audit. Mapping every AI dependency and its single-point-of-failure risk. Not just “which provider are we using” but “what happens if this entire category of capability becomes unavailable, significantly more expensive, or geographically restricted?” Most teams have never run this audit. The combined risk profile of a typical AI product is more concentrated than it appears from any individual dependency.

Hybrid deployment strategy. Running smaller, purpose-specific models for latency-critical features rather than defaulting to large frontier models for everything. Not full local deployment — the cost is prohibitive for most workloads — but strategic placement of specialized models where frontier models are overkill and edge deployment reduces latency and dependency simultaneously.

Data gravity awareness. Understanding that AI capabilities concentrate around where the data is. Organizations with unique, high-quality proprietary data have infrastructure leverage that commodity compute cannot replicate. The infrastructure investment that matters most for most product organizations isn’t compute — it’s the data infrastructure that makes proprietary training and fine-tuning possible.

The Product Leader’s Infrastructure Blind Spot

The specific blind spot Huang’s argument reveals for product leaders is this: we tend to evaluate AI infrastructure decisions the way we evaluate software vendor decisions — on current price and current capability. Infrastructure decisions have a different time horizon. The question isn’t “what does this cost today and does it work today?” It’s “what are the migration costs if this relationship changes, and what product decisions am I foreclosing by accepting this dependency?”

Product decisions made inside infrastructure constraints you don’t understand tend to look like missed opportunities in retrospect. You couldn’t build the feature because the provider didn’t support it. You couldn’t expand to a new market because the data residency requirements were incompatible with your architecture. You couldn’t negotiate on price because the switching cost was too high.

These aren’t failures of product strategy. They’re consequences of infrastructure decisions made without full visibility into the constraints they created. NVIDIA’s sovereign AI documentation lays out the infrastructure investment thesis at the national level — the product-level translation is understanding which version of these constraints applies to your organization and your product decisions.

Beyond the Hype Cycle: What Actually Changes

The sovereign AI framing matters for product leaders not because most of us are going to build national AI infrastructure, but because it makes the infrastructure constraint explicit in a way that the “just use the API” default doesn’t.

The products that survive infrastructure disruptions — pricing changes, geopolitical shifts, regulatory changes, provider strategy pivots — will be the ones built by teams that understood their infrastructure dependencies before they became constraints. Replace “national” with “product” in Huang’s argument and it holds: product sovereignty means having enough infrastructure control to make independent product decisions when the landscape changes.

Your Turn: Apply This Today

You don’t need to build your own data center to act on this. Start with visibility:

• Run an AI dependency audit this quarter. List every AI provider, model API, and infrastructure service your product depends on. For each one, answer: what percentage of core user value depends on this? What’s the migration path if it becomes unavailable or 3x more expensive? The audit will surface concentrations of risk you haven’t explicitly accepted.
• Map your data gravity. Identify the proprietary data assets your organization holds that an external provider cannot access. That data is your infrastructure leverage. Build the strategy for using it — fine-tuning, retrieval augmentation, evaluation datasets — before a competitor with similar data beats you to it.
• Add infrastructure questions to your product strategy review. Before any major AI feature decision, ask: what infrastructure constraints does this create or deepen? What does the migration path look like if the provider relationship changes? These questions belong in the product review, not just the engineering review.
• Build abstraction layers into your AI integrations. Design your AI integrations so that the provider is swappable without rewriting product logic. This is a small upfront investment that dramatically improves your negotiating position and reduces future migration cost.
• Assess data residency requirements in your target markets. If you’re expanding geographically, understand the AI data requirements in each target market before committing to an architecture. Retrofitting data residency compliance into an AI product is significantly more expensive than designing for it in advance.
• Run a “what if the frontier changes?” scenario annually. Ask: if the leading AI capabilities shift significantly in the next 18 months — new dominant model, new pricing structure, new regulatory environment — what product decisions would we wish we’d made differently? Use the answers to adjust your current infrastructure strategy.

The infrastructure decision connects to every other AI product decision — including the build vs. buy framework for AI infrastructure and how the sovereign AI argument translates to day-to-day product leadership.

Building AI products and trying to make infrastructure decisions that hold up as the landscape shifts? I consult with product teams on AI product strategy, infrastructure dependency frameworks, and building products that remain competitive when external constraints change. Let’s talk.

Jensen Huang’s sovereign AI argument is compelling at the nation-state level. Every country should control its AI destiny rather than depending on foreign infrastructure. The strategic logic is sound. The implementation story is considerably messier — and the mess is where the real product leadership lessons live.

I’ve watched organizations at multiple scales wrestle with the build vs. buy decision in AI infrastructure. The companies that get it right are not the ones that defaulted to either extreme. They’re the ones that developed a clear-eyed framework for evaluating the real trade-offs — and they usually had to learn that framework the hard way.

The Infrastructure Reality Check

Huang’s sovereign AI concept — building your own AI infrastructure rather than depending on external providers — carries a real cost that keynote slides consistently understate. When an organization decides to build infrastructure it could otherwise purchase, it’s making a decision that involves: significant upfront capital for compute, storage, and networking; ML engineering talent that is among the most expensive in the market; operational overhead for running, monitoring, and maintaining systems at scale; and the ongoing cost of keeping pace with a capability curve that is advancing faster than most internal teams can match.

None of this makes the build decision wrong. It means the build decision needs to be evaluated honestly against its actual cost — not against a reference point of what the infrastructure will be worth once it’s working perfectly. Most organizations evaluate the upside of sovereignty and underweight the downside of the build timeline.

Where Sovereignty Actually Matters

Not all AI capabilities are equal candidates for sovereignty decisions. The ones where building your own infrastructure makes strategic sense share a few characteristics: the capability is core to your product’s differentiation (commoditizing it would eliminate your moat), you have proprietary data that a vendor-provided model cannot access, your use case requires latency, privacy, or compliance constraints that external APIs cannot meet, or the capability is stable enough that you can amortize the build cost over multiple years.

The capabilities that are bad candidates for sovereignty decisions are the ones that are advancing rapidly at the frontier, where your internal team cannot keep pace with external model improvement, or where the task is generic enough that a frontier model already outperforms what you could build.

The practical sovereignty framework for most product organizations is not Huang’s comprehensive infrastructure ownership — it’s selective sovereignty. Own the capabilities where your proprietary advantage lives. Buy the capabilities that commodity providers can run better and cheaper than you can.

The Build vs. Buy Reality for Product Leaders

The build vs. buy decision in AI infrastructure is different from the traditional build vs. buy decision in software for one important reason: the capability being purchased is improving continuously. When you buy a license for accounting software, the software doesn’t improve significantly month over month. When you integrate a frontier AI model via API, you get the benefit of every model improvement the provider ships — without rebuilding anything.

This changes the economics substantially. A team that builds its own search ranking model might spend six months building something that outperforms GPT-4 on their specific use case. In twelve months, the frontier model has caught up and surpassed them — and they now own the maintenance burden of a system they can no longer keep competitive without sustained investment.

The sovereignty trade-off can be managed architecturally without owning the infrastructure: building abstraction layers that let you swap providers without rewriting product logic, maintaining evaluation frameworks that monitor output quality across providers, designing fallback logic for service failures, and avoiding deep API-specific integration that creates lock-in without corresponding value. This isn’t sovereignty in Huang’s comprehensive sense, but it’s practical sovereignty — controlling outcomes without controlling every component. For a deeper look at NVIDIA’s sovereign AI framework, the primary argument is worth reading directly; the implementation gap is significant.

Architectural Implications: What I’m Doing Differently

The sovereign AI argument changed how I think about AI architecture decisions — not by convincing me to build everything in-house, but by making the dependency questions explicit in every infrastructure conversation.

Before any significant AI integration decision, I now want to know: if this provider doubles their price or degrades their service quality in 18 months, what does our migration path look like? What would it cost, and how long would it take? That question changes which integration architecture you choose today. Teams that can answer it confidently have built practical sovereignty. Teams that can’t have accepted dependency without negotiating the terms of that dependency.

The goal isn’t to avoid all external dependencies. The goal is to understand your dependencies clearly and make intentional choices about which ones are acceptable risks and which ones are existential risks to your product. That discipline — applied to AI infrastructure the same way good engineering teams apply it to any critical external dependency — is the real lesson in Huang’s argument for most product leaders.

Your Turn: Apply This Today

Run this framework against your current AI infrastructure decisions:

• Map your AI dependency profile. List every external AI provider or API your product depends on. For each one, estimate: what percentage of your core user value depends on this dependency? What happens if it goes away or becomes 3x more expensive? The map will surface risks you’ve been treating as invisible.
• Apply the “sovereignty criteria” to each AI capability. For each capability on your list, score it against four criteria: is it core to your differentiation, do you have proprietary data for it, does it require compliance constraints external providers can’t meet, and is it stable enough to amortize a build? Build where you score 3+. Buy where you don’t.
• Build an abstraction layer before you build anything else. If you’re integrating any AI provider today, start with an abstraction layer that lets you swap providers. It’s a small upfront investment that dramatically reduces your future migration cost and negotiating leverage with current providers.
• Run a “provider departure” scenario annually. Once a year, ask: if our primary AI provider announced end-of-life in 6 months, what would we do? How long would migration take? What would it cost? The answer tells you your actual dependency risk — not the theoretical dependency you think you have.
• Price your build decisions against the opportunity cost. Before committing to building AI infrastructure, calculate the engineering hours required. Then ask: what could those same engineers build that would advance user value directly? The opportunity cost is real and often underweighted in infrastructure conversations.
• Establish a “make vs. buy” review as a standing agenda item for major AI decisions. Don’t let it default to either direction. Build the habit of explicit evaluation — cost, timeline, capability trajectory, and dependency risk — before any significant AI infrastructure commitment.

This infrastructure dependency thinking connects directly to the broader strategic framing — how the sovereign AI argument translates to product leadership decisions and why domain expertise becomes more valuable, not less, when AI handles the generic capabilities.

Navigating AI infrastructure decisions and trying to build something defensible rather than just functional? I consult with product teams on AI architecture strategy, build vs. buy frameworks, and building products that remain competitive as the AI capability landscape shifts. Let’s talk.

Most AI product failures I’ve seen aren’t caused by bad algorithms. They’re caused by good algorithms that no one thought about as a system.

A team ships a content recommendation model. It performs beautifully in testing. Six months later, they ship a search ranking model. Also strong in isolation. Then a personalization layer. Three technically sound components — and now users are getting a contradictory experience that none of the individual feature reviews could have predicted. The models are working. The system is broken.

Charlie Munger’s latticework principle — the idea that knowledge only becomes useful when it hangs together in connected frameworks rather than isolated facts — is the most precise description I’ve found for what AI product teams are missing. Here’s what it looks like in practice.

The Hidden Architecture Problem in AI Product Development

Traditional software features behave in largely predictable ways. You add a filter to a list view; it filters the list. The feature is self-contained. The mental model for reviewing it is simple: does it do what it’s supposed to do?

AI features don’t work this way. They create feedback loops. They shape user expectations. They interact with other AI features in ways that emerge from scale, not from design sessions. A recommendation engine that’s technically optimizing for engagement can be simultaneously teaching users that the product doesn’t understand what they actually need. The technical metric is green. The user relationship is eroding.

This is the hidden architecture problem: the behavior of your AI product portfolio as a system is different from — and often opposed to — the behavior of each feature in isolation. Munger’s latticework principle is the framework for thinking about both at once.

Mental Models vs. Best Practices: What the Latticework Changes

Most AI product teams operate by best practices. A/B test the recommendation algorithm. Use the highest-performing model for your use case. Personalize based on user behavior data. These aren’t wrong — they’re just dangerously incomplete when applied without the mental models that reveal their limits.

“A/B test your recommendations to optimize conversion” — the mental model that challenges this: conversion rate optimization in AI systems often conflicts with long-term trust. Users can’t easily verify the quality of AI recommendations. Optimizing for short-term conversion can train users to distrust the recommendations that actually serve them best.

“Use the highest-performing model” — the mental model that challenges this: model performance is one variable in user adoption. Latency, explainability, and consistency often matter more than raw accuracy for real-world usage patterns. A slightly less accurate model that responds in 200ms and explains its reasoning may outperform a more accurate model that takes 2 seconds and offers no explanation.

“Personalize based on behavior data” — the mental model that challenges this: personalization creates feedback loops. The system effects — filter bubbles, amplified biases, reduced serendipity — often outweigh the individual user benefit of better-targeted content. At scale, you may be building a product that each individual user finds useful while simultaneously reducing the quality of the collective experience.

These aren’t theoretical concerns. They’re the failure modes of AI products that ships feature-by-feature without a connected framework for evaluating how those features behave as a system. MIT Technology Review’s analysis of AI product failures consistently surfaces these systemic issues as more common than pure technical failures.

Building Your AI Mental Model Latticework

The practical application is a shift in the questions you ask at product review. Instead of evaluating each AI feature in isolation — does this model perform? does this feature get used? — you evaluate the portfolio as a system:

How does this feature change user expectations for every other AI feature in the product? If your AI writing assistant produces near-perfect outputs, does that raise the bar for your AI translation feature in a way that creates dissatisfaction where none existed before?

How do this feature’s feedback loops interact with the feedback loops of other AI features? A recommendation engine and a search ranking model fed by the same behavioral data are creating compound feedback loops. Are they amplifying each other toward better outcomes or toward worse ones?

How does the portfolio of AI features together change the user’s mental model of what the product is? Users don’t experience features — they experience a product. The cumulative effect of your AI features determines whether users trust the product, rely on it, or grow quietly skeptical of it. That cumulative effect is what you’re actually building, whether you’re thinking about it or not.

The Munger Test for AI Product Decisions

I run what I think of as the Munger test before any significant AI feature decision: can I explain why this feature will improve the overall product — not just its isolated metric — using at least three different mental models?

If I can only make the case from one angle — it’s technically better, or it’s cheaper, or users asked for it — I’m probably missing something important. The features that hold up under the multi-model test tend to ship well. The ones that only make sense from one angle tend to create problems we didn’t anticipate.

That’s the compound interest of connected thinking. Each mental model makes the others more useful. The latticework, over time, makes you a dramatically better evaluator of AI product decisions than any individual framework alone.

Your Turn: Apply This Today

Start building the latticework habit with these concrete steps:

• Map your AI feature portfolio as a system. List all the AI features currently live in your product. Draw arrows between any two features that share data, shape user expectations about each other, or create feedback loops. If you’ve never done this, you will find something that surprises you.
• Apply the three-model rule to your next feature decision. Before approving or building any AI feature, require the team to make the case from at least three different mental model angles — technical, behavioral, economic. If the feature only looks good from one angle, hold it until the others are addressed.
• Run a “best practices challenge” in your next review. Take one of your team’s standard AI best practices and ask: what is the mental model that challenges this? What is the failure mode of this practice at scale? The answer will improve your practice or flag a risk you haven’t accounted for.
• Evaluate user trust as a system-level metric, not a feature-level metric. Create or request a metric that captures user trust in your AI product overall — not per feature. Track it quarterly. Connect it explicitly to your AI feature decisions.
• Design your AI features’ feedback loops on paper before you ship them. For each AI feature in your pipeline, sketch the feedback loop: what user behavior does this feature reward? What does rewarding that behavior do to user behavior over time? Is the loop pointing toward value or away from it?
• Run the Munger test before your next roadmap commit. For each AI initiative on your roadmap, ask: can I explain the expected value using three different frameworks? If not, spend 30 minutes developing the weaker angles before committing. The discipline is the point.

The individual mental model disciplines that feed into this latticework are worth studying separately — I’ve written about how Munger’s inversion principle applies specifically to AI feature development, and how building the multi-discipline lens changes the questions you ask at product reviews.

Building AI products and looking for a sharper framework for portfolio-level thinking? I consult with product teams on AI product strategy, system-level design, and building the decision habits that make the difference between features that work in isolation and products that work at scale. Let’s talk.