The hidden work in selling AI to a regulated buyer

The demo was never the hard part

A product team builds something good. The model works, the interface is clean, the pilot metrics are real. The buyer's operating team wants it. Then the deal enters a phase nobody staffed for, and it sits there. Not because anyone said no, but because a vendor security questionnaire arrived with 280 questions, a model risk officer wants to know how the outputs are validated, a privacy reviewer wants the data flow, and a contracts person wants to know what happens when the model provider deprecates the endpoint you built on. Each of those people can stop the deal, none of them can approve it alone, and none of them attended the demo.

This is the part of an AI sale that never shows up in the roadmap. Call it the evidence phase. The engineering that wins it looks nothing like the engineering that built the product, and the companies most surprised by it are usually the ones with the better model.

The pattern holds across every regulated buyer. A bank runs it through model risk management, a hospital through privacy and clinical safety, an agency through an authorization process, a defense prime through supply chain and export control. Different vocabularies, one structure: somebody who is accountable if the thing fails has to be handed enough written material to accept that risk in their own name.

Three reviewers, three different questions

The single most useful thing to understand is that "the review" is not one review. It is three separate reviews with different owners, different vocabularies, and different failure modes, running in parallel and blocking each other.

The security reviewer asks where the data goes. Their instrument is a questionnaire, usually descended from a standard set: the Cloud Security Alliance CAIQ, the Shared Assessments SIG, something HITRUST-flavored in healthcare, or NIST SP 800-53 control families in federal work. They want subprocessors, encryption, key custody, retention, incident notification windows, and deletion on termination.

The model risk reviewer asks whether the output can be trusted. In a bank that is governed by SR 11-7, the Federal Reserve and OCC supervisory guidance on model risk management, operative since 2011, which treats every model as requiring conceptual soundness review, ongoing monitoring, and validation by someone independent of the developer. In healthcare the analogue is clinical validation and, where the software meets the definition, FDA oversight of software as a medical device. This reviewer increasingly also asks whether you map to the NIST AI Risk Management Framework or ISO/IEC 42001.

The legal and contracts reviewer asks who eats the loss. Indemnification for output, intellectual property in what the model produces, training rights over their data, audit rights, termination. This reviewer is the one most likely to read your marketing copy back to you and ask whether the engineering supports it.

The accuracy number is the thing they will not accept

Almost every AI product carries a headline number. Ninety-four percent accuracy. Forty percent time saved. Half the false positives. In a commercial sale that number persuades. In a regulated review it is the first thing attacked, and the attack is always the same three questions: on what data, against what ground truth, and who else can run it.

Most teams cannot answer the third. The number came from a notebook, on a snapshot of data that has since changed, scored against labels one person produced, and nobody has rerun it since March. That is not dishonest and it is not unusual. It is simply not evidence, because evidence is a claim someone else can reproduce.

What converts it is unglamorous. A frozen evaluation set with documented provenance and a written labeling protocol, including how labeler disagreements were resolved. A scoring script in version control anyone can run against a build. Results broken out by segment, because the aggregate hides the case the reviewer worries about. Confidence intervals, since 94% on 200 examples and 94% on 20,000 are different claims. And a record of every past run, so drift shows as a line rather than a surprise.

Building that after the questionnaire arrives takes six to ten weeks under deadline. Building it before costs the same engineering hours on your own schedule. The difference in deal outcome is almost entirely which of those two you did.

Model risk management is a real discipline, and it predates all of this

Teams selling into financial services often meet SR 11-7 in a deal and mistake it for AI-specific bureaucracy. It is neither. It has governed credit, pricing and capital models for over a decade, and it rests on a premise worth borrowing outside banking: a model creates risk through use, so the controls attach to the use rather than to the mathematics.

Three of its requirements reliably surprise vendors. Independent validation means somebody who did not build the model has to review it, which means your internals must be legible to an outsider. Conceptual soundness means the reviewer will ask why this approach suits this problem, and "the benchmark scores were high" is not an answer to that question. Ongoing monitoring means the validation is not a one-time event, so the buyer needs a continuing signal from you after the contract is signed.

