Warum On-Premises-KI-Bereitstellungen im Einkauf ins Stocken geraten (und welche Einordnung das löst)

Ab dem 2. Dezember 2027 gelten die Betreiberpflichten nach dem EU AI Act für Hochrisiko-KI-Systeme in den Bereichen Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, Migration, Asyl und Grenzkontrolle ^[1]. Compliance-Teams warten 2026 nicht bis Dezember 2027 mit ihrer Positionierung. Sie verfassen bereits jetzt Lieferanten-Due-Diligence-Fragebögen, und der Einkauf von Unternehmens-KI gerät bei diesen Fragebögen in einem Tempo ins Stocken, das mit der eingekauften Technologie wenig zu tun hat. Die Lösung ist nicht eine bessere Demo. Sie liegt in einer Neuformulierung dessen, worum es im Einkaufsgespräch tatsächlich geht.

Wie „Stillstand" 2026 konkret aussieht

Der technische Proof-of-Concept besteht. Das Modell liefert auf der eigenen Arbeitslast des Kunden brauchbare Ergebnisse. Der technische Prüfer verfasst eine positive Stellungnahme und übergibt die Akte an den Einkauf. Dann liegt die Akte. Drei Wochen später meldet sich das Compliance-Team des Kunden mit einem Vermerk zurück: „Wir können unsere Betreiberpflichten für diesen Workflow nicht nachweisen, wenn die Inferenz auf einem Endpunkt stattfindet, den wir nicht kontrollieren."

Die Unternehmensumfrage von a16z hat die Form dieses Musters bereits in seiner Entstehung erfasst: Vertragszyklen, die „früher über ein Jahr bis zum Abschluss brauchten, werden in 2 oder 3 Monaten durchgeschoben" – für Produkte, die zu den neuen Anforderungen passen ^[4]. Die Implikation gilt auch umgekehrt: Der Einkauf von Produkten, die nicht zu den neuen Anforderungen passen, dauert weiterhin das Jahr. Auch überzeugende technische Piloten ändern daran nichts.

Was der Einkauf tatsächlich nachweisen muss

Der EU AI Act unterscheidet zwischen dem Anbieter eines KI-Systems und dem Betreiber ^[1]. Eine Bank, die eine Drittanbieter-LLM-API zur Bewertung von Kreditanträgen einsetzt, ist der Betreiber. Zu den Betreiberpflichten gehören menschliche Aufsicht, Monitoring, Vorfallsmeldung und der Nachweis dieser Fähigkeiten auf Anfrage. Diese Pflichten treffen die Bank, nicht den LLM-Anbieter – und das Einkaufsteam der Bank ist die Schnittstelle, an der die Lieferantenauswahl darüber entscheidet, ob die Pflichten praktikabel erfüllbar sind.

Diese Stoßrichtung ist nicht auf die EU beschränkt. NIST hat am 7. April 2026 eine Konzeptnotiz zu einem AI-RMF-Profil für vertrauenswürdige KI in kritischer Infrastruktur veröffentlicht ^[2] – die erste bundesweite Eingrenzung von AI-RMF-Betreiberpflichten für Betreiber kritischer Infrastruktur in den Vereinigten Staaten. Die AI Policy Observatory der OECD führt ein lebendes Repository „aus mehr als 80 Jurisdiktionen und Organisationen" ^[3]. Die jurisdiktionsübergreifende Konvergenz auf betreiberseitige Pflichten ist der Trend, nicht die Ausnahme.

Einkaufsteams in regulierten Branchen lesen diese Signale und positionieren sich vorab. Sie können nicht bis zum 2. Dezember 2027 warten, um zu erfahren, ob eine Lieferantenarchitektur ihnen die Erfüllung ihrer Pflichten überhaupt erlaubt.

Warum „wir sind SOC 2" die falsche Antwort ist

Die anbieterseitige Antwort, die in der Vergangenheit Einkaufsgespräche im Unternehmensumfeld aufgelöst hat – SOC 2 Type II, ISO 27001, GDPR-konformes DPA – adressiert anbieterseitige Kontrollen. Sie sind notwendig. Für die jetzt anstehenden Betreiberpflichten reichen sie nicht aus.

