Entscheidungskriterien für KI-Tools und KI-Plattformen (Ein risikobasierten „Enterprise-AI-Assessment)



Nicht das beste KI-Tool suchen – sondern das passende für den konkreten Anwendungsfall

Die Auswahl eines KI-Tools wirkt auf den ersten Blick einfach:

ChatGPT, Claude, Gemini, Copilot, Mistral, Llama – welches System ist das beste?

Für Unternehmen ist diese Frage allerdings zu kurz gedacht.

Denn bei der Einführung von KI geht es nicht nur um Modellqualität oder Benutzerfreundlichkeit. Entscheidend sind unter anderem Datenschutz, Informationssicherheit, Integration in die bestehende IT-Landschaft, Kosten, Skalierbarkeit, Governance, regulatorische Anforderungen und – zunehmend wichtig – die Sicherheit von KI-Agenten.

Die entscheidende Frage lautet deshalb nicht:

„Welches KI-Tool ist das beste?“

sondern:

„Welche KI-Plattform erfüllt unsere Anforderungen für den konkreten Anwendungsfall hinsichtlich Daten, Risiko, Sicherheit, Integration, Kosten und Governance?“

Das ist ein wesentlicher Perspektivwechsel.

Ein KI-Tool für die Erstellung eines Marketingtexts hat andere Anforderungen als ein KI-System, das auf interne Unternehmensdaten zugreift, Software entwickelt, Personalentscheidungen unterstützt oder selbstständig Aktionen in Unternehmenssystemen ausführt.

1. Datenschutz, Datenverarbeitung und Compliance

Bei der Auswahl eines KI-Dienstes sollte zunächst geklärt werden:

Welche Daten verlassen eigentlich unser Unternehmen – und was passiert anschließend damit?

Dabei reicht die Aussage „DSGVO-konform“ nicht aus.

Datenschutz- und Compliance-Anforderungen hängen immer vom konkreten Anwendungsfall, den verarbeiteten Daten, der Rechtsgrundlage, den Vertragsbedingungen, den beteiligten Dienstleistern und der technischen Umsetzung ab.

1.1 Datenresidenz und Datensouveränität

Zu prüfen sind beispielsweise:

• Wo werden Eingaben verarbeitet?
• Wo werden Prompts und Outputs gespeichert?
• Wo befinden sich Backups?
• Welche Regionen können Daten verarbeiten?
• Welche Subdienstleister sind beteiligt?
• Welche internationalen Datenübermittlungen finden statt?
• Gibt es EU-, EWR- oder andere definierte Datenresidenzoptionen?
• Welche technischen und vertraglichen Möglichkeiten bestehen für die Kontrolle der Daten?

Dabei sollte zwischen verschiedenen Begriffen unterschieden werden:

Datenresidenz ≠ Datensouveränität ≠ Datenschutz.

Ein Anbieter kann beispielsweise eine Verarbeitung in einer europäischen Region anbieten, während gleichzeitig weitere technische oder organisatorische Abhängigkeiten außerhalb Europas bestehen.

Für besonders schützenswerte Informationen kann deshalb eine weitergehende Bewertung erforderlich sein.

1.2 Kein Training mit Unternehmensdaten

Ein wichtiges Auswahlkriterium ist die Frage:

Werden unsere Eingaben und Ergebnisse zum Training oder zur Verbesserung von Modellen verwendet?

Hier sollten keine Marketingaussagen ausreichen. Entscheidend sind:

• Vertragsbedingungen
• Datenschutzvereinbarung
• technische Dokumentation
• Konfiguration
• Produktvariante
• konkrete API- oder Workspace-Nutzung

Bei verschiedenen Enterprise-Angeboten wird beispielsweise ausdrücklich zugesichert, dass Geschäftsdaten standardmäßig nicht zum Training verwendet werden. Auch OpenAI beschreibt dies für seine Business- und API-Angebote.

1.3 No Training ist nicht Zero Retention

Ein besonders wichtiger Unterschied:

„Kein Training“ bedeutet nicht automatisch „keine Speicherung“.

Ein Anbieter kann Daten nicht für das Training verwenden und sie trotzdem für einen bestimmten Zeitraum speichern.

