Het merendeel van de AI Suite-productlijn installeert op de eigen machine van de gebruiker. Er is geen tenant. Er is geen cloudlogin die toegang tot de inferentiemotor beperkt. De desktop-apps communiceren met een lokale aisuite-server proces dat op zijn beurt communiceert met een model op het apparaat zelf of met een door de klant beheerde AI Server die binnen het netwerk van de klant draait. Die keuze — desktopinstaller, geen SaaS — is bewust gemaakt, en de redenen zijn het waard om op te schrijven.

Reden 1: gereguleerde kopers kunnen productieprompts niet in de cloud van een ander plaatsen

De EU AI-verordening, van kracht sinds 2024, classificeert een substantieel aantal bedrijfsworkflows als "hoog-risico" en legt registratie-, menselijke toezicht- en gegevensverwerkingsverplichtingen op aan de implementerende partij [1]. Equivalenten of parallelle kaders bestaan in de lidstaten van de OESO [2], en Amerikaanse federale agentschappen opereren volgens het NIST AI Risk Management Framework bij de inkoop van AI-systemen [3]. Geen van deze kaders verbiedt cloud AI; ze vereisen dat de implementerende partij gelijktijdig en op verzoek kan aantonen wat waarheen is gestuurd en wat terugkwam.

In de praktijk botst die eis met de manier waarop cloud LLM API's vandaag werken. Een compliance-verantwoordelijke in de farmacie kan geen per-prompt audittrail ophalen uit een SaaS van een derde partij voor een workflow die patiëntidentificaties verwerkt, zelfs niet als de SaaS contractueel GDPR-conform is. Ze kunnen vereisen dat de prompt en respons nooit een netwerk verlaten dat zij bezitten. De schoonste manier om dat pad te bieden is door AI te leveren als een binary die de klant binnen zijn eigen perimeter draait — wat wij doen.

Dit is geen hypothetische koper. De klantengroep waar we sinds 2007 aan leveren omvat zes Fortune Global 500-organisaties in farmacie, financiën, overheid, juridisch, defensie en energie [4]. Elk van die sectoren heeft minstens één workflow waarbij het antwoord op "waar vindt de inferentie plaats?" bepaalt of het inkoopgesprek überhaupt begint.

Reden 2: een installeerbare binary sluit aan bij hoe ondernemingen daadwerkelijk software kopen

De aankoopprocedure voor een desktopapplicatie is goed begrepen binnen grote IT-organisaties. De applicatie wordt verpakt, verspreid via SCCM, Intune of Jamf, beheerd door dezelfde groepsbeleidregels als Microsoft Office, verwijderd wanneer de laptop wordt buiten gebruik gesteld. Inkoop, beveiligingsreview en eindgebruikerscomputing hebben allemaal processen die al tientallen jaren bestaan. AI Suite past hier naadloos in.

Cloud SaaS vereist daarentegen een parallel proces: een vendor-risk review per tenant, een gesprek over identiteitsfederatie, voortdurende audits van de vendorstatus, en een constante onderhandeling over wiens verplichtingen wat dekken als er iets misgaat. Handig voor sommige soorten software. Slecht passend bij het soort AI-workflows dat onze klanten bouwen.

Door installeerbare apps te leveren die kunnen authenticeren bij de eigen identiteitsprovider van de klant — Microsoft Entra ID of Google Workspace via OpenID Connect — houden we inferentie-inhoud buiten de Software Tailor control plane. Organisatiediensten verwerken nog steeds de gegevens die nodig zijn om de implementatie te beheren: personeelslijst en rollen, rechten, beleid en serverstatus, geaggregeerd gebruik, administratieve audit, licenties en ondersteuning. Dit zijn echte vendor-side gegevens, maar ze zijn gescheiden van prompts, reacties en klantdocumenten op het lokale of klant-gehoste modelpad.

Reden 3: nul projectfalen sinds 2007 hangt af van het niet afhankelijk zijn van de uptime van een ander

We leveren al negentien jaar maatwerksoftware met een staat van nul projectfalen sinds 2007 [4]. Die staat bestaat omdat het team elke laag van de levering beheerst: code, build, test, deployment artefact. Op het moment dat we de productieworkflow van een klant afhankelijk maken van de beschikbaarheid van de cloud van een ander bedrijf, stopt die staat met van ons te zijn om te verdedigen.

Cloud AI-leveranciers hebben storingen. Ze beperken. Ze veranderen prijzen. Ze stoppen met modellen. Ze stoppen met hele API's. Klanten die we bedienen in de farmacie en defensie kunnen niet hebben dat hun jarenlange regelgevende zaak stagneert omdat een modelendpoint dat zij niet bezitten werd gemigreerd. Daarom plaatsen we hun lokale modelpad niet op zo'n endpoint. Het model leeft op de computer van de klant en inferentie gebeurt op de computer van de klant. Onze infrastructuur levert de control-plane diensten die nodig zijn voor identiteit, rechten, beleid, fleet status, geaggregeerd gebruik, administratie en ondersteuning; het is niet de inferentie-runtime en ontvangt geen prompt- of responsinhoud via dat pad.

Wat dit betekent voor evaluatie

Als u een compliance-verantwoordelijke, CIO of CTO bent die lokale AI evalueert voor een bedrijfsimplementatie, zien de relevante vragen er anders uit dan bij een cloud SaaS-evaluatie:

  • Waar vindt de inferentie plaats? Op het apparaat van de gebruiker, of op een server die de klant beheert. Niet op die van ons.
  • Wat verlaat de perimeter? Op het lokale of klant-gehoste inferentiepad gaan geen prompts, reacties of documentinhoud naar Software Tailor. Control-plane, licentie, beveiliging, telemetrie (indien ingeschakeld) en ondersteuningsgegevens hebben aparte gedocumenteerde datapaden.
  • Wat is het auditspoor? Content-vrije JSONL, lokaal opgeslagen, exporteerbaar. Het model ziet nooit inhoud waarop het niet is geïnstrueerd te reageren, en de auditregel ziet helemaal geen inhoud.
  • Wat gebeurt er als de leverancier verdwijnt? Geïnstalleerde binaries en de gratis lokale runtime zijn niet afhankelijk van een gehoste inferentie-tenant. Abonnement, organisatie en centraal beheerde Pro-mogelijkheden kunnen nog steeds afhankelijk zijn van geldige rechten en control-plane diensten, dus een exitplan moet hiermee rekening houden.

Dat zijn de vier vragen die we hebben gebouwd AI Admin Console en de Local AI Suite om helder te beantwoorden. Het artikel over EU AI Act compliance en on-prem implementatie behandelt de regelgeving uitgebreider.

Referenties

  1. Europese Commissie. "AI-wet — Regelgevend kader voor AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Geraadpleegd op 15-06-2026.
  2. OECD AI Policy Observatory. "Nationale AI-beleidslijnen." https://oecd.ai/. Geraadpleegd op 15-06-2026.
  3. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Geraadpleegd op 15-06-2026.
  4. Software Tailor. "Eerdere klanten." https://softwaretailor.com/past-clients.htm. Geraadpleegd op 15-06-2026.