Warum der KI-Einkauf mehr als eine Lizenzentscheidung ist

Neue KI-Werkzeuge landen oft zuerst als Pilot im Fachbereich: ein Assistent für Texte, eine Recherchefunktion, ein Copilot im CRM oder ein System zur Dokumentenanalyse. Der Einstieg wirkt unkompliziert. Doch sobald ein Tool regelmäßig mit Unternehmensdaten arbeitet, Ergebnisse in Geschäftsprozesse einfließen oder Mitarbeitende darauf vertrauen, wird aus dem Softwaretest eine Governance-Frage.

Die zentrale Aufgabe lautet deshalb nicht, jedes KI-Tool maximal bürokratisch zu prüfen. Unternehmen brauchen vielmehr einen wiederholbaren Prozess, der früh die Fragen sichtbar macht, die später teuer werden können: Welche Daten fließen wohin? Welche Aktionen darf das System ausführen? Wer kontrolliert Ergebnisse? Welche Rolle hat das eigene Unternehmen nach dem EU AI Act? Was müssen Anwender wissen, damit sie das System sinnvoll und sicher nutzen?

Artikel 4 des EU AI Act macht AI Literacy dabei zu einem festen Bestandteil des organisatorischen Rahmens. Anbieter und Betreiber von KI-Systemen müssen Maßnahmen ergreifen, die die Entwicklung von KI-Kompetenz ihrer Mitarbeitenden und weiterer Personen unterstützen, die in ihrem Auftrag mit KI-Systemen arbeiten. Die aktuelle Fassung verlangt kein identisches Kompetenzniveau für jede einzelne Person; sie stellt auf Wissen, Erfahrung, Ausbildung und Nutzungskontext ab. Genau deshalb sollte der Schulungsbedarf bereits beim Einkauf mitgedacht werden.

Die folgenden zehn Prüffragen sind kein Ersatz für Rechts-, Datenschutz- oder Informationssicherheitsprüfung im Einzelfall. Sie helfen, diese Prüfungen mit dem tatsächlichen Nutzungsszenario zu verbinden.

1. Welches konkrete Problem soll das KI-Tool lösen?

Ein guter Prüfprozess beginnt nicht beim Anbieterprospekt, sondern beim Use Case. Beschreiben Sie in wenigen Sätzen, welche Aufgabe das System übernehmen soll, welche Personen es nutzen und welches Ergebnis erwartet wird. Ein allgemeines Ziel wie „Produktivität mit KI steigern“ reicht dafür nicht.

Besser ist beispielsweise: Das Vertriebsteam soll lange Ausschreibungsunterlagen zusammenfassen und daraus einen ersten Fragenkatalog erstellen. Oder: Der Kundenservice soll Antwortentwürfe auf Basis freigegebener Wissensartikel erhalten.

Ein klarer Zweck hilft später bei fast allen weiteren Entscheidungen. Nur wenn bekannt ist, wofür das Tool genutzt wird, lässt sich beurteilen, welche Daten erforderlich sind, welche Fehler relevant werden und welche menschliche Kontrolle sinnvoll ist. Gleichzeitig verhindert ein definierter Anwendungsbereich, dass aus einem begrenzten Pilot unbemerkt ein Werkzeug für völlig andere Aufgaben wird.

  • Zweck und Zielgruppe schriftlich festhalten.
  • Erlaubte und nicht vorgesehene Anwendungen benennen.
  • Verantwortliche Fachabteilung bestimmen.
  • Erfolgskriterien und relevante Fehlerarten definieren.

2. Welche Daten werden eingegeben, erzeugt und gespeichert?

Die Frage „Ist das Tool DSGVO-konform?“ ist für einen Einkaufsprozess zu pauschal. Entscheidend ist, welche Daten im konkreten Szenario verarbeitet werden und unter welchen Bedingungen. Ein Tool für öffentliche Marketingtexte hat ein anderes Datenprofil als ein Assistent, der Lebensläufe, Kundenakten oder interne Verträge verarbeitet.

Erfassen Sie deshalb Eingaben, Ausgaben und Metadaten. Prüfen Sie, ob Prompts oder hochgeladene Dateien gespeichert werden, wie lange sie verfügbar bleiben, ob Inhalte für Training oder Produktverbesserung verwendet werden können und welche Konfigurationen der Anbieter bereitstellt. Klären Sie außerdem, wo Daten verarbeitet werden und welche vertraglichen Regelungen für den konkreten Einsatz erforderlich sind.

