Why we ship AI as installable binaries, not cloud SaaS

Most of the AI Suite line-up installs on the user's own machine. There is no tenant. There is no cloud login that gates access to the inference engine. The desktop apps talk to a local aisuite-server process that, in turn, talks to either an on-device model or to a customer-controlled AI Server running inside the customer's network. That choice — desktop installer, not SaaS — is deliberate, and the reasons are worth writing down.

Reason 1: regulated buyers can't put production prompts in someone else's cloud

The EU AI Act, in force since 2024, classifies a substantial set of enterprise workflows as "high-risk" and imposes record-keeping, human-oversight, and data-handling obligations on the deployer ^[1]. Equivalent or parallel frameworks exist across the OECD member states ^[2], and US federal agencies operate against the NIST AI Risk Management Framework when procuring AI systems ^[3]. None of these frameworks ban cloud AI; they require the deployer to be able to demonstrate, contemporaneously and per-request, what was sent where and what came back.

In practice, that requirement collides with how cloud LLM APIs work today. A pharma compliance lead can't pull a per-prompt audit trail from a third-party SaaS for a workflow that processes patient identifiers, even when the SaaS is contractually GDPR-aligned. They need the prompt and response to never leave a network they own. The cleanest way to give them that is to ship the AI as a binary the customer runs inside their own perimeter — which is what we do.

This isn't a hypothetical buyer. The customer cohort we have shipped to since 2007 includes six Fortune Global 500 organisations across pharma, finance, government, legal, defence, and energy ^[4]. Every one of those sectors has at least one workflow where the answer to "where does the inference happen?" decides whether the procurement conversation even starts.

Reason 2: an installable binary matches how enterprises actually buy software

The buying motion for a desktop application is well-understood inside large IT organisations. The application gets packaged, distributed through SCCM or Intune or Jamf, governed by the same group policies as Microsoft Office, removed when the laptop is decommissioned. Procurement, security review, and end-user-computing all have decades-old processes for this. AI Suite slots straight in.

Cloud SaaS, by contrast, requires a parallel motion: a vendor-risk review on a per-tenant basis, an identity-federation conversation, ongoing audits of the vendor's posture, and a constant negotiation about whose obligations cover what when something breaks. Useful for some kinds of software. Bad fit for the kind of AI workflows our customers are building.

By shipping installable apps that authenticate to the customer's own identity provider — Microsoft Entra ID or Google Workspace via OpenID Connect — and that store nothing on our servers beyond the org roster and the audit log of administrative actions, we put the procurement conversation in the box it already knows how to handle.

Reason 3: zero project failures since 2007 depends on not depending on someone else's uptime

We have shipped custom software for nineteen years with a record of zero project failures since 2007 ^[4]. That record exists because the team controls every layer of the delivery: code, build, test, deployment artefact. The moment we make a customer's production workflow depend on another company's cloud staying available, that record stops being ours to defend.

Cloud AI vendors have outages. They throttle. They change pricing. They retire models. They retire whole APIs. Customers we serve in pharma and defence cannot have their year-long regulatory case stall because a model endpoint they don't own was migrated. So we don't put them on one. The model lives on the customer's box, the inference happens on the customer's box, and the only thing on our infrastructure is the lightweight admin surface they use to manage their own deployment.

What this means for evaluation

If you're a compliance lead, a CIO, or a CTO evaluating local AI for an enterprise deployment, the relevant questions look different from a cloud SaaS evaluation:

• Where does the inference happen? On the user's device, or on a server the customer controls. Not on ours.
• What leaves the perimeter? Org roster and admin actions only. No prompts, no responses, no document contents.
• What's the audit trail? Content-free JSONL, locally stored, exportable. The model never sees content it isn't told to act on, and the audit row never sees content at all.
• What happens when the vendor goes away? The binaries the customer installed continue to work. The local AI Server they enrolled continues to serve. No re-platforming required.

Those are the four questions we built AI Admin Console and the Local AI Suite to answer cleanly. The article on EU AI Act compliance and on-prem deployment covers the regulation side in more depth.

References

1. European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Accessed 2026-06-15.
2. OECD AI Policy Observatory. "National AI policies." oecd.ai. Accessed 2026-06-15.
3. NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Accessed 2026-06-15.
4. Software Tailor. "Past clients." softwaretailor.com/past-clients.htm. Accessed 2026-06-15.

Related articles

• Why on-prem AI deployments stall in procurement (and the framing that fixes it)
• EU AI Act in 2026: what on-prem deployment changes about compliance
• All articles →