The demo can work perfectly and still fail the customer’s real test. For an Accra founder selling an AI product to a European company, the critical question is where each prompt, uploaded file and model response travels, and whether the contract permits that journey.
In 2013, Austrian privacy activist Max Schrems challenged Facebook’s transfer of European user data to the United States. The legal mechanism supporting those transfers, known as Safe Harbor, had been accepted for years. Then the assumptions beneath it were tested.
The dispute moved from Ireland to the Court of Justice of the European Union. In 2015, the court invalidated Safe Harbor. Companies that had treated international data transfer as settled infrastructure suddenly had to reconsider how European personal data crossed the Atlantic.
The European Commission’s account of the case records the result. The software still ran. The servers still responded. The boundary around acceptable data movement had changed.
A working prompt can conceal the real architecture
Picture the decision facing the founder in Accra.
The European prospect has supplied realistic documents for a demonstration. The product extracts information, classifies requests and drafts useful responses. It performs well enough for the customer’s commercial lead to invite legal and security colleagues into the next call.
Then legal asks where the data went.
That question reaches below the interface. The founder now has to account for the model provider, hosting region, logs, backups, analytics, support tooling and any subprocessors that may receive customer information. A single prompt can pass through several systems before its answer returns to the screen.
The demo proved that the product could perform the task. It did not prove that the product could perform it within the customer’s contractual boundaries.
This is the same mechanism that made the Schrems case consequential. A functioning technical route had been mistaken for an acceptable legal route. Once the transfer itself came under scrutiny, performance could no longer settle the matter.
Map the data path before choosing the demo
Founders on limited runway often build the shortest route to visible value. That instinct is usually rational. A polished demonstration can unlock a paid pilot faster than several weeks spent designing infrastructure for requirements nobody has confirmed.
The mistake is allowing speed to erase the data map.
Before using customer material, write down what enters the product, which services receive it, where those services process or store it, how long they retain it and who can inspect the logs. Include the quiet tools. Error tracking and prompt observability can hold more sensitive context than the main database.
Then separate the information required to prove the workflow from the information that makes the demo feel realistic. Synthetic records, redacted documents or customer-approved samples may establish the same product value without sending live personal or confidential data through an unapproved chain.
This resembles the product discipline in how a paid pilot changed Kweku’s roadmap. The first test should answer the commercial question while creating the smallest avoidable liability.
A founder does not need to solve every future compliance requirement before showing a prototype. They do need to know what the prototype does with someone else’s data.
Treat legal review as product discovery
Legal questions often arrive as requests for documents: a processor list, retention policy, data-processing terms or evidence of where information is hosted. Underneath those requests sits a product requirement.
Can this workflow run inside the customer’s permitted boundary?
That requirement may change the design. The customer might require regional processing, shorter retention, disabled model training, restricted human access or a different provider. Some changes will be configuration. Others may alter cost, latency or the features that can be offered.
Those constraints belong in the pilot conversation early, alongside accuracy and integration requirements. Ask what categories of data the customer expects to use, what may leave its environment and which approvals are required before real records enter the system.
The answer could reveal that the current architecture cannot support the account profitably. That is useful information. It is cheaper to discover the constraint before the founder promises a launch date, builds a custom integration and counts the contract as future runway.
The same caution applies when considering a technical change whose security implications remain unclear, as explored in whether to merge an AI security fix you cannot yet explain. A green test result answers one question. It does not answer every question the customer is buying against.
Put the boundary into the next build
After legal raises the issue, the next useful artifact is not a longer sales deck. It is a plain data-flow record that engineering, the founder and the customer can examine together.
For each step, name the input, service, processing location, retention behaviour and deletion path. Mark any detail still awaiting confirmation from a provider. If the proposed pilot needs synthetic data until contracts or configurations are ready, state that directly.
Schrems’s 2013 challenge became a 2015 judgment because the route data took carried obligations that technical success could not remove. The smaller version of that lesson arrives in startup sales calls every week.
Before running the next demo, send the customer a short data-use note and ask them to approve the test material. The model can wait for the right inputs. Your contract may not survive the wrong ones.
Comments
No comments yet.