• qa_deck_100#slide 83 · Implementation modes and deployment choices

Organisations should choose between cloud and local deployment for RAIDT by asking a governance question before an infrastructure question: can this deployment support a complete run-level evidence pack for each material use? RAIDT defines the run as the unit of governance, so the relevant test is whether the organisation can reconstruct one configured use in context through prompt and template identifiers, model deployment identifiers, configuration settings, retrieved context or snapshot hashes where relevant, outputs, checks, and oversight records. On that basis, deployment should be evaluated against the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability) and summarised in a score profile rather than judged by convenience alone. If a provider limits access to model identifiers, version metadata, safety-policy documentation, or low-level traces, the organisation may only achieve anchors 1=missing / 3=partial / 5=audit-ready on Auditability and Traceability, even when outputs appear useful.

Local or tightly controlled private deployment is therefore preferable for high-impact workflows where contestability, repeat-run testing, and post-incident reconstruction are essential. The papers show that versioning, logging, retrieval snapshots, integrity hashes, and review records are what make governance inspectable in practice. Cloud deployment can still be appropriate where the vendor exposes sufficient evidence fields and the task is lower risk, but it should be accepted only if evidence capture, retention, access control, and review workflows can be embedded around it. In RAIDT terms, influence methods as governance interventions must be assessed together with deployment architecture, because prompt controls, retrieval, adapters, and oversight only improve governance when their effects are actually recorded and reviewable at run level.

Consider a public-service eligibility advice workflow that uses retrieved policy text. A cloud API may be attractive because it is quick to scale and simple to integrate, but if the service does not expose the exact model deployment identifier, prompt version, retrieval snapshot, or review trace, the agency will struggle to defend a disputed recommendation months later. It may know that an answer was produced, yet not be able to show precisely which policy clause version was used or what controls were active at the time.

A local or private deployment behind the organisation?s orchestration layer can log the prompt template ID, policy snapshot hash, output hash, timestamp, and human review decision for each run. In RAIDT terms, that makes the run-level evidence pack reconstructable and improves the score profile, especially for Auditability and Traceability. For a high-stakes benefits decision, that governance advantage is likely to outweigh the extra operational burden of local control.

• 08-RAIDT_Foundations_M_V50
• 18-RAIDT-Technical-Foundation_M_v04