
On February 10, 2026, in United States v. Heppner (No. 25-cr-00503-JSR, Southern District of New York), Judge Jed Rakoff held that roughly thirty-one documents a defendant prepared using the consumer version of a generative AI platform were not covered by attorney-client privilege (the confidentiality protection on lawyer-client communications) or the work-product doctrine (the protection on material prepared for litigation). The defendant had used a public AI chatbot to work on his own defense. The court’s reasoning reaches far beyond one criminal docket: putting information into a public AI platform is disclosure to a third party, and disclosure to a third party is how confidentiality dies.
It was not an isolated signal. In a separate matter, a federal court ordered roughly 20 million ChatGPT conversation logs produced to the plaintiffs in the consolidated copyright litigation against OpenAI, over the platform’s objections that production would invade its users’ privacy. Two different courtrooms, one consistent message: every prompt your team types into a rented AI service is a business record on someone else’s server, kept under someone else’s retention policy, reachable by someone else’s litigation.
The privilege analysis in Heppner turns on a doctrine every first-year law student learns: confidentiality protections survive only as long as the communication stays inside the protected circle. Hand a draft to an outside party with no duty of confidentiality and the protection is waived. The court treated the consumer AI platform as exactly that kind of outside party: its privacy policy gave the user no reasonable expectation of confidentiality, so material routed through it was shared with a stranger to the privilege. The work-product claim failed separately, because the documents were not prepared by or at the direction of counsel.
The holding was expressly tied to those facts: a public, non-enterprise platform, used without counsel’s direction. That is the door left open, and legal commentators analyzing the ruling have walked straight through it: tools that contractually or architecturally guarantee confidentiality can support a different analysis. On-premise AI is the strongest form of that guarantee, because the data never leaves the organization’s control and no third party ever holds it. Confidentiality by the system’s design, not by a vendor’s promise.
Privilege is the sharpest version of the issue, but the underlying logic applies to any confidential information: client lists, financials, personnel matters, unfiled patents, M&A discussions, source code. If it is confidential, and your team pastes it into a public AI prompt box, you have shared it with a third party whose logs are discoverable and whose retention policy you do not control. The 20-million-logs production order makes that concrete: the logs existed, so they were produced.
A private AI server dissolves the third-party problem instead of papering over it. The model runs inside your walls. Prompts, drafts, and outputs never cross the internet. The only logs are on your hardware, under your retention policy, inside your discovery perimeter, exactly like the rest of your files.
What that looks like in practice on an eRacks system:
One necessary caveat: we build architecture, not legal opinions. Whether and how the Heppner analysis applies to your practice is a question for your counsel. What we can say is that the technical side of the answer is now the easy part.
The full breakdown for legal practices, including the ruling timeline and an architecture comparison, is at eracks.com/law-firm-ai-server. For everyone else wondering what it would take to bring confidential AI work inside the building: tell us what your team runs through AI today, and we will tell you straight which box does it, or whether you need one at all.
joe July 28th, 2026
Posted In: AI Servers, News
Tags: AI confidentiality, AI provisioning, AILSA, air-gapped AI, attorney-client privilege, ChatGPT logs, law firm AI, legal AI server, on-premise AI, private AI, US v Heppner, work product

Running large language models (LLMs, the AI models behind chat assistants) on your own hardware, often called “private” or “on-premise” AI, keeps your data inside your building, replaces per-user cloud fees with a one-time purchase, and removes vendor lock-in. The catch is sizing it right. We just published a full, vendor-neutral guide to doing exactly that, and here is the short version.
Three reasons come up again and again. Privacy and compliance: protected health information (HIPAA), attorney-client material, controlled government data, and source code often cannot legally or contractually leave your control. Predictable cost: a one-time purchase instead of per-seat or per-token billing that grows with every user and every query. Control: your models, your uptime, no rate limits, and no vendor quietly deprecating the model your workflow depends on. For light or occasional use a cloud API is cheaper and simpler; private AI wins when you have data you cannot send out, or when usage is steady and everyday.
A model has to fit in GPU memory (VRAM, the fast memory on the graphics card) to run at full speed. How much you need is set by the model’s parameter count and its quantization (compressing the weights to fewer bits each: Q4 is about 4 bits per weight and near-lossless for most tasks, Q8 is about 8 bits, fp16 is full precision).
| Model size | Q4 (4-bit) | Q8 (8-bit) | Good for |
|---|---|---|---|
| 7 to 8B (Llama 3.1 8B, Mistral) | ~6 GB | ~10 GB | chat, RAG, coding assist |
| 32 to 34B (Qwen 2.5 32B) | ~22 GB | ~38 GB | strong reasoning, agents |
| 70B (Llama 3.3 70B) | ~42 GB | ~80 GB | frontier-class open models |
| 120B+ or several at once | 70 GB+ | 140 GB+ | heavy or multi-tenant |
A quick rule: VRAM in GB is roughly the parameter count in billions times 0.6 for Q4, or times 1.1 for Q8, with context headroom included. (RAG, or retrieval-augmented generation, feeds the model your own documents at query time.)
System RAM stages models into the GPUs, runs the model server and your data pipeline, and spills over when a model is slightly too big for VRAM. Size it at roughly 1.5 to 2 times your total VRAM. CPU and PCIe lanes: the processor feeds the GPUs through PCIe lanes, so a multi-GPU server needs enough lanes to drive every card at full bandwidth. That is why we build on server-class AMD EPYC and Intel Xeon processors rather than desktop chips: far more PCIe lanes, and support for ECC (error-correcting) memory.
The arithmetic is direct. A cloud subscription such as ChatGPT Team runs about $30 per user per month. For a 30-person team that is roughly $10,800 a year, every year, with your prompts on someone else’s servers. An on-premise eRacks AILSA at $7,695 covers the same everyday inference on hardware you own, and pays for itself in under a year. In practice, self-hosting wins at roughly 5 to 10 or more regular users, or any privacy mandate.
You do not need flagship NVIDIA silicon to run these models. You need VRAM.
| Server | GPU memory | Comfortably runs | From |
|---|---|---|---|
| AILSA (2U) | up to 96 GB | Llama 3.3 70B (Q4), Qwen 2.5 32B | $7,695 |
| AIDAN (2U) | 32 GB | 32 to 34B models, 8B at full precision | $13,895 |
| AINSLEY (4U) | 128 GB | 70B with room for long context | $21,995 |
| AISHA (4U) | up to 256 GB | 70B at Q8, or several models, multi-tenant | $30,995 |
Every eRacks AI server ships with Ubuntu LTS (long-term-support Linux) and a complete open-source AI stack (Ollama, Open WebUI, vLLM, llama.cpp, PyTorch) pre-installed and tested. Staff reach the AI from a browser on day one. No per-seat or per-token fees, you own the hardware, and your data never leaves the building.
Start from the model, not the GPU: decide the largest model you will run and at what quantization, size the VRAM (about params times 0.6 for Q4), then add system RAM at 1.5 to 2 times that, and choose a server CPU with the lanes for your GPU count. If privacy is the driver, on-premise is the answer and the only question is which size. And the entry is lower than people expect: a 70B-class model, private, from $7,695.
Configure an AI server → or read the full sizing guide.
Want us to size one to your exact models and user count, at no charge? Reply to this post, a real engineer will help.
joe July 27th, 2026
Posted In: AI Servers, News
Tags: AI inference server, AILSA, GPU VRAM, HIPAA AI, Intel Arc Pro B50, Intel Arc Pro B70, Llama 70B, local LLM, on-premise AI, open source AI server, private AI, Qwen 32B, self-hosted LLM, system RAM