Deshalb sollten mindestens drei Fragen getrennt betrachtet werden:

   Frage

 Bedeutung

    Wird mit unseren Daten trainiert?

 Nutzung der Daten zur Modellverbesserung

   Wie lange werden Daten gespeichert?

 Retention

   Wo werden Daten verarbeitet/gespeichert?

 Datenresidenz

  Bei bestimmten API-Angeboten existieren inzwischen auch Zero-Data-Retention-Modelle. OpenAI beschreibt beispielsweise eine Zero-Data-Retention-Option für berechtigte API-Kunden.

Für die Bewertung zählt jedoch immer die konkrete Produktvariante und Konfiguration.

2. EU AI Act und regulatorische Anforderungen

Der EU AI Act macht aus der KI-Nutzung zunehmend eine Governance-Aufgabe.

Seit dem 2. August 2026 gelten unter anderem neue Transparenzanforderungen nach Art. 50. Dazu gehören beispielsweise Anforderungen an die Kennzeichnung bestimmter KI-generierter Inhalte und die Information von Personen, wenn sie direkt mit bestimmten KI-Systemen interagieren.

Bei der Auswahl eines Tools sollte deshalb nicht nur gefragt werden:

„Ist das Tool AI-Act-ready?“

Sondern:

• Welche Rolle hat unser Unternehmen?
• Sind wir Anbieter oder Betreiber eines KI-Systems?
• Welche KI-Systeme und Modelle werden eingesetzt?
• Welche Risikokategorie ist relevant?
• Welche Transparenzanforderungen bestehen?
• Welche Dokumentation wird benötigt?
• Welche Anforderungen bestehen an menschliche Aufsicht?
• Wie werden Änderungen am Modell behandelt?
• Wie wird die KI-Nutzung überwacht?
• Wie werden KI-Vorfälle behandelt?

Die regulatorische Bewertung ist deshalb nicht ausschließlich eine Eigenschaft des Tools.

Sie entsteht aus dem Zusammenspiel von:

Tool + Anwendungsfall + Daten + Organisation + Prozess + Nutzung.

3. Integration und Architektur

Ein KI-System ist selten eine isolierte Anwendung.

In Unternehmen soll KI beispielsweise mit

• Microsoft 365
• SAP
• Salesforce
• ServiceNow
• Atlassian
• CRM-Systemen
• ERP-Systemen
• Dokumentenmanagement
• Entwicklungsumgebungen
• Datenbanken
• APIs
• internen Wissensplattformen

zusammenarbeiten.

Damit wird die Frage der Architektur zentral.

3.1 API First

Ein professionelles KI-Angebot sollte geeignete Integrationsmöglichkeiten besitzen:

• REST APIs
• Graph APIs
• Webhooks
• SDKs
• standardisierte Schnittstellen
• Authentifizierung und Autorisierung
• Monitoring
• Rate Limiting

Dabei sollte nicht nur gefragt werden:

„Gibt es eine API?“

Sondern:

„Kann die API sicher und kontrolliert in unsere Unternehmensarchitektur integriert werden?“

4. Identität und Berechtigungen

Dieser Punkt wird bei KI-Systemen häufig unterschätzt.

Eine KI darf nicht plötzlich mehr sehen oder mehr tun dürfen als der Benutzer, in dessen Kontext sie arbeitet.

Besonders bei RAG-Systemen und KI-Agenten ist deshalb eine saubere Berechtigungsarchitektur erforderlich.

Zu prüfen sind beispielsweise:

• Integration mit Entra ID / IAM
• Single Sign-on
• RBAC / ABAC
• Benutzerkontext
• Service Accounts
• Service Principals
• Delegated Access
• Least Privilege
• Rollen für KI-Agenten
• Trennung von Benutzer- und Maschinenidentitäten
• Rechte auf Datenquellen
• Rechte auf Tools und APIs

Ein wichtiger Grundsatz lautet:

Die KI sollte grundsätzlich keine Berechtigungen erhalten, die der zugrunde liegende Benutzer oder Prozess nicht benötigt.

5. RAG – Unternehmenswissen statt Model Training

