The enterprise deal died in a security questionnaire

An enterprise AI buyer is buying an operating relationship as well as a capability. Someone in the organisation will be accountable when confidential data is mishandled, an answer causes trouble or the supplier disappears. Their questions can feel slow to a startup that has just made a compelling demo. They still deserve concrete answers.

The title describes a familiar type of commercial failure, not a specific client story or a measured claim about how deals are lost. My argument is that security and procurement readiness belong in the product plan early enough to influence what the team builds and promises.

Draw the data journey in ordinary language

Show what enters the product, where it travels, which systems process it and where copies may remain. Include application logs, backups, analytics, model providers and any human support access. The diagram should make sense to a buyer who is responsible for the business but does not write code.

Then test a real question against it. If a customer uploads a document and later asks for removal, which systems are involved? What can your team actually remove, on what timeline, and under which agreed retention rules? An honest bounded answer is more useful than a broad promise that the implementation cannot support.

Separate your controls from your supplier’s controls

A supplier’s published assurance does not automatically describe your application. Your permissions, logging, support process and configuration still matter. Attribute evidence accurately and show which controls your company operates itself.

Do not invent a certification because the market expects it. If a certification is in progress, describe its actual status. If a control is manual, explain the process and owner. Buyers need to judge the current arrangement, not an attractive future version of it.

Build an evidence pack people can inspect

NIST’s Generative AI Profile offers a voluntary cross-sectoral resource for AI trustworthiness. It is not a substitute for a buyer’s requirements, a legal review or a certification. The following pack is my proposed starting point for a clearer commercial conversation.

The pack does not need to be enormous. It needs to be current and internally consistent. A short accurate document can save more time than a large policy library whose authors have left and whose controls nobody can demonstrate.

Make the pilot easier to approve

Start with a bounded workflow, a named group of users and a clear decision at the end. Where suitable, use approved non-sensitive examples before introducing customer data. Define permitted actions, unsupported uses and the person who can stop the pilot.

Agree the evaluation and commercial question before implementation. Are you testing technical feasibility, daily use, integration effort or the case for a wider purchase? Those are related but different. An endless pilot often begins as several people silently testing different things.

The customer’s security team should be able to see how the scope limits exposure. Do not claim that a pilot is harmless merely because it is small. A small system with broad permissions can still create a large problem.

Answer questionnaires with evidence and an expiry date

Maintain an answer library with links to supporting material, owners and review dates. Avoid copying last year’s response into a new context without checking it. A question about one product, hosting location or customer requirement may have a different answer elsewhere.

When something is unsupported, say so and offer a realistic alternative if one exists. That might be a narrower workflow, an additional approval step or a later delivery date. Let the buyer make an informed decision instead of discovering the limit during a live deployment.

Keep unresolved contractual or privacy questions with the appropriate qualified owners. Product leadership can make the facts and tradeoffs clear. It should not quietly make legal commitments that the organisation has not approved.

Bring the right person to the next meeting

A good commercial follow-up is specific: here is the data flow, here is the current control, here is the open question and here is who can answer it. Sending another demo rarely resolves a missing retention policy. Inviting ten people without a decision to make rarely helps either.

For teams selling AI products, this is a useful place for product leadership to connect engineering, commercial work and customer trust. My guides to knowledge-assistant permissions and data provenance cover two frequent parts of that conversation. I can help turn the questions into a scoped delivery plan, so the next meeting has a decision to make rather than more ribbon to unwrap.

Questions people ask

Why do enterprise AI purchases get stuck after a successful demo?

The buyer may still need evidence about data handling, permissions, quality, contractual scope and operational ownership. A useful demo does not answer all those operating questions.

Does a model provider’s certification certify an AI startup’s product?

No. Attribute the provider’s evidence accurately and document the application controls your own organisation operates. Check the actual scope of any assurance claim.

What should a first enterprise AI pilot include?

Define a bounded workflow, approved data, named users, permissions, acceptance criteria, escalation owner and the decision the pilot will support.