← Alle Artikel

Unternehmen Veröffentlicht 2026-06-15 · 5 Min. Lesezeit

Warum wir KI als installierbare Binärdateien ausliefern, nicht als Cloud-SaaS

Lokale Inferenz, kundengesteuertes Audit und ein bereits etablierter Einkaufsprozess. Drei strukturelle Gründe, warum die KI-Produkte von Software Tailor Desktop-Installer sind und kein Tenant in unserer Cloud.

Der Großteil der AI Suite-Produktlinie wird auf dem eigenen Rechner der Anwenderin installiert. Es gibt keinen Tenant. Es gibt kein Cloud-Login, das den Zugriff auf die Inferenz-Engine gatet. Die Desktop-Apps sprechen mit einem lokalen aisuite-server-Prozess, der wiederum entweder mit einem On-Device-Modell oder mit einem kundengesteuerten AI Server innerhalb des Kundennetzwerks kommuniziert. Diese Wahl – Desktop-Installer statt SaaS – ist bewusst, und die Gründe sind es wert, schriftlich festgehalten zu werden.

Grund 1: Regulierte Käufer können Produktiv-Prompts nicht in der Cloud eines Dritten halten

Der EU AI Act, in Kraft seit 2024, stuft eine substanzielle Menge unternehmerischer Workflows als „hochriskant" ein und legt dem Betreiber Pflichten zur Protokollierung, menschlichen Aufsicht und Datenverarbeitung auf [1]. Vergleichbare oder parallele Rahmenwerke existieren in den OECD-Mitgliedstaaten [2], und US-Bundesbehörden arbeiten beim Einkauf von KI-Systemen gegen das NIST AI Risk Management Framework [3]. Keines dieser Rahmenwerke verbietet Cloud-KI; sie verlangen, dass der Betreiber zeitnah und pro Anfrage nachweisen kann, was wohin gesendet wurde und was zurückkam.

In der Praxis kollidiert diese Anforderung damit, wie Cloud-LLM-APIs heute funktionieren. Eine Compliance-Verantwortliche im Pharmabereich kann für einen Workflow, der Patientenkennungen verarbeitet, keinen prompt-genauen Audit-Pfad aus einer Drittanbieter-SaaS ziehen – selbst wenn die SaaS vertraglich GDPR-konform ist. Sie braucht, dass Prompt und Antwort niemals ein Netzwerk verlassen, das ihrem Unternehmen gehört. Der sauberste Weg, ihr das zu geben, ist die KI als Binärdatei auszuliefern, die der Kunde innerhalb seines eigenen Perimeters betreibt – und genau das tun wir.

Das ist kein hypothetischer Käufer. Die Kundenkohorte, an die wir seit 2007 ausliefern, umfasst sechs Fortune-Global-500-Organisationen aus den Branchen Pharma, Finanzen, Behörden, Recht, Verteidigung und Energie [4]. In jeder dieser Branchen gibt es mindestens einen Workflow, bei dem die Antwort auf „Wo findet die Inferenz statt?" darüber entscheidet, ob das Einkaufsgespräch überhaupt beginnt.

Grund 2: Eine installierbare Binärdatei passt zu der Art, wie Unternehmen Software tatsächlich einkaufen

Der Einkaufsprozess für eine Desktop-Anwendung ist in großen IT-Organisationen gut verstanden. Die Anwendung wird paketiert, über SCCM oder Intune oder Jamf verteilt, durch dieselben Gruppenrichtlinien wie Microsoft Office gesteuert und beim Außerbetriebsetzen des Laptops entfernt. Einkauf, Sicherheitsprüfung und End-User-Computing verfügen alle über jahrzehntealte Prozesse dafür. AI Suite fügt sich direkt ein.