Betreiberpflichten verlangen vom Betreiber, auf Anfrage nachzuweisen, welche Daten durch das KI-System geflossen sind. Das ist eine Frage an die eigenen Logs des Betreibers, nicht an die des Anbieters. Ein SOC-2-zertifizierter Anbieter, der Prompt und Antwort in einer verwalteten Cloud hält, kann diese Lücke nicht schließen, weil die Lücke auf der Betreiberseite der Grenze liegt: Der Betreiber kann kein Log über etwas erzeugen, das er nicht sieht.

Das ist die strukturelle Diskrepanz, die das Einkaufsgespräch zum Stillstand bringt. Das Compliance-Team verfasst einen Vermerk gegen Betreiberpflichten. Der Anbieter antwortet mit anbieterseitigen Zertifizierungen. Beide Schiffe ziehen aneinander vorbei.

Die Einordnung, die den Stillstand auflöst

Drei Eigenschaften der Bereitstellungsarchitektur, im Lieferantenfragebogen vorab benannt, lassen den Stillstand zusammenbrechen:

1. Inferenz lokal beim Betreiber. Entweder auf dem Gerät der Anwenderin oder auf einem Server, den der Betreiber betreibt. Prompts und Antworten verlassen den Perimeter des Betreibers nicht.
2. Inhaltsfreie Audit-Logs im Besitz des Betreibers. Jede administrative Aktion wird mit Zeitstempel und Akteur im SIEM des Betreibers protokolliert. Im Audit-Eintrag erscheinen keine Prompts und keine Antworten. Der Eintrag ist der Nachweis; der Inhalt verbleibt beim Betreiber und unterliegt dessen eigener Aufbewahrungsrichtlinie.
3. Identität über den IdP des Betreibers. OIDC gegen Microsoft Entra ID oder Google Workspace. Die bestehenden Zugriffskontrollen und SSO-Richtlinien des Betreibers gelten unverändert.

Dies sind keine Anbietereigenschaften, die zertifiziert werden müssten. Es sind Eigenschaften der Bereitstellungsarchitektur, die spezifiziert werden müssen. Sobald der Lieferantenfragebogen daran ausgerichtet ist, schreibt sich der Compliance-Vermerk von selbst: Zu jeder Betreiberpflicht gibt es eine entsprechende architektonische Eigenschaft, auf die der Betreiber verweisen kann.

Wie das in der von uns ausgelieferten Form aussieht

Software Tailors AI Suite wird als Desktop-Installer ausgeliefert, der mit einem lokalen Inferenzprozess kommuniziert. AI Admin Console ist die Verwaltungsoberfläche, mit der das IT-Team des Betreibers Richtlinien durchsetzt, Lizenzen verwaltet und Audits sichtbar macht. Sechs Fortune-Global-500-Kunden aus den Branchen Pharma, Finanzen, Behörden, Recht, Verteidigung und Energie haben diese Form seit 2007 in Betrieb genommen (frühere Kunden), und jedes dieser Engagements durchlief eine Variante der oben beschriebenen Einordnung, bevor der Vertrag unterzeichnet wurde.

Der schnellste Weg, dies konkret zu machen, ist eine reale Arbeitslast durchzuspielen. Ein kostenloser 1-wöchiger Pilot bringt das Modell auf die Hardware des Kunden, den Audit-Eintrag in das SIEM des Kunden und die Identität über den IdP des Kunden – ausreichend, damit das Compliance-Team den Vermerk gegen die Pflichten verfasst, die es tatsächlich treffen.

Quellen

1. Europäische Kommission. „AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Abgerufen am 2026-06-03.
2. NIST. „AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Abgerufen am 2026-06-03. Die Konzeptnotiz zu kritischer Infrastruktur wurde am 7. April 2026 veröffentlicht.
3. OECD AI Policy Observatory. „Policy Navigator dashboards." oecd.ai/en/dashboards. Abgerufen am 2026-06-03.
4. Andreessen Horowitz. „State of Generative AI in the Enterprise." a16z.com/generative-ai-enterprise-2024. Veröffentlicht am 21. März 2024. Abgerufen am 2026-06-03.

Verwandte Artikel

• Die Verschiebung vom Cloud-First- zum Datenresidenz-First-Einkauf von Unternehmens-KI
• OECD AI Policy Observatory: Was sich in den letzten 12 Monaten geändert hat
• Inhaltsfreie Audit-Logs: Wie wir nachweisen, was das Modell getan hat, ohne Prompts aufzubewahren
• EU AI Act 2026: Was On-Premises-Bereitstellung an der Compliance ändert
• Warum wir KI als installierbare Binärdateien ausliefern, nicht als Cloud-SaaS
• Alle Artikel →