Data Policy: Wer kontrolliert die Daten wirklich
Die erste Ebene der Bewertung eines AI-Vendors ist die Datenpolitik. In der Praxis ist jede Interaktion mit einem AI-System gleichzeitig ein potenzieller Input für weitere Verarbeitung, Logging oder sogar Modelltraining.
Die zentrale Frage ist daher nicht nur, ob der Vendor „Daten schützt“, sondern ob er klar definiert, was nach der Verarbeitung mit den Daten geschieht. In Enterprise-Umgebungen muss eindeutig sein, ob Daten für das Modelltraining verwendet werden, wie lange sie gespeichert werden und ob eine echte Möglichkeit zur vollständigen Löschung besteht. Ebenso wichtig ist das Verständnis der Datengeografie, da diese oft den rechtlichen Rahmen ihres Schutzes bestimmt.
Wenn diese Regeln nicht explizit und auditierbar sind, verliert die Organisation faktisch die Kontrolle über ihre eigenen Datenwerte.
Auditability: Black Box oder erklärbares System
Der zweite zentrale Bereich ist die Auditierbarkeit. In klassischen Softwaresystemen ist es möglich, rückwirkend zu rekonstruieren, welche Logik zu einem bestimmten Ergebnis geführt hat. Im Fall von AI gilt das nicht automatisch, da das Ergebnis eines probabilistischen Modells und nicht einer festen Logik entspringt.
Für den Enterprise-Einsatz ist es daher kritisch, dass der Vendor zumindest ein grundlegendes Maß an Nachvollziehbarkeit bieten kann. Das bedeutet die Möglichkeit, Inputs, Modellversion, verwendeten Kontext und idealerweise auch Zwischenschritte der Verarbeitung rückwirkend einzusehen.
Ohne diese Fähigkeit wird das AI-System zu einer Black Box, was internes Audit, Compliance und Incident-Handling erheblich erschwert.
Modell- und Vendor-Flexibilität: versteckter Lock-in
Eines der am meisten unterschätzten Risiken von AI-Lösungen ist Vendor Lock-in, der deutlich stärker ist als im traditionellen SaaS. Der Grund ist, dass der Wert eines AI-Systems nicht nur in der Anwendung selbst liegt, sondern in der Kombination aus Modell, Prompts, Datenlayer und Workflow-Logik.
In der Praxis bedeutet das, dass das System zwar technisch ersetzbar ist, seine Migration jedoch extrem schwierig ist. Prompt Engineering ist nicht standardisiert, Workflows sind oft an eine spezifische Implementierung gebunden, und auch Embeddings oder Memory-Layer sind häufig inkompatibel.
Daher ist es wichtig, frühzeitig zu prüfen, ob das System mit mehreren Modellen arbeiten kann und ob es den Export von Konfiguration und Logik erlaubt. Wenn das nicht möglich ist, handelt es sich eher um ein geschlossenes Ökosystem als um eine flexible Enterprise-Lösung.
Onboarding und Offboarding: der Test, den die meisten Firmen nicht machen
Bei AI-Systemen konzentrieren sich Unternehmen oft auf das Onboarding, also darauf, wie schnell ein System eingeführt werden kann. Viel wichtiger ist jedoch die Frage, was passiert, wenn die Organisation es nicht mehr nutzen möchte.
Offboarding umfasst nicht nur den Datenexport, sondern auch die Fähigkeit, Workflows anderswo wieder aufzubauen, das System ohne Informationsverlust abzuschalten und sicherzustellen, dass keine Daten im Vendor-System verbleiben.
Ein starkes Risikosignal ist es, wenn der Vendor nicht klar beschreiben oder demonstrieren kann, wie ein Exit aus der Plattform aussieht. In der Praxis bedeutet das oft, dass der Exit entweder sehr teuer oder technisch sehr komplex ist.
Incident Response: AI-spezifische Fehler
AI-Systeme haben Arten von Incidents, die in klassischer Software nicht existieren. Dazu gehören Situationen, in denen das Modell falsche oder gefährliche Outputs generiert, sensible Daten durch Input-Prompts leakt oder durch spezifische Angriffe auf Sprachmodelle manipuliert wird.
Daher reicht ein allgemeiner Incident-Response-Plan nicht aus. Der Vendor muss spezifische Prozesse für AI-Verhalten definiert haben, einschließlich Monitoring von Inputs und Outputs, der Fähigkeit, Teile des Systems schnell zu deaktivieren, sowie Mechanismen zum erneuten Testen des Modells nach einem Incident.
Wenn diese Prozesse nicht existieren, verlässt sich die Organisation auf eine Reaktion, die nicht an die Natur des Risikos angepasst ist.
SLA: das Problem ist nicht Verfügbarkeit, sondern Qualität
Traditionelle SLA-Modelle, die auf Uptime basieren, sind im AI-Kontext unzureichend. Die reine API-Verfügbarkeit sagt nichts darüber aus, ob das System konsistente oder korrekte Outputs liefert.
Im AI-Kontext müssen SLAs daher um Metriken wie Latenz, Stabilität der Antworten, Fehlerraten und die Existenz von Fallback-Mechanismen bei Modellverschlechterung erweitert werden.
Ohne diese Parameter wird das SLA zu einem formalen Dokument, das die reale Servicequalität nicht widerspiegelt.
Integration: wo AI zu Wert wird
Der große Unterschied zwischen Demo-AI und Produktionssystemen ist der Integrationsgrad. Viele Lösungen funktionieren gut als eigenständige Chatbots, aber ihr Wert zeigt sich erst, wenn sie in die bestehenden Prozesse der Organisation integriert sind.
Echter Enterprise-Wert entsteht nur dann, wenn AI kein isoliertes Tool ist, sondern Teil von CRM-, ERP-, Support- oder operativen Systemen.
Daher ist es wichtig, nicht nur die Modellqualität zu bewerten, sondern auch die Fähigkeit zur Integration in reale Workflows und bestehende Infrastruktur.
Pricing: wo die Komplexität verborgen liegt
AI-Pricing ist oft deutlich weniger transparent, als es auf den ersten Blick erscheint. Zusätzlich zu den Grundkosten für die Nutzung des Modells können Kosten für Token, Storage, Logging, Fine-Tuning oder Skalierung entstehen.
Das Problem ist, dass diese Kosten oft erst bei Produktionslast wirklich sichtbar werden, nicht während der Pilotphase.
Daher ist es entscheidend, reale Nutzung in großem Maßstab zu simulieren und zu verstehen, wie sich der Preis bei steigendem Traffic oder langfristiger Nutzung verändert.
Fazit: AI-Vendor ist ein Entscheidungssystem, kein Softwareprodukt
Der grundlegende Wandel im Denken beim AI-Procurement besteht darin zu verstehen, dass man kein Tool kauft, sondern ein System, das Daten verarbeitet, Entscheidungen generiert und sich über die Zeit verändern kann.
Daher reicht es nicht aus, Funktionen oder Preis zu bewerten. Entscheidend ist das Verständnis von Datenkontrolle, Auditierbarkeit, Systemflexibilität und der Fähigkeit der Organisation, ohne Wertverlust auszusteigen.
Ein AI-Vendor, der diese Aspekte nicht transparent erklären kann, stellt in der Praxis ein höheres Risiko als einen Mehrwert dar.
