When a security questionnaire arrives before an AI contract is signed, the fastest component to build can become the largest obstacle to closing the deal. The risk usually sits in the data path: what reaches the model, where it goes, how long it remains there, and who can retrieve it.
Consider Kojo, an invented composite of several early-stage founders I have encountered. At 4:38 on a Friday afternoon in Accra, he had a browser tab open to the contract his prospective customer had promised to send. Instead, an email arrived with a spreadsheet attached: 126 security questions, several highlighted in yellow.
Kojo had expected a signature before Monday. Without it, he could not commit to the engineer he wanted to hire, and the candidate had another offer waiting. He opened the first worksheet and found questions about subprocessors, encryption, access logs, data deletion, incident response and model training. His AI feature had taken one engineer eleven days to build. By Friday evening, it was threatening the entire sale.
The demo hid the real product boundary
Kojo’s demo looked simple. A customer uploaded a document, asked a question and received a useful answer in seconds. The prospect’s product lead saw faster work. The security team saw confidential information leaving one controlled environment and entering several systems they had never approved.
That difference matters.
During product development, Kojo had treated the model call as one step inside the application. The questionnaire forced him to draw the full route. A document entered his storage layer. Extracted text moved through a third-party service. A model provider processed the prompt. Application logs captured part of the request. An error-monitoring tool retained diagnostic data.
Each decision had been reasonable in isolation. Together, they created a chain Kojo could not explain cleanly.
This is common when founders choose AI tools for speed. The provider gets the feature working before the customer meeting. Later, the customer asks whether its data trains a model, crosses a regional boundary, appears in logs or survives after deletion. “We use a reputable provider” does not answer any of those questions.
The questionnaire had exposed the actual product boundary. It extended beyond Kojo’s codebase to every service that could receive, store or reveal customer data.
Compliance work competes with the roadmap
By Saturday morning, Kojo had three possible responses.
He could complete the questionnaire quickly and answer uncertain items with optimistic language. That might preserve the sales timeline, while creating written promises his product could not support.
He could rebuild the AI workflow before replying. That would delay the contract and probably cost him the engineer.
Or he could narrow the first deployment so the customer’s most sensitive data never entered the AI path.
The third option looked commercially weaker. The prospect had been impressed by the full demo. Reducing scope risked making the product feel less valuable at the exact moment Kojo needed the contract.
But the original scope was already unavailable. It existed in the demo, not in a form the customer could safely approve.
This resembled the decision behind the integration offer that would have cost a founder his roadmap. Revenue can arrive carrying months of unplanned product work. A security review makes that hidden work visible before the money lands.
Kojo stopped treating the questionnaire as paperwork and used it as a design constraint.
The safer contract started with less AI
On Monday morning, Kojo proposed a smaller pilot. The first version would process a restricted document category, exclude sensitive fields before any model request, limit internal access and use a defined deletion process. Questions he could not answer stayed marked as unresolved.
He also separated three kinds of statements in his response: what the system already did, what he could configure before the pilot, and what would require new engineering. That distinction prevented a sales promise from quietly becoming a security guarantee.
The customer still had reasons to decline. The reduced pilot offered less automation, and security approval remained uncertain. Kojo sent the revised scope knowing he might lose both the deal and the candidate.
Late that afternoon, the customer agreed to review the narrower deployment. It was not a signature. It was enough to keep the contract alive without pretending the original architecture was ready.
The useful lesson was uncomfortable: the model had been the fastest part because someone else had already built it. The obligations surrounding the model still belonged to Kojo.
Draw the data path before the buyer does
A founder can surface this problem before procurement sends a spreadsheet.
Take one real customer file and trace every system that touches it. Include storage, model providers, analytics, error logs, support tools and backups. Then ask four plain questions: What data enters? Who can access it? How long does it remain? Can we delete it when the customer asks?
If one answer depends on a vendor setting nobody has checked, verify it before putting the claim in a proposal. If the answer requires engineering work, price and schedule that work before agreeing to the contract. If the risk comes from sending more data than the feature needs, reduce the data before adding another policy document.
This exercise also clarifies who controls the roadmap. As the spreadsheet that revealed who really owns your roadmap shows, a buyer’s requirements can become product decisions long before anyone calls them features.
On Tuesday, Kojo removed the hiring decision from his whiteboard. In its place, he drew five boxes showing where one customer document travelled. The diagram was less exciting than his AI demo. It was the first version of the product that the customer might actually be allowed to buy.
Comments
No comments yet.