Q155 - What_is_the_difference_between_local_and_cloud_configuration
Q155 — What is the difference between local and cloud configurations in RAIDT?
← RAIDT · Star S8 - Implementation and Operations · primary item: S8.09 · Local deployment
Appears in sources
integrated_82#Q4.4
Answer
In RAIDT, the difference between local and cloud configurations is not a difference in the governing framework itself, but a difference in deployment context, evidentiary reach, and which interventions are technically feasible. RAIDT treats the "run as the unit of governance", so a case is defined as a scenario paired with an influence configuration and a model deployment, which may be either a cloud API assistant or a local instruct model. In both settings, the same "run-level evidence pack" is required: run identifiers, prompts, model or deployment identifiers, configuration settings, retrieved context snapshots where relevant, outputs, and recorded checks. Those artefacts are then assessed across the "five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability)", yielding a "score profile" using "anchors 1=missing / 3=partial / 5=audit-ready".
The substantive difference lies in control over the configured system and therefore in what can be versioned and reconstructed. In the empirical RAIDT study, baseline prompting, structured prompting, and RAG were implemented in both cloud and local settings, whereas LoRA/PEFT and RLHF-type alignment were executed locally because they required adaptation or preference optimisation on model weights. Local configurations therefore support direct governance of adapters, alignment layers, and training provenance, but they also require a controlled environment and stronger lifecycle management. Cloud configurations remain governable under RAIDT, yet their governance readiness depends more heavily on disciplined capture of prompts, retrieval snapshots, deployment identifiers, and checks. The central empirical finding is that governance outcomes depended less on vendor branding than on evidence completeness and whether "influence methods as governance interventions" were instrumented and logged.
Practical example
Consider the HR shortlist scenario reported in the RAIDT programme. A team could run a cloud API assistant to draft candidate justifications, recording the prompt template ID, job-criteria version, model deployment ID, outputs, and reviewer checks in the evidence pack. That cloud run could still achieve a strong RAIDT profile, but if the organisation later cannot show the exact configuration used, traceability and auditability weaken.
A local configuration changes what the organisation can govern directly. If the same HR workflow uses a local instruct model with a versioned LoRA adapter aligned to the organisation's rubric, the team can also record adapter identifiers and training provenance. This makes the run easier to reconstruct months later if an applicant challenges the decision. The trade-off is operational: the organisation must maintain the controlled environment, version control, and logging discipline needed to preserve that evidence reliably.
Sources in RAIDT papers
09-RAIDT_Empirical_M_V50.docx08-RAIDT_Foundations_M_V50