Zum Hauptinhalt springen
9 – 17 UHR +49 8031 3508270 LUITPOLDSTR. 9, 83022 ROSENHEIM
DE / EN

KI-Plattform für Unternehmen auswählen: 10 Kriterien für einen langfristigen AI-Stack

Tobias Jonas Tobias Jonas | | 10 min Lesezeit

Kriterienkatalog, KO-Fragen und gewichtete Bewertungsvorlage für Geschäftsführung, CIOs, IT-Leitung und KI-Verantwortliche.

Kurzfassung: Wählen Sie eine KI-Plattform für Unternehmen nicht nach der beeindruckendsten Demo und nicht nach dem gerade führenden Modell. Entscheidend ist, ob daraus ein eigener, erweiterbarer AI-Stack entstehen kann: mit kontrollierter Identität, dokumentierten Datenwegen, austauschbaren Modellen, berechtigungsgetreuem Firmenwissen, offenen Integrationen und einem belastbaren Betriebsmodell.

Eine riskante Fehlentscheidung bei Unternehmens-KI ist nicht zwingend eine schlechte Modellantwort. Es kann auch eine gute Einzellösung sein, die sich später nicht mit den nächsten Anwendungsfällen verbinden lässt. Dann können getrennte Identitäten, doppelte Wissensindizes, widersprüchliche Regeln und mehrere Kostenmodelle entstehen. Was als schneller Pilot begann, kann so zur neuen Schatten-IT werden.

Dieser Leitfaden dreht die Perspektive um: Bewertet wird nicht nur das heutige Tool, sondern die Fähigkeit, darauf in den nächsten Jahren kontrolliert aufzubauen.

Tool, Plattform oder AI-Stack?

Die Begriffe werden oft synonym verwendet, beschreiben aber drei verschiedene Ebenen:

EbeneZweckTypisches Ergebnis
KI-ToolEine abgegrenzte Aufgabe lösenChat, Transkription, Übersetzung oder Bildgenerierung
KI-PlattformGemeinsame technische Dienste für mehrere Anwendungsfälle bereitstellenIdentität, Modelle, Wissen, Agenten, APIs und Protokollierung
AI-StackTechnik, Organisation und Weiterentwicklung verbindenZielarchitektur, Betriebsmodell, Governance, Schulung, Use-Case-Portfolio und Roadmap

Ein Unternehmen kann mit einem Tool starten. Es sollte aber vor dem Rollout klären, ob dieses Tool später Teil der Plattform werden kann – oder eine weitere Insel bleibt.

Zielbild: die Schichten einer langfristigen Enterprise-KI

Ein belastbares Zielbild lässt sich in sieben Schichten beschreiben:

  1. Nutzerzugang: Chat, Office, mobile Nutzung, Fachanwendungen und APIs
  2. Identität und Autorisierung: Single Sign-on, Gruppen, Rollen und delegierte Rechte
  3. Modellschicht: freigegebene Anbieter, Regionen, Routing und Fallbacks
  4. Wissensschicht: Dokumente, Metadaten, Vektorindizes und Quellberechtigungen
  5. Aktionsschicht: MCP, REST, Fachsysteme, Agenten und deterministische Workflows
  6. Kontrollschicht: Audit, Sicherheit, Qualität, Kosten und Incident-Prozesse
  7. Betriebs- und Befähigungsschicht: Owner, Support, Schulung, Leitlinie und Roadmap

Die zentrale Prüffrage lautet deshalb: Kann die angebotene Lösung in diesen Stack hineinwachsen, ohne dass Identität, Daten und Integrationen bei jeder Erweiterung neu gebaut werden müssen?

Vor der Punktebewertung: fünf KO-Kriterien

Ein hoher Gesamtscore darf einen grundlegenden Mangel nicht verdecken. Legen Sie vorab fest, welche Antworten zum Ausschluss führen. Für viele Unternehmen sind das mindestens diese fünf:

  • Der Verarbeitungsweg von Prompt, Antwort, Dateien und Protokollen ist nicht vollständig dokumentiert.
  • Single Sign-on sowie rollen- oder gruppenbasierte Freigaben fehlen.
  • Daten, Prompt-Vorlagen, Agentendefinitionen oder Wissensbestände sind nicht in dokumentierten Formaten exportierbar.
  • Schreibende Agenten arbeiten nur mit einem weitreichenden technischen Sammelkonto.
  • Verantwortung für Updates, Sicherheitsvorfälle, Modellfreigaben und Support bleibt ungeklärt.

