Choosing AI hosting: map data flows before comparing models
A worked portal example compares data flows, logs and operating tasks for a self-managed model server and a cloud service.
Choose how to run AI for a specific workflow. A model on your own server and a managed model service differ in processing and operation. The suitable option becomes clear only when you follow the whole path from input to stored result.
Define the task and data boundary
A fictional software company wants to summarise internal notes in its project portal. A person may read only notes from their authorised project and checks the draft before saving it. The model is not tasked with sending messages or changing project permissions.
For the example project P-72, an internal rule applies: unprocessed customer notes must not be sent to external processing services. This is an assumption of the example. It does not replace examining your company's actual data and requirements.
Compare the complete data flow
The table describes planned flows, not a tested installation. Here, “self-managed model server” means a server operated by the company within the approved environment. A rented server can also be self-managed; its inclusion in that approved environment must be assessed separately. Location alone does not describe the division of responsibilities.
Step | Self-managed model server | Managed model service |
|---|---|---|
Input | Portal checks project access and reads the selected note. | Portal checks the same access and reads the same note. |
Note goes to the internal model service. | Note would go to the provider; blocked under the example rule. | |
Logs | Check portal, proxy and error service for copies of the text. | Also establish the provider's processing and logging arrangements. |
Outage | Person summarises manually; no external fallback call. | Person summarises manually; no switch to an unassessed service. |
The planned operational log contains, for example, requestId and status, rather than the full note or model response. These custom example attributes do not define a complete security log. Error handling, support exports and backups must also respect the defined data boundary.
Check the runtime actually in use
The Ollama FAQ, for example, distinguishes local processing from cloud models and describes disabling cloud features. This concerns that runtime. A frontend, extension or separate error service may have additional connections. The installed program's name therefore does not establish the complete data flow.
In an approved pilot setup, examine the destinations used, the content of resulting logs and the outage path. A network destination list alone establishes neither the content of encrypted transfers nor storage at the provider. An external service also requires its specific processing and retention information; a general statement about cloud services is insufficient.
Decide on operation and suitability together
For a self-managed model server, people must cover updates, access, capacity, monitoring and recovery. With a model service, the provider performs the agreed model operation; portal permissions, integration and your own logs remain your team's tasks. Initially compare both using the same synthetic inputs and expected results. This does not approve the processing of real customer notes. Quality and waiting times under the required load are established in the pilot, not inferred from location.
Under the example rule, the external model call has not yet been approved. The self-managed server is an option once its data flow, output quality and operation have been checked. Without a responsible operations team, that option is not ready for use either. A different data class or approval of a specific external data flow may change the decision.
Sources
Read more
All articles
AI & Automation with ASES
AI assistants and automated workflows