
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
This month, one of our distributors repriced a GPU by 29 percent. Overnight. The same card, quoted to us on a Thursday, cost $280 more on Friday. Server-grade DDR5 ECC memory (error-correcting code memory, the kind servers use to detect and fix bit errors) is running $24 to $28 per gigabyte on the street, roughly triple what it cost before the 2026 memory shortage. Enterprise hard drives jumped too.
In a market like this, most server vendors reach for the same three tricks. We think you should know what they are, because we built our whole pricing system to do the opposite.
The teaser config. The advertised price quietly assumes last year’s components: less memory than the workload needs, a boot drive standing in for storage, a processor two generations back. The real configuration costs thousands more, which you discover after you are invested.
“Call for pricing.” If the vendor will not put a number on the page, the number depends on who is asking. That is not pricing, that is negotiation, and it always favors the side with more information. That is never the buyer.
The silent quote. A price quoted in a volatile market is a bet. Some vendors let you carry a stale quote right up to the purchase order, then “revise” it when backing out is hardest.
The configurator price is the price. Every configuration on eracks.com produces a real, orderable number, computed from what the components actually cost us. No “starting at” games: change the memory, the drives, the GPUs, and watch the price move in both directions, up and down, with the parts market.
Robots watch the market so the catalog stays true. Automated trackers re-check memory, drive, and GPU street prices daily and weekly, and feed re-pricing that a human reviews before it ships. When a component spikes, we re-price openly rather than let the old number quietly stop being true.
When a build goes underwater, we fix the build in the open. This week our own margin checks flagged two NAS models whose entry configurations no longer made sense at current drive prices. We did not pad the price and we did not gut the spec quietly. We changed the default drive count, published the same price, and left every larger configuration exactly where it was. The entry price stayed real.
Quotes tell you everything up front. As of this month, every formal eRacks quote carries five things: your discounts by name, a validity window, a component-volatility note, an estimated lead time (in this market, chassis allocation is a real thing, and you deserve to know it before you order), and a configuration that matches a product we actually ship today. That last one sounds obvious. It is not industry practice.
When we cannot source a part at a price we can stand behind, we say so. Some configurations show “get a quote” instead of a number. That is not coyness. It means the market for that part is moving too fast for a printed price to stay true, so we price it fresh, with a validity window, when you ask.
Earlier this year a prospect told us one of our configurations looked misleading. We did not enjoy hearing it, and he had a point: a stale page had drifted out of sync with the parts market. That critique turned into the system described above: automated price tracking, margin floors, re-verified defaults, and the five-line quote rule. The fix for being wrong is not better wording. It is better plumbing.
We have been building open-source servers since 1999. No venture capital, no lock-in, no per-seat fees, and nothing in the business model that needs a pricing trick to work. In a shortage, transparent pricing is slower and occasionally embarrassing. It is also the only kind worth publishing.
Configure anything, from a ZFS NAS to a private AI server, and the number you see is the number. If your workload does not fit a page, ask us and you will get a quote with all five lines on it.
joe July 20th, 2026
Posted In: News
Tags: AI server, DRAM shortage, NAS, no lock-in, Open Source, quotes, server pricing, supply chain, transparent pricing

The 2026 drive and memory shortage has quietly broken a lot of storage price lists. Drives that vendors still advertise as standard are backorder-only at every national retailer. Memory prices moved 50 percent in a quarter. A configurator that hasn’t been re-checked against real supply this year is, politely, fiction.
So we re-verified our entire NAS line: every default component, checked against multiple named suppliers, for both price and actual in-stock availability. Here is what changed, and what it means if you’re shopping for storage this summer.
Our large NAS models used to default to the 30TB Seagate IronWolf Pro. It’s a fine drive, and it has become effectively unobtainable: backorder-only at the one national supplier still listing it, dropped from Seagate’s own current lineup, unavailable everywhere else we checked. Continuing to default to it would mean quoting systems we could not ship this week.
The fix: our high-capacity systems now default to the 24TB IronWolf Pro, in stock at multiple national retailers at about $35 per terabyte, and we added the 32TB IronWolf Pro, also in stock, at the top of the ladder at nearly the same cost per terabyte. Every drive in our NAS configurators remains CMR (conventional magnetic recording); we do not use shingled SMR drives, whose write performance collapses during the sustained writes of a RAID rebuild, exactly when you can least afford it.

