AI Platform Risk: When Your Model Vendor Competes With You
In the first week of July 2026, the CEO of Palantir went on CNBC and said the quiet part with a microphone on. “Something has gone completely wrong,” Alex Karp told Squawk Box, describing how enterprises feel about paying frontier AI labs by the token. His summary of the customer’s fear was blunt: “I’m going to get no value and they’re going to get my IP.” Around the same time, Chamath Palihapitiya pushed a sharper version of the same warning at the pharmaceutical industry: the companies paying one leading AI lab for research tools are, in his framing, funding the drug pipeline of a future rival.
Here’s what makes that warning land. The lab in question had just announced it would develop its own drugs. Days later, reporting surfaced that it is in early talks with Samsung to manufacture a custom inference chip. Its consumer app keeps absorbing features that used to be standalone products. Sell the tools, enter the market, own the silicon. All in one company, all in one quarter.
You can dismiss Karp’s version as a competitor talking his book. Palantir sells the alternative, and his complaint about token pricing doubles as an ad. Fine. Strip out the names, the quarter, and the motives, and a structural question is left standing, and it does not go away when the news cycle does.
Every AI startup I know, including both of mine, is built on top of a vendor that is structurally incentivized to climb into its customers’ markets. Not because the people are bad. Because the economics point that way, the capital demands it, and nothing in the terms of service prevents it.
The old name for this is platform risk. I think the old name is hiding the new shape of it. The 2010s taught founders that platform risk means the platform cuts off your API access. The 2020s version is quieter and worse: the platform never cuts you off. It absorbs your category while your integration keeps working perfectly.
This post is the dependency map I wish I’d had when I started building on foundation models: where the labs are expanding, what you actually pay them beyond the token bill, what they can and cannot see about your business, a five-question test that scores whether your product is on their roadmap, and the layers where a startup can stand that the labs structurally will not absorb.
Table of Contents
- The Old Platform Risk Playbook Is the Wrong Map
- The Stack Creep Map: Four Directions of Absorption
- The Three Invoices: What You Actually Pay a Model Vendor
- What the Lab Actually Sees (It Is Not Your Data)
- The Absorption Test: Five Questions That Score Your Exposure
- The Survivable Layers: What Labs Will Not Absorb
- The Contrarian Take: Platform Risk Is a Subsidy
- What to Do Monday Morning
- FAQ: AI Platform Risk
The Old Platform Risk Playbook Is the Wrong Map
Founders my age learned platform risk from two case studies, and both of them teach the wrong lesson for the AI era.
The first is Zynga. At IPO, Zynga’s filing admitted it generated “substantially all” of its revenue and players through Facebook. In the first half of 2012, Zynga alone accounted for 14 percent of Facebook’s revenue, down from 19 percent the year before. Everyone could see the dependency. Then Facebook made its Credits system mandatory for game payments and took 30 percent of every transaction, changed discovery rules whenever it suited the feed, and Zynga’s market cap fell roughly 80 percent within a year of listing. The lesson founders took: don’t build your distribution on someone else’s platform.
The second is Twitter. In January 2023, the most beloved third-party clients, Tweetbot and Twitterrific, stopped working overnight. No warning, no email, no deprecation window. Weeks later the free API was gone and the enterprise tier was priced at 42,000 dollars a month. A whole shelf of businesses died in a fortnight. The lesson founders took: don’t build your product on an API someone else controls.
Both lessons are true. Neither is the map for what founders face now, because Facebook and Twitter were distribution platforms. They owned the audience, and the threat was always access: they could raise the toll or close the gate. Your product and their business were different products. Facebook never shipped its own FarmVille.
A foundation model lab is a different animal. It is not your distribution channel; you bring your own customers. It is your capability supplier. The intelligence in your product is manufactured by them, metered by them, and improved by them on a schedule you don’t control. And unlike Facebook, the lab’s expansion path runs directly through the products built on top of it. When the model gets better, some percentage of the products built on last year’s model gaps stop being products and start being features. OpenAI’s DevDay in October 2023 was the first mass demonstration: document upload arrived and a shelf of “chat with your PDF” startups became a checkbox; custom GPTs arrived and a wave of assistant builders became a template gallery. Jasper, the flagship of the wrapper era, reportedly watched revenue fall about 70 percent as long-form writing became a free default inside ChatGPT.
So the threat model inverted. The 2010s platform hurt you by cutting access. The AI platform hurts you by improving. Nobody revokes your key. Your integration works flawlessly the morning their new release makes your product unnecessary.
The scale of what sits downstream makes this a first-order question now. Menlo Ventures pegged enterprise spend on LLM APIs at 8.4 billion dollars by mid-2025, up from 3.5 billion six months earlier, inside a 37 billion dollar enterprise AI spend that tripled in a year. That is an economy’s worth of products standing on three suppliers. By Menlo’s count, Anthropic, OpenAI, and Google together serve nearly 88 percent of enterprise LLM API usage. Concentration like that is not automatically a crisis. It becomes one for the specific companies standing where a supplier decides to walk. The rest of this post is about knowing whether that’s you, and moving before it is.
| Dimension | 2010s platform risk (Facebook, Twitter) | AI platform risk (foundation model labs) |
|---|---|---|
| What you depend on them for | Distribution: their users, your product | Capability: your users, their intelligence |
| How they hurt you | Revoke access, raise the toll, change the rules | Ship your product as a feature; absorb the category |
| Warning signs | Policy changes, API pricing letters | Launch events, acquisitions, vertical hires |
| Your integration when it happens | Breaks loudly | Keeps working while demand drains away |
| The defense | Own your distribution | Own a layer the lab will not absorb |
The Stack Creep Map: Four Directions of Absorption
To defend against a supplier, you first need to know which way it’s walking. I track lab expansion in four directions, and each direction is lethal to a different kind of startup. I call it the Stack Creep Map.
Direction one: UP, into app surfaces
This is the oldest direction and the best documented. The labs’ consumer and business apps keep eating the feature layer above the API. Document analysis, code execution, memory, scheduled tasks, artifacts, app stores, agent modes: each one shipped as a keynote feature, and each one had been somebody’s startup the quarter before. The pattern earned its own graveyard sites, and the deaths were rarely dramatic. The wrapper startups didn’t get shut off; they got outgrown. If your product’s core loop can be described as “the model, plus a nicer interface for one use case,” you are in this direction’s path, and I’ve written a whole post on the wrapper trap about climbing out of it.
Direction two: DOWN, into silicon and compute
By mid-2026, one leading lab was reported to be in early talks with Samsung to manufacture a custom inference chip on a 2 nanometer process, following the path Google walked with TPUs and Amazon with Trainium. Down-stack moves rarely kill application startups directly. What they change is the cost curve and the margin structure underneath everyone. A lab that owns its inference silicon can price tokens below competitors’ marginal cost when it wants market share, which resets the economics for every product doing heavy inference, including yours. If your margin depends on reselling or routing compute, this direction is aimed at you; I covered the picks-and-shovels side of this in AI infrastructure plays for indie builders.
Direction three: OUT, into verticals
This is the direction that changed in 2026, and it’s the one that should reset your threat model. Selling a science workbench to pharma researchers is a tools business. Announcing your own drug development programs while selling that workbench is something new: the supplier entering the customer’s industry with the customer’s money. The lab’s own leadership framed the drug programs as a way to build credibility and firsthand experience for its biopharma tooling. I believe them. That is exactly what makes it structural rather than sinister: doing the customer’s job yourself is the best possible training data for the tools, and the best possible tools business funds doing the customer’s job. The flywheel only spins one way, and it spins toward your market. Health records, legal research, financial analysis: every regulated vertical with expensive human workflows is a candidate. If you sell AI into a vertical, the question is no longer whether a lab enters it, but which layer of it you hold when they do. My vertical AI SaaS playbook covers wedge selection; this post covers what to hold.
Direction four: IN, into your workflow
The quietest direction. One major lab closed six acquisitions in the first quarter of 2026 alone, nearly matching its total for all of 2025, and the pattern in the targets is developer tooling, evals, experimentation platforms, and agent frameworks. Roughly half of its acquisitions featured open-source components, which reads as goodwill and functions as adoption. None of this attacks your product. It attacks your exit options. When the vendor’s SDK is your framework, its evals are your test suite, and its agent runtime is your orchestration, the practical cost of ever switching vendors climbs a little with every sprint. You didn’t sign an exclusivity deal. You accreted one.
Four directions, one common property: not a single one of them requires the lab to touch your API access or violate a term of service. Stack creep is not a breach. It’s the business model working as designed, which is exactly why the 2010s playbook, watch for policy changes and keep your key safe, misses it completely.
The Three Invoices: What You Actually Pay a Model Vendor
Karp’s charge against the labs was that they profit from an enterprise three times: they charge for tokens, they gain access to IP and know-how, and eventually they commoditize the customer’s edge. As stated, it’s a competitor’s caricature. But underneath the caricature is a real accounting insight that most founders haven’t done for themselves. When you build on a model vendor, you pay three different invoices, and only one of them shows up in billing.
The first invoice is the token bill. Metered, visible, negotiable, and honestly the least interesting of the three. It’s also the only one most founders manage. Whole teams exist to shave 30 percent off inference spend while the other two invoices compound silently. I wrote about the margin mechanics in revenue models for AI products, so I’ll leave the token bill there.
The second invoice is the demand receipt. Every successful product built on a model is a proof, visible to the whole market including the vendor, that a category of demand exists and that current model capability is sufficient to serve it. You cannot avoid issuing this receipt. Your landing page issues it. Your case studies issue it. Your job postings issue it. When a wave of “chat with your documents” startups hit traction in 2023, they collectively proved the category was worth absorbing, and it was absorbed within the year. The receipt is not your data leaking; it’s your existence signaling. Traction in a shallow category is a term sheet you write for your own replacement.
The third invoice is the switching debt. Menlo Ventures’ enterprise data shows how this one compounds: in their 2025 survey, only 11 percent of teams had changed model providers in the previous year, while 66 percent had upgraded to newer models from their existing vendor. Read those two numbers together. Teams overwhelmingly deepen the relationship they have rather than shop the market, not because switching is impossible but because every convenience adopted, vendor SDK, proprietary tool-calling format, fine-tunes, batch APIs, agent runtimes, adds a brick to the wall between you and the second-best option. The vendor’s developer experience team is, among other things, a switching-debt origination desk. The debt is real even if you never intend to switch, because your negotiating position on every other term is a function of how credibly you could.
| Invoice | What you pay | Where it shows up | How to shrink it |
|---|---|---|---|
| Token bill | Metered inference cost | Your monthly invoice | Caching, routing, model right-sizing, price it into your product |
| Demand receipt | Proof your category is worth absorbing | Their roadmap, 6 to 18 months later | Only build where the receipt is expensive to act on (deep workflow, regulated last mile) |
| Switching debt | Accrued cost of ever leaving | Your architecture, your negotiating position | Thin abstraction layer, portable evals, quarterly swap drills |
You cannot zero all three invoices, and trying is its own failure mode. Founders who obsess over the token bill build caching Rube Goldberg machines while standing in a shallow category. Founders who panic about the demand receipt go dark, stop marketing, and die of obscurity instead of absorption. Founders who fixate on switching debt build seven-provider abstraction layers before they have seven customers. The skill is knowing which invoice is the dangerous one for your specific product, and the next two sections give you the tools to work that out.
What the Lab Actually Sees (It Is Not Your Data)
Karp’s IP line lands because founders already half-believe a paranoid version of it: the fear that everything you send the API is feeding the vendor’s next model, so your prompts and your customers’ documents are training your replacement. That version is mostly false, and the truth matters because it redirects your defense budget.
Here is the actual policy baseline, and it’s worth reading your own vendor’s terms rather than trusting a blog post, including mine. The major labs do not train on business API data by default. One leading lab cut standard API log retention to 7 days in late 2025 and states API inputs and outputs are not used for training. Its main rival makes training exclusion the default on business tiers and offers zero data retention agreements on its enterprise tier, where prompts and completions are not stored beyond the processing window. These are contractual commitments that enterprises audit; violating them would be existential for the vendor’s B2B business. Your prompts are not secretly training the model that replaces you.
So relax? No. Redirect. The uncomfortable truth is that the lab does not need your data to absorb your category, and the proof is that every absorbed category so far was absorbed without it.
What the lab actually sees is cheaper than your data and impossible to encrypt:
It sees aggregate usage shapes. Not your prompts, but the fact that millions of tokens flow through document-heavy workloads, or coding workloads, or support-ticket workloads. Capacity planning requires this. Roadmaps are downstream of capacity planning.
It sees the public market. Your launch post, your pricing page, your case studies, your Product Hunt badge, your conference talk. The demand receipt from the last section is issued in public. Nobody at a lab needs to peek at API traffic to notice that “AI scribe for clinicians” raised four hundred million dollars across twelve startups; TechCrunch covers it.
It sees its own app data. The consumer and business chat apps run under different terms than the API, and their usage tells the vendor exactly which use cases people attempt, where the model fails, and which features would capture the most engagement. The features that killed the wrapper class were prioritized from this signal, not from anyone’s API business data.
And it sees what everyone sees: which categories are shallow. When a use case works in a demo with a generic prompt, it will work as a feature. The 2023 DevDay deaths were not intelligence operations. They were the vendor shipping the obvious.
This reframe changes where you spend. The paranoid version has founders burning weeks on prompt obfuscation and self-hosting deliberations to protect secrets the vendor never wanted, while leaving the actual exposure, a shallow category loudly validated, completely unaddressed. Contractual data protections are table stakes and you should have them: training exclusion confirmed in writing, retention terms understood, zero data retention if your customers’ compliance requires it. I walk through that checklist in the AI governance stack. But understand what those protections buy. They protect your customers’ confidentiality. They do not protect your business model. Nothing in a zero data retention agreement stops the vendor from shipping your product next quarter, sourced entirely from what you told the world on purpose.
The Absorption Test: Five Questions That Score Your Exposure
After watching this cycle repeat since 2023, in my own products and in a few dozen founders’ products I’ve reviewed, I’ve compressed the exposure question into five yes-or-no questions. I run them on both of my companies every quarter. Answer honestly; the test is cheap and self-deception is not.
A walkthrough of the five, because the scoring is only useful if you answer them the way an investor would, not the way a founder in love answers.
Question one: is your core value a missing model feature? Be brutal about the word “core.” In 2023, “handles long documents” was a product. In 2024 it was a parameter. If the honest pitch for your product is that the model can’t yet do X reliably and you’ve taped over the gap, you are renting a hole that the landlord is actively filling. Products built in model gaps have the shelf life of the gap, which is measured in release cycles, and my post on surviving model churn shows how short those cycles have gotten.
Question two: does the user’s job finish inside the vendor’s surface? Follow the output. If your product’s result gets pasted back into a chat app, or your product is a thin detour between the user and the model’s own interface, the vendor’s UX team is already working on removing the detour. If the job finishes in your system of record, your audit trail, your filing with a regulator, the vendor’s surface can grow forever without touching you.
Question three: would your data loop stop compounding if you swapped the model? This one separates real data moats from rented ones. Feedback data that lives in your evals, your labeled outcomes, your workflow database, keeps compounding no matter whose model runs inference. Advantage that lives inside one vendor’s fine-tuning pipeline is a deposit in a bank you don’t control. I wrote the longer version in the data moat playbook: the loop is the moat, the pile is not.
Question four: is your price anchored to the vendor’s price? Cost-plus pricing on top of a deflating input is a slow leak. Token prices have fallen off a cliff for equivalent capability, and every cut invites your customers to ask why your price hasn’t followed. If you charge for outcomes, seats doing valuable work, or workflow ownership, vendor price moves are margin news, not existential news. I made the full argument in AI product pricing.
Question five: could the vendor demo your product with a generic prompt? The keynote test. Picture the vendor’s next launch event. If a presenter with no knowledge of your domain could reproduce your core loop on stage with a clever prompt and a screen recording, your category is demo-able, and demo-able categories get demoed. What cannot be demoed on stage: ten years of transaction records, a certified integration with a regulator’s filing system, a liability-bearing review workflow, a distribution list of forty thousand practitioners who trust your name.
Score in hand, you know which ground you’re standing on. The next section is about the ground itself: the specific layers where a startup can build that the labs, for structural reasons rather than lack of appetite, will not follow.
The Survivable Layers: What Labs Will Not Absorb
Before the layers, place this post in the trilogy it belongs to, because the three questions get conflated and they have different answers. The wrapper trap asks: is my product deep enough to be a product today? Model churn asks: does my product survive the vendor’s next release? Platform risk asks: does my company survive the vendor’s next business model? You can pass the first two and still fail the third. A deep, churn-resistant product in a vertical the lab decides to enter is a well-built house in a flood plain.
The good news is that lab economics are legible, and they point away from five specific layers. A frontier lab is a machine for selling generalized intelligence at maximum scale. Its valuation, by mid-2026 approaching a trillion dollars for the leader, prices in serving every industry at once with one model family and thin, standardized product surfaces. That machine has allergies. It is allergic to head-count-heavy services, to niche sales cycles, to carrying legal liability for domain outcomes, and to anything that doesn’t amortize across the whole customer base. Those allergies are your real estate.
| Layer | Why the lab will not take it | What building it looks like |
|---|---|---|
| System of record workflow | Requires deep, niche integrations that do not amortize across a general customer base | Your product is where the work legally and operationally lives, not where it gets drafted |
| Proprietary data loop | Outcome labels are generated by your workflow position, not purchasable at any price | Every completed job improves routing, evals, and pricing in vendor-portable form |
| Regulated last mile | Labs sell tools and disclaim outcomes; carrying liability breaks their margin structure | You hold the license, the audit trail, the E&O policy, and the accountable signature |
| Cross-vendor routing | No single vendor will ever optimize your independence from itself | Thin abstraction, portable evals, the ability to swap models in days without product change |
| Taste and distribution | Trust and judgment in a niche are earned serially; capital cannot parallelize them | A named point of view, an audience that buys from you, standards the market adopts |
Layer one: system of record workflow. The lab’s product surface is a conversation. Yours should be the place where the work is filed, tracked, approved, and audited. In my transaction coordination business, the model drafts and checks documents, but the product is the workflow spine: deadlines, compliance states, handoffs, an audit trail a broker can show a regulator. A chat app can generate any single artifact in that chain and it would not matter, because no one runs a hundred-deal pipeline out of a chat thread. Depth of workflow is boring to demo, brutal to replicate, and invisible from a keynote stage, which is exactly the point.
Layer two: the proprietary data loop. Not a data pile, a loop. The distinction from the data moat playbook bears repeating here because platform risk sharpens it: your loop must compound in a form you own. Outcome labels, error taxonomies, eval suites, routing rules learned from thousands of completed jobs. Stored in your infrastructure, applied at inference time to whichever model is best this quarter. A loop with that shape converts every model improvement, from any vendor, into your margin. A loop trapped in one vendor’s fine-tunes converts your effort into their lock-in.
Layer three: the regulated last mile. Notice what the lab did when it entered pharma: it picked neglected diseases, a category with sympathetic framing and thinner commercial competition, and it sells the workbench while partnering for the regulated parts. Labs enter verticals as tool sellers and demand aggregators; they do not want to hold the malpractice policy, the fiduciary duty, the state licenses, or the clawback risk. If your product carries the liability and the compliance surface, you are not competing with the lab, you are the thing that makes its output usable in your industry. This is the deepest version of the wedge I described for AI in regulated industries, and it’s why boring industries with licensing regimes are the best places a founder can build.
Layer four: cross-vendor routing. The market has already voted on this one. Menlo’s data shows 37 percent of enterprises now run five or more models in production, and multi-provider adoption jumped from 23 to 40 percent in ten months. Buyers want portfolio exposure to intelligence, not marriage to a vendor. If your product routes across vendors with portable evals deciding which model earns each task, you convert the labs’ rivalry into your input price competition, and every price war between them widens your margin. Note the honest caveat: routing is insurance and negotiating posture, not a moat by itself. Everyone can buy an abstraction layer. Combined with layers one through three, though, it makes you the only party in the transaction with no structural loyalty.
Layer five: taste and distribution. The layer capital cannot compress. A lab can replicate any feature in a quarter; it cannot replicate being the name a niche trusts, the standard a market wrote its process around, or the judgment to know which output is actually good. I’ve made the long case in the taste moat. In the platform risk frame, taste and owned distribution do something specific: they survive absorption events. When the vendor ships a competing feature, the audience that bought your judgment doesn’t evaporate the way feature users do. Ask the newsletter writers who outlived every content tool wave.
Five layers, one design principle: build so that the lab improving makes you stronger, not optional. The full map of where these opportunities sit is in my AI opportunity map, but the compressed version is this: stand where the flywheel pushes you forward instead of running you over.
The Contrarian Take: Platform Risk Is a Subsidy
Now the part most coverage of the Karp flare-up got wrong. The standard read is that building on the labs has become too dangerous, that smart money avoids the blast radius, that the future belongs to sovereign stacks and owned weights. I think that read fails both on the evidence and on the strategy, and I’ll take them in order.
First, the evidence. The same expansion that threatens shallow products is the largest subsidy ever handed to founders who hold a survivable layer. The cost of a unit of intelligence collapsed by a factor of roughly 280 in two years for equivalent capability, per Stanford’s AI Index. The labs spent hundreds of billions of raised capital to make that happen, and they charge you pennies on the dollar of what the capability costs to create because they are locked in a price war with each other. If you own the workflow, the loop, and the last mile, every launch event you were supposed to fear is your input cost falling and your product getting better without an engineering sprint. The correct emotional response to your supplier’s keynote, if you’re standing on the right layers, is greed, not dread.
Second, the strategy. The sovereign pitch, own your models, own your weights, escape the platform, is the right answer for governments and a trap for startups. You do not escape a supplier by becoming a worse version of it. A startup that diverts capital from workflow depth to model ownership buys itself a permanently inferior model plus a new full-time job, while giving up the one advantage it had: being the best buyer in a buyer’s market. The startups that died since 2023 did not die from insufficient sovereignty. They died from standing in the vendor’s path with nothing the vendor couldn’t demo. Chatbase’s founder was told his product was a weekend project on borrowed capability; the ones who listened built depth, the ones who didn’t became keynote slides.
And the fear itself is mispriced in one final way: absorption is a sign you found real demand. The categories the labs absorb are, by definition, the validated ones. That means the demand receipt you inevitably issue can be spent on purpose. Launch the shallow version to prove the category, then race the absorption clock to move value into the layers the lab won’t follow: that is not a bug in the era, it is the actual playbook of the era. Platform risk punishes the stationary, not the downstream.
What to Do Monday Morning
Six moves, in order of return on effort. This is the audit I run on my own companies each quarter, and none of it needs a committee.
1. Run the Absorption Test on your core product. Five questions, ten minutes, write the score down with a date. If you scored 4 or 5, your real deadline is the next major launch event, and your roadmap for the quarter is moving value into workflow, loop, and last mile. If you scored 0 or 1, stop reading defensive posts and go compound your lead.
2. Read your vendor terms once, properly. Confirm training exclusion on your tier in writing. Know your retention window. If you serve regulated customers, get the zero data retention agreement or document why you don’t need it. One hour, and it also becomes sales collateral for your next enterprise deal. The governance stack post has the full checklist.
3. Price the swap, then thin it. Write down, in engineer-days, what swapping your primary model vendor would cost today. If the answer is “we don’t know,” that’s the finding. Get to a thin abstraction with portable evals so the answer is measured in days, then actually run a swap drill on one workload per quarter. Menlo’s numbers say only 11 percent of teams switched vendors last year; you don’t need to switch, you need the credible ability to, because that ability reprices every other term.
4. Move one loop asset out of the vendor’s walls. Pick the highest-value thing currently trapped in vendor-specific form, a fine-tune, prompt library keyed to one model’s quirks, evals that only run on one API, and rebuild it vendor-portable. One asset per quarter compounds fast.
5. De-anchor your pricing from tokens. If your invoice line reads like a markup on inference, restructure toward outcomes or workflow value this quarter, before a vendor price cut forces the conversation on worse terms. The pricing post has the models.
6. Put the labs’ launch events on your competitive calendar. Watch keynotes the way you’d watch a competitor’s earnings call, because that’s what they are: a quarterly disclosure of which direction the stack creep is walking. Update your map, rerun the test, adjust one thing. Fifteen minutes a quarter is enough to never be surprised.
The founders who get hurt by platform risk are almost never the ones who knew their exposure. They’re the ones who never priced it, because the integration kept working and the invoice only showed tokens.
FAQ: AI Platform Risk
What is AI platform risk?
AI platform risk is the exposure a company takes on when its product depends on a foundation model vendor that can absorb the company’s market. It has two halves: the classic dependency risks (pricing, terms, access) and the newer structural risk that the vendor expands up, down, out, or into your category, turning your product into one of its features. The second half is the dangerous one, because nothing breaks when it happens; demand simply moves to the platform.
Do OpenAI and Anthropic train their models on my API data?
By default on business API tiers, no. The major labs contractually exclude business API data from training, and enterprise agreements add short or zero retention windows. Confirm your specific tier’s terms in writing. The practical risk is not your prompts training your replacement; it is your public traction proving your category is worth absorbing, which requires no access to your data at all.
What is stack creep?
Stack creep is a model vendor’s expansion beyond selling intelligence by the token: up into app surfaces and features, down into custom silicon and compute, out into vertical industries like science and healthcare, and inward into developer workflows through SDKs, tooling, and acquisitions. Each direction absorbs a different class of startup, and each is a rational extension of the vendor’s economics rather than a hostile act.
How do I know if my AI startup is at risk of being absorbed?
Run the five-question Absorption Test: Is your core value a missing model feature? Does the user’s job finish inside the vendor’s surface? Would your data loop stop compounding if you swapped models? Is your price anchored to the vendor’s? Could a keynote demo reproduce your core loop with a generic prompt? Four or five yes answers means your category is on a roadmap somewhere; zero or one means you hold defensible ground.
Should I build my own model to escape platform risk?
Almost never. Training your own frontier-class model is capital you don’t have spent acquiring a permanently worse input, and open-weight self-hosting buys independence at the cost of quality, speed, and a new operational burden. The escape from platform risk is not becoming your own supplier; it is owning workflow, data loops, the regulated last mile, and distribution, the layers where the supplier structurally will not follow.
Is multi-model architecture worth it for an early-stage startup?
A thin version, yes: a minimal abstraction layer and evals that run identically across vendors, so a swap is measured in days. A heavy version, no: routing infrastructure across seven providers before product-market fit is procrastination wearing an architecture diagram. Treat multi-model as insurance and negotiating posture. The market is heading that way regardless: over a third of enterprises already run five or more models in production.
How is AI platform risk different from the wrapper trap?
The wrapper trap is a product question: is there enough depth beyond the model call to justify existing today? Platform risk is a market structure question: does your company survive its supplier’s expansion tomorrow? A product can be genuinely deep and still sit in a vertical the vendor enters. You escape the wrapper trap by adding depth; you survive platform risk by choosing which layers the depth lives in.
What moats actually survive foundation model expansion?
Five layers hold up: system-of-record workflow (the job legally lives in your product), proprietary data loops stored in vendor-portable form, the regulated last mile where you carry the license and liability, cross-vendor routing that converts lab rivalry into your input pricing, and taste plus owned distribution, the trust that keeps customers when features get cloned. Features, interface polish, and model-gap patches do not survive; they are the absorption zone.
I write one deep playbook like this every day at the intersection of AI, entrepreneurship, and personal growth. If this one changed how you think about your stack, the AI opportunity map is the parent guide, and how founders should think about AI is where the whole system starts.