Retrieval Augmented Generation, kurz RAG, ist inzwischen ein wichtiger Baustein vieler Enterprise-AI-Architekturen.

Dabei wird ein Sprachmodell nicht unbedingt mit den Unternehmensdaten neu trainiert. Stattdessen werden relevante Informationen zur Laufzeit aus einer Wissensbasis abgerufen und dem Modell als Kontext zur Verfügung gestellt.

Das ist praktisch – aber keineswegs automatisch sicher.

Bei RAG sollte unter anderem geprüft werden:

• Welche Dokumente werden aufgenommen?
• Wer darf Dokumente einstellen?
• Wer darf sie ändern?
• Welche Benutzer dürfen sie lesen?
• Wie werden Berechtigungen aus dem Quellsystem übernommen?
• Wie schnell werden Änderungen übernommen?
• Wie werden veraltete Informationen erkannt?
• Wie wird die Qualität der Treffer getestet?
• Werden Quellen im Ergebnis angezeigt?
• Wie wird mit widersprüchlichen Informationen umgegangen?
• Wie werden Prompt-Injection-Angriffe in Dokumenten verhindert?
• Wie werden Embeddings geschützt?
• Wer darf die Wissensbasis administrieren?

Besonders wichtig:

Eine RAG-Lösung ist nur dann wirklich Enterprise-tauglich, wenn auch die Berechtigungslogik der zugrunde liegenden Informationsquellen berücksichtigt wird.

6. Modellagnostik und Vendor Lock-in

Viele Unternehmen wollen heute nicht mehr von einem einzigen Modellanbieter abhängig sein.

Das kann strategische Gründe haben:

• unterschiedliche Modellqualitäten
• unterschiedliche Preise
• unterschiedliche Datenschutzanforderungen
• unterschiedliche Regionen
• Performance
• Verfügbarkeit
• regulatorische Anforderungen
• technologische Entwicklung

Eine modellagnostische Architektur kann deshalb Vorteile bieten.

Beispielsweise könnte eine Anwendung abhängig vom Anwendungsfall unterschiedliche Modelle verwenden:

Standardaufgabe → günstiges Modell

komplexe Analyse → leistungsfähigeres Modell

sensible Daten → bestimmtes Deployment

Ausfall → alternatives Modell

Modellagnostik reduziert allerdings nicht automatisch den Vendor Lock-in.

Auch die darüberliegende Plattform, RAG-Architektur, Agent-Frameworks und proprietäre APIs können Abhängigkeiten erzeugen.

Deshalb sollte die Frage lauten:

Wo entstehen in unserer AI-Architektur Abhängigkeiten – und wie können wir sie kontrollieren?

7. Total Cost of Ownership – nicht nur Tokenpreise betrachten

Die Kosten eines KI-Systems bestehen selten nur aus den Kosten für Tokens oder Benutzerlizenzen.

Zu berücksichtigen sind beispielsweise:

• Lizenzkosten
• Tokenkosten
• API-Kosten
• Infrastruktur
• GPU-Kosten
• RAG-Infrastruktur
• Vektordatenbanken
• Datenaufbereitung
• Schnittstellen
• Monitoring
• Security
• Governance
• Tests
• Schulungen
• Administration
• Support
• Integration
• Migration
• laufende Modellbewertung

Bei Agenten können zusätzliche Kosten entstehen, weil ein einzelner Benutzerauftrag mehrere Modellaufrufe, Datenbankzugriffe oder Tool-Aufrufe auslösen kann.

Deshalb sollte ein Unternehmen nicht nur fragen:

„Was kostet eine Anfrage?“

sondern:

„Was kostet der gesamte Geschäftsprozess mit KI?“

8. Skalierbarkeit und Performance

Ein System, das mit zehn Benutzern funktioniert, muss nicht automatisch für 10.000 Benutzer geeignet sein.

Zu prüfen sind beispielsweise:

• maximale Benutzerzahl
• gleichzeitige Anfragen
• API Rate Limits
• Token Limits
• Kontextgrößen
• Antwortzeiten
• regionale Latenz
• Verfügbarkeit
• Skalierungsmechanismen
• Mandantenfähigkeit
• Lastverhalten
• Failover

