Drei Fragen, die Sie vor jeder KI-Beauftragung stellen sollten

In Beratungsgesprächen sehe ich immer wieder dasselbe Muster: Drei Fragen werden nicht gestellt — und genau diese drei werden später teuer. Nicht, weil die Geschäftsführer unvorsichtig wären, sondern weil die Fragen technisch genug sind, dass sie im Verkaufsgespräch untergehen. Der Anbieter spricht über Möglichkeiten, der Kunde über Ziele, und niemand spricht über die Architektur, die am Ende darüber entscheidet, ob das Projekt trägt.

Wenn Sie vor der Beauftragung eines KI-Anbieters nur drei Dinge klären, dann diese.

1. Wo liegen unsere Daten im konkreten Verarbeitungspfad — und wer hat in welcher Form Zugriff?

Globale Cloud-Standardverträge klingen zunächst beruhigend. In der Praxis landen Prompts und Modell-Ausgaben aber oft in Regionen, die der DSGVO nicht standhalten — auch dann, wenn die Marketing-Seite eine „EU-Region” verspricht. Der Unterschied zwischen „EU-Region” und „EU Data Zone mit vertraglich garantierter Datenresidenz” ist kein Detail, sondern entscheidet über die Rechtmäßigkeit der gesamten Verarbeitung.

Die Antwort, die Sie brauchen, ist konkret: Welche Rechenzentren werden genutzt? Welche Sub-Auftragsverarbeiter sind eingebunden? Wie lange werden Logs aufbewahrt, und wo? Ein Anbieter, der diese Fragen nicht aus dem Stand beantworten kann, hat seine eigene Architektur nicht verstanden — oder will sie nicht offenlegen. Beides ist ein Warnsignal.

2. Was passiert mit unserem Projekt, wenn der Anbieter morgen die Preise verdoppelt oder das Modell abschaltet?

Vendor-Lock-in ist im KI-Bereich härter als in jedem anderen IT-Feld. Anbieter ändern Modelle, Token-Preise und Verfügbarkeiten oft ohne nennenswerten Vorlauf. Ein Modell, auf das Sie Ihre Prozesse aufgebaut haben, kann in einer neuen Version anders antworten — oder ganz verschwinden. Wenn Ihre Lösung dann nicht modular gebaut ist, sitzen Sie in der Geiselhaft eines Anbieters, dessen Roadmap Sie nicht kontrollieren.

Die Gegenfrage, die Sie stellen sollten: Lässt sich das zugrunde liegende Modell austauschen, ohne die gesamte Anwendung neu zu bauen? Eine sauber abstrahierte Architektur erlaubt genau das. Eine, die fest an die API eines einzelnen Anbieters gekoppelt ist, nicht.

3. Können wir dieselbe Lösung perspektivisch on-premise oder im echten EU-Datenraum betreiben?

Wenn die Antwort „nein” lautet, sollten Sie zweimal nachdenken. Was heute regulatorisch zulässig ist, kann durch neue Vorgaben — den EU AI Act, DORA, branchenspezifische Aufsichtsanforderungen — morgen problematisch werden. Migrierbarkeit ist in regulierten Branchen kein Luxus, sondern Risikomanagement.

Das bedeutet nicht, dass Sie heute on-premise gehen müssen. Es bedeutet, dass die Architektur den Weg dorthin offenhalten sollte. Eine Lösung, die von Anfang an auf austauschbare, auch lokal betreibbare Modelle setzt, gibt Ihnen die Option, ohne Sie zur sofortigen Investition zu zwingen.

Warum diese drei Fragen den Unterschied machen

Sie sind keine Schikane gegenüber dem Anbieter. Sie zwingen ihn lediglich, vom Marketing-Sprech in die technische Realität zu wechseln. Ein seriöser Partner wird die Fragen begrüßen, weil sie zeigen, dass Sie verstehen, worum es geht. Ein Anbieter, der ausweicht, relativiert oder die Fragen als „zu technisch für diese Phase” abtut, hat Ihnen bereits die wichtigste Antwort gegeben.

Im Kern geht es um eine einfache Haltung: KI-Projekte in regulierten Branchen scheitern selten an der Idee. Sie scheitern an Datenflüssen, an Abhängigkeiten und an Architekturen, die nicht für die Realität einer beaufsichtigten Organisation gebaut wurden. Wer diese drei Fragen früh stellt, verschiebt das Scheitern aus der teuren Implementierungsphase in das kostenlose Erstgespräch — und das ist genau der richtige Ort dafür.