KO-Kriterien sind unternehmensspezifisch. In regulierten Bereichen kommen beispielsweise strengere Anforderungen an Regionen, Verschlüsselung, Protokollierung oder menschliche Freigaben hinzu.

Die zehn Auswahlkriterien

1. Architekturhoheit und Betriebsmodell

Klären Sie zuerst, wo die Plattform läuft und wer welche Ebene administriert. „Private Instanz“, „dediziert“ und „im eigenen Tenant“ sind nicht dasselbe. Relevant sind Cloud-Konto, Netzwerk, Schlüssel, Datenbanken, Backups, Deployment-Pipeline und administrative Notfallzugriffe.

Prüffrage: Welche Komponenten liegen in unserer Umgebung, welche beim Betreiber, wer kann administrativ zugreifen und was bleibt bestehen, wenn wir den Betriebspartner wechseln?

Eine starke Antwort enthält ein Architekturdiagramm, eine Verantwortungsmatrix und ein dokumentiertes Übergabeszenario – nicht nur einen Standortnamen.

2. Identität und durchgängige Berechtigungen

Eine Enterprise-KI muss an das vorhandene Identity and Access Management anschließen. Single Sign-on ist dabei nur der Anfang. Entscheidend ist, ob Rollen und Gruppen bis zu Agenten, Modellen, Wissensräumen und Werkzeugen durchgreifen.

Prüffrage: Wird die Identität eines Nutzers bis in Wissensabfragen und Aktionen in Fachsystemen weitergegeben, oder arbeiten alle Anbindungen mit gemeinsamen Servicekonten?

Für schreibende Aktionen sollte zusätzlich festgelegt sein, wann eine menschliche Freigabe nötig ist und wie diese protokolliert wird.

3. Datenhoheit und dokumentierte Verarbeitungswege

„EU-Hosting“ beschreibt nur einen Teil der Verarbeitung. Ein vollständiges Datenflussbild umfasst Eingaben, Ausgaben, hochgeladene Dateien, Embeddings, Suchindizes, Telemetrie, Sicherheitsprotokolle, Backups und angebundene externe Dienste.

Prüffrage: Können wir für jede Datenklasse erzwingen und nachweisen, welche Modell-Endpunkte, Regionen, Speicher und Werkzeuge verwendet werden dürfen?

Eine belastbare Plattform setzt Regeln technisch um. Eine Richtlinie, die nur im Intranet steht, verhindert keine falsch geroutete Anfrage.

4. Modellfreiheit, Abstraktion und Fallbacks

Mehrere Modelle sind kein Selbstzweck. Der strategische Wert liegt darin, die Modellschicht von Oberfläche, Wissen und Integrationen zu entkoppeln. Dann kann ein Modell nach Qualitätsmessung, Verfügbarkeit, Datenweg oder Kosten ersetzt werden, ohne den gesamten Anwendungsfall neu zu bauen.

Prüffrage: Welche Änderungen sind nötig, um einen neuen Modell-Endpunkt hinzuzufügen, ein Modell zu sperren oder bei einem Ausfall kontrolliert auf ein freigegebenes Fallback zu wechseln?

Prüfen Sie auch, ob Prompts, strukturierte Ausgaben und Tool-Aufrufe über mehrere Anbieter getestet werden können. API-Kompatibilität allein garantiert noch keine gleiche Antwortqualität.

5. Firmenwissen mit Berechtigung und Lebenszyklus

Bei Retrieval Augmented Generation (RAG) zählt nicht nur, ob ein Dokument gefunden wird. Entscheidend sind Quellberechtigungen, Aktualität, Metadaten, Löschung, Versionierung und die Nachvollziehbarkeit der verwendeten Fundstellen.

Prüffrage: Was passiert im KI-Index, wenn ein SharePoint-Recht entzogen, eine Datei ersetzt oder eine Aufbewahrungsfrist erreicht wird?

Fordern Sie einen Test mit echten Berechtigungsänderungen. Eine vorbereitete Demo mit öffentlichen Beispieldokumenten prüft diesen kritischen Teil nicht.

6. Integrationen, Agenten und Workflows

Unternehmenswert entsteht, wenn die KI mit vorhandenen Systemen arbeitet. Dabei sollten drei Mechanismen unterschieden werden: lesender Wissenszugriff, offene agentische Aktionen und deterministische Workflows.

Prüffrage: Unterstützt die Plattform offene Schnittstellen wie REST und MCP, und lässt sich ein klar definierter Prozess an eine Workflow-Engine übergeben, statt ihn vollständig einem Sprachmodell zu überlassen?

