Where customer records physically sit can matter more to a buyer than an award because it determines which legal, security and operational questions the buyer must resolve. A founder selling AI software should know the storage location, the subprocessors involved and the path each record takes before procurement asks.
In 2013, Microsoft faced a US warrant for customer email stored in Dublin, Ireland. The company disclosed information held in the United States but challenged the demand for content stored abroad. A question that sounds like infrastructure configuration had become a dispute about jurisdiction, access and the reach of national law.
The litigation continued for years. Microsoft president Brad Smith argued publicly that governments should follow established international processes when seeking data stored in another country. The dispute reached the US Supreme Court, then became moot in 2018 after Congress passed the CLOUD Act and the government obtained a new warrant under the revised law. The case is documented by the US Supreme Court and Oyez.
That history carries a practical warning for a small AI company. The region selected in a cloud dashboard is connected to contracts, government access, incident handling and customer obligations. Procurement knows this, even when a founder would rather discuss the model.
The question behind the question
The morning after the ceremony, the procurement lead ignored the trophy and asked me where the customer records would physically sit.
That question was doing more work than it appeared to.
They needed to know whether their organisation could approve the proposed setup. They may also have needed to understand who could access the records, which vendors would process them and whether data would cross a border. “We use a major cloud provider” would identify a supplier while leaving those decisions unresolved.
Awards can establish that other people noticed your work. They cannot tell a buyer where a support engineer can view a record, whether a model provider retains a prompt or what happens to backups after deletion.
The buyer was evaluating the system they would have to defend internally. That system included the product, the vendors behind it and the explanation they would give to legal, security and leadership.
Draw the record path before writing the answer
An early-stage team can answer this without producing a fifty-page compliance pack. Start with one customer record and follow it.
Where does the record enter the product? Which application receives it? Where is it stored? Does an automation tool copy part of it elsewhere? Does an AI provider receive the complete record, selected fields or a redacted version? Where do logs and backups go? Who can access each copy?
This exercise often exposes a gap between the architecture founders describe and the architecture customers actually buy. A product may store its main database in Europe while sending prompts containing customer details to another provider under different terms. A Ghanaian founder serving a German customer may also rely on support or engineering access from another country. None of those facts automatically ends a deal. Hiding them inside a vague answer creates the larger risk.
The same discipline applies when a demo uses clean sample data but production will contain inconsistent or sensitive records. I explored that gap in what happens when your AI demo passes using data production will not have. A convincing demonstration proves that one path works. Procurement needs to understand the paths that remain when the system meets real data.
Narrow the promise when the architecture is unresolved
Sometimes the honest answer is that the current setup does not meet the buyer’s requirement.
That does not force a founder into an immediate rebuild. A smaller pilot may use synthetic data, redacted fields or a limited workflow that keeps sensitive records outside the product. The contract should describe that boundary plainly. The team can then learn whether the product creates enough value to justify the work required for a broader deployment.
This is a product decision as much as a security decision. Moving regions, replacing a model provider or adding customer-specific hosting can consume runway and pull engineers away from the roadmap. A serious buyer request deserves analysis. It does not deserve an automatic yes.
A useful response gives the current facts first, identifies the unresolved point and offers the smallest configuration the team can support truthfully. The approach resembles the decision in AI security questionnaires: why Kojo narrowed the pilot to keep the contract alive. Narrowing scope can preserve a commercial conversation while keeping the product promise inside what the team has built.
Build credibility from the answer
The Microsoft dispute lasted long enough for the law around it to change. A startup procurement review happens on a smaller scale, but the underlying problem has the same shape: storage location connects technical design to legal authority and customer risk.
That is why the email after the award mattered. The ceremony established visibility. The question tested whether I understood the operational consequence of what we had shipped.
Before the next buyer call, open a blank page and draw the route taken by one customer record. Put every database, model provider, automation service, log, backup and human access point on it. Then write the answer procurement should receive in plain language, including the parts that remain unresolved.
Comments
No comments yet.