Gerade bei produktiven KI-Anwendungen sollte Performance nicht nur anhand von Herstellerangaben bewertet werden.

Ein Proof of Concept mit realistischen Last- und Nutzungsszenarien liefert häufig wesentlich bessere Erkenntnisse.

9. Enterprise Security

KI bringt klassische Informationssicherheitsanforderungen mit neuen Angriffsmöglichkeiten zusammen.

Dabei sollte zwischen mindestens zwei Bereichen unterschieden werden:

LLM Security

Beispiele:

• Prompt Injection
• Indirect Prompt Injection
• Jailbreaks
• Sensitive Information Disclosure
• Data Leakage
• Model Manipulation
• Data Poisoning
• Insecure Output Handling
• Supply-Chain-Risiken
• Unbounded Consumption

Agent Security

Bei autonomen oder teilautonomen Agenten kommen zusätzliche Risiken hinzu:

• Excessive Agency
• übermäßige Berechtigungen
• Missbrauch von Tools
• Manipulation von Agentenzielen
• Zugriff auf nicht vorgesehene APIs
• Aktionen ohne menschliche Freigabe
• Agent-to-Agent-Kommunikation
• Identitätsmissbrauch
• unkontrollierte Folgeaktionen

Damit verändert sich das klassische Sicherheitsmodell.

Ein Chatbot erzeugt möglicherweise nur eine Antwort.

Ein Agent kann dagegen:

lesen → entscheiden → API aufrufen → Daten verändern → weitere Aktionen auslösen.

Die Sicherheitsanforderungen sind entsprechend höher.

10. Guardrails und Policy Enforcement

Ein Enterprise-KI-System sollte nicht ausschließlich auf das Modell selbst vertrauen.

Zusätzliche Kontrollmechanismen können beispielsweise festlegen:

• Welche Daten dürfen eingegeben werden?
• Welche Inhalte dürfen verarbeitet werden?
• Welche Modelle dürfen verwendet werden?
• Welche Benutzer dürfen welche Modelle verwenden?
• Welche Tools darf ein Agent verwenden?
• Welche Aktionen benötigen eine Freigabe?
• Welche Informationen dürfen das Unternehmen verlassen?
• Welche Antworten müssen geprüft werden?

Guardrails können damit eine technische Umsetzung von Unternehmensrichtlinien unterstützen.

Sie ersetzen jedoch keine Governance.

11. Auditierbarkeit und Nachvollziehbarkeit

„Explainable AI“ wird häufig so verstanden, als müsse das Unternehmen die vollständige interne Entscheidungslogik eines großen Sprachmodells nachvollziehen können.

Das ist in der Praxis nicht immer realistisch.

Für Enterprise-Anwendungen ist deshalb häufig ein anderer Ansatz sinnvoll:

Traceability statt vollständiger Modelltransparenz

Nachvollziehbar sollten beispielsweise sein:

• Benutzer
• Zeitpunkt
• verwendetes Modell
• Modellversion
• Prompt bzw. relevante Eingabeinformationen
• verwendete Datenquellen
• RAG-Dokumente
• Tool-Aufrufe
• ausgeführte Aktionen
• Guardrails
• Freigaben
• Ergebnis
• Fehler
• Sicherheitsereignisse

Damit entsteht ein nachvollziehbarer AI Audit Trail.

Dabei muss allerdings auch das Logging selbst datenschutz- und sicherheitskonform gestaltet werden.

„Alles loggen“ ist daher nicht automatisch die richtige Lösung.

12. AI Governance und Lifecycle Management

Hier liegt aus meiner Sicht eine der wichtigsten Erweiterungen klassischer KI-Tool-Auswahlverfahren.

• Ein KI-System ist kein einmal angeschafftes Softwareprodukt.
• Modelle verändern sich.
• Prompts verändern sich.
• RAG-Daten verändern sich.
• Benutzer verändern ihre Nutzung.
• Agenten erhalten neue Tools.
• Anbieter ändern Preise, Modelle und Funktionen.
• Deshalb braucht KI einen eigenen Lifecycle.

Ein möglicher Ablauf:

