Attorney-client privilege is incompatible with most cloud AI deployments. A self-hosted DGX Spark restores the architectural property that the privilege has always required. Here is the case for law firms considering sovereign AI, with the specific concerns about discovery, work product, and ethics rules.

Sovereign AI for Law Firms

9 min read
authoritysovereign-ai

Attorney-client privilege is incompatible with most cloud AI deployments. The privilege has always required that confidential communications stay within the attorney-client relationship; sending those communications to a third-party AI vendor’s servers for processing is in tension with that requirement at the architectural level. A self-hosted DGX Spark restores the architectural property the privilege requires.

Quick Take

  • The privilege problem: sending privileged communications to a third-party AI vendor’s servers introduces a third party into the communication. Most US ethics opinions in 2026 have flagged this as a risk; some have flagged it as a likely waiver.
  • The work-product problem: AI-generated drafts are work product. Sending them to a cloud AI for refinement potentially exposes the firm’s litigation strategy.
  • The discovery problem: if AI-generated drafts have been processed by a cloud AI, the prompts and responses are arguably discoverable in litigation. The cloud vendor’s logs are arguably subpoena-reachable.
  • The self-hosted answer: the firm holds the AI on its own infrastructure. No third party in the communication; no third-party logs to subpoena; the privilege analysis becomes the same as it has always been.
  • The DGX Spark fit: legal document analysis, contract review, deposition summarization, and brief research are workloads that fit the Spark’s MoE-language-model architecture comfortably.

The privilege problem in more detail

Attorney-client privilege protects confidential communications between an attorney and their client made for the purpose of obtaining legal advice. The privilege requires confidentiality; the communication must not be disclosed to third parties. Disclosure to a third party generally waives the privilege.

A cloud AI vendor that processes the firm’s communications is a third party. The vendor’s terms of service typically include logging, retention, and (depending on the vendor) training on the input data. Each of these is in tension with the confidentiality requirement.

Several state and federal bar associations have issued opinions in 2024-2026 that flag cloud AI use in legal practice as a risk area. The opinions vary: some require informed client consent before cloud AI use; some require that the cloud vendor sign a Business Associate Agreement equivalent; some flag specific use cases as inappropriate. The trend across opinions is toward more caution rather than less. By early 2026, at least 14 state bar associations had issued formal guidance or ethics opinions on attorney AI use, with the majority treating cloud-processing of client communications as a disclosure that demands affirmative client consent.

Why does attorney-client privilege push toward off-cloud AI? Because the privilege is not a policy preference; it is an architectural requirement. The Upjohn Co. v. United States ruling (1981) and the body of state common law built on it treats any voluntary disclosure to a third party as a potential waiver. A cloud API call is voluntary disclosure to the vendor’s infrastructure. The self-hosted alternative removes that third party from the communication path entirely.

Caveat: on-premises is not the right answer for every firm. A two-attorney practice billing under $500,000 per year may have no IT staff and no suitable physical space for server hardware. For that firm, a properly configured cloud vendor relationship with a signed data processing addendum, strict retention limits, and explicit client consent may be more defensible than a self-hosted deployment managed by a non-technical administrator.

The self-hosted alternative removes the third party from the communication. The AI runs on the firm’s own infrastructure, the firm controls the access and retention, and the privilege analysis returns to its pre-AI form.

The work-product problem

Work product doctrine protects materials prepared by an attorney in anticipation of litigation. Drafts, internal memoranda, and strategic analyses are work product.

AI-generated drafts of legal documents are arguably work product (the question is somewhat unsettled in 2026 but the trend is toward inclusion). If a firm uses a cloud AI to refine a draft, the draft and the prompts have been disclosed to the cloud vendor. The vendor’s logs contain the firm’s work product.

A subpoena directed at the cloud vendor in connection with the litigation could reach those logs. The vendor’s response depends on the vendor’s compliance posture; many vendors will produce logs in response to a lawful subpoena. The firm’s work product becomes discoverable in a way the firm did not anticipate when it decided to use the cloud AI.

The self-hosted alternative keeps the work product on the firm’s infrastructure. The firm’s existing discovery protocols apply. The cloud vendor’s logs do not exist because there is no cloud vendor in the path.

The discovery problem

Even routine matters can produce discovery surprises. A firm’s use of cloud AI in case A can produce discoverable artifacts that affect case B if the same AI service was used.

Why does GDPR Article 6 lawful-basis analysis matter for EU-facing law firms? Because most cloud AI vendors process data under a “legitimate interests” or “performance of contract” basis. If the firm is handling personal data about opposing parties, witnesses, or third parties, the firm bears the burden of establishing its own lawful basis for sending that data to the vendor. Article 83 of the GDPR sets fines up to 4% of global annual turnover or EUR 20 million, whichever is higher. The exposure is not theoretical for law firms that handle cross-border matters.