Eine hilfreiche Faustregel: Offene Aufgaben gehören zu einem Agenten, stabile und prüfbare Abläufe in einen Workflow. Schreibende Aktionen benötigen begrenzte Rechte, Bestätigung und Fehlerbehandlung.

7. Sicherheit, Governance und Nachweise

Eine Plattform macht eine Organisation nicht automatisch DSGVO- oder AI-Act-konform. Sie muss aber die organisatorischen Maßnahmen technisch unterstützen: Freigaben, Zweckbindung, Rollen, Audit-Informationen, Löschung und bei Bedarf Human-in-the-Loop.

Prüffrage: Können wir nachvollziehen, wer welchen freigegebenen Agenten und welches Modell genutzt hat, ohne durch übermäßige Protokollierung neue sensible Datenbestände zu erzeugen?

Bewerten Sie außerdem Prompt-Injection-Schutz, Secret-Management, Netzwerkgrenzen, Schwachstellenmanagement und Incident-Prozesse. Zertifikate sind Nachweise für definierte Geltungsbereiche, kein Ersatz für die Prüfung des eigenen Anwendungsfalls.

8. Observability, Qualität und AI-FinOps

Nutzerzahlen allein zeigen nicht, ob eine Plattform Wert schafft. Nötig sind technische und fachliche Signale: Erfolgsquote von Werkzeugaufrufen, Antwortzeiten, Fehler, Modellverbrauch, Kosten und ein definierter Qualitätsmaßstab je Anwendungsfall.

Prüffrage: Lassen sich Verbrauch und Qualität einem Team, Anwendungsfall oder Agenten zuordnen, und können Limits oder Budgets bei Bedarf technisch durchgesetzt werden?

Trennen Sie Reporting von Steuerung. Ein Dashboard zeigt Vergangenes; Routing, Quoten und Budgets verändern zukünftiges Verhalten.

9. Adoption, KI-Kompetenz und fachliche Ownership

Ein technisch sauberes System ohne Nutzung ist kein Erfolg. Benötigt werden erreichbare Einstiegspunkte, konkrete Vorlagen, geschulte Mitarbeitende und Fachverantwortliche, die Ergebnisse beurteilen können. Der aktuelle Artikel 4 des EU AI Act verpflichtet Anbieter und Betreiber von KI-Systemen, Maßnahmen zu treffen, die die Entwicklung von KI-Kompetenz bei ihren Mitarbeitenden und weiteren für sie mit den Systemen arbeitenden Personen unterstützen. Zu berücksichtigen sind unter anderem Wissen, Erfahrung, Ausbildung und Schulung sowie der Einsatzkontext und die betroffenen Personengruppen; ein bestimmtes individuelles Kompetenzniveau muss nach dem aktuellen Wortlaut nicht garantiert werden.

Prüffrage: Wer verantwortet pro Anwendungsfall Inhalt, Qualität und Freigabe, und wie wird die notwendige KI-Kompetenz aufgebaut und dokumentiert?

Eine allgemeine Prompt-Schulung reicht für einen agentischen Einkaufsprozess nicht aus. Schulung muss mit dem Risiko und dem tatsächlichen Arbeitsablauf wachsen.

10. Roadmap, Modularität und Exit

Eine langfristige Plattform muss zwei scheinbare Gegensätze verbinden: stabile Grundlagen und austauschbare Bausteine. Identität, Datenregeln und Audit sollten verlässlich bleiben; Modelle, Agenten und Integrationen müssen sich schnell weiterentwickeln lassen.

Prüffrage: Welche Teile können wir selbst oder mit einem anderen Partner weiterbetreiben, welche Daten und Konfigurationen erhalten wir zurück und wie wird die Roadmap gemeinsam priorisiert?

Der Exit ist nicht nur ein Vertragskapitel. Er zeigt, ob die Architektur tatsächlich Ihnen dient oder nur während der Vertragslaufzeit zugänglich ist.

Gewichtete Scorecard fürs Lastenheft

Die folgende Verteilung ist ein Ausgangspunkt, keine allgemeingültige Wahrheit. Passen Sie die Gewichte vor dem ersten Anbietertermin an – sonst beeinflusst die beste Demo unbewusst die Kriterien.

