The Technical Debts Diligence Still Doesn't Price - AI, Information and Technology

Saïd Toro made a useful argument in his recent piece for The National CIO Review, “Technology Diligence Is Broken.” Diligence, he writes, is built to answer the wrong question. It screens for what could kill the deal instead of asking, in his words, “what is technology worth to the investment thesis?” That reframing, pricing technology into the deal rather than just clearing it, is the thesis this post picks up. Toro’s examples, an ERP nobody modeled, a two-person IT shop carrying all the institutional knowledge, customizations that turn a bolt-on into a multi-year integration, are real and common. They are also just the visible layer.

Underneath them sits a second category of debt that a compressed diligence window rarely reaches: the architecture of the business itself. Where its workloads live, how its data is governed, who can access what and why, and whether the people running it can execute a modernization plan instead of just keeping the lights on. These debts do not show up as a red flag in a report. They show up eighteen months into the hold, as slow integration, stalled AI initiatives, and margin that never quite expands the way the model said it would.

Infrastructure Debt Is a Capital Decision Wearing an IT Disguise

Ask what percentage of a target’s infrastructure sits in owned data centers versus cloud, and you get more than a technology answer. You get a preview of capital intensity for the next five years. A company running 60% of production on owned hardware is not simply “on-prem.” It is carrying a depreciation schedule, a refresh cycle, and a physical footprint that a buy-and-build thesis has to absorb with every acquisition it bolts on.

Cloud doesn’t automatically fix this. It just moves the debt somewhere less visible. A target that migrated in a hurry, one workload at a time, with no consolidated landing zone, usually ends up with cloud sprawl instead of cloud discipline: workloads scattered across accounts and regions, redundant services, and a surface area that is expensive to secure and hard to reason about. Diligence teams price the AWS bill. They rarely price the fact that nobody can produce a current inventory of what’s actually running, or that many employees have their own accounts that are passing thru purchasing as office supplies leaving risk and governance gaps.

This is the same instinct that shows up in Toro’s ERP example, a decision that looked operational at the time and turns out to be structural. Infrastructure footprint deserves the same treatment: not a line item, but a constraint on how fast the thesis can move.

Data Debt Is the One That Compounds

This is where I’d push the diligence conversation further than most checklists go. Poor or absent data management rarely fails loudly. It fails quietly, in the reporting package that’s held together with a single analyst’s spreadsheet, in the margin figure that can’t be produced below the company level, in the “current” price list that’s actually eleven months old and nobody flagged it.

The failure mode gets worse, not better, once AI enters the picture. A model or an agent doesn’t know a document is stale unless something tells it. It will retrieve the wrong version, synthesize an answer from conflicting sources, and produce something confident and wrong. In a regulated portfolio company, that’s not a reporting nuisance. It’s a compliance exposure with a dollar figure attached.

A few questions surface this quickly, and they’re worth asking in diligence rather than discovering later:

Is there a canonical definition of the entities that drive the P&L, customer, product, provider, contract, or is “customer” defined five different ways across five systems?
Can a field’s lineage be traced from source system to board report, or does that trust depend on one person’s memory?
Are access controls evaluated against what the data actually is, or only against which system it happens to sit in?

None of this requires a five-year data transformation program before close. It requires knowing, going in, whether the target has a semantic foundation to build on or whether the modernization plan is starting from zero.

Access and Integration Debt Quietly Cap the Thesis

Identity and integration architecture rarely get diligence attention, and they should. Most targets still run role-based access control, permissions scoped to a system, an application, or a job title. That model was designed for a world where data stayed inside its system of record. It breaks down the moment a company wants an AI agent, or even a straightforward analytics layer, to work across finance, operations, and customer data at once. What looks like a security control on paper becomes, in practice, either an access bottleneck or an access hole.

Integration debt sits right next to it. A target with years of point-to-point integrations, this system talks to that one through a script someone wrote in 2019, has no real API layer to plug a new acquisition into. Every add-on becomes bespoke work. That’s the mechanism behind the “every acquisition needs a new platform” problem Toro describes. It’s not usually the platform itself. It’s the absence of a clean interface for anything new to connect to.

Modernization Plans That Aren’t Actually Plans

Nearly every target arrives with some version of a modernization or AI roadmap. Far fewer arrive with one that’s sequenced against the investment thesis. A roadmap that lists a dozen initiatives with no prioritization, no owner, and no tie to a specific EBITDA or working-capital outcome isn’t a plan. It’s a wish list that will get raided for budget the first time the board asks a hard question.

The AI-enablement version of this is newer but follows the same pattern. A company can be genuinely excited about AI and still have no governed data foundation underneath it, no clear entity definitions, no lineage, no access model that scales past a handful of use cases. Enthusiasm without foundation produces pilots that never leave the sandbox. That gap is worth surfacing before close, because fixing it later competes for the same capital and the same attention as everything else on the 100-day list.

The Talent Gap Nobody Wants to Write Down

Toro’s two-person IT shop example points at something bigger. Most legacy technology organizations were staffed to keep systems running, not to interpret data, redesign architecture, or execute a modernization program. That’s not a criticism of the people. It’s a description of what the role was hired to do for the last decade.

A team like that can be perfectly competent at operations and still lack the analytic and architectural skills a buy-and-build or margin-expansion thesis actually requires. That mismatch is why modernization roadmaps stall after the diligence team leaves. Somebody wrote the plan. Nobody on staff can execute it. Left unaddressed, it becomes the reason the company reacts slowly to a competitor, a channel shift, or a pricing move, and slow reaction is where disruption gets its opening.

Somebody Has to Own It

Every one of these debts, infrastructure, data, access, roadmap, talent, shares a root cause. Nobody at the target was ever accountable for the whole picture. IT owned system changes and uptime. Finance owned the numbers (but might get challenged to describe the governance). Nobody owned whether the architecture could support the next five years of the thesis, after-all these were smaller companies who were growing into multi-year value theses.

That accountability gap used to be tolerable because technology sat next to the business. It doesn’t anymore, especially when the business scales. At the same time, the business process itself is being rewritten by automation and AI, which means the systems and the operating model are no longer separable questions. A CIO or CTO answering only for uptime and ticket queues is answering the wrong scope for what the role has become. That person needs a seat at the leadership table with the same standing as finance or operations, because the decisions they’re making, what gets automated, what data becomes an asset, where an agent is trusted to act, are business decisions now, not IT decisions with a business impact.

The same shift is happening in reverse across the rest of the executive team. Sponsors are increasingly looking for leaders who are “double deep,” genuinely fluent in the business and conversant enough in the technology to know what a modernization roadmap actually implies for the P&L. A CFO who can’t read a data lineage gap as a control risk, or a COO who can’t tell the difference between an integration that scales and one that doesn’t, is going to misjudge the thesis. The technology organization isn’t a support function anymore. It’s a source of competitive reaction speed, and that has to show up in who sits in the room, not just in who gets asked to present.

Put that person in place, with real authority over the operating model and the data foundation rather than service delivery alone, and measure them against the same outcomes the rest of the leadership team is measured against. Everything else on this list gets easier to fund and easier to sequence once someone with a seat at the table owns the whole architecture instead of its individual parts.

The checklist will keep finding expired firewall contracts and aging operating systems. It was built for that. What it won’t find is the slower kind of debt, the one accumulating in the data layer, the access model, and the org chart, quietly setting the ceiling on how fast the company you bought can actually become the company you modeled.

Read Saïd Toro’s original piece, Technology Diligence Is Broken: What Private Equity Firms Miss Before the Deal and Pay For Later, at The National CIO Review.