Ask where your cloud AI provider actually runs your workload and the honest answer is usually a region, not a place - “us-east,” a provider’s data center footprint, a shared pool of machines that moves your job to whichever one is free. Ask where Exalt local AI hardware runs and the answer is a box, in a room, with an address. That difference sounds small. It is not.
What an address gives you
A machine with a physical address can be pointed at. You can walk into the room and touch it. You can unplug it - not as a metaphor for canceling a subscription, but as an actual electrical event you control, today, without a support ticket. You can put it on an equipment list for your insurer. You can hand it to an auditor and say “this is the system,” rather than describing an API endpoint and a contract.
None of that is available to a tenancy. A tenant in someone else’s cloud has an account, a bill, and a set of permissions - not an asset. When a compliance team asks where a model’s weights live, or where an index of scanned documents is stored, the honest answer for a cloud tenant is “somewhere in the provider’s infrastructure, under terms we agreed to but do not operate.” That may be an acceptable answer for a given workload. It is a different answer than “in that room,” and the two should not be described as interchangeable.
Who has access, and who decides
Physical access to the appliance is a question your own facilities and IT policy answers - who has a key, who has a login, what the audit log on the door and the machine both show. That is not a security guarantee. On-premises hardware can be stolen, mishandled, or misconfigured by the people who have access to it, and a badge system is not a substitute for good access control on the machine itself. It is a different risk shape: the attack surface is physical proximity and internal process, rather than a third party’s infrastructure, staff, and subprocessors. Having the box on site does not remove risk. It relocates the questions you have to answer to ones you can actually inspect.
The same shift applies to change control. On a shared cloud platform, the provider can update the underlying service, change a default, deprecate an API, or alter a terms-of-service clause on a schedule that is theirs, not yours. On hardware in your building, when the system software changes is agreed for your deployment, not set by a provider’s release calendar. That is not automatically an upside - who patches, upgrades and supports it is part of the terms you agree, not something a shared platform decides for everyone at once. You are trading a support queue you do not control for an update schedule you agreed to.
A machine with an address can be pointed at, unplugged, audited, inventoried, and insured. A tenancy can only be canceled.
What happens when the relationship ends
This is the question that exposes the difference most plainly. When a cloud AI contract ends - non-renewal, a pricing change you won’t accept, the vendor discontinuing the product - what you are owed is usually an export window and a deletion certificate, if the contract promises even that much. The index, the configuration, the operational muscle memory the assistant built up answering your organization’s questions: some of that travels in an export file. Some of it does not, because it was never a discrete artifact so much as a configuration living inside someone else’s service.
When a relationship with Exalt ends, the appliance is still in the room. The weights, the index, and the configuration are on equipment in your building, which is a specific and checkable claim rather than a promise about export formats. That has a mundane but real consequence: the system can be inventoried and insured the way any other on-site equipment is - it shows up in a disaster-recovery plan, an asset register, and an M&A due-diligence packet the same way a server or a piece of manufacturing equipment does. A subscription does not show up in any of those the same way.
What you give up
The trade is real, and it runs against on-site hardware as often as for it. A cloud tenancy gives you elasticity - capacity that scales up for a demand spike and back down when it passes, billed for what you used. On-site hardware is set up for the workload it was configured around, and adding capacity means adding units. A cloud tenancy also gives you someone else’s operations team: patching, redundancy, and incident response staffed around the clock by people whose job is exactly that. With the box in your building, day-to-day operation sits closer to your own team; how much of it Exalt carries is set by the support level you agree.
- You give up elasticity - the deployment is set up for known load, not an unbounded spike.
- You give up a vendor’s shared operations staff for support terms agreed for your deployment, on hardware configured around a specific workflow rather than general-purpose infrastructure - see how that hardware gets configured around the work.
- You give up the option to walk away with nothing but an unpaid invoice - ending the relationship now means dealing with a physical asset, not just canceling a plan.
What you get in return is the set of things a tenancy structurally cannot offer: a machine you can point to, a location you can name on a data-residency form without a subprocessor list attached, and continuity that does not depend on a vendor’s continued interest in the product line. Whether that trade is the right one depends on the workload - a system built to hold policy manuals and answer staff questions inside one organization has different requirements than a public-facing service that needs to burst to ten times its normal traffic overnight.
An address is not a strategy
Having the hardware in your building answers “where does this live and who can touch it,” not “is this system accurate” or “will it stay up.” Those are separate questions, and this article is not a claim about either - an appliance on your floor can be neglected as easily as a cloud account, and a physical address does not make a model more correct. What it changes is the shape of the accountability: fewer intermediaries between a question about the system and an answer you can verify yourself, because the system in question is a specific machine you can walk up to. For a closer look at how on-site hardware keeps day-to-day data inside the building, see the case for keeping data on site, and for what crosses the wall and when, see isolation. If you’re weighing whether an on-site appliance or a hosted service fits your situation, that’s a scoping conversation, not a spec sheet - a look at the hardware itself or a consultation is a better place to work through it than a blog post.