Därför levererar vi AI som installerbara binärer, inte som moln-SaaS

Det mesta av AI Suite-utbudet installeras på användarens egen maskin. Det finns ingen tenant. Det finns ingen molninloggning som villkorar åtkomsten till inferensmotorn. Skrivbordsapparna talar med en lokal aisuite-server-process som i sin tur talar antingen med en modell på enheten eller med en kundkontrollerad AI Server som körs inuti kundens nätverk. Det valet — skrivbordsinstallatör, inte SaaS — är medvetet, och skälen är värda att skriva ner.

Skäl 1: reglerade köpare kan inte lägga produktionsprompter i någon annans moln

EU AI Act, i kraft sedan 2024, klassificerar en betydande uppsättning företagsarbetsflöden som ”högrisk” och ålägger den driftansvarige skyldigheter avseende loggföring, mänsklig tillsyn och datahantering ^[1]. Motsvarande eller parallella ramverk finns över OECD-länderna ^[2], och amerikanska federala myndigheter arbetar mot NIST AI Risk Management Framework vid upphandling av AI-system ^[3]. Inget av dessa ramverk förbjuder moln-AI; de kräver att den driftansvarige ska kunna visa, samtidigt och per förfrågan, vad som skickades vart och vad som kom tillbaka.

I praktiken kolliderar det kravet med hur moln-LLM-API:er fungerar i dag. En läkemedelsföretagets compliance-ansvarig kan inte hämta ett granskningsspår per prompt från en tredjeparts-SaaS för ett arbetsflöde som behandlar patientidentifierare, även när SaaS:en är avtalsmässigt GDPR-anpassad. De behöver att prompten och svaret aldrig lämnar ett nätverk de äger. Det renaste sättet att ge dem det är att leverera AI:n som en binär som kunden kör inuti sin egen perimeter — vilket är vad vi gör.

Detta är ingen hypotetisk köpare. Kundkohorten vi levererat till sedan 2007 omfattar sex Fortune Global 500-organisationer inom läkemedel, finans, offentlig sektor, juridik, försvar och energi ^[4]. Var och en av dessa sektorer har minst ett arbetsflöde där svaret på ”var sker inferensen?” avgör om upphandlingssamtalet överhuvudtaget kan börja.

Skäl 2: en installerbar binär matchar hur företag faktiskt köper programvara

Köprörelsen för en skrivbordsapplikation är väletablerad inom stora IT-organisationer. Applikationen paketeras, distribueras via SCCM eller Intune eller Jamf, styrs av samma grupprinciper som Microsoft Office, och avinstalleras när den bärbara datorn avvecklas. Inköp, säkerhetsgranskning och slutanvändardatorhantering har alla mångåriga processer för detta. AI Suite passar rakt in.

Moln-SaaS kräver däremot en parallell rörelse: en leverantörsriskgranskning per tenant, ett samtal om identitetsfederation, fortlöpande revisioner av leverantörens säkerhetsposition och en ständig förhandling om vems skyldigheter som täcker vad när något går sönder. Användbart för vissa typer av programvara. Dålig passform för den typ av AI-arbetsflöden våra kunder bygger.

Genom att leverera installerbara appar som autentiseras mot kundens egen identitetsleverantör — Microsoft Entra ID eller Google Workspace via OpenID Connect — och som inte lagrar något på våra servrar utöver organisationens medlemslista och granskningsloggen över administrativa åtgärder, placerar vi upphandlingssamtalet i den fålla det redan vet hur det ska hanteras.

Skäl 3: noll projektmisslyckanden sedan 2007 beror på att inte vara beroende av någon annans drifttid

Vi har levererat skräddarsydd programvara i nitton år med ett facit på noll projektmisslyckanden sedan 2007 ^[4]. Det facit finns eftersom teamet kontrollerar varje lager i leveransen: kod, bygge, test, distributionsartefakt. I det ögonblick vi gör en kunds produktionsarbetsflöde beroende av att ett annat företags moln förblir tillgängligt slutar det faciten att vara vårt att försvara.

Moln-AI-leverantörer har avbrott. De stryper. De ändrar priser. De avvecklar modeller. De avvecklar hela API:er. Kunder vi betjänar inom läkemedel och försvar kan inte få sitt årslånga regulatoriska ärende att fastna för att en modellslutpunkt de inte äger har migrerats. Så vi placerar dem inte på en. Modellen lever på kundens maskin, inferensen sker på kundens maskin, och det enda som finns på vår infrastruktur är den lättviktiga administrationsytan de använder för att hantera sin egen distribution.

Vad detta innebär för utvärdering

Om du är compliance-ansvarig, CIO eller CTO som utvärderar lokal AI för en företagsdistribution ser de relevanta frågorna annorlunda ut än vid en utvärdering av moln-SaaS:

• Var sker inferensen? På användarens enhet, eller på en server kunden kontrollerar. Inte på vår.
• Vad lämnar perimetern? Endast organisationens medlemslista och administrativa åtgärder. Inga prompter, inga svar, inget dokumentinnehåll.
• Hur ser granskningsspåret ut? Innehållsfri JSONL, lokalt lagrad, exporterbar. Modellen ser aldrig innehåll den inte fått i uppdrag att agera på, och granskningsraden ser aldrig innehåll alls.
• Vad händer när leverantören försvinner? De binärer kunden installerat fortsätter att fungera. Den lokala AI Server de registrerat fortsätter att leverera. Ingen omplattformning krävs.

Det är de fyra frågorna vi byggde AI Admin Console och Local AI Suite för att besvara rent. Artikeln om efterlevnad av EU AI Act och on-prem-distribution går djupare in på regleringssidan.

Referenser

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

Relaterade artiklar

• Noll projektmisslyckanden sedan 2007 — de tekniska reglerna bakom det
• Varför on-prem-AI-distributioner fastnar i inköp (och inramningen som löser det)
• EU AI Act 2026: vad on-prem-distribution förändrar i fråga om efterlevnad
• Alla artiklar →