Idee → Bewertung → Freigabe → Implementierung → Test → Betrieb → Monitoring → Änderung → Re-Evaluierung → Ablösung

Dazu gehören unter anderem:

• AI Inventory
• Use-Case-Beschreibung
• Risikobewertung
• Klassifizierung
• Verantwortlichkeiten
• Freigabeprozess
• Modellmanagement
• Datenmanagement
• Testmanagement
• Monitoring
• Incident Management
• Change Management
• Lieferantenmanagement
• regelmäßige Reviews
• Exit-Strategie

Hier lässt sich KI-Governance sehr gut mit bestehenden Managementsystemen verbinden, beispielsweise mit ISO/IEC 27001 und ISO/IEC 42001.

13. AI Inventory – wissen, wo KI eingesetzt wird

Eine überraschend einfache Frage ist:

Welche KI-Systeme werden in unserem Unternehmen überhaupt eingesetzt?

Die Antwort ist in vielen Unternehmen nicht vollständig bekannt.

Neben offiziell eingeführten Anwendungen existieren häufig:

• private ChatGPT-Nutzung
• Copilot-Nutzung
• Browser-Plugins
• KI-Funktionen in SaaS-Anwendungen
• Entwicklerwerkzeuge
• KI-gestützte Meeting-Tools
• automatische Übersetzung
• OCR und Dokumentenanalyse
• RAG-Systeme
• eigene KI-Anwendungen
• Agenten

Ein AI Inventory sollte deshalb beispielsweise enthalten:

•     KI-System:  internes RAG-System
•    Anbieter:  Anbieter X
•    Modell:  Modell Y
•    Zweck:  Wissenssuche
•    Benutzer: Mitarbeiter
•    Daten: interne Dokumente
•    Kritikalität:  hoch
•    Risiko:  mittel
•    Verantwortlicher:  Fachbereich
•    Freigabe:  Management
•    Rechtsgrundlage:  geprüft
•    letzte Bewertung:  Datum
•    nächste Review:  Datum

  Damit wird aus einer unübersichtlichen Tool-Landschaft eine steuerbare Umgebung.

14. AI Literacy und Benutzerkompetenz

Technologie allein reicht nicht.

Mitarbeiter müssen verstehen:

• Was kann das System?
• Was kann es nicht?
• Welche Daten dürfen eingegeben werden?
• Wie zuverlässig sind Ergebnisse?
• Wann muss ein Mensch prüfen?
• Wie werden Fehler erkannt?
• Wie werden KI-generierte Inhalte gekennzeichnet?
• Welche Unternehmensregeln gelten?

Gerade bei generativer KI ist ein Grundsatz entscheidend:

Eine überzeugend formulierte Antwort ist nicht automatisch eine richtige Antwort.

AI Literacy sollte deshalb nicht nur eine einmalige Schulung sein, sondern Bestandteil des laufenden AI-Governance-Programms.

15. Lieferanten- und Ökosystemmanagement

Eine KI-Plattform besteht häufig nicht nur aus einem Anbieter.

Dahinter können stehen:

Unternehmen → AI-Plattform → Gateway → Modellanbieter → Cloud Provider → RAG → Datenbank → Plugin → API → weitere Dienstleister

Damit entsteht eine komplexe Lieferkette.

Zu bewerten sind beispielsweise:

• Subdienstleister
• Cloud Provider
• Modellanbieter
• Datenverarbeitung
• Sicherheitsnachweise
• Zertifizierungen
• SLA
• Support
• Incident Management
• Änderungsmanagement
• Auditrechte
• Exit-Möglichkeiten
• Datenexport
• Löschung
• Portabilität

16. Support, Skills und Ökosystem

Eine technisch hervorragende Plattform kann trotzdem ungeeignet sein, wenn sie intern nicht betrieben werden kann.

Deshalb sollten auch folgende Fragen gestellt werden:

• Welche Fähigkeiten benötigen wir intern?
• Gibt es Low-Code-/No-Code-Möglichkeiten?
• Wie hoch ist der Administrationsaufwand?
• Wie groß ist das Ökosystem?
• Gibt es Integrationen?
• Gibt es verfügbare Spezialisten?
• Wie gut ist die Dokumentation?
• Wie schnell entwickelt sich die Plattform?
• Wie belastbar ist der Support?
• Welche SLA werden angeboten?