Aus Governance-Sicht ist wichtig, diese Erkenntnisse in eine verständliche Nutzungsregel zu übersetzen. Mitarbeitende brauchen keine Vertragsanalyse im Schulungsmodul. Sie müssen wissen, welche Daten sie in genau dieses System eingeben dürfen und welche nicht.

3. Welche Rolle hat das Unternehmen im Sinne des EU AI Act?

Der EU AI Act unterscheidet unter anderem Anbieter und Betreiber von KI-Systemen. Wer eine fertige Anwendung intern nutzt, befindet sich typischerweise in einer anderen Rolle als ein Unternehmen, das ein System unter eigenem Namen auf den Markt bringt oder wesentlich verändert. Die konkrete Einordnung hängt vom jeweiligen Sachverhalt ab und sollte nicht allein aus der Produktbezeichnung abgeleitet werden.

Diese Rollenfrage ist wichtig, weil Pflichten im AI Act an unterschiedliche Akteure adressiert sind. Bei der Beschaffung sollte deshalb dokumentiert werden, wer das System bereitstellt, wie es eingesetzt wird und ob geplante Anpassungen die eigene Rolle verändern könnten.

Auch die Risikokategorie darf nicht nur nach dem Marketingnamen beurteilt werden. Derselbe technische Baustein kann in unterschiedlichen Einsatzkontexten unterschiedliche regulatorische Fragen auslösen. Der AI Act arbeitet bewusst risikobasiert. Für Unternehmen ist daher der tatsächliche Zweck wichtiger als das Etikett „Copilot“ oder „Assistent“.

4. Kann das Tool nur Inhalte erzeugen – oder auch handeln?

Ein Textgenerator mit reinem Entwurfsmodus hat einen anderen Handlungsspielraum als ein System, das E-Mails versendet, Datensätze verändert, Tickets schließt oder Bestellungen auslöst. Beim Einkauf sollte deshalb sichtbar sein, welche Integrationen und Berechtigungen heute und künftig vorgesehen sind.

Vergeben Sie möglichst nur Rechte, die für den definierten Zweck benötigt werden. Prüfen Sie, ob Lese- und Schreibrechte getrennt werden können, ob technische Identitäten sauber verwaltet werden und ob Zugänge schnell widerrufbar sind. Ein Tool muss nicht deshalb Zugriff auf ein komplettes Postfach oder Laufwerk erhalten, weil die Integration technisch bequem ist.

Für agentische Funktionen gilt zusätzlich: Eine Modellanweisung ist keine robuste Zugriffskontrolle. Grenzen für besonders folgenreiche Aktionen sollten nach Möglichkeit technisch und prozessual abgesichert werden.

5. Wo ist menschliche Kontrolle wirklich notwendig?

Human Oversight sollte nicht als pauschales „Ein Mensch schaut irgendwann drauf“ verstanden werden. Definieren Sie, welche Ergebnisse oder Aktionen vor ihrer Nutzung geprüft werden müssen, welche Informationen die prüfende Person dafür sieht und welche Befugnis sie hat, eine Aktion zu stoppen.

Artikel 26 des EU AI Act enthält für Betreiber von Hochrisiko-KI-Systemen konkrete Pflichten zur menschlichen Aufsicht: Sie müssen geeignete technische und organisatorische Maßnahmen treffen und die Aufsicht Personen zuweisen, die über notwendige Kompetenz, Schulung, Befugnis und Unterstützung verfügen. Viele heute eingesetzte generative Standardtools sind nicht allein deshalb Hochrisiko-Systeme. Das Prinzip ist dennoch eine nützliche Governance-Frage: Eine Freigabe funktioniert nur, wenn die zuständige Person versteht, was sie prüfen soll und tatsächlich eingreifen kann.

Ordnen Sie deshalb Fehler nach ihren Folgen. Ein interner Brainstorming-Entwurf braucht meist eine andere Kontrolle als eine externe Aussage, eine Personalentscheidung oder eine irreversible Systemaktion.

6. Wie wird Qualität vor dem Rollout getestet?