We have restructured the eRacks private AI server line into a clear Good, Better, Best ladder. The goal is simple: whatever size model you want to run, there is one obvious system for it, at a price that reflects what is actually inside the box. Prices on the mid-tier dropped substantially from the old line, because the new systems use current-generation parts and are sized honestly for the work.
First, the framing. Private AI means running large language models (LLMs, the software behind AI assistants) on hardware you own, inside your own building. Your prompts, your documents, and your model outputs never touch a cloud provider. You buy the system once, and there are no per-seat or per-token fees afterward. Every system in the line is air-gap ready (able to operate with no internet connection at all), which matters for legal, medical, financial, and government work.
The AILSA is the entry point. It is a 2U system (a U is 1.75 inches of rack height) assembled, burned in, and certified by eRacks, with Intel Arc GPUs (graphics processing units, the chips that run AI models). The base build carries two Arc B50 low-profile cards for 32GB of VRAM (the GPU’s onboard memory, which holds the model), with larger Arc Pro options available in the configurator. It handles 70B-class models (roughly 70 billion parameters), which covers most private chat, coding, and RAG workloads (retrieval-augmented generation, where the model answers from your own documents).
The new AISLING is the workhorse of the line. It pairs a 24-core AMD Threadripper 9960X with 128GB of ECC memory (error-correcting code memory, which detects and fixes memory errors) and a single 1600W power supply. The 4U chassis takes up to three dual-slot GPUs, which means 96GB of total VRAM with Intel Arc Pro B70 cards. That is enough headroom to run a 70B-class model at higher precision, serve more simultaneous users, or hold longer context windows.
The new AILEEN steps up to server-class silicon: a 32-core AMD EPYC 9355 with 12 memory channels and 192GB of ECC memory. The extra memory bandwidth feeds the GPUs and speeds up CPU-side work like document indexing. It takes up to four GPUs for 128GB of VRAM, and it has redundant 1+1 power (two supplies, either one can run the system alone). AILEEN also ships in custom colors: blue, black, white, or red. The blue unit is the one pictured here.
| Model | Form factor | GPU memory (VRAM) | From |
|---|---|---|---|
| AILSA | 2U | 32GB base, larger Arc Pro options | $5,995 |
| AISLING | 4U | up to 96GB (3 x Arc Pro B70) | $16,995 |
| AILEEN | 4U | up to 128GB (4 GPUs) | $21,995 |
Some buyers need validated OEM server systems rather than our eRacks-Certified workhorse builds, usually because their ops teams require out-of-band management (a dedicated channel for remote hardware control, such as IPMI, that works even when the operating system is down). For them, the AIDAN 2U EPYC starts at $13,895, and the AISHA 4U starts at $30,995 with support for up to 10 GPUs.
All five models ship with Ubuntu LTS and the open-source AI stack pre-installed: Ollama, Open WebUI, vLLM, llama.cpp, and PyTorch. Each unit is burned in (run under sustained load before shipping) and tested. You get browser access to your own models on day one: unbox, rack, log in.
Not sure which tier fits? Start with our private AI sizing guide, which walks through how much GPU memory and system RAM a given model actually needs. Then configure the system that matches.
joe July 5th, 2026
Posted In: AI Servers, News
Tags: AI server, AMD EPYC, AMD Threadripper, GPU server, Intel Arc Pro, Ollama, open source AI, private AI, self-hosted LLM, vLLM