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 may need the prompt and response to never leave a network they own. The cleanest way to provide that path 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 can authenticate to the customer's own identity provider — Microsoft Entra ID or Google Workspace via OpenID Connect — we keep inference content out of the Software Tailor control plane. Organisation services still process the records needed to operate the deployment: roster and roles, entitlements, policy and server state, aggregate usage, administrative audit, licensing and support. Those are real vendor-side records, but they are separated from prompts, responses and customer documents on the local or customer-hosted model path.
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 their local-model path on one. The model lives on the customer's box and inference happens on the customer's box. Our infrastructure supplies the control-plane services needed for identity, entitlement, policy, fleet state, aggregate usage, administration and support; it is not the inference runtime and does not receive prompt or response content on that path.
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? On the local or customer-hosted inference path, no prompts, responses or document contents go to Software Tailor. Control-plane, licence, security, telemetry (when enabled) and support records have separate documented data paths.
- 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? Installed binaries and the free local runtime do not depend on a hosted inference tenant. Subscription, organisation and centrally managed Pro capabilities can still depend on valid entitlements and control-plane services, so an exit plan must account for them.
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
- European Commission. "AI Act — Regulatory framework on AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Accessed 2026-06-15.
- OECD AI Policy Observatory. "National AI policies." https://oecd.ai/. Accessed 2026-06-15.
- NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Accessed 2026-06-15.
- Software Tailor. "Past clients." https://softwaretailor.com/past-clients.htm. Accessed 2026-06-15.