The enshittification of AI: How the products you depend on are being quietly degraded

AI features rarely fail with a bang. They fade, slowly, in the background: answers get a little noisier, costs creep up, and the “easy” workflow starts demanding more oversight than you planned for. Product leaders feel this as a hundred paper cuts, not a single incident. That slow slide has a name, the enshittification of AI products.

What makes this tricky is that the technology can still look impressive while the incentives around it shift toward extraction. A tool that started as a boost can turn into a dependency, and dependency turns ordinary vendor decisions into product risk. We’ll walk through how that risk forms, why it tends to show up as small frictions instead of clear breaking changes, and how money, concentration, and privacy pressures quietly shape the experience your users end up living with. Most importantly, we’ll focus on the practical moves that keep you in control, even when the platform you’re building on changes the rules.

Dependency dynamics: When early AI adoption becomes structural risk

If you’re a product leader, AI adoption almost never starts as a big, formal strategy. It usually starts as a shortcut that’s hard to ignore: a platform that’s free or cheap, a pilot you can ship fast, and a team that suddenly looks superhuman.

But that early phase isn’t neutral. The pricing is the hook. Once your workflows, roadmap, and customer expectations depend on a model you don’t control, the platform can start reshaping the relationship.

Here’s the quiet pivot: as your dependence grows, the platform has reasons to prioritize businesses through ads, surveillance, and paid placements. That prioritization changes what your users see and what your team can measure.

You’ll feel it first as friction. Then you’ll realize it’s structure.

As the platform tightens its grip, a few dependency dynamics tend to show up together:

• Privacy gets compromised as surveillance becomes a monetization layer, which can collide with your brand promises.
• Walled gardens emerge, so integrations that once felt easy become gated, priced, or strategically limited.
• Lock-in risks increase around critical IP and data, because the most valuable learning loops now live inside someone else’s system.

None of this requires the technology to fail. In fact, experts have pointed out that the business models are often the flawed part, not the underlying capability, especially when you examine the broader ethical implications of AI.

At the same time, product reality is messier than the demos. AI outputs make mistakes and need human oversight, and even AI firms admit there are limits to output quality. If you don’t design for that oversight, you’re effectively outsourcing your quality bar to a probabilistic system.

There’s another cost that can hide in plain sight: nonconsensual AI-generated content can create unpaid labor, where people’s work gets absorbed into the machine without permission, credit, or compensation.

This is the enshittification of AI products in the adoption phase. What begins as acceleration can drift into extraction, especially in a culture of speed at all costs that treats risk as a problem for later.

Later is arriving. Consumer groups in the EU are advocating for a Digital Fairness Act, and the broader trend isn’t destiny because the harms are reversible with policy. The strategic move now is to map where you’re becoming dependent, then look at how the hidden capability inside these systems can be used without surrendering your leverage.

Capability overhang: Turning hidden model power into leverage

Start by spotting the moments where an AI system has quietly become the default step in your workflow. Then build an exit ramp while it’s still easy.

Here’s the uncomfortable part about the enshittification of AI products. They almost never get worse with a clear “breaking change.” They degrade through small frictions: more ads where you expected answers, more lock-in dressed up as convenience, and more “good enough” output that pushes quality control onto your team, mirroring what Doctorow’s enshittification cycle predicts.

That’s the trap Doctorow’s cycle describes. Platforms start by treating users well, then pivot to business customers, and eventually extract value from everyone once dependence is high. AI products are still early in that arc, which is why you still have real choices.

Capability overhang is where you can take back control. The models can do more than most products let you safely access because the interface, the defaults, and the business model are tuned for growth, not your outcomes.

You can hold both clarity and urgency here, without panic.

You see the symptoms already. Outputs contain errors that need human oversight, and that oversight isn’t a rounding error. Nonconsensual AI content shows up in feeds, inboxes, and search, so users waste time sorting reality from sludge. Meanwhile, AI-generated pages can drown out organic results, and your discoverability starts depending on systems you don’t control.

So the job isn’t “use more AI.” It’s capture the upside without accepting the dependency.

A straightforward way to do that is to separate capability from packaging:

• Treat model output as a draft, not a decision, then build review steps where the risk actually lives.
• Keep your prompts, evaluation rubrics, and workflows portable so you can switch providers when the ad load rises or reliability slips.
• Define what content you will not ingest or generate, because cleanup costs compound when nonconsensual material becomes normal.

Do this and the system’s hidden potential works for you, instead of quietly rewriting your operating model.

The broader debate matters, too. Some skeptics argue the AI business model is fundamentally unsustainable, and that the hype could end up looking like fraud driven more by economic pressure than technical limits. Whether or not that’s how history judges it, the practical implication is the same: assume incentives will drift toward extraction unless something counters them.

