DECISION TOOLKIT · PLATTFORMAUSWAHL
Das Tool an der Arbeit ausrichten, nicht an der Demo
Die Karte ist eine Ausgangshypothese, kein Benchmark. Sie trennt Time-to-Value von Kontrolle und Reversibilität und zwingt zur Validierung mit repräsentativer Arbeit.
Ein einzelner Gewinner ist meist die falsche Antwort. Ein Primärmuster wählen und den Zusatznutzen eines zweiten Musters explizit machen.
Die Bewertungseinheit ist ein abgeschlossener Workflow, nicht eine Modellantwort.
Die Frage «Welches KI-Tool ist das beste?» ist für Unternehmen fast immer falsch gestellt. Claude Code, OpenAI Codex, ChatGPT Enterprise, Gemini, Mistral, Kimi Work und offene Modelle verkörpern unterschiedliche Ausführungs- und Kontrollmuster. Die Wahl muss am Workflow und an der erlaubten Autorität beginnen.
Zuerst die Arbeitsform bestimmen
Ein verwalteter Chat-Workspace unterstützt Wissensarbeit mit gemeinsamer Identität und Administration. Ein Coding Agent darf Repositories lesen, Befehle ausführen und Änderungen erzeugen. Ein Desktop Agent arbeitet nahe an Dateien und authentisierten Browser-Sessions. Eine offene Modellarchitektur überträgt mehr Kontrolle — und mehr Lifecycle-Verantwortung — an das Unternehmen.
Diese Kategorien sind nicht austauschbar. Ein Feature-Vergleich verdeckt die wichtigsten Unterschiede.
| Arbeitsmuster | Primäre Architekturfrage |
|---|---|
| Enterprise Assistant | Wie bleiben Identität, Quellenberechtigungen und Datenklassen erhalten? |
| Coding Agent | Welche Autorität erhält der Agent über Repository, Shell, Netzwerk und Secrets? |
| Desktop Agent | Welche lokalen Dateien, Browser-Sessions und geplanten Aktionen sind erlaubt? |
| Eigene Anwendung | Wie werden Modell, Retrieval, Tools, Evals und Betrieb integriert? |
| Open-weight / self-hosted | Kann die Organisation Serving, Sicherheit, Updates und Kapazität verantworten? |
Sechs Entscheidungsdimensionen verwenden
1. Daten
Verfolgen Sie den vollständigen Pfad von Input, Kontext und Output. Prüfen Sie Residenz, Retention, Training, Telemetrie, Subprozessoren, Löschung und Quellberechtigungen. «Enterprise» ist kein Ersatz für eine konkrete Datenflusskarte.
2. Integration
Betrachten Sie Identität, APIs, MCP-Server, Repositories, SaaS-Connectoren und Geschäftssysteme. Jede Integration erweitert nicht nur den Kontext, sondern möglicherweise die Autorität des Systems.
3. Sicherheit
Threat Modeling muss zu Kontrollen führen: Least Privilege, Isolation, Secret Handling, Netzwerkregeln, geschützte Branches, Human Gates, Logging und ein unmittelbarer Widerrufspfad. Community-Plugins und MCP-Server sind Supply-Chain-Komponenten, keine neutralen Komfortfunktionen.
4. Leistung
Benchmarken Sie repräsentative Aufgaben. Messen Sie nicht nur subjektive Qualität, sondern Abschlussquote, Fehlerarten, Quellenbezug, Testverhalten, Latenz, Intervention und Stabilität bei langem Kontext.
5. Wirtschaftlichkeit
Lizenzen oder Tokenpreise zeigen nur einen Teil. Total Cost umfasst Integration, Evaluation, Sicherheitsarbeit, Change, Review, Compute, Support und Betrieb. Eine teurere Plattform kann wirtschaftlicher sein, wenn sie Komplexität entfernt; eine offene Architektur kann günstiger wirken und trotzdem mehr Ownership verlangen.
6. Reversibilität
Ein glaubwürdiger Exit hängt von portablen Daten, wiederverwendbaren Evals, standardisierten Tool-Verträgen, entkoppelter Geschäftslogik und dokumentierten Alternativen ab. Reversibilität ist kein abstrakter Wunsch, sondern eine konkrete Architektureigenschaft.
Plattformen am selben Evidence Pack vergleichen
Verwenden Sie für alle Kandidaten dieselben Aufgaben, Datenklassen, Qualitätskriterien und Risikofälle. Dokumentieren Sie Konfiguration, Modellversion, erlaubte Tools und menschliche Intervention. Sonst vergleichen Sie Produktdemos statt Systeme.
Ein gutes Decision Record enthält:
- den Workflow und das gewünschte Ergebnis;
- Daten- und Autoritätsgrenzen;
- Evaluationsresultate und Fehlermuster;
- Integrations- und Betriebsmodell;
- Sicherheits- und Vertragsannahmen;
- Kosten, Abhängigkeiten und Exit-Pfad;
- den Entscheid, seine Gültigkeitsdauer und Review-Trigger.
Multi-Plattform kann richtig sein — aber nicht zufällig
Unterschiedliche Plattformen können für Wissensarbeit, Software Engineering und private Inferenz sinnvoll sein. Das ist nur dann eine Architektur, wenn Identität, Datenklassen, Tool-Berechtigungen, Evaluation und Ownership plattformübergreifend konsistent sind. Andernfalls entsteht ein Portfolio aus Schattenstandards.
Die richtige Empfehlung ist deshalb selten «ein Gewinner für alles». Sie ist eine begründete Zuordnung von Workflow, Autorität, Kontrolle und Betriebsverantwortung — mit einem expliziten Weg, den Entscheid zu revidieren, wenn sich Technologie oder Evidenz verändert.