Hier sollte auch zwischen Innovation und Betriebsstabilität unterschieden werden.

Ein Startup kann sehr schnell innovative Funktionen liefern.

Ein etablierter Anbieter kann andere Vorteile bei Support, Compliance und langfristiger Verfügbarkeit bieten.

Die Bewertung sollte deshalb zum jeweiligen Risiko und Anwendungsfall passen.

17. Die strategische Architektur: AI Gateway

Mit zunehmender Nutzung verschiedener KI-Modelle entsteht eine weitere Architekturfrage:

Wie verhindern wir, dass jede Anwendung direkt mit einem anderen Modellanbieter verbunden ist?

Eine mögliche Antwort ist eine zentrale AI-Gateway-Schicht.

Vereinfacht:

Unternehmensanwendung

↓

AI Gateway

↓

GPT / Claude / Gemini / Mistral / Llama / weitere Modelle

Das Gateway kann als zentrale Vermittlungsschicht dienen.

Beispiele für Funktionen können sein:

• einheitliche API
• Modell-Routing
• Fallback
• Rate Limiting
• Kostenkontrolle
• Authentifizierung
• Logging
• Monitoring
• Guardrails
• zentrale Policies
• Modellwechsel

Ein Beispiel für einen solchen technischen Ansatz ist LiteLLM. Die aktuelle Dokumentation beschreibt unter anderem eine einheitliche Schnittstelle für mehr als 100 LLMs, Routing und Fallback, Kosten-/Budgetsteuerung sowie zentrale Authentifizierungs-, Logging- und Monitoring-Funktionen.

18. AI Gateway ist aber kein Allheilmittel

Ein AI Gateway kann ein wichtiger Baustein einer Enterprise-AI-Architektur sein.

Es ersetzt jedoch nicht:

• IAM
• Datenschutz
• Informationsklassifizierung
• RAG-Berechtigungen
• AI Governance
• Risikomanagement
• sichere Softwareentwicklung
• Agenten-Governance
• Lieferantenmanagement
• Business Continuity
• regulatorische Bewertung

Insbesondere bei Agenten muss die Architektur weiter gedacht werden.

Ein mögliches Zielbild:

Benutzer

↓

AI-Anwendung

↓

AI Gateway

↓

Modell

↙︎ ↘︎

RAG Tools / APIs

↓ ↓

Wissensbasis Unternehmenssysteme

Dabei müssen insbesondere Identität, Berechtigungen, Policies, Logging und Freigaben durchgängig berücksichtigt werden.

19. Was sollte ein Unternehmen konkret bewerten?

Aus den genannten Punkten lässt sich eine praktische Bewertungsmatrix entwickeln.

   Dimension

 Typische Prüffragen

•    Datenschutz:  Wo werden Daten verarbeitet?
•    Datenverwendung:  Werden Daten gespeichert oder zum Training verwendet?
•    Compliance:  Welche regulatorischen Anforderungen sind relevant?
•    Sicherheit:  Wie werden Daten, Zugänge und Schnittstellen geschützt?
•    LLM Security:  Wie werden Prompt Injection und Data Leakage behandelt?
•    Agent Security:  Welche Aktionen darf ein Agent ausführen?
•    IAM:  Werden bestehende Benutzerrechte berücksichtigt?
•    Architektur:  Wie gut lässt sich die Lösung integrieren?
•    RAG:  Wie werden Datenquellen und Berechtigungen umgesetzt?
•    Modellstrategie:  Wie stark ist die Abhängigkeit von einem Modellanbieter?
•    TCO:  Welche Gesamtkosten entstehen?
•    Skalierbarkeit:  Wie verhält sich die Lösung bei steigender Nutzung?
•    Governance:  Wie werden KI-Systeme freigegeben und überwacht?
•    Lifecycle:  Wie werden Änderungen und neue Modellversionen behandelt?
•    Monitoring:  Welche Logs, Metriken und Alarme gibt es?
•    Lieferanten:  Wie werden Anbieter und Subdienstleister bewertet?
•    Exit:  Wie können Daten, Konfiguration und Anwendungen migriert werden?
•    Kompetenz:  Welche Fähigkeiten benötigen die Mitarbeiter?