Eine überzeugende Produktdemo ist kein belastbarer Test für den eigenen Arbeitsalltag. Erstellen Sie vor dem Rollout eine kleine Sammlung realer Aufgaben und definieren Sie, woran ein akzeptables Ergebnis erkannt wird. Testen Sie nicht nur ideale Beispiele, sondern auch unvollständige, widersprüchliche oder ungewöhnliche Eingaben.

Bei generativer KI gehören erfundene Fakten, falsch zugeordnete Quellen und übermäßig selbstsichere Antworten zu den Fehlerbildern, auf die Anwender vorbereitet sein sollten. Bei integrierten oder agentischen Systemen kommen Prozessfehler hinzu: falsche Empfänger, doppelte Aktionen, ungeeignete Werkzeugaufrufe oder manipulative Inhalte aus externen Quellen.

Dokumentieren Sie dabei nicht nur eine Gesamtquote. Für den Betrieb ist entscheidend, welche Fehler auftreten, wie gut sie erkannt werden und was im Fehlerfall passiert. Ein System, das bei Unsicherheit zuverlässig eskaliert, kann für einen Prozess geeigneter sein als eines, das häufiger eine Antwort liefert, aber kritische Fehler verdeckt.

7. Welche Transparenzpflichten können den Einsatz betreffen?

Seit 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 des EU AI Act. Sie betreffen unter anderem bestimmte direkte Interaktionen mit KI, maschinenlesbare Kennzeichnung synthetischer Inhalte sowie Offenlegungspflichten bei Deepfakes und bestimmten veröffentlichten Texten. Welche Pflicht greift, hängt von Rolle und Nutzungsszenario ab.

Für den Einkauf bedeutet das: Prüfen Sie, ob das Produkt Funktionen bereitstellt, die für den vorgesehenen Transparenzprozess benötigt werden. Bei einem Kundenbot kann relevant sein, wie ein KI-Hinweis umgesetzt wird. Bei generativen Medienwerkzeugen ist zu klären, welche technischen Herkunftsmarkierungen das System unterstützt.

Vermeiden Sie zugleich die Gegenreaktion „Alles mit KI muss immer sichtbar gekennzeichnet werden“. Der AI Act unterscheidet konkrete Fälle. Ein guter Beschaffungsprozess hält fest, welcher Fall vorliegt und wer für die Umsetzung verantwortlich ist.

8. Wie lässt sich der Anbieterwechsel oder das Abschalten organisieren?

KI-Governance endet nicht beim Go-live. Unternehmen sollten schon vor dem Kauf wissen, wie Daten exportiert oder gelöscht, Zugänge widerrufen und Integrationen getrennt werden können. Das ist besonders wichtig, wenn ein Tool tief in Arbeitsabläufe eingebaut wird.

Fragen Sie deshalb nach Exit-Möglichkeiten und administrativen Kontrollen. Wer kann Nutzer sperren? Wie werden API-Schlüssel rotiert? Was passiert mit gespeicherten Inhalten nach Vertragsende? Können Funktionen zentral deaktiviert werden? Welche Abhängigkeiten entstehen durch proprietäre Workflows oder Wissensspeicher?

Ein praktikabler Exit-Plan schützt nicht nur bei einem Anbieterwechsel. Er hilft auch bei Sicherheitsvorfällen oder wenn ein Pilot fachlich nicht die erwartete Qualität erreicht.

9. Was müssen Mitarbeitende vor der Nutzung lernen?

Hier verbindet sich Beschaffung direkt mit Artikel 4. Ein neues Tool verändert den Nutzungskontext – und damit möglicherweise den notwendigen Kompetenzaufbau. Ein allgemeiner KI-Grundlagenkurs kann weiterhin sinnvoll sein, reicht aber nicht automatisch für jede Anwendung.

Leiten Sie aus dem Tool-Profil konkrete Lernziele ab:

  • Welche Aufgaben darf das System übernehmen?
  • Welche Daten dürfen Anwender eingeben?
  • Welche typischen Fehler müssen sie erkennen?
  • Wann müssen Fakten oder Quellen geprüft werden?
  • Welche Ergebnisse brauchen eine Freigabe?
  • Welche Funktionen oder Integrationen sind ausdrücklich nicht vorgesehen?
  • An wen wird bei Unsicherheit oder einem Vorfall eskaliert?

