Alex Karp did something on live television that most CEOs will never do: he described, in blunt, almost uncomfortable terms, how the current AI market is structurally stacked against serious enterprises - and why, if they are not careful, they will spend the next decade training the very systems that will replace them.
Beneath the theatrics of his CNBC appearance was a simple thesis every board and management team needs to confront: if you don’t own your ontology, if you don’t control your alpha, and if you don’t govern the application layer where AI actually touches your business, then your “AI strategy” is really a subsidy to someone else’s balance sheet.
In finance, alpha is the return you generate above the market because you know or do something others don’t. In an enterprise AI context, alpha is the hard‑won combination of proprietary data, expert heuristics, and distinctive workflows that make your institution perform differently from its peers. It’s the pattern recognition your best people have, the shortcuts your teams use, and the judgments that only experience can teach. When Karp talks about “owning your alpha,” he means making sure those patterns are captured, amplified, and protected inside your own systems - instead of being quietly absorbed into someone else’s model and product roadmap.
That conviction - that governance should be the mechanism by which institutions protect and compound their own alpha, rather than see it extracted by others - is exactly what inspired the name Alpha Governance Group.
The real AI safety question: who learns from you?
For the past 18 months, public debate about “AI safety” has lived at 30,000 feet: existential risk, alignment research, and thought experiments about model licensing.
That discussion matters, but it misses the question that actually determines who wins and who loses in enterprise AI. That question is brutally concrete:
- Who controls the models?
- Who controls the weights?
- Who controls the value your business creates when it uses those models?
In today’s typical setup, the pattern looks like this:
- You pay for access to a powerful model and the infrastructure to run it.
- You start sending it your contracts, code, designs, tickets, logs, and strategy decks.
- The model, and its provider, quietly learn how your business and your industry actually work - how your people prompt, correct, and refine.
- Those learnings are rolled into improved general‑purpose models and into new vertical products, often focused on the most valuable workflows they now understand from you and your peers.
From the AI frontier lab’s perspective, that’s efficient. From an enterprise perspective, it’s a transfer of institutional knowledge: you’re paying for tokens while they accumulate your patterns, your edge cases, your tacit playbook.
That’s what Karp means when he channels his customers frustration as saying they “waste their time with tokens, get no real value, and the labs get their IP.” The “IP” here isn’t just individual documents; it’s the way your business thinks and acts, captured through AI interactions.
The foundational enterprise AI question is not “Which model scores highest on benchmarks?” It’s "Who is allowed to learn from your operations at scale, over time, for their own benefit?".
Everything else, including safety, sits downstream of that.
Ontology: your business as code
Most executives were never taught to think about “ontology,” but they live with it every day.
In the AI context, your ontology is the explicit, machine‑readable definition of how your business fits together:
- The entities that matter: customer, mission, asset, shipment, case, patient, contract, claim.
- The relationships between them: which assets support which mission; which contracts depend on which supplier; which patients relate to which trials.
- The rules that govern them: who may see or change what; what counts as an exception; what must be escalated; what must never happen.
For decades, this ontology has been implicit and fragmented - buried in schemas, policy binders, slide decks, and the heads of a few irreplaceable people. That was barely tolerable when software was a tool. It becomes untenable once you invite AI agents into the loop.
Without an explicit ontology, an AI system sees your company as a pile of text and tables. It can autocomplete and summarize, but it has no grounded sense of what is at stake. That’s how you get confident answers that ignore dependencies, violate policies, or miss signals your best operators spot instantly.
With a well‑designed ontology, the picture changes:
- An agent doesn’t just see “an invoice”; it sees “an invoice from a flagged supplier on a high‑priority project in a sanctioned region.”
- A recommendation to “optimize capacity” is evaluated against rules that know which facilities are safety‑critical, which shifts trigger overtime, and which regulators are involved.
- A query about “sensitive customer data” is scoped automatically to the right systems, redactions, and jurisdictions.
Ontology is your business‑as‑code layer. It is the digital constitution that tells AI what exists in your world, how things connect, and what is allowed to happen.
Crucially, it’s also where governance lives:
- Access control is defined on meaningful entities and relationships, not just on columns and tables.
- Data residency, retention, and masking policies are tied to business concepts (customer, country, case type), not just to filenames.
- Human‑in‑the‑loop requirements are bound to specific decisions (“approve a loan above this threshold,” “change this treatment plan”), not retrofitted later.
When Karp talks about Palantir’s ontology as the layer that makes frontier models “safe and useful and precise” in battlefield, intelligence, clinical, and industrial contexts, he’s not describing a theoretical schema. He’s describing the control plane where reality and rules are codified so models can be powerful without being reckless.
If that control plane is yours, each AI interaction makes your understanding of your own business sharper. If it belongs to a vendor, each interaction makes their understanding of your business sharper.
Forward‑deployed builders: how ontology and governance become real
Ontologies don’t emerge from slideware. They are discovered, negotiated, and encoded at the messy frontier where work actually happens.
That’s why forward‑deployed engineers - and their equivalents in other organizations - are so central in Karp’s story. They are how ontology and governance stop being abstractions and become operational.
A forward‑deployed team sits with the people who carry the business on their backs: plant managers, grid operators, clinicians, logistics leads, investigators, traders. Their job is not to evangelize AI; it’s to quietly:
- Surface the real workflows.
They observe who really gets called when something breaks, how exceptions are handled, where the “shadow process” diverges from the documented one. It’s those actual flows, not the idealized diagrams, that must be captured in ontology. - Extract tacit knowledge.
They work with the expert everyone trusts - “the person who always knows” - to turn intuitive judgment into rules, thresholds, and relationships. If a seasoned engineer can spot from a handful of signals that a failure is imminent, that logic can be encoded so an agent can at least flag it every time. - Codify the non‑negotiable guardrails.
They sit with risk, legal, compliance, and mission owners to understand where no model is ever allowed to act alone: use of force, certain clinical decisions, specific financial moves, regulatory communications. Those boundaries aren’t left to policy memos; they’re baked into the application layer.
Think of forward‑deployed teams as alpha harvesters and governance coders. They turn your best people’s instincts into system behavior and tie that behavior tightly to the rules you can defend in court, in front of regulators, or on the battlefield.
When that work is done on your behalf, inside your architecture, you get safer, more relevant, more compounding AI.
When that work is primarily done in service of a vendor’s generic platform, your experts are still teaching—but the main beneficiary is the vendor’s product.
The application layer: where AI meets your reality
All of this - ontology, alpha, governance - becomes tangible in exactly one place: the application layer.
A model, by itself, can predict tokens or patterns. It does not:
- Log into your systems.
- Enforce your policies.
- Sequence multi‑step workflows.
- Decide when and how humans should be involved.
The application layer is the software that:
- Receives business problems in your language (“clear this claims backlog under these constraints,” “prioritize maintenance given this budget and risk profile”).
- Chooses which agents and models to call, with what context and parameters.
- Translates model outputs into concrete actions in your systems: open a ticket, update a record, draft a message, propose a decision.
- Applies your rules: checks, thresholds, escalations, audit logs.
Karp’s argument (and Nvidia’s) is that this is the strategic high ground:
- A generalist model behind a vanilla API, accessed the same way by everyone, will never perform as well in your environment as a system shaped by your actual data, ontology, and workflows.
- The entity that controls the application layer - the layer that connects models to the messy specifics of your business - is the one that captures the enduring value.
That’s why, in serious deployments, frontier models are never used raw. They’re wrapped:
- In Palantir’s case, inside an application layer grounded in an ontology that reflects missions, assets, regulations, and risks.
- In Box’s world, behind content layers that enforce permissions, classifications, and retention policies for unstructured data.
- In many internal builds, inside orchestration platforms that enforce corporate policies and integrate with existing systems.
If you own this layer, AI acts under your rules, in your frame of reference. If a vendor owns it, your business is effectively operating inside someone else’s software constitution.
Models, applications, ontology: the real hierarchy of control
It helps to see the AI stack as three key components:
- Model layer
- Foundation and fine‑tuned models, closed or open.
- Provide generic reasoning, language, and pattern recognition.
- Application layer
- Orchestrates tasks, calls models, integrates with your systems.
- Encodes workflows, agent behavior, tools, and runbooks.
- Ontology and governance layer
- Defines what exists, how it’s connected, and what’s allowed.
- Encodes policies, permissions, risk appetite, and escalation.
Most of the noise in the market is at layer 1. But structural control sits in layers 2 and 3:
- The application layer decides how models are actually used and what actions they can take.
- The ontology/governance layer decides what counts as a valid action in the first place.
Karp’s insistence on being “model‑agnostic” is not a philosophical preference; it’s architectural. If you get layers 2 and 3 right, you can swap models in layer 1 as they improve, as economics shift, or as policies change - without rewriting your institutional brain.
For boards, the implications are direct:
- Obsessing over which frontier model is “best” is less important than deciding who owns the application layer and the ontology.
- If your application logic and ontology live wholly inside a vendor’s platform, you have less control than you think, no matter how many “BYO model” options you tick.
Alpha: what you can’t afford to lose
In finance, alpha is what you earn above the market because you know or do something others don’t. In an AI‑infused enterprise, your alpha consists of:
- Unique data: telemetry, longitudinal customer histories, proprietary research, internal docs and deliberations.
- Unique heuristics: the ways your experts weigh signals, sequence actions, and resolve trade‑offs.
- Unique workflows: how your teams coordinate across functions, geographies, and constraints.
AI makes that alpha legible:
- It’s in the prompts your people use, the corrections they apply, the edge cases they escalate.
- It’s in the patterns your agents learn to handle well and the ones humans intervene on.
- It’s in the ontological refinements you make as you understand your world more clearly.
The key is where that legibility goes.
If your ontology, application layer, and governance are under your control, those signals deepen your model of your business. AI becomes a way to extract, encode, and scale your alpha, making you harder to imitate over time.
If, instead, your main AI usage is routed through a vendor’s opaque application layer and into their training loops, then you are giving away that legibility. The model that understands your patterns best will live elsewhere, behind someone else’s API, on someone else’s terms.
That is the structural concern beneath the Figma-Anthropic story and other emerging tensions. Figma deeply integrated Anthropic’s models into its product and even had Anthropic’s chief product officer on its board, giving the lab rich visibility into how modern design workflows actually operate. Months later, Anthropic launched Claude Design - a prompt‑to‑prototype tool that reads a customer’s codebase and design files, builds a design system, and produces production‑ready interfaces - directly in Anthropic’s own ecosystem. Overnight, the model provider that powered Figma’s AI features also became a direct competitor in its core category. Even if every rule was technically followed, the pattern is clear: once your workflows and patterns are exposed at scale at the model layer, the economic incentive for that provider to move “up the stack” into your vertical becomes overwhelming.
The enterprise‑level question is simple:
Do you want AI to be the mechanism by which your alpha compounds inside your institution, or the mechanism by which it is standardized and sold back to you?
Governance as alpha
We’re used to treating governance as defensive: compliance, risk mitigation, audit. In an agentic enterprise, governance becomes offensive: it’s how you decide who gets better, faster.
In practice, governance becomes alpha in four ways:
- Who learns from your interactions
- You explicitly decide which data, logs, and feedback can be used to train internal models, which can be used to tune vendor‑hosted models dedicated to you, and which must never leave certain boundaries.
- You ensure that general‑purpose models do not learn from your workloads by default.
- Where compounding happens
- You design your AI architecture so that new workflows, ontological refinements, and guardrails are built into your own application layer.
- Each new use case reuses and strengthens this fabric, reducing marginal cost and increasing differentiation.
- Where agents may act and how
- You specify, in code and policy, which decisions can be automated, at what thresholds, with what escalation paths and logs.
- You give agents room to create value in domains you understand and have bounded, while preventing them from taking irrecoverable actions.
- How much model optionality you retain
- You avoid hard‑wiring your ontology and workflows into a single provider’s proprietary scaffolding.
- You build around standards and interfaces you can re‑implement or move if needed.
Each of these is a design choice. Taken together, they determine whether AI makes your organization more unique and resilient—or more generic and dependent.
What boards and executives should do now
None of this is academic.
It leads directly to a short agenda for boards and executive teams.
1) Adopt a clear control doctrine
Agree, in writing, on a few non‑negotiables:
- We will own our ontology—the core representation of our business logic - and avoid designs that make it non‑portable.
- We will treat the application layer that orchestrates agents and model calls as strategic infrastructure, not a disposable integration.
- We will not allow vendors to learn from our workloads in ways that enable them to compete directly in our core businesses without explicit, compensated agreement.
This becomes your AI equivalent of a risk appetite statement.
2) Map your current state
Ask for a concise, candid map of:
- Where your de facto ontology lives (systems, docs, people).
- Which AI tools and platforms currently receive your data, prompts, and context - and under what terms they retain and use that information.
- Where AI agents or automated workflows are already acting, what decisions they’re making, and what guardrails exist (or don’t).
You are looking, above all, for places where critical knowledge and workflows are already flowing into systems you do not control.
3) Build a forward‑deployed ontology and governance team
Create a small, high‑leverage team that:
- Works inside business units to surface real workflows, decisions, and tacit knowledge.
- Encodes that into an explicit ontology and into application‑layer runbooks.
- Designs and evolves guardrails based on outcomes and risk appetite, not just abstract policy.
Make this team jointly accountable to technology, operations, and risk—not buried under any one function.
4) Re‑paper and re‑architect where necessary
For material AI vendor relationships:
- Tighten contractual terms around data use, retention, and training.
- Push for architectural patterns where your ontology and application logic remain under your control, even if vendors help build them.
- Where that is impossible, constrain the relationship to non‑core, non‑differentiating areas.
Internally:
- Invest in a shared application layer - APIs, services, orchestration - that all AI use cases must plug into.
- Ensure this layer is the primary consumer of models, not dozens of direct app‑to‑model integrations you can’t see or govern.
5) Tie AI to controlled outcomes, not hype
Shift reporting away from “we rolled out X copilots” to:
- These are the workflows we’ve automated or augmented.
- These are the business outcomes (efficiency, revenue, risk reduction, resilience).
- These are the governance measures in place (guardrails, logs, audits).
- These are the learning loops we control and how they improve our internal systems.
Use that lens to allocate capital: more into governed, high‑ROI use cases; less into uncontrolled experimentation that primarily trains vendors.
The decision you can’t outsource
Alex Karp’s television outburst drew attention because it sounded like a rant. It matters because it wasn’t just about his company. It was a crack in the public façade of an uneasy reality: many CEOs and boards are privately furious that they’ve been told to spend aggressively on AI in ways that leave them more dependent and less differentiated.
You don’t have to like Karp, Palantir, Nvidia, or any particular vendor to take the underlying structure seriously. The core choice he surfaced is simple:
- Use AI to codify and compound your ontology, your alpha, under your governance, with control of the application layer that connects models to your reality; or
- Use AI primarily through other people’s control planes, donating your data, workflows, and judgment so their models and platforms understand your business better than your next generation of employees will.
One path is harder upfront and demands uncomfortable clarity about control. The other is easier - until it isn’t.
You cannot outsource this decision. You can only delay it. And every month you delay, you may be teaching someone else’s system a little more about how to run your business.
