Deployment Topology Is a Control Surface
Learn to analyze deployment topology as a critical control surface for AI systems, focusing on data boundaries, risk management, and operational controls. Understand how deployment affects auditability, security, and compliance constraints to design defensible AI architectures aligned with sensitivity requirements.
A scoring matrix narrows model choice down to a defensible short list. It says nothing about where that model actually runs, or what can be proven about the data path once it does. Capability selection answers whether a model can perform the task at the required quality: generating accurate policy summaries, following instruction constraints, extracting fields from HR documents. Deployment topology answers where inference runs and what can be controlled and evidenced around the data path, including who can observe prompts, retrieved context, and outputs, and what logs and change records exist for risk owners.
We have two sensitivity tiers. The same task design can carry a very different risk posture depending on where the prompt and retrieved passages cross a trust boundary. General policy Q&A can tolerate broader operational dependencies. Restricted HR and finance policy assistance raises the bar on data boundary control, access patterns, and reviewable evidence of processing location and key control. These can be classified as the following boundaries:
Trust boundary 1: User data leaves the client and enters the application control domain.
Trust boundary 2: Query and sensitive content leave the application domain to retrieval/context services.
Trust boundary 3: Query and retrieved context leave to the model inference environment (location varies).
The following diagram shows these trust boundaries in a retrieval-augmented generation flow.
Comparing topologies under shared requirements
Write the requirements down once, and apply them consistently, to make a topology comparison tractable. The shared set: data residency expectations, ...