Die Europäische Kommission betont, dass Artikel 4 den Nutzungskontext, technisches Wissen, Erfahrung, Ausbildung und Schulung berücksichtigt. Sie schreibt kein bestimmtes Zertifikat und kein identisches Kompetenzniveau für jede Person vor. Für den Einkauf ist das eine Chance: Schulung lässt sich gezielt an System und Rolle ausrichten, statt erst nach dem Rollout eine allgemeine Pflichtfolie nachzuschieben.

10. Wer entscheidet über Änderungen nach dem Go-live?

KI-Produkte verändern sich schnell. Anbieter ergänzen Modelle, Funktionen, Konnektoren und Automatisierungen. Gleichzeitig entwickeln Fachbereiche neue Nutzungsweisen. Ein einmaliger Einkaufscheck kann deshalb veralten.

Definieren Sie einen Change-Prozess: Welche Änderungen müssen erneut geprüft werden? Wer bewertet neue Integrationen? Wann ist ein erneuter Test nötig? Wann müssen Nutzungsregeln oder Schulungsinhalte aktualisiert werden? Besonders relevant sind Änderungen an Datenquellen, Berechtigungen, automatisierten Aktionen und der Rolle menschlicher Freigaben.

Ein einfacher Trigger-Katalog hilft: neues Modell, neuer Datenzugriff, neue externe Kommunikation, neue autonome Aktion, neue Zielgruppe oder neuer Einsatz in einem sensiblen Prozess. Nicht jede kleine Produktänderung braucht ein großes Gremium. Aber wesentliche Änderungen sollten einen benannten Verantwortlichen erreichen.

Eine schlanke KI-Einkaufscheckliste für die Praxis

Für viele Unternehmen lässt sich der Prozess auf eine Seite verdichten. Vor Freigabe eines neuen KI-Tools sollten Fachbereich, IT, Informationssicherheit, Datenschutz und – je nach Fall – weitere zuständige Funktionen gemeinsam beantworten können:

  • Ist der konkrete Use Case beschrieben und verantwortet?
  • Sind Datenarten, Speicher- und Verarbeitungswege geklärt?
  • Sind Anbieter-/Betreiberrolle und relevante Risikofragen eingeordnet?
  • Sind Berechtigungen auf das notwendige Maß begrenzt?
  • Sind menschliche Freigaben für folgenreiche Ergebnisse definiert?
  • Wurde mit realistischen Fehlerfällen getestet?
  • Sind relevante Transparenzanforderungen berücksichtigt?
  • Existieren Abschalt-, Widerrufs- und Exit-Möglichkeiten?
  • Sind rollenbezogene Lernziele und Nutzungsregeln vorbereitet?
  • Gibt es einen Verantwortlichen für spätere wesentliche Änderungen?

Diese Liste ist bewusst kein universelles Compliance-Siegel. Sie schafft einen nachvollziehbaren Ausgangspunkt, an dem Fachlichkeit, Technik und Kompetenz zusammenkommen. Je sensibler der Einsatz, desto tiefer müssen einzelne Prüfungen gehen.

Fazit: Gute KI-Governance beginnt vor dem ersten Login

Viele Probleme beim KI-Einsatz entstehen nicht, weil Mitarbeitende grundsätzlich unvorsichtig sind, sondern weil wichtige Entscheidungen beim Rollout offenbleiben. Wenn niemand klar festlegt, welche Daten erlaubt sind, welche Ergebnisse geprüft werden und welche Rechte ein Tool benötigt, kann auch eine spätere Schulung diese Lücken nur begrenzt ausgleichen.

Der bessere Ansatz verbindet Beschaffung und Befähigung: Use Case definieren, Daten und Rechte prüfen, Kontrollen testen, Verantwortlichkeiten festlegen und anschließend genau die Menschen schulen, die mit dem System arbeiten oder es beaufsichtigen.

LimaBravo AI MasteryKI-Kompetenz strukturiert aufbauen.
Praxisnahe AI Literacy mit Rollenbezug, Wissenschecks und nachvollziehbaren Lernmaßnahmen für Unternehmen.
AI Mastery ansehen
← Alle Beiträge