Q259 - Cloud_vs_local_deployment_definition_example_and_why_it_matt
Q259 — Cloud vs local deployment — definition, example, and why it matters in RAIDT
← RAIDT · Star S8 - Implementation and Operations · primary item: S8.08 · Cloud deployment
G. Implementation & Operations | Ordered by mind-map priority: inner circles first, then operational detail.
Appears in sources
workshop_dense_100#slide 82
Answer
In RAIDT, cloud versus local deployment is not primarily a hosting distinction; it is a difference in how much governance-relevant evidence the organisation can access and preserve. Cloud deployment typically means using a vendor-managed model or platform through an API or managed service. Local deployment means the organisation controls the execution environment more directly, whether on-premises or in a tightly governed private stack. RAIDT treats this distinction as important because run as the unit of governance means every material use must be reviewable as evidence, not merely described through model-level documentation. The relevant question is therefore whether the deployment can generate a run-level evidence pack that supports reconstruction, challenge, and comparison across uses.
Why this matters is visible in the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability). A cloud service can be scalable and convenient, but it may expose only partial metadata, leaving gaps in model deployment identifiers, version history, retrieval snapshots, or raw traces. In that case, the organisation may achieve a superficially strong output while still recording a weak score profile for Auditability or Traceability. By contrast, local deployment can support stronger version control, repeat-run testing, logging, and integrity checks, which helps reviewers apply anchors 1=missing / 3=partial / 5=audit-ready in a defensible way. RAIDT therefore makes deployment choice consequential for governance readiness: influence methods as governance interventions only count when they are preserved as inspectable evidence within the run-level evidence pack.
Practical example
A healthcare note summarisation service illustrates the distinction. If a hospital uses a cloud scribing service that returns only the final summary and minimal metadata, clinicians may receive a convenient draft but governance teams may be unable to reconstruct which prompt template, deployment version, or safety settings shaped the note. If a complaint later alleges that pending test uncertainty was omitted, the organisation has little basis for review beyond the text itself.
With a local or tightly controlled private deployment, the same task can be logged with the prompt template ID, decoding settings, model deployment identifier, output hash, retrieval snapshot where applicable, and a human oversight flag. That evidence allows the hospital to inspect the run-level evidence pack, justify the score profile, and decide whether the workflow is dependable enough for continued use in a safety-critical setting.
Sources in RAIDT papers
08-RAIDT_Foundations_M_V5018-RAIDT-Technical-Foundation_M_v04