Der Großteil der AI Suite-Produkte wird auf dem eigenen Rechner des Nutzers installiert. Es gibt keinen Mandanten. Es gibt keinen Cloud-Login, der den Zugriff auf die Inferenz-Engine einschränkt. Die Desktop-Apps kommunizieren mit einer lokalen aisuite-server ein Prozess, der wiederum entweder mit einem auf dem Gerät befindlichen Modell oder mit einem vom Kunden kontrollierten AI Server kommuniziert, der im Netzwerk des Kunden läuft. Diese Wahl – Desktop-Installer, kein SaaS – ist bewusst getroffen, und die Gründe sind es wert, festgehalten zu werden.
Grund 1: Regulierte Käufer dürfen Produktions-Prompts nicht in der Cloud Dritter ablegen
Das seit 2024 geltende EU AI-Gesetz klassifiziert eine Vielzahl von Unternehmens-Workflows als „hochrisikoreich“ und auferlegt dem Betreiber Aufzeichnungs-, menschliche Aufsicht- und Datenhandhabungspflichten [1]. Äquivalente oder parallele Regelwerke existieren in den OECD-Mitgliedstaaten [2], und US-Bundesbehörden orientieren sich bei der Beschaffung von KI-Systemen am NIST AI Risk Management Framework [3]. Keines dieser Regelwerke verbietet Cloud-KI; sie verlangen vom Betreiber jedoch, zeitnah und auf Anfrage nachweisen zu können, was wohin gesendet wurde und was zurückkam.
In der Praxis kollidiert diese Anforderung mit der Funktionsweise heutiger Cloud-LLM-APIs. Ein Compliance-Leiter in der Pharmaindustrie kann für einen Workflow, der Patientenkennungen verarbeitet, keine pro-Prompt-Audit-Trail aus einem Drittanbieter-SaaS ziehen, selbst wenn das SaaS vertraglich GDPR-konform ist. Möglicherweise müssen Prompt und Antwort das eigene Netzwerk niemals verlassen. Der sauberste Weg, diese Anforderung zu erfüllen, ist, die KI als Binärdatei auszuliefern, die der Kunde innerhalb seines eigenen Perimeters ausführt – genau das tun wir.
Dies ist kein hypothetischer Käufer. Die Kundengruppe, an die wir seit 2007 ausgeliefert haben, umfasst sechs Fortune Global 500-Unternehmen aus den Bereichen Pharma, Finanzen, Regierung, Recht, Verteidigung und Energie [4]. Jeder dieser Sektoren hat mindestens einen Workflow, bei dem die Antwort auf die Frage „Wo findet die Inferenz statt?“ darüber entscheidet, ob das Beschaffungsgespräch überhaupt beginnt.
Grund 2: Eine installierbare Binärdatei entspricht der tatsächlichen Softwarebeschaffung in Unternehmen
Der Beschaffungsprozess für Desktop-Anwendungen ist in großen IT-Organisationen gut bekannt. Die Anwendung wird verpackt, über SCCM, Intune oder Jamf verteilt, unterliegt denselben Gruppenrichtlinien wie Microsoft Office und wird entfernt, wenn das Laptop außer Betrieb genommen wird. Beschaffung, Sicherheitsprüfung und Endbenutzer-Computing verfügen über jahrzehntelange Prozesse dafür. AI Suite fügt sich nahtlos ein.
Cloud-SaaS hingegen erfordert eine parallele Vorgehensweise: eine Risikoüberprüfung des Anbieters für jeden Mandanten, eine Identitätsföderationsvereinbarung, fortlaufende Audits der Anbieter-Sicherheitslage und eine ständige Verhandlung darüber, wessen Verpflichtungen was abdecken, wenn etwas schiefgeht. Nützlich für bestimmte Arten von Software. Schlechte Passform für die Art von KI-Workflows, die unsere Kunden entwickeln.
Indem wir installierbare Apps ausliefern, die sich beim eigenen Identitätsanbieter des Kunden authentifizieren können — Microsoft Entra ID oder Google Workspace über OpenID Connect — halten wir Inferenzinhalte außerhalb der Software Tailor Steuerungsebene. Organisationsdienste verarbeiten weiterhin die Datensätze, die für den Betrieb der Bereitstellung erforderlich sind: Teilnehmerlisten und Rollen, Berechtigungen, Richtlinien und Serverstatus, aggregierte Nutzung, administrative Prüfungen, Lizenzierung und Support. Das sind echte Anbieter-seitige Datensätze, aber sie sind getrennt von Eingabeaufforderungen, Antworten und Kundendokumenten auf dem lokalen oder kunden-gehosteten Modellpfad.
Grund 3: Null Projektfehler seit 2007 beruht darauf, sich nicht auf die Verfügbarkeit Dritter zu verlassen
Wir liefern seit neunzehn Jahren kundenspezifische Software mit einer Erfolgsbilanz von null Projektfehlern seit 2007 [4]. Diese Bilanz besteht, weil das Team jede Ebene der Auslieferung kontrolliert: Code, Build, Test, Bereitstellungsartefakt. In dem Moment, in dem wir den Produktionsworkflow eines Kunden von der Verfügbarkeit der Cloud eines anderen Unternehmens abhängig machen, endet diese Bilanz und wir können sie nicht mehr 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 der Pharma- und Verteidigungsbranche bedienen, können es sich nicht leisten, dass ihr jahrelanger regulatorischer Fall ins Stocken gerät, weil ein Modell-Endpunkt, der ihnen nicht gehört, migriert wurde. Deshalb setzen wir ihren lokalen Modellpfad nicht auf einen solchen Anbieter. Das Modell lebt auf dem Rechner des Kunden und die Inferenz erfolgt auf dem Rechner des Kunden. Unsere Infrastruktur stellt die Steuerungsebene-Dienste bereit, die für Identität, Berechtigung, Richtlinie, Flottenstatus, aggregierte Nutzung, Verwaltung und Support benötigt werden; sie ist nicht die Inferenzlaufzeit und empfängt auf diesem Pfad keine Eingabeaufforderungs- oder Antwortinhalte.
Was das für die Evaluierung bedeutet
Wenn Sie Compliance-Verantwortlicher, CIO oder CTO sind und lokale KI für eine Unternehmenseinführung bewerten, sehen die relevanten Fragen anders aus als bei einer Cloud-SaaS-Bewertung:
- Wo findet die Inferenz statt? Auf dem Gerät des Nutzers oder auf einem Server, den der Kunde kontrolliert. Nicht auf unserem.
- Was verlässt den Perimeter? Auf dem lokalen oder kunden-gehosteten Inferenzpfad gehen keine Eingaben, Antworten oder Dokumentinhalte an Software Tailor. Steuerungsdaten, Lizenz-, Sicherheits-, Telemetrie- (wenn aktiviert) und Support-Daten haben separate dokumentierte Datenwege.
- Wie sieht die Prüfspur aus? Inhaltsfreie JSONL, lokal gespeichert, exportierbar. Das Modell sieht niemals Inhalte, auf die es nicht reagieren soll, und die Prüfzeile sieht überhaupt keine Inhalte.
- Was passiert, wenn der Anbieter nicht mehr existiert? Installierte Binärdateien und die kostenlose lokale Laufzeit sind nicht von einem gehosteten Inferenz-Mandanten abhängig. Abonnements, Organisationen und zentral verwaltete Pro-Funktionen können jedoch weiterhin gültige Berechtigungen und Steuerungsebene-Dienste erfordern, weshalb ein Ausstiegsplan diese berücksichtigen muss.
Das sind die vier Fragen, die wir entwickelt haben AI Admin Console und die Local AI Suite um klar zu beantworten. Der Artikel zur EU AI Act-Konformität und On-Premise-Bereitstellung behandelt die regulatorische Seite ausführlicher.
Quellen
- Europäische Kommission. „AI Act – Regulatorischer Rahmen für KI.“ https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Zugriff am 15.06.2026.
- OECD AI Policy Observatory. „Nationale KI-Strategien.“ https://oecd.ai/. Zugriff am 15.06.2026.
- NIST. „AI Risk Management Framework (AI RMF 1.0).“ https://www.nist.gov/itl/ai-risk-management-framework. Zugriff am 15.06.2026.
- Software Tailor. „Frühere Kunden.“ https://softwaretailor.com/past-clients.htm. Zugriff am 15.06.2026.