Caveat: the privilege-protection model has a gap on cross-jurisdiction work. A UK firm advising on EU-regulated matters faces not only GDPR but the UK GDPR and, depending on data transfer paths, adequacy-decision constraints. A US firm with EU clients faces extraterritorial GDPR obligations that the “keep it on-prem” answer addresses only if the on-premises server is in the right jurisdiction. Infrastructure jurisdiction is a separate analysis from privilege.

The cloud vendor’s logs are arguably the firm’s records, depending on how the vendor structures the relationship. If the firm is the data controller and the vendor is the data processor (which is the typical GDPR-frame structure), the logs are the firm’s data. Discoverable from the firm via subpoena directed at the firm; possibly discoverable from the vendor directly via subpoena directed at the vendor.

The firm that has used cloud AI on dozens of matters has an attack surface for discovery that the firm using self-hosted AI does not. The attack surface may or may not be exploited; the firm’s risk profile depends on whether opposing counsel notices the cloud-AI use.

The self-hosted answer eliminates the new attack surface. The firm’s existing document retention and discovery protocols cover the AI’s outputs; no new vendor relationship is added to the firm’s discovery profile.

What the DGX Spark deployment looks like

A law-firm sovereign-AI deployment has three workload categories.

Category 1: contract review. The AI reads incoming contracts, identifies clauses that match or differ from firm-standard templates, and flags items for partner review. The workload is high-volume (dozens to hundreds of documents per week) and the AI’s output is internal-review material rather than client-facing work product.

Category 2: deposition and document review. The AI ingests deposition transcripts or large document sets, produces summaries, identifies key passages, and supports the attorney’s review. The workload is variable but can be intensive during discovery phases.

Category 3: brief research. The AI assists with legal research, identifying relevant cases and producing initial drafts. The workload is bursty around brief-writing deadlines.

All three workloads fit on a single DGX Spark with Qwen 3.6 PrismaQuant as the primary model. The unified-memory architecture handles the long-context document analysis that legal work demands. The on-premises form factor satisfies the privilege concern at the architectural level.

Why model isolation per matter? Because a model that has ingested document set A during in-context processing retains that context for the duration of the session. Without explicit context boundaries, asking the model about matter B while still holding matter A context can produce cross-contamination of the AI’s working memory. The practical answer is a per-matter inference session, started fresh with no carryover context. This is straightforward to enforce with a self-hosted deployment; it is not something a cloud API user can reliably verify.

Caveat: model isolation is not the same as data isolation. A self-hosted deployment that writes inference logs to a shared disk without per-matter access controls has the same cross-contamination risk at the data layer that cloud deployments have at the vendor layer. The deployment runbook needs to specify log retention, per-matter subdirectories, and access-control policies as explicitly as it specifies the inference server configuration.

Caveat: BAR rules are not uniform. ABA Model Rules of Professional Conduct Rule 1.6 (Confidentiality) and Rule 1.1 (Competence, including technological competence as clarified in the 2012 amendment to Comment 8) provide the federal baseline, but each state adopts its own version. As of mid-2026, a small number of states still have not issued AI-specific guidance, meaning a firm practicing in those jurisdictions must reason from first principles applied to existing confidentiality rules.

For the broader reference architecture, see The Sovereign AI Stack in 2026. For the compliance-instrumentation patterns that apply across regulated industries, see Sovereign AI Healthcare: GDPR / HIPAA / DGX Spark.

What the firm needs to plan for

The deployment is not free. The firm takes on responsibilities that the cloud vendor would have handled.

IT operational capacity. The firm needs an IT operator who can manage a Linux server. Most large firms have this; small firms may not. The deployment writeup should include a runbook handover, but the firm needs at least one person who can execute the runbook. Caveat: a firm without that operational capacity should not deploy at all; the architecture is wrong if the operational layer cannot stand it up. As of 2026, finding qualified IT staff for niche LLM-stack work is itself a constraint that the budget conversation usually understates.

Hardware budget. Roughly €4,500 for the DGX Spark plus ancillary equipment. The total is small compared to most firms’ annual technology budgets but is real capital outlay.

Recurring maintenance. Roughly 4 hours per month of IT time for ongoing maintenance, plus occasional crash recovery (see Power Failure Recovery on a DGX Spark: The 30-Minute Procedure).

The total first-year cost for a law firm is roughly €20,000 to €30,000 all in. The cost is justified by the elimination of the privilege-and-discovery risks above plus the operational benefit of having a capable AI tool that the firm controls.

Where this fits

For the broader compliance framework, see Sovereign AI Healthcare: GDPR / HIPAA / DGX Spark (the patterns are similar; the specific regulations differ). For the reference architecture, see The Sovereign AI Stack in 2026. For the broader cost model, see Self-Hosted AI vs Cloud APIs: Real Total Cost.