Regulation is one counterweight. Doctorow has warned that more ads inside LLM experiences are a likely next move. The EU Digital Fairness Act is one example of a policy effort aimed at reversing that kind of slide.

Hold onto that thought. Once you’ve mapped where overhang can become leverage, you’re ready to see why so much money is rushing in anyway, and how that surge can distort product decisions long before it improves user outcomes.

Investment surge: When AI growth starts extracting value

Build guardrails before the ad load shows up. And price your own patience now, because the funding wave is about to ask for receipts.

The biggest driver behind AI product “enshittification” usually isn’t one villain. It’s what happens when huge financial expectations collide with the messy reality of shipping real systems. With the broader AI market projected to reach $2.48 trillion by 2034, a lot of board decks quietly assume your product should become a platform, a tollbooth, or both. That mindset shows up early as pressure to “prove monetization” while users are still figuring out what the product is even for.

It starts as small, reasonable asks:

Add a paywall tier. Add a usage cap. Add a sponsor slot inside the assistant. Each move makes sense on its own. Put them together, and you drift away from usefulness as the North Star.

Then the supply side hits.

AI data centers are projected to consume the majority of high-end memory, and costs have already shown how fast they can jump, with DRAM prices rising over 50% quarter-over-quarter entering 2026. In product terms, inference gets more expensive, experimentation gets riskier, and the easiest path to margin stops being better quality. It becomes more extraction.

That’s where strategy matters. If you treat AI like a feature you can subsidize forever, you’re setting yourself up for abrupt degradations later. If you treat it like a business with explicit unit economics from day one, you can make tradeoffs on purpose, and users can actually predict what will happen.

Watch for three early distortions that investment hype tends to amplify: roadmaps that over-index on headline demos, measurement systems that reward engagement over outcomes, and vendor choices that lock you into pricing leverage you don’t control.

The goal isn’t to resist growth. It’s to decide ahead of time what you won’t sell off to get it, and to root that line in a clear, durable AI business strategy.

Once you see how financial gravity and infrastructure scarcity shape behavior, the next question is simple: who controls the underlying inputs, and how concentrated ownership can turn dependence into a one-way street.

Data monopolies: How hidden controls quietly degrade quality

Start by drawing a hard line around the inputs you don’t control: training data, inference capacity, and the monitoring signals that tell you when the system is drifting. When those inputs get concentrated, your product roadmap quietly turns into a negotiation, even if nobody calls it that.

This is where the enshittification of AI products stops looking like random “quality issues” and starts looking engineered. If a provider has the data advantage and the compute leverage, they can degrade performance in ways that feel like normal variance, while you take the user-facing blame and miss the larger pattern of engineered AI degradation dynamics.

It usually shows up first as a budget conversation. Then it becomes a governance conversation.

Two things cap your autonomy more than anything else: cost pressure and risk pressure. To manage both, stacks increasingly get designed to degrade on purpose. Synthetic data fills in when real signals are scarce or too expensive. Models get throttled when demand spikes. Data drift monitoring becomes the guardrail that decides when the system is allowed to be “good” versus merely “acceptable.”

If you depend on a single upstream provider for those choices, you don’t just buy a model. You buy their definition of acceptable.

One subtle move is controlled degradation through multi-model deployments. A smaller model can run alongside the full version and absorb routine traffic or lower-risk tasks. The full model gets saved for moments that justify the cost or the exposure. That can be a smart sustainability and unit economics play on your side, but it’s also a clean way for a gatekeeper to turn quality into a tiered experience without ever changing the marketing page.

That’s why EU AI Act persistence and AISecOps aren’t “compliance work” off to the side. They’re the language of leverage. The more your operating model depends on someone else’s controls, the more reactive your governance becomes, and the easier it is for anti-competitive dynamics to hide inside safety and efficiency stories.

So the job is to make dependency visible. Push for input optionality where you can. Where you can’t, insist on clear drift and throttling policies. Treat degradation paths as first-class product behavior, not an outage.

Once you can see where concentration turns into control, you’re ready to look at the specific organizations that design these incentives and benefit from them.

Major players: How quiet defaults degrade AI performance

Once you start asking for drift rules and throttling policies, you end up in a different kind of meeting. It is not about new features. It is about who gets to define what “good enough” means when the system is under pressure.

That is usually when the architects of AI product enshittification show up. They do not walk in wearing a “bad guy” label. They show up as default settings, procurement limits, and platform roadmaps that quietly treat performance like a cost you can dial down.