KriteriumBeispielgewichtNachweis
Architekturhoheit und Betriebsmodell12 %Architekturdiagramm, RACI, Übergabeszenario
Identität und Berechtigungen10 %Live-Test mit zwei Rollen und entzogenem Recht
Datenhoheit und Verarbeitungswege14 %Datenflussbild, Verträge, Regionskonfiguration
Modellfreiheit und Fallbacks10 %Wechsel eines Endpunkts im Testsystem
Firmenwissen und Lebenszyklus12 %Synchronisations- und Berechtigungstest
Integrationen, Agenten und Workflows12 %Ende-zu-Ende-Demo mit Ihrer Beispielanwendung
Sicherheit, Governance und Nachweise12 %Sicherheitskonzept, Audit- und Incident-Beispiel
Observability und AI-FinOps8 %Nutzungs-, Qualitäts- und Budgetansicht
Adoption und Ownership5 %Schulungs- und Rollout-Konzept
Roadmap, Modularität und Exit5 %Roadmap-Prozess, Export- und Betriebsübergabe
Gesamt100 %

Bewertungsskala:

  • 0 – nicht vorhanden: Anforderung wird nicht erfüllt.
  • 1 – teilweise: manuell, geplant oder nur mit deutlicher Einschränkung.
  • 2 – erfüllt: im angebotenen Umfang nachgewiesen.
  • 3 – stark erfüllt: nachgewiesen, automatisierbar und auf Ihren Zielzustand übertragbar.

Berechnen Sie je Zeile Punktwert × Gewicht. Eine „3“ ohne belastbaren Nachweis wird höchstens als „1“ gewertet. Zusätzlich bleiben die vorher definierten KO-Kriterien unabhängig vom Gesamtscore bestehen.

Direkt nutzbare Anforderungen für Ihre Ausschreibung

Der folgende Block lässt sich als Ausgangspunkt in ein Lastenheft übernehmen und an Ihre Risikoklasse anpassen:

  • Die Lösung MUSS alle Speicher- und Verarbeitungswege für Prompts, Antworten, Dateien, Indizes, Backups und Protokolle dokumentieren.
  • Die Lösung MUSS Single Sign-on sowie rollen- und gruppenbasierte Freigaben für Modelle, Agenten, Wissensräume und Werkzeuge unterstützen.
  • Die Lösung MUSS Modell-Endpunkte austauschbar anbinden können, ohne Nutzerkonten, Wissensbasis und Integrationen neu aufzubauen.
  • Die Lösung MUSS Änderungen an Quellberechtigungen und Löschungen in angebundenen Wissensbeständen abbilden können.
  • Schreibende Aktionen MÜSSEN nach dem Least-Privilege-Prinzip begrenzbar, protokollierbar und bei Bedarf bestätigungspflichtig sein.
  • Daten, Agentendefinitionen, Vorlagen und Konfigurationen MÜSSEN in dokumentierten Formaten exportierbar sein.
  • Für Updates, Sicherheitsvorfälle, Modellfreigaben, Support und Betriebsübergabe MUSS eine Verantwortungsmatrix vorliegen.
  • Die Lösung SOLL offene Schnittstellen wie REST und MCP sowie die Übergabe definierter Abläufe an eine Workflow-Engine unterstützen.

Wie CompanyGPT diese Architektur abbildet

CompanyGPT ist bei innFactory kein isolierter Chatbot, sondern der Kern, auf dem wir gemeinsam mit dem Unternehmen einen eigenen AI-Stack aufbauen. Der Ausgangspunkt ist standardisiert; die Roadmap entsteht aus Ihren Anwendungsfällen, Systemen und Datenklassen.

BedarfBaustein im CompanyGPT-Stack
Gemeinsamer, kontrollierter KI-ZugangCompanyGPT mit Single Sign-on, Rollen, Modellen und Agenten
Firmenwissen und große DokumentbeständecompanyRAG und companyFILES, einschließlich Berechtigungskonzept
Arbeit in Word, Excel, PowerPoint und OutlookcompanyM365 mit nativem Office-Add-in
Fachsysteme und WerkzeugeMCP-Integrationen, REST und individuelle Anbindungen
Deterministische Automatisierungn8n als ergänzende Workflow-Schicht
Nutzung und AgentenaktivitätcompanyDASHBOARD
Anbieterübergreifendes Routing, Budgets und Fallbacksoptionales, eigenständiges AI Gateway
Organisatorische VerankerungKI-Leitlinie, Mitarbeiterschulung, Owner-Modell und gemeinsame Ausbauplanung

Nicht jedes Unternehmen braucht alle Bausteine am ersten Tag. Genau das ist der Punkt einer modularen Architektur: Die Basis ist produktiv nutzbar, während Wissen, Integrationen und Steuerung nach einem priorisierten Backlog wachsen. Das Unternehmen baut damit nicht bei jedem neuen Use Case ein neues Tool auf, sondern erweitert eine vorhandene Fähigkeit.

Häufige Fragen

Was unterscheidet eine KI-Plattform von einem KI-Tool?

