Introduction
For two years, adopting AI was the easy part. You bought the seats, shipped the features, and told the board a good story. No one sent an invoice.
In 2026, the invoices arrive, and they do not look like invoices. They look like a reclassification letter under the EU AI Act. A migration that stalls halfway. A vendor bill that jumps 80% overnight. A productivity number your CFO has quietly stopped believing. The speed had a cost, and this is the year it comes due.
Q1-Q2 2026 industry research maps nine separate friction points across the business, from compliance to sales to customer success. Four sit with other teams, sales, marketing, ops, and customer success. The other five land squarely on engineering. Here is what the data shows for each, what we see when we walk into codebases dealing with them, and what actually helps.
What the EU AI Act Actually Requires of You
The EU AI Act’s obligations for high-risk AI systems were first set to apply from August 2, 2026. That date has moved. In June 2026 the EU adopted the Digital Omnibus, which defers the deadline for stand-alone high-risk systems under Annex III to December 2, 2027, and for high-risk AI embedded in regulated products under Annex I to August 2, 2028. Two things were not deferred and still apply: the transparency rules and the AI literacy duty, in force since February 2025, which requires documented staff training rather than informal onboarding. The extra time is real, but it is time to prepare, not time to ignore.
Two things are worth getting right now: the penalties and your classification.
The penalties are not one number, they are two tiers, and most product teams worry about the wrong one. Breaching high-risk obligations, things like technical documentation, risk management, and human oversight, carries fines up to €15M or 3% of global annual turnover, whichever is higher, under Article 99 of the Act. The €35M or 7% figure that gets quoted everywhere sits one tier above that and applies to outright banned uses, not to the high-risk obligations most teams actually face. Knowing which tier applies keeps your compliance response proportional to the real exposure.
Then classification, which is where teams miscategorize themselves. If you build an AI system on top of a third-party model and ship it under your own name, you are generally the provider of that system, not just a downstream user, even if you never touched the underlying model. On top of that, Article 25 flips a deployer into a provider in three specific cases: you put your name or trademark on an existing high-risk system, you substantially modify one, or you change a system’s purpose so that it becomes high-risk. Provider status is where the heavy obligations sit for high-risk systems: audit logs, technical documentation, and documented human oversight. Most mid-market teams built none of that, because they assumed they were downstream users.
What we see: the human-oversight requirement is the one teams underestimate. A Slack channel where someone eyeballs model outputs is not an oversight mechanism a regulator will accept. It needs to be a logged, reviewable step in the system, which means it is an architecture decision, not a policy PDF. If you are building AI features into a regulated product, treat oversight and audit logging as first-class components from the start. Our agentic AI development work in fintech and healthcare bakes this in rather than bolting it on later.
Engineering Teams Are Measuring the Wrong Thing
A pattern engineering leaders have started calling “tokenmaxxing” has become a top concern: measuring AI productivity by raw token consumption instead of by output quality or business outcome.
This breaks in two directions. CFOs and boards, after roughly 18 months of high-volume AI spending, are asking leaders to justify token metrics in outcome terms and getting nothing usable back. And internal token leaderboards, built for visibility, are reshaping team culture. Junior engineers learn that high AI interaction volume signals competence, rather than the quality of judgment applied to model output.
What we see: the teams that stay effective treat AI output the way they treat a junior PR, as something to be reviewed and verified, not counted. The metrics worth tracking are outcome-based: time from AI output to verified working code, and the rate of AI-authored code that fails in production. Track token spend as a constraint against margin, not a scoreboard. If you cannot yet measure how often AI-written code breaks after a merge, that is the first instrument to build.
Our co-founder Roman Rodomansky made the same argument on stage at DevWorld Amsterdam: token count spikes the moment someone uploads a PDF, so it measures activity, not quality. We wrote up his take on measuring AI adoption without tokenmaxxing.
Legacy Infrastructure Is Now
a Talent Problem
Roughly 33% of engineering time at mid-market companies goes to maintaining existing systems rather than building new ones, per Saritasa’s survey of 500-plus US IT professionals.
Behind that number is a narrower squeeze. NIX United’s migration analysis calls it the “dead language” bottleneck: COBOL, older Java releases, and pre-modern PHP stacks whose specialist pool is actively shrinking. As the pool contracts, retention costs rise, while modifying undocumented code written by developers who have since left remains high-risk. There is a security dimension too. Older TLS versions on legacy systems are uninspectable by modern monitoring, so lateral movement or data exfiltration through those channels can go undetected until after a breach.
What we see: the risk almost always sits in the parts nobody wants to touch, the module with no tests and no original author. Rewriting it all at once is how modernization projects die. The move that works is strangler-pattern migration: wrap the legacy system, route new functionality through modern services, retire the old code path by path, with tests going in first.
AI Agents Are Quietly Rewriting
SaaS Pricing
Two related trends, documented in SaaStr community data and the Teneo 2026 B2B Software Vendor Survey, are breaking seat-based pricing.
The first is stealth churn: customers reduce actual usage as AI agents displace human seats, without reducing seat counts or initiating a cancellation, until a renewal review forces the issue. The second is internal displacement: teams using AI coding agents to build internal tools that replace SaaS subscriptions, in some documented cases displacing $20,000-plus in annual vendor spend. At the same time, vendors whose pricing scales with agent activity are seeing customers challenge bill increases of 80% or more.
What we see: the build-versus-buy line has genuinely moved, but the trap is treating an internally built replacement as a weekend project. An agent can scaffold the first version fast. Keeping it reliable, observable, and secure over two years is the actual cost, and it does not show up in the demo. We help teams make that call honestly and, when building is the right answer, build agent systems that hold up in production rather than becoming next year’s legacy problem.
Let's explore your use case and define where agentic AI development services can bring the most value.
The Data Layer Is the Real Constraint on AI-Ready Infrastructure
CIO.com’s 2026 analysis identifies the data layer as the binding constraint in most mid-market modernization programs. Real-time pipelines and automated cleansing are prerequisites for AI-ready infrastructure. Most companies in this segment are still running data warehouses built for periodic reporting rather than continuous AI consumption.
This is the least visible of the five and the most blocking. You can ship an AI feature on top of a batch-oriented warehouse, but it will be stale, challenging to trust, and expensive to fix once it is in front of customers.
What we see: teams reach for the model and the agent framework first, then discover the data feeding them is inconsistent, delayed, or duplicated across the systems from point 3. The order that works is the reverse. Get the pipeline continuous and the data clean, then layer AI on top. Data engineering is unglamorous, and it is the difference between an AI feature that works and one that quietly erodes trust.
The Pattern Underneath All Five
These are not five unrelated fires. Three drivers show up across all of them.
Governance lag
AI adoption outpaced the governance to support it, across compliance, measurement, and procurement. Most of what looks like a 2026 crisis is governance being built retroactively, under time pressure.
Architectural debt
Core infrastructure built before 2022 is increasingly incompatible with 2026 requirements, and the gap between the cost of modernizing and the cost of not modernizing is widening.
Measurement misalignment
Seat counts and token volumes do not map to the outcomes boards now demand. Until measurement is redefined, justifying continued spend stays hard.
Here is our take after building these systems: the companies making real progress are not the ones with the biggest AI budget. They are the ones treating governance, architecture, and measurement as one connected problem. Fix any single point in isolation, and you buy temporary relief while the root cause moves to the next fire. The work that lasts is the work that addresses the layer underneath all five.
Working on One of These?
All five trace back to the same gap: AI moved faster than the architecture, governance, and measurement underneath it. That gap is where we work. We build production-grade AI and agent systems, modernize the legacy code that blocks them, and get the data layer ready to feed them, for teams that need the result to hold up in front of real users, not just in a demo.
If one of these five is your problem right now, tell us where you are stuck and we will tell you honestly whether it is worth building, fixing, or leaving alone. Start a conversation with the Ralabs team.