Every eRacks storage system, from the 1U four-bay NAS4 to the petabyte-class NAS100, now defaults to a ZFS RAIDZ2 pool: dual parity, meaning any two drives can fail without losing data. RAIDZ3 (triple parity) and striped mirrors (the performance-first layout) are right there in the dropdown, and traditional hardware RAID remains available for shops that require it, just never as a silent default.
Under every pool is an IT-mode HBA (a host bus adapter that passes drives directly to the operating system), because ZFS wants to see raw drives to do its end-to-end checksumming and self-healing. If you’re deciding between RAIDZ2, RAIDZ3, and mirrors, our free ZFS layout guide works through the math.
Component costs moved, so prices moved: mid-size and large models are repriced to current reality (the NAS12 now starts at $8,995, the NAS72 at $25,995), and every price in the configurator reflects a component list we verified we can buy this week. The entry line held: the NAS4 still starts at $1,995 and the NAS6 at $2,995, now with 16GB of DDR5 standard and ECC memory available as an upgrade.
This is the same discipline we described on our refreshed Components We Use page: new parts only, authorized US distribution, multi-source price-and-availability checks before anything gets quoted, and a 72-hour burn-in before anything ships.
Browse the re-verified line at eracks.com/products/rackmount-nas-servers, or ask us to spec one for your workload, a human answers.
joe July 9th, 2026
Tags: CMR, drive shortage, IronWolf Pro, IT-mode HBA, NAS, RAIDZ2, supply chain, transparent pricing, TrueNAS, ZFS

In 2015 we published a page called Components We Use, prompted by the broker emails that arrive in our inbox four or five times a week: “clean pull” hard drives by the pallet, bank wire only, 90-day warranty if you’re lucky. The message of that page was one sentence: every new eRacks system is built from 100% new, factory-fresh components, full stop.
A decade later the emails still come, but the merchandise has evolved. This week’s version offered current-generation AMD EPYC server processors, “brand new”, at 50 to 70 percent below any plausible new-part price. So we rewrote the page for 2026, and the new material is worth a blog post of its own, because knowing this trick can save you real money and real pain.
Modern AMD EPYC processors include a security feature called Platform Secure Boot (PSB for short). When a large vendor like Dell, or a cloud data center, first powers a chip in one of their servers, PSB burns one-time fuses inside the processor that bind it permanently to that vendor’s firmware. That chip will now boot only on that vendor’s motherboards. Forever. There is no unlock.

When those servers are decommissioned, the pulled CPUs flow into the gray market, where brokers list them as “brand new” at half price. Buy one for a custom build and you own a very expensive paperweight: it will never POST (pass the power-on self-test) on a Supermicro, ASUS, or any other standard board. The discount is the tell. A price that looks impossible through authorized distribution usually is.
The refreshed page spells out our sourcing practice in full, and it is the same one we have followed since 1999:
None of this is new policy. What is new is the page saying it plainly for 2026, with the vendor-lock mechanics explained, so that when one of those emails lands in YOUR inbox, you know exactly what is being sold.
Read the full page, including the vintage 2015 broker email we preserved for posterity: eracks.com/components-we-use
CPU photographs by smial via Wikimedia Commons, Free Art License.
joe July 6th, 2026
Posted In: Behind the Scenes, News
Tags: AMD PSB, burn-in, components, gray market, hardware, sourcing, transparency, vendor-locked CPU, warranty