Der Markt für KI-Tools ist unübersichtlich geworden. Neue Anbieter erscheinen im Wochentakt, etablierte Softwarehäuser ergänzen ihre Produkte um KI-Funktionen, und Start-ups versprechen spektakuläre Effizienzgewinne. Für ein mittelständisches Unternehmen im DACH-Raum ist es kaum möglich, diesen Markt vollständig zu überblicken. Umso größer ist die Versuchung, sich von einer eindrucksvollen Produktdemo, einem günstigen Einstiegspreis oder der Empfehlung eines Bekannten leiten zu lassen. Beides führt regelmäßig zu Fehlentscheidungen – nicht weil das Werkzeug schlecht wäre, sondern weil es nicht zum konkreten Bedarf, zur Datenlage oder zum Sicherheitsniveau des Unternehmens passt.
Eine strukturierte Anbieterauswahl übersetzt diese Komplexität in einen wiederholbaren Prozess. Sie beginnt nicht bei den Anbietern, sondern beim eigenen Bedarf, macht die Bewertung anhand definierter Kriterien vergleichbar und dokumentiert, warum eine Entscheidung so und nicht anders getroffen wurde. Das schützt vor Fehlkäufen, schafft aber auch Nachvollziehbarkeit gegenüber Geschäftsführung, Datenschutz, Betriebsrat und – im Rahmen von KI-Governance und EU AI Act – gegenüber Aufsicht und Auditoren.
Aus unserer Beratungspraxis kehren dieselben Muster immer wieder: Erstens die Feature-Faszination – ein Werkzeug wird wegen einer beeindruckenden Funktion gekauft, die im Alltag kaum gebraucht wird, während zentrale Anforderungen unbeachtet bleiben. Zweitens der Datenschutz-Blindflug – KI-Dienste werden eingeführt, ohne zu klären, wohin die eingegebenen Daten fließen und ob sie zum Training des Anbieters verwendet werden. Drittens die Schatten-Beschaffung – Fachbereiche schließen eigenständig Abos ab, ohne IT, Datenschutz oder Einkauf einzubinden, sodass eine unkontrollierte Landschaft entsteht (siehe auch Shadow AI). Und viertens der Lock-in aus Versehen – ein Anbieter wird so tief integriert, dass ein späterer Wechsel praktisch unmöglich oder unbezahlbar wird.
Diese Fehler haben eine gemeinsame Wurzel: Sie entstehen, wo eine Entscheidung getroffen wird, bevor die richtigen Fragen gestellt wurden. Eine strukturierte Auswahl kehrt die Reihenfolge um – sie stellt sicher, dass Funktion, Datenschutz, Sicherheit, Kommerzialität und Ausstiegsfähigkeit gemeinsam bewertet werden, bevor ein Vertrag unterschrieben wird.
Eine belastbare Anbieterauswahl erfüllt vier Aufgaben zugleich. Sie stellt Passung sicher, also die Übereinstimmung zwischen Werkzeug und tatsächlichem Bedarf. Sie sichert Compliance, indem sie Datenschutz und regulatorische Anforderungen früh prüft, statt sie nachzuschieben. Sie schafft Vergleichbarkeit, weil unterschiedliche Anbieter anhand derselben Maßstäbe bewertet werden. Und sie erzeugt Nachvollziehbarkeit – eine dokumentierte Entscheidungsgrundlage, die auch Monate später erklärt, warum diese Wahl richtig war. Die folgenden Kapitel behandeln jeden dieser Aspekte im Detail, beginnend mit dem Fundament: der Anforderungsdefinition.
Der häufigste Grund für gescheiterte KI-Einführungen ist nicht ein schwaches Produkt, sondern eine unklare Anforderung. „Wir wollen etwas mit KI machen“ ist kein Use Case, sondern ein Wunsch. Ein tragfähiger Anwendungsfall benennt konkret, welche Aufgabe unterstützt oder automatisiert werden soll, wer damit arbeitet, welche Daten dabei verarbeitet werden und woran der Erfolg gemessen wird. Erst wenn dieser Rahmen steht, lässt sich beurteilen, ob ein Anbieter passt – und ob überhaupt ein KI-Werkzeug die richtige Antwort ist oder ob eine klassische Softwarelösung genügt.
Bewährt hat sich, Anforderungen in zwei Klassen zu trennen. Muss-Kriterien sind nicht verhandelbar – etwa die Verarbeitung personenbezogener Daten in einer EU-Region, die Anbindung an ein bestehendes System oder eine bestimmte Verfügbarkeit. Erfüllt ein Anbieter ein Muss-Kriterium nicht, scheidet er unabhängig von allen anderen Stärken aus. Soll- und Kann-Kriterien sind wünschenswert, aber gewichtbar; sie fließen in die spätere Bewertung ein, ohne allein den Ausschlag zu geben. Diese Trennung verhindert, dass ein glänzendes Nice-to-have eine fehlende Grundanforderung überstrahlt.
Für die Anforderungsliste empfiehlt es sich, mehrere Dimensionen bewusst abzufragen: die fachliche Funktion (was das Werkzeug können muss), die Datenanforderung (welche Daten mit welchem Schutzbedarf verarbeitet werden), die Integrationsanforderung (welche Systeme angebunden werden müssen), die Nutzergruppe (wie viele Personen mit welchem Kenntnisstand) sowie nichtfunktionale Anforderungen wie Verfügbarkeit, Sprachunterstützung, Barrierefreiheit und Antwortzeiten. Ein guter Test für die Qualität einer Anforderung ist die Frage: Könnte ein Außenstehender damit objektiv prüfen, ob ein Anbieter sie erfüllt?
Der Use-Case-Fit beschreibt, wie gut ein Werkzeug den konkreten Anwendungsfall trifft – nicht in der Theorie, sondern im realen Arbeitskontext. Ein generatives Textwerkzeug kann brillant Marketingtexte formulieren und dennoch für die Analyse strukturierter Vertragsdaten ungeeignet sein. Entscheidend ist deshalb, den Anwendungsfall so nah wie möglich an der Realität zu prüfen: mit echten (gegebenenfalls anonymisierten) Beispieldaten, im vorgesehenen Prozess und mit den Menschen, die später damit arbeiten. Ein häufig unterschätzter Aspekt ist dabei die Datenreife: Viele KI-Anwendungen entfalten ihren Nutzen nur, wenn die zugrunde liegenden Daten in ausreichender Qualität und Struktur vorliegen. Fehlt diese Grundlage, hilft auch der beste Anbieter nicht.
Bevor konkrete Anbieter verglichen werden, lohnt eine grundsätzliche Weichenstellung. Buy bedeutet, ein fertiges KI-Produkt einzukaufen – schnell, planbar, aber mit begrenzter Individualisierbarkeit. Build heißt, eine eigene Lösung zu entwickeln oder ein Basismodell selbst zu betreiben – maximale Kontrolle, aber hoher Aufwand und Bedarf an interner Kompetenz. Partner steht für die Zusammenarbeit mit einem Dienstleister, der eine passgenaue Lösung auf Basis vorhandener Modelle baut und betreibt. Für die meisten Mittelständler ist „Buy“ oder „Partner“ der realistische Weg; „Build“ bleibt Sonderfällen mit klarem strategischem Differenzierungsbedarf vorbehalten. Diese Grundsatzentscheidung prägt die gesamte spätere Anbieterauswahl und sollte deshalb bewusst und dokumentiert getroffen werden.
In der Praxis werden Funktion und Qualität oft vermengt – zu Unrecht. Die Funktion beantwortet die Frage „Kann das Werkzeug es grundsätzlich?“, die Qualität die Frage „Tut es das verlässlich genug für unseren Zweck?“. Ein Werkzeug kann funktional alles bieten und dennoch inkonsistente oder fehleranfällige Ergebnisse liefern. Gerade bei generativer KI ist die Qualität kein feststehender Wert, sondern hängt vom Anwendungsfall, den Eingabedaten und der Bedienung ab. Deshalb lässt sich Qualität seriös nur mit eigenen Testreihen im echten Kontext beurteilen – nicht anhand von Marketingversprechen. Wo Fehlausgaben oder Halluzinationen kritische Folgen hätten, gehört die menschliche Kontrolle fest in den Prozess, unabhängig davon, wie überzeugend ein Anbieter auftritt.
Support und Roadmap werden bei der Auswahl regelmäßig zu niedrig gewichtet – und rächen sich später. Ein Werkzeug, das im Betrieb Fragen aufwirft, ohne dass qualifizierte Hilfe erreichbar ist, frisst still Produktivität. Und ein Anbieter ohne erkennbare Produktstrategie oder mit fragiler wirtschaftlicher Lage kann von einem Tag auf den anderen ein Werkzeug einstellen, das zum festen Bestandteil der Arbeit geworden ist. Prüfen Sie deshalb bewusst, in welcher Sprache und mit welchen Reaktionszeiten der Support arbeitet, wie transparent die Weiterentwicklung kommuniziert wird und wie stabil der Anbieter wirtschaftlich aufgestellt ist. Referenzkunden aus einem vergleichbaren Umfeld liefern hier oft aussagekräftigere Hinweise als jede Selbstauskunft.
Sobald ein KI-Dienst personenbezogene Daten verarbeitet, gelten die Anforderungen der DSGVO – unabhängig davon, wie leistungsfähig oder günstig das Werkzeug ist. Für die Anbieterauswahl bedeutet das: Bestimmte Datenschutzfragen müssen früh und verbindlich geklärt werden, bevor eine engere Auswahl überhaupt sinnvoll ist. Andernfalls droht der teuerste Fall der Beschaffung – ein Werkzeug, das nach Einführung wieder abgeschaltet werden muss, weil es datenschutzrechtlich nicht tragfähig ist.
Ein zentrales Prüffeld ist der Serverstandort: Wo werden die Daten gespeichert und verarbeitet? Viele KI-Anbieter betreiben ihre Infrastruktur global; nicht wenige haben ihren Hauptsitz außerhalb der EU. Wird ein Anbieter außerhalb der EU eingesetzt oder werden Daten in Drittländer übertragen, stellt sich die Frage nach einer zulässigen Grundlage für den Datentransfer und nach zusätzlichen Schutzmaßnahmen. Die datenschutzrechtliche Bewertung solcher Drittlandtransfers ist komplex und im Einzelfall mit einer Fachjurist:in oder dem oder der Datenschutzbeauftragten zu klären.
Als in der Regel datenschutzfreundlichere Optionen bieten viele Anbieter inzwischen eine EU-Region an – also die Zusicherung, Daten ausschließlich in Rechenzentren innerhalb der EU zu verarbeiten. Wo verfügbar, reduziert das die Komplexität der Transferprüfung erheblich. Für Anwendungsfälle mit besonders hohem Schutzbedarf kann darüber hinaus Self-Hosting oder der Betrieb in einer souveränen bzw. privaten Cloud die weitreichendste Kontrolle bieten: Die Daten verlassen die eigene kontrollierte Umgebung nicht. Dieser Weg erfordert allerdings mehr interne Kompetenz und Ressourcen und ist nicht für jedes Werkzeug verfügbar. Welcher Weg im konkreten Fall angemessen und zulässig ist, hängt von der Datenkategorie, dem Schutzbedarf und der rechtlichen Bewertung ab.
Wird ein KI-Anbieter mit der Verarbeitung personenbezogener Daten beauftragt, ist regelmäßig ein Auftragsverarbeitungsvertrag (AVV) erforderlich. Prüfen Sie frühzeitig, ob der Anbieter einen belastbaren AVV bereitstellt und ob dessen Inhalt zu Ihren Anforderungen passt – etwa hinsichtlich der Weisungsgebundenheit, der technischen und organisatorischen Maßnahmen und der Regelungen zur Rückgabe und Löschung von Daten. Ein besonders wichtiger und oft übersehener Punkt sind die Subunternehmer: KI-Dienste stützen sich häufig auf weitere Anbieter, etwa für Rechenkapazität oder Basismodelle. Diese Kette sollte transparent sein, denn jeder eingebundene Subunternehmer erweitert den Kreis der Stellen, die potenziell mit den Daten in Berührung kommen. Ein Anbieter, der seine Subunternehmer nicht offenlegt, ist ein Warnsignal.
Ein weiterer, für KI spezifischer Punkt ist die Frage nach dem Training mit Kundendaten: Werden die eingegebenen Daten zur Weiterentwicklung der Modelle des Anbieters verwendet? Für viele Unternehmen ist das ein Ausschlusskriterium, insbesondere bei vertraulichen oder personenbezogenen Inhalten. Seriöse Anbieter machen hierzu klare, vertraglich abgesicherte Aussagen und bieten – wo relevant – ein Opt-out oder eine Zusicherung, Geschäftskundendaten grundsätzlich nicht zum Training zu nutzen.
Vendor Lock-in bezeichnet den Zustand, in dem ein Unternehmen so stark von einem Anbieter abhängig ist, dass ein Wechsel nur mit erheblichem Aufwand, hohen Kosten oder Funktionsverlust möglich wäre. Bei KI-Werkzeugen ist diese Gefahr besonders ausgeprägt, weil Abhängigkeit auf mehreren Ebenen zugleich entstehen kann: bei den Daten, bei den Integrationen, bei den Arbeitsabläufen und beim spezifischen Verhalten des jeweiligen Modells. Ein Lock-in ist nicht per se schlecht – eine tiefe Integration kann große Effizienzgewinne bringen. Problematisch wird er erst, wenn er unbewusst entsteht und keine Ausstiegsoption mehr besteht.
Um Lock-in bewerten zu können, hilft es, die typischen Abhängigkeitsquellen zu kennen. Datenbindung entsteht, wenn Inhalte, Konfigurationen oder trainierte Anpassungen in einem proprietären Format vorliegen und sich nicht sauber exportieren lassen. Integrationsbindung entsteht, wenn ein Werkzeug tief mit anderen Systemen verknüpft ist und jede Schnittstelle einzeln nachgebaut werden müsste. Prozessbindung entsteht, wenn ganze Arbeitsabläufe auf die Eigenheiten eines Werkzeugs zugeschnitten wurden. Und Modellbindung ist eine KI-spezifische Form: Prompts, Feinabstimmungen und Erfahrungswerte, die für ein bestimmtes Modell optimiert wurden, lassen sich nicht ohne Weiteres auf ein anderes übertragen.
Eine Exit-Strategie klingt paradox, solange ein Werkzeug noch gar nicht eingeführt ist – ist aber genau dann am wirksamsten. Wer vor dem Vertragsabschluss klärt, wie ein späterer Ausstieg funktionieren würde, verhandelt aus einer Position der Stärke. Die zentralen Fragen lauten: Lassen sich alle relevanten Daten in einem nutzbaren Format exportieren? Wie lange dauert eine Migration realistisch, und was kostet sie? Gibt es alternative Anbieter, auf die gewechselt werden könnte? Und wie ist die Datenrückgabe und -löschung nach Vertragsende geregelt? Für kritische Werkzeuge empfiehlt sich zudem, bewusst auf eine gewisse Anbieter-Neutralität zu achten – etwa durch Architekturen, die das zugrunde liegende Modell austauschbar halten. Das mag kurzfristig etwas mehr Aufwand bedeuten, sichert aber die langfristige Handlungsfähigkeit.
Die Sicherheit eines KI-Anbieters lässt sich von außen nur begrenzt beurteilen. Genau deshalb haben sich anerkannte Zertifikate und Prüfberichte etabliert: Sie bestätigen, dass eine unabhängige Stelle die Sicherheitsvorkehrungen eines Anbieters nach definierten Maßstäben geprüft hat. Für die Anbieterauswahl sind sie ein wichtiges Kriterium – allerdings eines, das man richtig lesen muss. Ein Zertifikat ist kein Freibrief, sondern ein Beleg dafür, dass bestimmte Prozesse zu einem bestimmten Zeitpunkt einem bestimmten Standard entsprachen.
Die ISO/IEC 27001 ist die international etablierte Norm für Informationssicherheits-Managementsysteme. Ein zertifizierter Anbieter hat nachgewiesen, dass er ein systematisches Managementsystem für Informationssicherheit betreibt – mit Rollen, Richtlinien, Risikobetrachtung und kontinuierlicher Verbesserung. Das sagt viel über die organisatorische Reife aus, macht aber keine Aussage über die Qualität eines einzelnen KI-Ergebnisses. SOC 2 ist ein vor allem im nordamerikanischen Raum verbreiteter Prüfungsstandard, der die Kontrollen eines Dienstleisters entlang von Kriterien wie Sicherheit, Verfügbarkeit und Vertraulichkeit betrachtet. Wichtig ist die Unterscheidung: Ein SOC-2-Bericht, der einen Zeitraum betrachtet, ist aussagekräftiger als eine reine Momentaufnahme. Für KI-spezifische Managementaspekte gewinnt zusätzlich die ISO/IEC 42001 an Bedeutung – die Norm für KI-Managementsysteme.
Ein häufiger Fehler ist, ein Zertifikat als bloßes Häkchen zu behandeln. Entscheidend ist der Geltungsbereich: Ein Zertifikat kann sich auf einzelne Rechenzentren oder Produktteile beschränken, während das konkret genutzte Werkzeug gar nicht erfasst ist. Ebenso wichtig sind Aktualität und Gültigkeitszeitraum sowie die Frage, welche unabhängige Stelle geprüft hat. Seriöse Anbieter stellen entsprechende Nachweise in einem Trust-Center oder auf Anfrage bereit; Zurückhaltung an dieser Stelle ist ein Warnzeichen. Für die Auswahl gilt: Zertifikate sind ein wertvolles Signal und in vielen Fällen ein Muss-Kriterium – aber sie ersetzen nicht die eigene Prüfung, ob der Anbieter zum konkreten Schutzbedarf passt.
Neben den klassischen Sicherheitsfragen bringt KI eigene Risiken mit, die bei der Anbieterbewertung mitgedacht werden sollten. Dazu zählen etwa Angriffe über manipulierte Eingaben (Prompt Injection), das ungewollte Preisgeben vertraulicher Informationen über die Ausgaben eines Modells oder die Manipulation von Trainingsdaten. Ein reifer KI-Anbieter kann darlegen, wie er mit solchen Risiken umgeht – etwa durch Eingabefilter, klare Trennung von Kundendaten und ein Vorgehen zum Umgang mit Sicherheitsvorfällen. Wo diese Fragen nur ausweichend beantwortet werden, ist Vorsicht geboten.
KI-Werkzeuge werden nach sehr unterschiedlichen Modellen abgerechnet, und die Unterschiede sind für die Wirtschaftlichkeit entscheidend. Manche Anbieter berechnen einen festen Preis pro Nutzer und Monat, andere rechnen nach Verbrauch ab – etwa nach der Menge verarbeiteter Anfragen oder Textbausteine. Wieder andere kombinieren beides oder staffeln den Preis nach Funktionsumfang. Gerade verbrauchsbasierte Modelle sind tückisch: Sie wirken im Einstieg günstig, können bei intensiver Nutzung aber schnell und schwer kalkulierbar teuer werden. Für eine seriöse Bewertung ist es deshalb unerlässlich, das Lizenzmodell zu verstehen und die erwartete Nutzung realistisch zu schätzen.
Für die Praxis lohnt es sich, die gängigen Modelle bewusst zu unterscheiden und ihre jeweiligen Chancen und Risiken zu kennen. Das Pro-Nutzer-Modell ist einfach zu kalkulieren, kann aber teuer werden, wenn viele Personen nur gelegentlich zugreifen. Das verbrauchsbasierte Modell skaliert mit dem tatsächlichen Nutzen, verlangt aber ein wachsames Kostencontrolling. Das Enterprise- oder Plattformmodell bündelt Funktionen in Paketen und eignet sich für breite Einführungen, bindet aber oft an längere Laufzeiten. Wichtig ist außerdem, versteckte Kostentreiber zu erkennen: Zusatzmodule, Premium-Support, Kosten für zusätzliche Integrationen oder Gebühren für Datenexport können die Rechnung erheblich verändern.
Die Total Cost of Ownership (TCO) betrachtet die Gesamtkosten eines Werkzeugs über seine gesamte Nutzungsdauer – nicht nur die Lizenzgebühr. Dazu gehören die einmaligen Kosten für Einführung, Integration und Datenaufbereitung, die laufenden Lizenz- und Verbrauchskosten, die Aufwände für Schulung und Change-Management, die internen Betriebskosten sowie die oft übersehenen Kosten eines möglichen späteren Wechsels. Ein Werkzeug mit niedriger Lizenzgebühr, das aber aufwendige Integration, intensive Schulung und ein hohes Wechselrisiko mit sich bringt, kann in der TCO teurer sein als eine auf den ersten Blick teurere, aber reibungslos einsetzbare Alternative.
Die TCO-Betrachtung ist eng mit der Frage des Nutzens verbunden. Eine kommerzielle Bewertung, die nur die Kosten betrachtet, ist unvollständig – entscheidend ist das Verhältnis von Kosten und erwartetem Wertbeitrag. Eine strukturierte Nutzenbetrachtung im Rahmen eines Business Case hilft, teure Werkzeuge zu rechtfertigen, die einen entsprechend hohen Nutzen stiften, und günstige Werkzeuge zu hinterfragen, die kaum etwas bewegen. Wichtig ist dabei ein realistischer, herstellerneutraler Blick: Von Anbietern in Aussicht gestellte Effizienzgewinne sind Annahmen, keine garantierten Ergebnisse, und sollten am eigenen Anwendungsfall überprüft werden.
Der Reiz eines strukturierten Prozesses liegt nicht in der Bürokratie, sondern in der Reihenfolge: Er sorgt dafür, dass die richtigen Fragen im richtigen Moment gestellt werden. Aus einer breiten Longlist wird über Ausschlusskriterien eine überschaubare Shortlist; die verbleibenden Anbieter werden in einem Proof of Concept praktisch erprobt und schließlich anhand einer gewichteten Scorecard verglichen. Am Ende steht eine dokumentierte Entscheidung, die auch später erklärbar bleibt.
Der Proof of Concept ist das Herzstück eines seriösen Auswahlprozesses, weil er die Lücke zwischen Versprechen und Wirklichkeit schließt. Eine Produktdemo zeigt, was ein Werkzeug im günstigsten Fall kann; ein PoC zeigt, was es im konkreten Kontext des Unternehmens tatsächlich leistet. Damit ein PoC aussagekräftig ist, braucht er drei Dinge: realistische Daten statt geschönter Beispiele, klare Erfolgskriterien, die vorab definiert werden, und die Beteiligung der späteren Nutzer:innen. Wichtig ist auch der Datenschutz: Werden im PoC echte personenbezogene Daten verwendet, gelten dieselben Anforderungen wie im Produktivbetrieb – häufig empfiehlt sich die Arbeit mit anonymisierten oder synthetischen Daten.
Eine Scorecard übersetzt die Bewertung in vergleichbare Werte. Ihr Nutzen steht und fällt mit zwei Prinzipien. Erstens die vorab festgelegte Gewichtung: Welche Kriterien wie stark zählen, wird definiert, bevor die Anbieter bewertet werden – sonst entsteht die Versuchung, die Gewichte nachträglich zum gewünschten Ergebnis passend zu machen. Zweitens die Ehrlichkeit über Unsicherheit: Nicht jedes Kriterium lässt sich präzise messen. Eine Scorecard erzeugt Vergleichbarkeit, aber keine mathematische Wahrheit – sie ist eine Entscheidungshilfe, kein Ersatz für Urteilsvermögen. Gerade bei knappen Ergebnissen sollten qualitative Erwägungen wie Zukunftsfähigkeit und Vertrauen bewusst mitgewogen werden.
Was in der Auswahl geprüft wurde, muss im Vertrag verankert sein – sonst bleibt es ein Versprechen ohne Verbindlichkeit. Der Vertrag ist der Moment, in dem aus Zusagen des Vertriebs belastbare Pflichten werden: zu Verfügbarkeit und Support, zum Umgang mit Daten, zur Vertragsbeendigung und zunehmend auch zu regulatorischen Nachweisen. Für den Mittelstand ist es wichtig, dass Fachbereich, IT, Datenschutz, Einkauf und – bei größeren Vorhaben – die Rechtsabteilung oder eine Fachjurist:in gemeinsam auf den Vertrag schauen.
Ein Service Level Agreement (SLA) regelt die zugesagte Dienstqualität – insbesondere Verfügbarkeit, Reaktions- und Wiederherstellungszeiten sowie die Folgen bei Nichteinhaltung. Wichtig ist, ein SLA nicht nur auf die zugesagte Verfügbarkeit zu reduzieren, sondern genau zu lesen: Wie wird die Verfügbarkeit gemessen, was gilt als Ausfall, welche Zeiten sind davon ausgenommen, und welche Konsequenzen hat eine Verletzung tatsächlich? Ein SLA mit hoher zugesagter Verfügbarkeit, aber ohne spürbare Folgen bei Nichteinhaltung, ist wenig wert. Ebenso relevant ist der Support: In welcher Sprache, zu welchen Zeiten und mit welchen Reaktionszeiten wird geholfen, und sind qualifizierte Ansprechpartner:innen erreichbar?
Mit dem EU AI Act gewinnt die vertragliche Absicherung regulatorischer Aspekte an Bedeutung. Für Unternehmen, die KI-Werkzeuge einsetzen, ist besonders die Rolle als Betreiber relevant: Wer ein KI-System in eigener beruflicher Verantwortung nutzt, hat je nach Risikoeinordnung eigene Pflichten – etwa die Nutzung gemäß den Anbieter-Vorgaben und die Sicherstellung menschlicher Aufsicht. Handelt es sich um ein Hochrisiko-System, sind zudem umfangreiche Anbieterpflichten zu beachten, deren Erfüllung sich der Betreiber vertraglich zusichern und belegen lassen sollte. Sinnvoll ist deshalb, im Vertrag zu regeln, welche Informationen und Nachweise der Anbieter zur Verfügung stellt, wie mit Änderungen am System umgegangen wird und wer bei regulatorischen Anforderungen welche Rolle übernimmt. Welche Pflichten im konkreten Fall greifen und wie sie vertraglich abzubilden sind, ist eine Frage des Einzelfalls und mit einer Fachjurist:in zu klären.