That last one has a product consequence most teams miss. If the buyer must monitor the model quarterly and you have given them no way to do it, you created work they must invent, and the reviewer prices that into the answer. Shipping the monitoring surface with the product converts an obligation you imposed into a feature you gave them.

Language models moved the goalposts, and the frameworks caught up

When the system includes a language model, two reference texts do most of the work in a review, and naming them early buys you credibility that generic assurances do not.

The OWASP Top 10 for Large Language Model Applications is the practical one: prompt injection, insecure output handling, training data poisoning, supply chain risk, sensitive information disclosure, excessive agency, overreliance, model theft. A reviewer who has read it will ask about prompt injection specifically, because it is the failure with no clean fix, and they want to see that you know that. The honest answer is architectural: constrain what the model may do, validate outputs before they reach anything consequential, and never let model output cross a trust boundary as if a person had authorized it.

MITRE ATLAS is the adversarial one, a knowledge base of real attack techniques against machine learning systems, built in the same shape as ATT&CK. It is the right vocabulary when the buyer's security team thinks in threat models rather than checklists, which describes most defense-adjacent buyers.

For governance rather than security, the names are the NIST AI RMF and ISO/IEC 42001, the AI management system standard published in December 2023. The RMF is voluntary and unpriced, so mapping to it is mostly a documentation exercise. ISO 42001 is certifiable, and the audit is a real budget item, commonly $25,000 to $60,000 for a first cycle at a mid-size company plus internal effort. Whether it is worth it depends on whether your buyers ask for it, and most today ask which framework you align to rather than which certificate you hold.

Excessive agency is the finding that kills the deployment

The most consequential design decision in a regulated AI deployment is what the system may do without a person. Teams tend to decide this by roadmap enthusiasm, then describe it to reviewers as though it were the product of a risk analysis.

Write down every action the system can take, and for each one, who authorized it, what evidence exists that it happened, and what reverses it. Actions that write to a system of record, move money, contact a customer, or change an entitlement need a person in the path or a mechanically enforced constraint. A rule in a prompt is not a constraint. A prompt is a request, and a language model is under no obligation to honor it.

Human-in-the-loop deserves particular skepticism, because it is the most oversold control in this field. If a reviewer approves 300 outputs an hour, no review is happening and the buyer's auditor will eventually say so. Real oversight requires the information needed to disagree, the time to use it, and a disagreement rate somebody tracks. If your override rate is under two percent, either the model is extraordinary or the review is decorative, and you should know which before someone else decides for you.

Federal buyers add an authorization layer, not just a questionnaire

If the buyer is a federal agency, or a contractor handling federal data, the review acquires a formal shape. Systems get authorized, and the authorization is a named official accepting risk in writing on the basis of a control package built to NIST SP 800-53. A cloud service sold to multiple agencies goes through FedRAMP, a program with its own timelines and costs rather than a document you assemble.

The numbers matter because founders underestimate them by an order of magnitude. A FedRAMP Moderate authorization has historically run into seven figures all-in for a first-time company, counting the third-party assessment organization, remediation engineering, documentation, and a continuous monitoring obligation that never ends. Twelve to eighteen months elapsed is normal. The program has been reformed to compress this, but no version of it is fast or cheap.

Where the data is controlled unclassified information on your own systems rather than a cloud service, the standard is NIST SP 800-171, and for defense work CMMC now puts an assessment behind it. The scoping decision is worth more than the control work: what sits inside the boundary determines how much of your company gets assessed. We wrote about that in drawing a realistic CUI boundary.

For a commercial company with one federal-adjacent opportunity, resist starting with the authorization. Find the buyer's actual path first. Selling through an integrator that already holds one, or deploying inside the agency's existing boundary, are both common and far cheaper than becoming an authorized service yourself for a single customer.

What the evidence file contains

Every review converges on the same set of artifacts. Prepared in advance, they cost a few focused weeks. Assembled under deadline by people with other jobs, they cost a quarter and read like it.

