Private AI
Your AI. Your data. Your infrastructure.
For real-estate organizations that can't — or won't — send sensitive operating data to someone else's model. We design and build AI systems that run where you decide: on hardware you own, in your own cloud account, or in a routed hybrid that keeps sensitive work private.
One gateway. Your rules. The right model.
Every request passes a policy gateway inside your environment. It applies your written data rules and sends each workload to the right class of model — reaching outside only where your policy allows.
Your environment
Requests
Your people and your systems
Policy gateway
Applies your written data rules
Open-weight · private
On infrastructure you control
Small & specialized
Fast, narrow work at volume
Retrieval
Grounded in your own documents
Frontier model · outside
Only where your policy allows it
Principle
The MaintenanceTech platform was designed to be model-agnostic and capable of using open-source models.
We design client systems the same way: the model underneath is a choice made per workload and per data rule — and it can change as better or more private options appear, without rebuilding the system around it.
What we design and build
Scoped per engagement, for your operation.
| PA-01 | Private model inference | Open-weight language models running on GPU servers you own or in your cloud account. |
|---|---|---|
| PA-02 | Private knowledge systems | Retrieval over your own documents, with answers that cite their sources. |
| PA-03 | Internal assistants and agents | Tools your team uses day to day, with permissions that mirror your organization. |
| PA-04 | Model routing and AI gateways | One entry point that sends each request to the right model under your data policy — private for sensitive work, commercial where that's appropriate. |
| PA-05 | Automation infrastructure | Workflow engines, queues and internal APIs that let AI act inside your systems, with people at the checkpoints. |
| PA-06 | Custom interfaces and integrations | Front ends and connections to the systems you already run. |
How we think about model architecture.
A live phone call, a 40-page lease and ten thousand inbound emails need different models — and sometimes different buildings. Pick a workload to see how we'd reason about it.
Illustrative · how we design systems
- 1Realtime voiceSpeech in, speech out, sub-second turns
- Frontier modelDeepest reasoning and writing, via API
- Open-weight, privateRuns on infrastructure you control
- Small & specializedFast, cheap, narrow — at volume
- Retrieval layerGrounds answers in your own documents
Conversation needs sub-second turn-taking, so a realtime voice model does the talking — within written rules for what it may say and do.
- Speed needed
- high
- Data sensitivity
- medium
- Volume
- medium
- Reasoning depth
- medium
Human checkpoint: Anything touching money parks for a person.
Where it runs — and who runs it.
Deployment options described by architecture and responsibility, including what we don't offer.
| Pattern | Where the models run | Where data lives | Who operates it | Status |
|---|---|---|---|---|
| Your cloud account | Open-weight models on GPU instances in your cloud tenancy — or a commercial model under your own agreement | Your cloud account | Your team, or K3YHOLD under a support agreement | Custom capability |
| Your own hardware | Open-weight models on GPU servers you own, on-site or in colocation | Your building or colocation space | Your team, or K3YHOLD under a support agreement | Custom capability |
| Routed hybrid | A gateway sends sensitive work to private models and routine work to commercial services | Split by your written data policy | Designed and documented together | Custom capability |
| Fully air-gapped | No outside network connection at all | — | — | Not offered today |
| Managed private AI, hosted by K3YHOLD | A private service we would run for you | — | — | Future offering · not available |
We will build the server it runs on.
Some data never gets to leave the building. When that is the constraint, the answer is not a smaller cloud — it is a machine of your own, specified for the work it has to do and standing where you can point at it.
- 01
Specified for the workload, not from a catalogue
We size the machine around the models you will actually run and the load you will actually put on them — memory first, because that is what decides which models fit. An assistant a dozen people use is a different machine from one that reads every document you own.
- 02
Built, burned in and handed over
We assemble and configure it, install the model-serving stack and the gateway, run it hard before it matters, and hand it over with the build documented — what is in it, what runs on it, and how to take it apart.
- 03
In your rack, your server room, or colocation
It lives where your policy says it has to. If you would rather not run a room, the same build can sit in a colocation facility you hold the contract with — still your hardware, still your data.
- 04
Yours to operate, or ours to support
Your team can run it with the documentation we leave behind, or we can keep it patched, monitored and current under a support agreement. Either way the machine, the models and the data are yours.
- 05
Room to grow, and a way out
We plan the second machine before you need it, and we build on open-weight models and standard interfaces so the thing you own does not become the thing you are stuck with.
Where this stops
- Scoped per engagement — there is no packaged appliance to buy off this page.
- We do not offer a fully air-gapped build.
- This is about the private AI systems we design and build for you. MaintenanceTech has its own self-hosted path — the Property Managers Enterprise Edition — which is a different conversation.
How we approach it
- Step 01
Start from the data rules
Which data may leave your environment, which may be used by outside services, and which may never be used for training — decided before any model is chosen.
- Step 02
Right model for each workload
Sensitive, high-volume or latency-critical work can each call for a different model and a different place to run it.
- Step 03
Documented data flows
What goes where, who can see it and how long it's kept — written down so your security review has something real to review.
- Step 04
People at the checkpoints
The same discipline as MaintenanceTech: consequential actions stop for a person, and everything is recorded.
Who it’s for
- Owners and operators with financials, rent rolls and owner agreements that shouldn't leave their environment
- Property-management companies holding tenant personal data
- Brokerages handling client confidential information
- Organizations that want to avoid depending on a single AI vendor
Security and privacy
Every data flow we design is written down, so a security review has something real to review. What we hold, who we rely on and how information is handled are all set out in plain words.
Scope a private AI system.
Start with your data rules. We'll design the architecture around them and document every flow for your security review.