Kurz zusammengefasst
- Eine Plattform ist sinnvoll, wenn mehrere Anwendungen tatsächlich gemeinsame Grundlagen benötigen.
- Muss-Kriterien zu Daten, Rechten und Betrieb sollten vor Produktdemos feststehen.
- Modellvielfalt allein ist weniger wichtig als messbare Qualität und kontrollierbare Wechselbarkeit.
- Ein Pilot muss nicht nur eine Antwort erzeugen, sondern Identität, Datenfluss, Monitoring und Ausstieg praktisch belegen.
Welchen gemeinsamen Auftrag soll die Plattform erfüllen?
Eine Plattform bündelt wiederverwendbare Fähigkeiten wie Modellzugang, Identität, Datenanbindung, Tool-Verwaltung, Evaluation und Monitoring. Definieren Sie zuerst, welche konkreten Anwendungen diese Fähigkeiten in den nächsten zwölf bis vierundzwanzig Monaten benötigen.
Ein einzelner Use Case rechtfertigt nicht automatisch eine umfassende Plattform. Umgekehrt erzeugen mehrere isolierte Projekte unnötige Doppelarbeit, wenn sie dieselben Zugänge, Datenquellen und Kontrollen jeweils neu bauen.
- Priorisierte Anwendungen und Nutzergruppen
- Gemeinsame Modelle, Datenquellen und Tools
- Verbindliche Identitäts-, Qualitäts- und Governance-Regeln
- Erwartete Teams, Volumen, Regionen und Betriebszeiten
Welche Anforderungen gehören in den Vergleich?
Trennen Sie Muss-Kriterien von wünschenswerten Funktionen. Ein Ausschlusskriterium zu Datenstandort oder Identitätsintegration darf nicht durch viele weniger relevante Features ausgeglichen werden. Anforderungen sollten als prüfbare Szenarien statt als allgemeine Schlagworte formuliert sein.
| Muss-Gate | Prüfbares Szenario | Bestanden wenn |
|---|---|---|
| Daten und Vertrag | Datenfluss für den konkreten Dienst inklusive Logs, Support und Unterauftragnehmer nachzeichnen | Region, Speicherung, Training, Löschung und Vertrag erfüllen die verbindliche Vorgabe |
| Identität und Rechte | SSO verbinden und bestehende Dokumentrechte mit zwei unterschiedlichen Rollen testen | Die Plattform zeigt nie mehr Daten als das führende System erlaubt |
| Qualität und Sicherheit | Eigene Standard-, Grenz- und Angriffsfälle wiederholt ausführen | Alle Mindestwerte werden erreicht und kein definierter kritischer Fehler tritt auf |
| Betrieb | Modellwechsel, Quote, Ausfall, Alarm und Supporteskalation simulieren | Verantwortliche erhalten verwertbare Logs und der Ersatzweg funktioniert |
| Exit | Konfiguration, Testfälle, Daten und Anwendung auf eine Alternative übertragen | Export ist technisch nutzbar und vertraglich ohne unklare Restabhängigkeit möglich |
Was muss ein Auswahlpilot praktisch beweisen?
Eine vorbereitete Demo zeigt selten die schwierigen Grenzen. Lassen Sie Kandidaten denselben repräsentativen Anwendungsfall mit Ihren Sprachen, Berechtigungen und Datenbedingungen umsetzen. Der Pilot sollte auch Fehlerfälle und Betriebsaufgaben abdecken.
- Schritt 1
Qualität
Eigene Testfälle wiederholbar ausführen und kritische Fehler getrennt bewerten.
- Schritt 2
Integration
Single Sign-on, Rollen, eine echte Datenquelle und einen kontrollierten Tool-Aufruf verbinden.
- Schritt 3
Betrieb
Protokolle, Kosten, Modellversionen, Ausfälle und Supportwege praktisch prüfen.
- Schritt 4
Ausstieg
Daten, Konfiguration, Testfälle und Anwendungscode exportieren oder auf eine Alternative übertragen.
Wie sieht eine gewichtete Entscheidung mit zwei Kandidaten aus?
Nach bestandenen Muss-Gates werden die übrigen Unterschiede auf einer festen Skala von 1 bis 5 bewertet. Die folgende anonymisierte Scorecard zeigt bewusst, warum eine hohe Punktzahl kein Ausschlusskriterium aufheben darf. Jede Note verweist auf einen Test, Vertrag oder Betriebsnachweis.
| Kriterium | Gewicht | Kandidat A | Kandidat B | Beleg |
|---|---|---|---|---|
| Qualität mit eigenen Fällen | 30 % | 4/5 | 5/5 | Wiederholbares Eval mit identischem Testset |
| Daten und Sicherheit | 25 % | 5/5 | 4/5 | Datenfluss, Vertrag und technischer Sicherheitstest |
| Integration und Rechte | 20 % | 3/5 | 4/5, aber Rechtevererbung fehlt | SSO-, Rollen- und Dokumentzugriffstest |
| Betrieb und Support | 15 % | 4/5 | 3/5 | Ausfallübung, Logs und Supportfall |
| Vollkosten und Exit | 10 % | 2/5 | 4/5 | Dreijahresrechnung und Exporttest |
| Gewichtetes Ergebnis | 100 % | 77/100; alle Gates bestanden | 83/100; wegen fehlender Rechtevererbung ausgeschlossen | Dokumentierter Entscheid mit akzeptierten Nachteilen |
Wie wird aus der Auswahl eine tragfähige Entscheidung?
Fachbereich, Architektur, Sicherheit, Datenschutz, Einkauf und Betrieb bewerten dieselben dokumentierten Kriterien aus ihrer Verantwortung. Die Entscheidung hält nicht nur den Sieger, sondern auch Annahmen, offene Risiken und akzeptierte Abhängigkeiten fest.
- Gewichtung und Ausschlusskriterien vor der Schlussbewertung einfrieren
- Vertragsaussagen dem konkreten Produkt, Plan und Betriebsmodus zuordnen
- Eigentümer und Budget für Plattform und erste Anwendungen benennen
- Nach Pilot, Vertragsänderung und wesentlichem Architekturwechsel neu prüfen
Beispiel: Gemeinsame Plattform für drei erste Anwendungen
Ein Unternehmen plant Wissenssuche, Dokumentenverarbeitung und einen Service-Copiloten. Zwei Plattformen bestehen die Qualitätsanforderungen. Im Pilot zeigt sich jedoch, dass nur eine bestehende Rollen bis auf Dokumentebene übernimmt, Protokolle in das zentrale Monitoring liefert und Modellwechsel mit denselben Evals unterstützt. Export von Konfiguration und Daten wird vertraglich und technisch geprüft, bevor die Plattform breiter eingeführt wird.
Was Sie mitnehmen sollten
Wählen Sie eine Plattform für einen klaren gemeinsamen Auftrag. Belegen Sie Muss-Kriterien mit eigenen Fällen und prüfen Sie Datenfluss, Betrieb und Exit genauso praktisch wie die sichtbaren KI-Funktionen.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft