Hosted access versus operating weights: who does what?

This guide helps you assign operating responsibilities. It does not establish the duties of a particular supplier or approve a deployment.

A hosted AI service, self-operated downloadable weights and a managed deployment of selected weights divide the work differently. None of those labels tells you who will fix a failed integration, check a model update or restore the firm’s application records.

The useful question is:

For this exact arrangement, who does each job, who checks it, and what happens when it fails?

This guide assumes an Australian professional-services firm is considering a bounded evaluation with human review. Its practical output is a responsibility record for one proposed arrangement. If you are comparing several arrangements, complete a separate record for each.

The companion Open weights, closed weights and the rights your firm needs covers the broader route decision. The exact-weight licence worksheet helps you record weight and component permissions and unresolved rights questions; it does not provide legal clearance. Here, the task is to make the operating boundary visible.

Identify what is actually being proposed

Start with a short description of the arrangement:

• Hosted model service: a provider operates the model service; the firm may still build and maintain the application that connects to it.
• Self-operated weights: the firm arranges operation of the model in a selected environment. Hosting, software, support and integrations still need named owners.
• Managed selected weights: a supplier manages specified parts of a deployment using selected weights. Its scope may stop at the endpoint, leaving the application and workflow with the firm.

These are descriptions, not contractual allocations. Do not infer that “managed” includes backup of the firm’s records, or that “self-operated” means no information reaches an external service.

Microsoft’s AI shared responsibility model distinguishes AI platform, application and usage layers across service models. The primary page, checked 5 October 2026, states that Microsoft frames this as illustrative governance guidance, not a change to an agreement.

AWS’s Shared Responsibility Model describes AWS and customer responsibilities that vary by service and integration. The page, checked on the same date, supports using that distinction to ask better questions—not to establish what an unrelated AI supplier has agreed to do.

Copy the arrangement record

Complete this header before assigning tasks. Use unknown or not checked rather than leaving gaps blank.

Field	Record
Record ID and accountable business owner	[Identifier; named owner]
Proposed workflow	[Task; users; human review; evaluation dates]
Arrangement	[Hosted service / self-operated weights / managed selected weights; exact scope]
Supplier and supporting services	[Provider; host; manager; relevant subcontracted services where known]
Service and model identity	[Product/tier; endpoint or environment; model/checkpoint identifier; version where available]
Application boundary	[What the firm builds or operates; integrations; support tooling]
Information boundary	[Allowed data classes; prohibited inputs; output and log locations; access]
Evidence	[Applicable agreement; service description; configuration records; versions and check dates; evidence location]
Excluded uses	[For example: client access, confidential-data use or production reliance—not assumed exclusions]

Add a simple system sketch:

Information source → firm application → model service/runtime → outputs and logs

Mark any additional storage, support or telemetry paths. Note who can access each location and which paths remain unknown. The sketch is a working record, not proof that the information boundary is acceptable.

Use these questions to find the work

For each responsibility below, identify the exact tasks on both sides of the boundary. Split a row when different people or organisations perform different parts.

Responsibility	Questions to resolve
Infrastructure and runtime	Who operates the model runtime, host, network and connecting application? Where does each party’s work stop?
Model version and updates	Who selects or changes the model? Who communicates changes, checks the workflow afterwards and handles rollback where available?
Application integration	Who maintains prompts, connections, error handling and workflow controls?
Identity and access	Who grants and removes staff access, protects credentials and administers each console or endpoint?
Inputs, retention and logs	What is sent, stored and logged? Who sets retention, can inspect records and can change the configuration?
Monitoring	Who watches service health? Who detects failed requests and problematic workflow outcomes? Who receives and acts on alerts?
Output review	Who reviews consequential outputs before use? Who records corrections and handles uncertain results?
Incident handling	Who contains, investigates, notifies and restores each type of failure? What evidence and escalation routes are available?
Backup and recovery	What is backed up? Who restores the firm’s configuration and records? Who verifies restoration and the recovery expectations?
Exit	What can be exported or retained? Who removes access, retires integrations and confirms any agreed deletion?

The delivery arrangement changes which questions need particular attention:

• Hosted service: distinguish the provider’s model service from the firm’s account, application and workflow.
• Self-operated weights: name the people maintaining the runtime and supporting environment; do not assume that obtaining files supplies ongoing support.
• Managed selected weights: match each claimed managed task to the actual scope of work, and identify what remains with the firm.

