Resources
Understand it before it gets technical.
Use these guides to align business, IT, security, and facilities stakeholders around the same system boundary.
Buyer and operator resources
Answers for the whole room.
Available resources open directly. On-request worksheets are delivered through a short discovery exchange so they can be matched to the engagement.
On-premises AI: a buyer's guide.
A practical, hype-free guide to buying private AI you run yourself—what it is, the workloads that work today, what stays inside your network boundary, how to size it, and what evidence to demand before you accept a system.
Open resourceFour ways to run AI on data that cannot leave.
Most comparison pages are written by a vendor who wins every row. This one is not. Three of the four options below are better than us for some buyer, and this page says which buyer and why.
Open resourceZero-egress AI: how we prove nothing leaves.
Almost every on-premises AI vendor says the same thing—your data never leaves. That sentence is easy to write and impossible to trust on its own. Here is how a claim becomes evidence you can watch at your own firewall.
Open resourceAcceptance evidence: our published test results.
We would rather show you results than adjectives. Every item below lists its method, its result, the date it was verified, and the hardware it was measured on—so the claims are reproducible at your own acceptance rather than taken on faith.
Open resourceWhere the box lives—and every path around it.
This is the plain-language view you can draw with a customer before the detailed network diagram exists. It defines the physical site, the user paths, the optional outbound paths, and who owns each decision.
Open resourcePrivate AI readiness checklist
The users, workloads, facilities, identity, security, and support decisions to settle before hardware is ordered.
Request resourceWorkload discovery worksheet
A structured way to identify the first workflows worth testing and the evidence required to approve them.
Request resourceCommon questions
The practical answers.
Every final design is customer-specific. These answers establish the default operating pattern.
Where does the system physically live?
On your premises, usually a locked server room, network closet, or other controlled IT space with adequate power, cooling, and physical access control. Whether it ships as a tower or a rackmount depends on the tier you choose and your facility.
Is it exposed to the public internet?
No. The interface is published only to approved segments of your local network over private HTTPS, and the model and retrieval services stay on restricted backend networks. Nothing is designed to face the open internet.
How do remote and work-from-home staff connect?
Through your own managed remote-access path, typically a managed device, MFA, and your existing VPN or zero-trust (ZTNA) access. We design that path with your IT and security teams rather than opening a separate tunnel of our own.
Can it run with no internet connection?
Yes. The core AI workload is built to run fully offline. Optional functions such as cloud SSO, software updates, monitoring, or remote support may need narrowly scoped outbound access, and every one of those paths is documented and approved by you before it is enabled.
Do you set it up before it arrives?
Yes. We assemble, configure, and load-test the system on our controlled staging network using synthetic or explicitly approved data, then transport it to your site for final network, identity, and acceptance work.
Who can access it once it is live?
Only the users and administrators you authorize. Everyday use is kept separate from administrative access, and the system integrates your enterprise identity, roles, and audit logging where you need it.
Does buying Keep make us compliant?
No. No product by itself creates compliance. Keep is designed to operate inside your existing controls, policies, and evidence requirements; certification and accountability remain with your security program.
Still mapping it?
Put the open questions on one page.
A discovery briefing is built to clarify the physical site, users, data, access, workload, and approvals, not force a premature hardware decision.