Technical Due Diligence for AI-Built Software: What Checklists Miss

You are looking at a company with real growth, a small team, and a shipping cadence that seems too fast for its headcount. Somewhere in diligence, someone mentions that most of the product was built with AI.

The question you actually need answered is whether that is an advantage or a liability you are about to buy. Your advisors will pull up a technical due diligence checklist to find out. Those checklists are good, and every one of them is older than the thing you are assessing.

What does a standard checklist still get right?

Most of it. Architecture quality, test coverage, dependency health, delivery pipeline maturity, documentation, licensing hygiene: these are not made irrelevant by how the code was written, and any assessment that skips them is worse, not more modern.

The published frameworks buyers reach for, from Snyk's guide to Bain's private-equity technology framework, cover that ground competently. The problem is narrower and more specific. They were written for codebases produced by people, and they assume the failure modes that come with people: rushed work, turnover, shortcuts under deadline.

AI-built software fails differently, and the frameworks carry no line-items for it, because those line-items did not exist when they were written.

What did the scan actually find?

In May 2026, the Israeli security firm RedAccess reported finding roughly 380,000 publicly reachable applications built with tools like Lovable, Base44, Replit, and Netlify. About 5,000 of them carried sensitive corporate data.^[1][2]

The contents are the part that should get a buyer's attention: shipping routes and vessel port assignments, internal financial information from a Brazilian bank, customer service conversations, and summaries of doctor-patient conversations from a hospital.

Now the part that matters most for diligence, and the part most summaries of this story skip. The reported cause was not an exotic exploit. These applications were published in a state that made them publicly reachable, and search engines indexed them.

The platforms pushed back on the framing, and their objection is worth reading closely rather than dismissing:

He is right. That is what makes it a diligence problem rather than a vendor problem. The platform behaved as designed, the builder did not understand what the default meant, and the data went out anyway. RedAccess CEO Dor Zvi described the result plainly to WIRED: organizations are leaking private data through these applications.^[3]

Nobody in that chain was negligent in a way a standard security questionnaire would catch, which is the whole argument for adding line-items.

What should an AI-era checklist add?

Four things, none of which appear in the frameworks in circulation:

Where untrusted input meets a model

If the product passes user-supplied text into a language model, you need to know how many places that happens, what the model is trusted to do with the result, and whether its output flows into anything consequential downstream. This is an attack surface a conventional application security review does not look for, because a year ago it rarely existed.

Whether defaults were ever closed

The RedAccess finding is the case in point. Assess whether access controls exist on multi-tenant data, whether credentials stay server-side, and whether anything published was published intentionally. The question is not "did they make a mistake," it is "did anyone ever decide."

How dependencies got chosen

AI code generation adds libraries to solve the immediate problem. That is efficient, and it means a codebase can accumulate packages nobody evaluated for licensing, maintenance status, or transitive surface. A conventional audit catches known vulnerabilities in those packages. It does not catch the pattern of unreviewed selection at scale, which is what predicts the next problem.

Whether anyone can explain it

This is the one with the clearest effect on price. In an AI-built codebase, the distance between "this runs correctly" and "someone understands why" is wider than in a human-written one.

It reads as a code-quality concern and behaves as an operating cost: slower incident response, more expensive changes, and a team that cannot confidently answer questions about the asset you just bought. We have written before about debt in code nobody on the team wrote; in a deal, that debt has a number attached.

How should a buyer use these findings?

As pricing inputs, not as a pass-fail gate. This matters, because the reflex on hearing "AI-built" is to look for a reason to walk, and that reflex will cost you good assets.

A product with clean structure and a few unvetted packages is one negotiating position. A product where the logic works and nobody remaining can explain it is a different one, with a real number attached to post-close engineering support. Both are findings. Neither is a verdict.

Three questions turn findings into a position:

• What has to be remediated before close?
• What can wait until after, and at what cost?
• Who pays for it, and does that change the number?

Those are judgment calls, which is why diligence is performed by a person rather than filled in from a template. The checklist gives you structure. Someone with senior engineering judgment turns findings into a conclusion, which is the same argument we make about what separates working software from dependable software.

Production-grade is not a metric you can read off a dashboard. It is a conclusion somebody reaches on your behalf, and whether an AI-built product is ready for production is exactly the question a buyer is paying to have answered before the money moves.

If you are acquiring, or building toward an acquisition, the diligence window is when that conclusion gets made. Make sure the checklist being used is younger than the software.