Artifact	Who reads it	What it must contain
System and data flow description	Security, privacy	Every place data rests or moves, every subprocessor including model providers, retention and deletion behavior, and where the boundary sits
Model card or system card	Model risk, technical	Intended use, out-of-scope use, training and evaluation data provenance, performance by segment, known failure modes, version history
Evaluation report	Model risk, operating team	The frozen test set, the labeling protocol, the scoring code, results with intervals, and every prior run for drift
Control mapping	Security, audit	Your actual controls mapped to their framework, with honest gaps and dated remediation rather than blanket assertions
Adversarial test summary	Security	Prompt injection, data exfiltration through outputs, and the OWASP LLM items relevant to your architecture, with what was found and fixed
Monitoring and incident plan	Model risk, operations	What is measured in production, thresholds, who is paged, notification windows, and what a rollback looks like
Continuity position	Contracts, architecture	What happens on provider deprecation or price change, whether a second model has been tested against the same evaluation set

Only two of these are compliance documents. The rest are engineering artifacts a well-run system would have anyway. The evidence file is mostly a byproduct of building carefully, written down in a form an outsider can read.

The questionnaire is a document problem masquerading as an engineering problem

A 280-question security questionnaire takes an engineer about three days of scattered attention, spread over three weeks because they have a product to ship. Multiply by every prospect. Teams respond by hiring for it, which is slow and expensive, or by answering carelessly, which is worse: a wrong answer found later reopens everything and costs you the one thing you cannot rebuild quickly.

The mechanism that works is a maintained internal answer bank: every question ever asked, the correct answer, the engineer who owns it, the date it was last verified, and a link to the artifact that proves it. New questionnaires then become a mapping exercise that a non-engineer can drive, with engineering time spent only on genuinely new questions. The bank goes stale, so a quarterly pass over anything older than six months is part of the design rather than an afterthought.

The move that pays more is to preempt. A trust page carrying your architecture summary, subprocessor list, evaluation method and control mapping, sent before the questionnaire arrives, changes the reviewer's default from investigation to verification. That shift is worth weeks.

Two failure modes are worth designing against. The first is claiming a certification adjacency: saying a system is built on FedRAMP-authorized infrastructure, in language a reader could take as holding the authorization yourself. Reviewers check, and the discovery costs more than the gap ever would have. Inherited controls are real and worth describing precisely, which means naming what the platform provides and what remains yours.

The second is a marketing claim the engineering cannot support. Autonomous, when a person approves everything. Continuously learning, when the model is a static checkpoint. Explainable, when the explanation is a second model's guess about the first. These sentences live on your website, and the legal reviewer reads them next to your technical documentation. The Federal Trade Commission's 2024 enforcement work on AI claims made the point plainly: a claim about what a product does is one you have to be able to support.

What it costs and how long it takes

Rough ranges for a company taking a working AI product into its first regulated buyer. An evaluation harness with frozen sets, documented protocol and reproducible scoring: four to eight engineering weeks. Model card and system documentation: two to three weeks once the evaluation exists, much longer if it does not, because writing it is when you discover what you cannot answer. An adversarial pass against OWASP LLM items and relevant ATLAS techniques: two to four weeks. Control mapping to 800-53 or 800-171 with honest gaps: three to six weeks. An answer bank seeded from two real questionnaires: one to two weeks.

Call it a focused quarter of one senior engineer, or six to eight weeks with two or three people. Against a deal cycle that stalls for two quarters without it, the arithmetic is not close. The same file then serves every subsequent buyer in the segment, which changes the shape of a sales motion rather than one deal.

Bottom line

Regulated buyers are not slow because they are obstructive. They are slow because the people who can stop a deal need written evidence to accept risk in their own names, and most AI vendors arrive with a demo instead. The work that closes that gap is ordinary engineering discipline made legible: a reproducible evaluation, an honest description of what the system does and does not do, controls mapped to the framework the buyer already uses, and monitoring that keeps answering the question after signature. Build it before the questionnaire arrives and it is an advantage. Build it after and it is a fire drill you run at the exact moment your champion is losing patience.

Frequently asked questions