Cloud-SaaS erfordert dagegen einen parallelen Prozess: eine Lieferantenrisikoprüfung pro Tenant, ein Gespräch über Identitätsföderation, laufende Audits der Sicherheitslage des Anbieters und eine ständige Verhandlung darüber, wessen Pflichten was abdecken, wenn etwas schiefläuft. Für manche Arten von Software nützlich. Für die Art von KI-Workflows, die unsere Kunden aufbauen, ein schlechter Fit.

Indem wir installierbare Apps ausliefern, die sich gegen den eigenen Identity Provider des Kunden authentifizieren – Microsoft Entra ID oder Google Workspace via OpenID Connect – und die außer dem Organisationsverzeichnis und dem Audit-Log administrativer Aktionen nichts auf unseren Servern speichern, verlegen wir das Einkaufsgespräch in die Box, in der die Organisation bereits weiß, damit umzugehen.

Grund 3: Null Projektausfälle seit 2007 hängen daran, nicht von der Verfügbarkeit eines anderen abhängig zu sein

Wir liefern seit neunzehn Jahren maßgeschneiderte Software mit einer Bilanz von null Projektausfällen seit 2007 [4]. Diese Bilanz existiert, weil das Team jede Ebene der Auslieferung kontrolliert: Code, Build, Test, Auslieferungsartefakt. Sobald wir den produktiven Workflow eines Kunden davon abhängig machen, dass die Cloud eines anderen Unternehmens verfügbar bleibt, ist diese Bilanz nicht mehr unsere zu verteidigen.

Cloud-KI-Anbieter haben Ausfälle. Sie drosseln. Sie ändern Preise. Sie stellen Modelle ein. Sie stellen ganze APIs ein. Kunden, die wir in den Branchen Pharma und Verteidigung betreuen, können ihren jahrelangen regulatorischen Vorgang nicht ins Stocken bringen lassen, weil ein Modell-Endpunkt, der ihnen nicht gehört, migriert wurde. Also setzen wir sie nicht auf einen. Das Modell läuft auf der Maschine des Kunden, die Inferenz findet auf der Maschine des Kunden statt, und das Einzige auf unserer Infrastruktur ist die schlanke Verwaltungsoberfläche, mit der der Kunde seine eigene Bereitstellung verwaltet.

Was das für die Bewertung bedeutet

Wenn Sie als Compliance-Verantwortliche, CIO oder CTO lokale KI für eine Unternehmensbereitstellung bewerten, sehen die relevanten Fragen anders aus als bei einer Cloud-SaaS-Bewertung:

  • Wo findet die Inferenz statt? Auf dem Gerät der Anwenderin oder auf einem Server, den der Kunde kontrolliert. Nicht auf unserem.
  • Was verlässt den Perimeter? Ausschließlich das Organisationsverzeichnis und administrative Aktionen. Keine Prompts, keine Antworten, keine Dokumentinhalte.
  • Wie sieht der Audit-Pfad aus? Inhaltsfreies JSONL, lokal gespeichert, exportierbar. Das Modell sieht keine Inhalte, mit denen es nicht arbeiten soll, und der Audit-Eintrag sieht überhaupt keine Inhalte.
  • Was passiert, wenn der Anbieter wegfällt? Die vom Kunden installierten Binärdateien funktionieren weiter. Der lokale AI Server, den der Kunde in Betrieb genommen hat, liefert weiter aus. Kein Re-Plattforming erforderlich.

Dies sind die vier Fragen, für die wir AI Admin Console und die Local AI Suite sauber beantwortbar gebaut haben. Der Artikel zur EU-AI-Act-Compliance und On-Premises-Bereitstellung behandelt die regulatorische Seite ausführlicher.

Quellen

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

Verwandte Artikel

Bewerten Sie denselben Ansatz an einer realen Arbeitslast.

Ein kostenloser 1-wöchiger Pilot führt durch ein reales Stück Kundenarbeit – lokale Inferenz, kundengesteuerte Identität, kundengesteuertes Audit.

Produkt-Updates abonnieren

Neue kostenlose KI-Produkte, größere Updates und Releases, die nur über diese Seite verfügbar sind. Kein Spam.