Starting from constraints, not models

The first question in an AI system design conversation is almost never "which model" -- it's whether the data is even allowed to leave the client's own environment. If a regulator, a contract, or the client's own policy says no, that single constraint eliminates every hosted-API option before quality or cost enter the conversation at all, and the design starts from a self-hosted or in-perimeter managed model instead. Treating data residency as a checkbox to confirm later, after picking a model, routinely produces designs that have to be re-architected once the real constraint surfaces.

The same discipline applies to every other requirement a client states as a preference but means as a constraint: a strict overnight processing window, a hard cost ceiling, an uptime SLA. Working backward from what has to be true at the end -- the actual constraint -- produces a materially different architecture than working forward from "here's a capable model, let's build around it."

Worked examples

A client says data cannot leave their environment. How does your architecture change?

Model access moves in perimeter. Depending on what the client's cloud already looks like, that's a managed model service running inside their own cloud account and region,…