Copy one responsibility card per task

The questions above are not completed assignments. Use this card to turn each material task into a checkable record.

Field	Entry
Responsibility and exact task	[For example: restore the firm’s application configuration—not simply “backup”]
Boundary	[Systems and records included; items excluded]
Performing party	[Named team/person or supplier role; unassigned if unknown]
Accountable firm owner	[Person who ensures the allocation is adequate and checked]
Supplier contact, if relevant	[Role/contact route; escalation route]
Evidence and date	[Agreement section, scope of work, configuration or other evidence]
Verification	[What must be checked or tested; by whom; result or pending status]
Failure response	[What staff do; who is contacted; any stop condition]
Unresolved issue	[Precise gap; affected activity]
Next check	[Named person; required evidence or test; due date]
Status	[Evidenced / unresolved / disputed / not applicable—with reason]

“Supplier backs up” is not a complete entry. It leaves unanswered what is backed up, whether the firm’s application state is included, and who has checked that restoration works.

Likewise, “shared” is not a task assignment. Record each party’s part separately.

Review the record with the people doing the work

Obtain the applicable service description, agreement and configuration evidence for the proposed account and use.

For self-operation, include hosting and maintenance arrangements. For managed weights, obtain the manager’s scope of work and list the firm’s retained tasks. If a claim depends on a setting, record who can change it and how a change will be detected.

Then review the record with the relevant owners:

• The technical owner checks infrastructure, access, updates, monitoring, restoration and incident hand-offs.
• The information or privacy owner checks proposed information classes, paths, retention and access. This review alone is not an Australian regulatory-compliance finding.
• The workflow owner specifies output review and what staff do when the system is unavailable or wrong.
• The commercial or procurement owner checks supplier scope, support and exit evidence.
• A qualified legal reviewer, where needed, addresses material ambiguity in terms or obligations.

One person may hold several roles. The important point is to name them and record their input, rather than treating “IT” or “the supplier” as a complete answer.

A recovery gap hidden by a service label

Fictional, untested example. No supplier, account, system or recovery test has been inspected.

An advisory firm proposes using a managed deployment of selected weights to help staff sort synthetic practice documents. The proposal says the manager operates the endpoint. Staff assume that this includes everything needed to resume work after a failure.

While completing the recovery card, the operations lead finds no evidence that the manager backs up the firm’s classification rules, application configuration or review records. The application owner assumed the infrastructure contact owned that work; the infrastructure contact assumed the application owner did.

The gap is not evidence that managed deployment is unsuitable. It is evidence that an essential task remains unassigned.

For an evaluation that depends on retaining those records, the owner holds the affected step. The next checks are to:

1. Obtain the manager’s documented backup scope.
2. Assign responsibility for the firm’s application-state backup.
3. Specify and complete a proportionate restoration check before relying on recoverability.

If the evaluation can instead be designed safely without persistence, the owner may seek approval for that narrower scope. The record must state what can be lost and how staff will respond. It must not claim a recovery capability that has not been verified.

Record a bounded decision

Copy this closing record:

Field	Decision
Operating-responsibility outcome	[Ready for the defined evaluation / hold affected activity / obtain further evidence]
Scope	[Users; workflow; allowed data; dates; required controls]
Exclusions	[Uses and reliance not covered]
Supporting evidence	[Completed task cards; evidence references; reviewer input]
Outstanding issues	[Issue; why it does or does not affect this scope; owner and due date]
Decision owner and date	[Accountable business owner; recorded decision]
Other required checks	[Rights; information handling; technical feasibility; task fit; status and owner]
Review triggers	[Provider, tier, checkpoint, configuration, data class, users or delivery changes]

Mark the operating-responsibility check ready only when every material task has an evidenced allocation, a firm owner for verification and an agreed response to failure. This is not permission to bypass the separate rights, information-handling, technical or task-fit checks.

Hold the affected activity when an essential data path, supplier commitment, incident hand-off or recovery duty is unknown, disputed or unowned. A useful next check names the person, required evidence and due date.

Next action: choose one proposed arrangement, complete its header and system sketch, then review the material task cards with its business, technical and workflow owners.

Sources and boundaries

The linked Microsoft AI shared responsibility guidance and AWS shared responsibility model were checked 5 October 2026. They describe their own frameworks. Neither source establishes an unnamed supplier’s duties or guarantees privacy, security, location, retention, access or recovery. The task cards are a proposed method, not a verified allocation for a real service.