Three ways to deployprivate AI without guessing

Private AI is not one product with a single install path. It is a decision about where inference runs, who can reach it, and what still works when the internet does not.

Most buying processes skip that decision and jump to model names. That is backwards. The deployment model decides what you can promise a client. The model weights are a detail inside it.

The three shapes that actually exist

1 — Fully local

The model runs on hardware inside your network. Staff reach it the way they reach any internal tool. There is no outbound path from the inference layer for prompts or documents.

This is the strongest privacy posture. It is also the one that asks the most of your room, power, and IT habits. It fits firms that handle material they cannot allow to leave the building under any story — and that will use the system hard enough to justify the machine.

2 — Local with controlled access

Same idea as fully local for the sensitive work: inference stays on your side of the perimeter. Remote partners or staff connect through access you grant, log, and revoke. You are not “putting the firm on the public internet.” You are opening a door you hold the keys to.

This fits practices with more than one office, or partners who travel, without giving up the core rule that client material does not sit on a vendor’s retention schedule.

3 — Private enclave

You need private AI quickly, or you do not want to own a rack yet. The system runs in an enclosure operated for you — still isolated from public consumer tools, still with an access and logging story you can explain — without a capital project on day one.

This is how many firms start. It is also a valid steady state. Ownership of the outcome (privacy, fixed cost, audit trail) matters more than ownership of the chassis, as long as the contract matches the architecture.

How to choose without a six-week workshop

Walk the decision in this order:

• What material must never leave our building, even under a vendor NDA?
• Who needs access from outside the office, and can we revoke it in minutes?
• Do we have power, space, and someone who can keep a machine healthy?
• Do we need something working this month, or can we size hardware properly first?
• What would we show a client or regulator tomorrow about where prompts sat?

If the first answer is “almost everything we touch,” start from fully local or a tight enclave — not from a public chatbot with a business skin.

If remote access is routine, design the door first. Do not discover it after install.

If nobody can name who reboots the box on a Friday evening, do not buy a box yet. Take the enclave path or try a free node until the operating model is clear.

What we actually install

Phronexus is the system: Nexus as the control plane, Phron as the agent on each GPU machine. You get one screen for users, access, and nodes — whether those nodes sit in your building or in an enclosure we run for you.

We size before we ship. That means workflows, headcount, and what “good enough” latency means for your floor — not a catalogue page with the largest GPU highlighted.

More on the posture itself sits on our Security page. The buying questions that should precede any of this are in Seven questions to ask any AI vendor.

The mistake to avoid

Buying the model first and the perimeter second.

You can change weights. You cannot easily unwind a year of prompts that already lived on someone else’s disk. Pick the deployment shape that matches what you are allowed to promise. Then pick the machine.