Almost every vendor of enterprise AI software now makes the same guarantee in the first meeting: it runs on your infrastructure. That is usually true. The problem is not the sentence, it is that the sentence covers at least four different arrangements, with different operating costs, treated in the sales conversation as if they were one.
With where the data sits settled, and with the question of whether a local model is good enough for the task settled after it, what is left is where the software gets installed. The answer from the first piece, the one about Aptabit not seeing your data, carries a different weight depending on which arrangement is running in your environment, because it is the arrangement that decides where the outbound boundary sits.
Four arrangements that fit inside the same sentence
The sentence says where the software is installed, not where the boundary sits. In each arrangement the boundary rests on something different. On a physical wall, on a cloud contract, on the absence of an outbound route, or on a decision about how access was configured.
A server in the organization's own datacenter. The organization decides everything, and inherits everything a server demands: capacity, power, cooling, on-call coverage and hardware replacement. For an organization that already has a datacenter and the staff to run it, the marginal cost is small. For one that does not, this is an infrastructure project wearing an AI project's name. If the material is not restricted from leaving, this architecture may be more cost than the organization needs to carry, and a third-party service will do the job.
The client's own cloud account. A private cloud, or the client's own account on a public cloud, gives back elasticity without handing over ownership of the environment. A physical wall is one thing. An account configuration is another. The separation is still there, but it now depends on who holds credentials and on how access was designed.
An isolated environment. With no outbound connection, the guarantee stops depending on configuration. Nothing leaves because there is no route out. It is the strongest arrangement for confidentiality and the most expensive to operate. Everything that used to arrive over your network now arrives by procedure.
A hybrid decided flow by flow. Most of it runs inside, and specific flows go out to a hosted model. It is the arrangement convenience makes most attractive and the easiest to get wrong. It holds only while going out stays an explicit decision, taken flow by flow, and only while somebody can still say which flows leave today.
Where the most closed arrangement sends the bill
A piece that only listed advantages would help nobody decide. Our site says the platform operates offline, and that is exactly why the price of this arrangement has to be stated out loud. Three costs appear when the outbound connection stops existing, two of them yours and one of them ours.
The first is diagnosis. With no route out there is no remote support looking at the environment, and diagnosis comes to depend on what your team can collect and describe. That path is longer than a demo makes it look. The question to ask is how the vendor runs an investigation in that mode, not whether it does.
The second is updating. The opening piece in this series already noted that software with no channel back to its vendor does not receive security fixes on its own. What changes in an isolated environment is what takes that channel's place. The fix now crosses the boundary carried by a person, which turns every application of it into a procedure with a scheduled date, a named owner and a check on where the package came from before anything starts. Three questions decide whether the arrangement holds in your building: how long passes between a fix being published and that fix entering your environment, who on your team carries it across, and what happens to the system in production if the update fails halfway through. The last one gets asked least often, because it requires a way back to be planned before the update begins. Swapping a model travels the same route.
The third is ours. Going to the data forces the product to fit environments we do not choose and do not administer, and part of how it behaves in production depends on infrastructure we can neither guarantee nor reproduce. A vendor that hosts its own software knows the machine it runs on. We do not know yours.
None of this is an argument against isolation. It is a description of what isolation transfers to you. The question to ask before choosing it is who, on your team, runs those routines, and whether that person already exists today.
What to ask before choosing an arrangement
Put to any vendor offering to install software in your environment, these questions reveal which arrangement it actually stands behind:
- Which deployment arrangements is this product supported in, and what changes in each one?
- Who owns the cloud account this runs in, me or the vendor?
- What breaks if I cut the internet for a week?
- How does the product get updated and patched, and what does that require of me in each arrangement?
- Who on my team operates this after go live, and what happens if that person leaves?
The fifth is the one that least favors anyone selling software to install, and it brushes up against the question of what keeps running when the contract ends, the subject of a later piece in this series.
Why topology decides before features do
The site makes three claims about where the platform runs, and all three are claims about topology. It is self-hosted, on Docker or Kubernetes. The database, the files and the vectors stay on the client's infrastructure. The models can be local or come from an external provider. Read as features, those three claims say very little. Read as topology, they describe where the boundary can be placed, and what each position costs to hold.
Going to the data, rather than asking the data to come to us, settles where the boundary sits before anything else is settled. Choosing the arrangement is choosing how much of that boundary your organization takes on operating by itself.