Ein KI-Tool löst eine abgegrenzte Aufgabe. Eine Plattform stellt gemeinsame Identitäten, Datenregeln, Modelle, Wissensquellen, Integrationen und Governance für viele Anwendungsfälle bereit. Ein AI-Stack ergänzt diese technische Basis um Betrieb, Verantwortlichkeiten, Schulung und eine langfristige Roadmap.

Brauchen Unternehmen mehrere KI-Modelle?

Nicht zwingend am ersten Tag. Wichtig ist, dass Modell-Endpunkte später ohne Neuaufbau der Identität, Wissensbasis und Integrationen ergänzt oder ersetzt werden können. Häufig startet ein Unternehmen mit einem Standardmodell und ergänzt Spezial- sowie Fallback-Modelle nach gemessener Qualität, Datenanforderung und Kosten.

Reicht Hosting in einer EU-Region für die DSGVO?

Eine EU-Region ist nur ein Prüfkriterium. Zusätzlich zählen der konkrete Verarbeitungsweg jeder Anfrage, Verträge, Unterauftragnehmer, administrative Zugriffe, Löschung, Protokollierung, Verschlüsselung und die Datenweitergabe an angebundene Werkzeuge. Die Bewertung muss pro Anwendungsfall erfolgen und ersetzt keine Rechtsberatung.

Wie bewerten wir Anbieter mit der Scorecard?

Definieren Sie zuerst KO-Kriterien. Bewerten Sie die übrigen Kriterien dann von 0 bis 3 und multiplizieren Sie den Wert mit Ihrem Gewicht. Fordern Sie für hohe Bewertungen einen überprüfbaren Nachweis in einer Demo, Dokumentation oder Vertragsanlage. So gewinnt nicht automatisch die überzeugendste Präsentation.

Wie passt CompanyGPT in einen langfristigen AI-Stack?

CompanyGPT bildet den Plattformkern für Nutzerzugang, Modelle, Wissen und Agenten in der gewählten Kundenumgebung. Gemeinsam mit dem Unternehmen ergänzen wir entlang der Roadmap Bausteine wie companyRAG, companyFILES, companyM365, n8n, companyDASHBOARD und bei Bedarf das separate AI Gateway.

Fazit: Kaufen Sie keine Roadmap, die Sie nicht mitbestimmen

Die richtige Enterprise-KI-Plattform beantwortet nicht nur heutige Prompts. Sie schafft wiederverwendbare Grundlagen für die nächsten Wissensquellen, Agenten, Modelle und Prozesse. Deshalb gehören Architekturhoheit, Betriebsmodell, Berechtigungen und Roadmap genauso in die Auswahl wie Funktionen und Benutzeroberfläche.

Wenn Sie Ihren Kriterienkatalog nicht nur gegen eine Produktdemo, sondern gegen ein langfristiges Zielbild prüfen möchten, entwickeln wir im Architekturgespräch gemeinsam die passende Gewichtung, KO-Kriterien und erste Ausbaufolge. Mehr zur strategischen Einordnung finden Sie in unserer KI-Strategieberatung.

Für die nächsten Schritte helfen außerdem der Einführungsleitfaden für ChatGPT im Unternehmen und unser Verfahren zur Auswahl von Claude, GPT und weiteren Modellen.

Tobias Jonas
Geschrieben von

Tobias Jonas

Co-CEO, M.Sc.

Tobias Jonas, M.Sc. ist Mitgründer und Co-CEO der innFactory AI Consulting GmbH. Er ist ein führender Innovator im Bereich Künstliche Intelligenz und Cloud Computing. Als Co-Founder der innFactory GmbH hat er hunderte KI- und Cloud-Projekte erfolgreich geleitet und das Unternehmen als wichtigen Akteur im deutschen IT-Sektor etabliert. Dabei ist Tobias immer am Puls der Zeit: Er erkannte früh das Potenzial von KI Agenten und veranstaltete dazu eines der ersten Meetups in Deutschland. Zudem wies er bereits im ersten Monat nach Veröffentlichung auf das MCP Protokoll hin und informierte seine Follower am Gründungstag über die Agentic AI Foundation. Neben seinen Geschäftsführerrollen engagiert sich Tobias Jonas in verschiedenen Fach- und Wirtschaftsverbänden, darunter der KI Bundesverband und der Digitalausschuss der IHK München und Oberbayern, und leitet praxisorientierte KI- und Cloudprojekte an der Technischen Hochschule Rosenheim. Als Keynote Speaker teilt er seine Expertise zu KI und vermittelt komplexe technologische Konzepte verständlich.

LinkedIn