Somewhere between the demo and the rollout, someone from legal asks where the customer data actually goes once it hits the new AI tool. Most teams cannot answer that cleanly. Not because they are careless. Because nobody designed for the question before the integration shipped.
The four questions that matter
Where does the data go, physically and contractually? Who, specifically, gets to see it: your team, the vendor's, or a subprocessor nobody signed off on? What happens if the vendor swaps model providers next quarter without telling you? And if the system makes a decision, can you explain why, after the fact, to a customer or a regulator?
The privacy policy is not the answer
A privacy policy describes intent. It does not describe architecture. Whether a decision can be explained is determined by what you logged at the time it happened, not by what you promised in a document six months earlier. If the logging was not designed in, the explanation does not exist later, no matter how good the policy reads.
Design it before you build it
Cost governance, data boundaries, and explainability are structural decisions. They are cheap to make before the first line of code and expensive to retrofit after the system is already trusted with real customer data. Answer the four questions on paper first. The build gets simpler once you have.
