Too early is the wrong diligence question for an AI vendor
Funding rounds and company age tell you nothing about whether a vendor's system is safe to run in production.
"Who are your investors?" A prospect asked me that in a first meeting, and it was not small talk. Two meetings later, at a different carrier, the version was blunter: "You're a little early for us." Neither question is about curiosity. Both are a buyer trying to price a risk before signing anything: will this vendor still exist in two years, still be capable of supporting a regulated deployment, still be an entity a regulator can call when something goes wrong. Underneath a question about a cap table sits a real fear, and it deserves to be taken seriously. A vendor that disappears mid-contract leaves the buyer holding a system nobody can maintain, a data relationship nobody can unwind cleanly, and an audit trail with a gap in it. That fear is legitimate. The question built to answer it is not.
Why the instinct is sound
Buyers who ask about funding stage are not being lazy. They are reaching for the one proxy visible to them at the top of a sales conversation, before any system exists to inspect. A company two years old and self-funded looks riskier than one with a decade of filings and a familiar logo, and in most software categories, that heuristic has held up. Longevity used to correlate with survival, and survival used to correlate with support. A buyer who has lived through a vendor going dark mid-contract, taking a support team and a roadmap with it, is right to want that guarantee up front.
This instinct is a business discipline. It is not superstition. Procurement teams have spent decades building financial health checks into vendor selection because a lapsed relationship costs real money and real rework. The same discipline governs how large enterprises vet any vendor whose failure would be expensive to unwind, in software categories far outside artificial intelligence. Applied to an AI system running inside a regulated workflow, that discipline reaches for the tool it has always used. It is reasonable to distrust a company you cannot picture existing in five years. The industry's own current checklists still list funding stage, headcount, and years in business as vendor risk signals for exactly this reason, and treating those checklists as sloppy would be unfair to the people who wrote them.
Why funding and age answer the wrong question
Company biography and product risk are not the same axis, and the gap between them is where the instinct stops working. A funding round tells you how much cash sits in a bank account. Company age tells you how long an entity has existed under one name. Neither number describes what the system does inside a regulated workflow, whether its recommendations can be inspected after the fact, or who is contractually on the hook if something goes wrong.
Current vendor evaluation guidance agrees with the market's instinct instead of interrogating it. The typical checklist recommends scoring funding stage, team size, and whether a vendor has shipped beyond a pilot, treating operational maturity as a proxy for product risk. That convention is the default advice most procurement teams get handed today, and the trouble is not dishonesty. It answers a question about the company when the buyer's actual exposure sits with the system.
The real question inside "how established are you" is narrower than it sounds, and it splits into three parts. Will this system behave safely when it is making decisions that touch real people, at scale, inside a regulated industry. Will it be inspectable when something goes wrong, so an auditor or a regulator can see what happened and why. And will the vendor still be answerable if the system fails, meaning contractually on the hook rather than merely present.
None of those three questions has anything to do with a Series C or a decade-old logo. A well-funded vendor can run a black-box model nobody can inspect. A ten-year-old vendor can have shipped its AI product eighteen months ago, with none of the production history that would let anyone judge how it behaves under real conditions. Age and funding describe the company's balance sheet and calendar. They say nothing about the one thing a regulated buyer is trying to price: what happens when this specific system makes a decision that a regulator later asks about.
Live production answers the first question. A system with four years of production data behind it, run across 10,765 agents at a Fortune 500 insurance carrier, has been checked against real outcomes across full underwriting and hiring cycles, not a demo dataset assembled for a sales call. That claim describes behavior. A cap table has nothing to say about it.
Legal approval answers the second. When a Fortune 500 carrier's legal team clears an architecture in 17 days, what passed review was not a pitch deck. It was the data-flow design, the access model, and the audit surface, the same things an auditor asks to see two years into a deployment. Inspectability is a property of architecture, and architecture is exactly what a legal review tests. The architecture side of this same evaluation is a separate question with its own answer, and it is the one legal gates on before any vendor gets to discuss production history at all.
A money-back pilot answers the third. A vendor willing to price its own confidence, refunding a pilot that does not perform, is pricing accountability into the contract before the buyer has committed to anything.
The three questions that replace a cap table
Replace "how long have you been around" and "who funded you" with three questions any buyer can ask in a first meeting, before a product demo even starts.
How long has this system run against real production outcomes rather than a benchmark dataset. A vendor with genuine production history will give a specific number and a specific customer type instead of a vague range.
Can you show me one decision it got flagged on. Every system operating at real volume produces edge cases. A vendor with nothing to show either has no production history or is not willing to show it, and both answers matter.
Ask what happens contractually if the outcome does not show up, and whether the vendor will price a pilot on outcome and refund it if the outcome fails.
None of the three requires a technical background to ask or to judge. A buyer does not need to read a model card to know whether an answer to "show me a flagged decision" was concrete or evasive. The three questions test the same ground a full technical review covers, just earlier and without procurement.
Asking these three questions surfaces something else worth watching: how a vendor reacts to being asked about production history at all. A vendor confident in its answer treats the question as easy and moves through it in a sentence or two. A vendor without one changes the subject back to its roadmap, its founding story, or its raise, which is itself a useful signal. A team running a formal AI council review can build the same instinct into its own rubric; the governance checklist for that review inspects these same three surfaces at the committee level.
The proof
At a Fortune 500 insurance carrier, that proof stack is not hypothetical. A buyer can verify each point above on a single call, and none of it lives only in a deck. The methodology behind the trace that makes those outcomes auditable is published as Decision Traces.
A buyer who has cleared this trust bar still has work to do. The next diligence step, for an executive who cannot personally read a model, is inspecting the system itself: the decision record, the human approval gate, and what the enterprise keeps if the relationship ends. That inspection is its own piece, and it assumes the vendor has already answered the question this one is about.
Age and funding describe a company: when it was founded, how much cash it raised. None of that changes when the model running inside a customer's VPC does or does not misfire on a real decision. Production proof describes what the system actually did, how long it has run, what happened when it was wrong, what the vendor owes the buyer if it stays wrong.
A buyer evaluating whether to trust an AI vendor is buying the system. The diligence question should match what is being purchased.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.