20. Ein einfaches Bewertungsmodell

Für die Praxis muss eine solche Bewertung nicht kompliziert sein.

Ein Unternehmen kann beispielsweise für jeden Use Case fünf grundlegende Fragen beantworten:

1. Daten

Welche Daten werden verarbeitet und wie sensibel sind sie?

2. Risiko

Was passiert, wenn die KI einen Fehler macht?

3. Zugriff

Welche Informationen darf die KI lesen und welche Aktionen darf sie ausführen?

4. Abhängigkeit

Wie stark machen wir uns von Anbieter, Modell oder Plattform abhängig?

5. Governance

Wie können wir die Nutzung kontrollieren, überwachen und bei Bedarf wieder abschalten?

Je höher das Risiko eines Anwendungsfalls, desto detaillierter sollte die Bewertung erfolgen.

21. Von der Tool-Auswahl zum AI Assessment

Damit verändert sich auch der Auswahlprozess.

Nicht:

Tool A vs. Tool B vs. Tool C

sondern:

Schritt 1 – Use Case definieren

Was soll die KI konkret leisten?

Schritt 2 – Daten bestimmen

Welche Informationen werden verarbeitet?

Schritt 3 – Risiko bewerten

Was passiert bei falschen Ergebnissen oder Fehlfunktionen?

Schritt 4 – regulatorische Anforderungen bestimmen

Welche Anforderungen ergeben sich beispielsweise aus AI Act, DSGVO oder branchenspezifischen Vorgaben?

Schritt 5 – Architektur definieren

Wie werden KI, RAG, IAM, APIs und Unternehmenssysteme verbunden?

Schritt 6 – Anbieter bewerten

Welche Plattform erfüllt die Anforderungen?

Schritt 7 – Proof of Concept

Funktioniert die Lösung mit realistischen Daten und Prozessen?

Schritt 8 – Security & Compliance Assessment

Sind die technischen und organisatorischen Anforderungen erfüllt?

Schritt 9 – Freigabe

Wer trägt die Verantwortung für die Einführung?

Schritt 10 – Betrieb und Monitoring

Wie wird die KI dauerhaft überwacht und weiterentwickelt?

22. Fazit

Die Auswahl einer KI-Plattform ist heute keine reine Technologieentscheidung mehr.

Sie betrifft:

Daten + Sicherheit + Architektur + Kosten + Prozesse + Menschen + Governance + Regulierung.

Besonders bei generativer KI und KI-Agenten wird dieser Zusammenhang immer wichtiger.

Ein Unternehmen sollte deshalb nicht fragen:

„Welche KI ist die beste?“

Sondern:

„Welche KI-Lösung ist für diesen konkreten Anwendungsfall unter unseren technischen, organisatorischen, wirtschaftlichen und regulatorischen Rahmenbedingungen geeignet?“

Das führt zu einer anderen Art der KI-Auswahl:

Nicht technologiegetrieben, sondern anwendungs- und risikobasiert.

Und genau hier entsteht die Verbindung zu etablierten Managementsystemen.

AI Governance kann beispielsweise in ein bestehendes Informationssicherheitsmanagement nach ISO/IEC 27001 integriert werden. Für ein umfassenderes AI Management System bietet sich ISO/IEC 42001 an.

Die eigentliche Herausforderung besteht damit nicht darin, möglichst schnell möglichst viele KI-Tools einzuführen.

Die Herausforderung besteht darin, KI so in die Organisation zu integrieren, dass ihr Nutzen entsteht, ohne dass Sicherheit, Datenschutz, Compliance, Kontrolle und Verantwortlichkeit auf der Strecke bleiben.

Praxis statt PowerPoint gilt damit auch für KI:

Nicht die Anzahl der eingesetzten KI-Tools entscheidet über den Erfolg.

Entscheidend ist, ob KI kontrolliert, sicher und sinnvoll in die bestehenden Prozesse integriert wird.