By 2026, it is normal for AI systems to run in reduced modes to test stability and cut costs. It is also normal for organizations to choose efficiency over peak performance or to prioritize deploying production-ready AI tools for businesses. Sometimes that is the right call. The problem is the loophole: once a “temporary” reduction becomes an approved way of operating, the product can slowly get worse without anyone calling it an outage.

You can feel it in the constraints platform and infrastructure providers bring to the table. Latency budgets, memory limits, and data locality rules decide what you can ship and where. Then teams start designing around the constraints instead of designing around user outcomes.

That is how control concentrates without anyone saying it out loud.

The most influential players are not always one company you can name. It is more like a pattern of decision makers at different layers of your stack:

• Platform operators who expose knobs for cost and safety, then encourage dynamic model selection based on cost, latency, and safety instead of raw capability.
• Infrastructure teams who normalize graceful degradation paths so utility is maintained during outages, which is good practice that can also mask chronic underprovisioning.
• Enterprise governance functions that require auditability, data lineage, explainability, and bias controls, which can legitimately reduce risk but also push you toward smaller, more constrained deployments.

None of these forces is automatically wrong. The problem is incentives. When your main levers are cost, latency, and compliance, capability becomes negotiable. The user experience is often the first thing you trade away because it is the hardest to audit.

Your job is to make those trades explicit. Treat reduced modes and degradation paths as first-class product behavior. Define what triggers them. Insist on visibility into when dynamic model selection is happening and why.

Once you can see how the stack makes performance conditional, it gets easier to ask the next uncomfortable question: what data is being extracted, from whom, and under what consent, as these systems chase efficiency.

Controversy spotlight: How “reasonable” data choices become privacy risks

If you can spot when a model shifts, you can usually spot when the data shifts, too. The tricky part is where privacy risk hides: inside “optimization” work that quietly expands what you collect, reuse, and keep, all while users are just trying to finish a task.

The signal is already loud. Data breaches are the top worry for 63% of AI users, and broader AI user privacy concerns are rising fast. That’s not vague anxiety, it’s a realistic read of how AI-dependent workflows widen the blast radius. When your product becomes a daily co-worker, more sensitive material is going to pass through it.

Now add mobile distribution to the mix. 72.6% of iOS apps track private user data. Even if your AI experience is “just a feature,” it still lives in an ecosystem where tracking, third-party SDKs, and analytics defaults are normal. Your privacy posture ends up being the sum of a lot of small decisions.

That’s where controversy gets earned.

Data mining is rarely one villainous act. It’s a chain of “reasonable” choices that combine into outcomes customers would’ve never agreed to if you explained them plainly.

You see it when teams add more prompts and outputs to logs “for quality,” then keep them “for debugging,” then route them into tooling “for productivity.” Suddenly, the most personal customer text is in more places than anyone can name.

You also see it when identity and access controls get treated as “the platform’s problem,” even though compromised identities are a dominant breach driver. Cloud incidents increasingly come down to configuration and permission mistakes.

If you don’t want privacy to become your next reputational cliff, design for controllable data flows the same way you design for controllable performance:

• Treat prompt, retrieval, and output data as different classes with different retention rules, not one big blob called “telemetry.” Write down what’s allowed for each.
• Make data boundaries visible in-product, especially when content is leaving the workspace, moving into a vendor system, or being reused for training or evaluation.
• Build an operational kill switch for collection and sharing pathways, so you can respond to policy violations, shadow usage, or a breach without shipping a full release.

You’re not promising perfect secrecy. You’re making privacy a product behavior with clear triggers, limits, and reversibility, so “efficiency” can’t quietly turn into extraction.

Final thoughts

The pattern is consistent: fast adoption becomes structural reliance, and then the definition of “good enough” starts moving outside your org. As costs rise and expectations harden, quality control shifts onto your team, while upstream providers gain more room to gate capability, steer workflows, and monetize attention or data. None of this requires a dramatic outage. It just requires you to keep shipping while your leverage shrinks.

The fix isn’t to swear off AI. It’s to treat dependency, degradation paths, and data flows as core product behaviors you design on purpose, with visibility, guardrails, and real exit options. If you can make incentives explicit and keep your critical workflows portable, you can capture the upside without accepting the slow bleed. The enshittification of AI products only feels inevitable when it’s invisible. What would change in your roadmap if you assumed the defaults will drift, and planned for that now?

Ready to elevate your business with data-driven strategies and expert insights? Contact OnInitiative.com ([email protected]) today and let our team help you grow smarter, faster, and more efficiently!

About us

OnInitiative.com is a digital innovation partner that empowers professionals and organizations to design smarter, more fulfilling lifestyles. Through custom software solutions, productivity tools, and travel-tech integrations, we help people reclaim time, reduce stress, and make the most of every moment, whether at work, home, or on the road.