Select a deployment arrangement from the requirements of the whole workflow. Model location alone does not establish control over data, integrations or operations.
For: IT leaders and solution architects.
What you’ll take away
- Map data, access and operational responsibilities first.
- Compare deployment options using the same workflow and evaluation.
- Include maintenance, change and exit requirements in the decision.
Begin with a data-flow map
List the data entering the workflow and where it can appear: source systems, retrieval indexes, prompts, model requests, outputs, logs and backups. Include administrative access and third-party services. This map gives a deployment discussion a concrete subject.
Then identify the requirements that apply to each stage, including access, location, retention, availability and review. The appropriate arrangement depends on your context; a hosting label is not a substitute for assessing the actual service and contract.
Include a plain-language drawing alongside the technical map. A source owner should be able to see where a document is copied, where it is processed and where its content may persist after a user closes the application.
Compare the operating arrangements
| Arrangement | What to examine | Operating question |
|---|---|---|
| Managed cloud service | Provider terms, supported regions, data handling, access controls and available models | Which responsibilities remain with your team? |
| Private cloud environment | Network boundaries, administrative access, model hosting and connected services | Who maintains and validates the complete environment? |
| On-premises infrastructure | Compute capacity, model suitability, connectivity, patching and recovery | Can the organisation sustain the required service level? |
These categories describe possible operating arrangements. Individual implementations differ, and some workflows combine more than one.
For managed services, review the documented responsibility boundary for the particular service. Microsoft’s shared responsibility guidance is one starting reference. The operational assignment still needs to identify the people and controls used in your implementation.
Evaluate more than model quality
A model that performs well in a public test may behave differently on your documents, terminology or language mix. Compare candidate arrangements using the same representative tasks and review criteria.
Include the full task cost: infrastructure, integration, evaluation, human review and maintenance. Measure latency along the complete request path. Retrieval and document processing can be as relevant to the user experience as generation speed.
Ask the people who will operate the system to review the comparison. Their estimate should include source updates, access changes, incident investigation and regression checks. A lower infrastructure estimate can come with different support requirements.
Treat isolation as a design property
Hosting a model locally does not automatically isolate the application. Check outbound dependencies, support access, telemetry, package updates and backup paths. Equally, a cloud arrangement needs a review of the controls actually available and enabled.
Document the approved configuration and the conditions that trigger reassessment. A new source, model, integration or user group can change the original risk picture.
Work through one representative use case
Illustrative example: an internal policy assistant needs to search approved documents for two employee groups with different permissions. Compare each deployment option using the same library, questions and access tests. Include a withdrawn policy, an ambiguous question and a document that one group must not retrieve.
Record the complete path from the identity check to retrieval, generation and the source link shown to the user. Then compare answer support, response time, review effort and the work needed to maintain the service. This produces a decision grounded in the intended use, rather than a comparison of hosting labels.
Plan for a change of model or environment
A deployment decision should leave the team able to maintain and change the service. Identify what would need to move if a model, hosting arrangement or integration changed. This can include source-processing rules, retrieval indexes, prompts, evaluation cases, user permissions and operational records. Write down which elements depend on a specific service.
Review how the organisation can export or remove its information, how long the work could take and which people would carry it out. Some elements may be easier to recreate than to move. Record that assumption and its consequence for service continuity. A diagram alone will not reveal an operational dependency on an individual’s account or undocumented script.
Illustrative exercise: change one model in a test environment while keeping the same approved questions and sources. Note which interfaces, output checks and response expectations require adjustment. The exercise does not predict every future change, but it can reveal dependencies that deserve attention before the first release.
Use the result to complete a decision record with the selected option, owner, open questions and review triggers. Revisit the record when the workflow changes materially, rather than treating the initial choice as permanent.
Turn the comparison into a decision record
Record the intended use, assessed options, remaining uncertainties and the people who accepted the decision. Include the plan for testing and the reason an option was selected. This makes the choice reviewable when requirements change.
Use the AI readiness checklist to prepare the discussion. Aliph’s AI services can help define and evaluate an implementation scope.
Sources and further reading
These references offer additional context for the concepts in this resource.
- Microsoft Azure shared responsibility guidanceAn overview of responsibility boundaries across cloud service models.
- NIST AI Risk Management FrameworkA voluntary framework for considering AI risk across the lifecycle.
Published by Aliph Solutions. Examples and photographs are illustrative. Read our editorial approach for context on sources, dates and feedback.
Explore Aliph AI services
