Teilweise. Bisher hat keine KI, mit der ich gearbeitet habe, Vergaberecht vollständig verstanden. Bei längeren Fragestellungen und auslegungswürdigen Aspekten treten z.B. Konfabulationen auf.
Empfohlener Lernweg:
– Laden Sie offen verfügbare Einführungen in das Vergaberecht sowie die UfAB 2018 in NotebookLM hoch. Das Tool kann bei der strukturierten Aufarbeitung helfen.
– Besuchen Sie qualifizierte Schulungen, etwa die DVNW-Schulung zum Vergabespezialisten oder die Seminare von Prof. Dr. Einmahl zur aktuellen Rechtsprechung.
– Treten Sie einem aktiven Vergabe-Forum bei.
– Lernen Sie am konkreten Projekt – idealerweise mit erfahrener Unterstützung.

Das ist nicht dasselbe. Eine KI-Vergabe liegt vor, wenn die künstliche Intelligenz selbst der Hauptgegenstand der Beschaffung ist – etwa Entwicklung, Training oder Bereitstellung eines KI-Modells. Hier spielen Datenbasis, Lernverhalten, Nachvollziehbarkeit, Fairness und Nachtraining eine zentrale Rolle. Die Anforderungen sind offener, das Ergebnis unsicherer, und es empfiehlt sich meist ein flexibles Verfahren (z.B. Verhandlungsverfahren). Eine IT-Vergabe mit KI-Anteilen bedeutet, dass di KI nur eine Teilfunktion darstellt – etwa ein Modul in einem bestehenden IT-System. Hier stehen Integration, Schnittstellen, Betrieb und IT-Sicherheit im Vordergrund, die KI-Aspekte sind ergänzend zu berücksichtigen. Für die Praxis: In KI-Vergaben sollten Sie stärker auf Konzeptqualität, Trainingsdaten, Nachvollziehbarkeit, Tests und Anpassungsfähigkeit achten; in IT-Vergaben mit KI-Anteilen dagegen auf klassische IT-Kriterien wie Stabilität, Performance und Wartbarkeit. Weiterführende Informationen finden Sie z.B. auf Vergabeblog und der Webseite der WeCon.

Nutzen Sie interne oder externe Expertise. In jeder Organisation gibt es KI-interessierte Personen – auch außerhalb der IT. Prüfen Sie, ob eine verwandte Organisation punktuell helfen kann, oder holen Sie externe Unterstützung.
Führen Sie eine gründliche Markterkundung durch. Entwickeln Sie objektive Tests und bewerten Sie die Ergebnisse – das ist auch ohne tiefes KI-Verständnis möglich. Konzentrieren Sie sich auf Output-Qualität und messbare Kriterien (Genauigkeit, Geschwindigkeit). Führen Sie bei Unklarheiten Aufklärungsgespräche, um Begriffe erklären zu lassen.
Sie müssen KI nicht selbst entwickeln können, um ihre Leistung zu vergleichen – Sie brauchen definierte Maßstäbe und ggf. punktuelle Unterstützung von Spezialisten.

Eine Risikoanalyse ist nicht in allen Fällen rechtlich verpflichtend, wird aber dringend empfohlen. Sie ermöglicht es, frühzeitig technische, rechtliche und organisatorische Risiken zu erkennen – etwa Bias, Sicherheitslücken, Datenfehler oder Anbieterabhängigkeiten – und entsprechende Maßnahmen einzuplanen. Sobald die KI personenbezogene Daten verarbeitet und ein erhöhtes Risiko für die Rechte und Freiheiten Betroffener besteht, ist nach Art. 35 DSGVO eine Datenschutzfolgeabschätzung verpflichtend. Diese sollte bereits in der Planungs- und Vergabephase berücksichtigt werden, damit technische und vertragliche Schutzmaßnahmen (z.B. Privacy by Design, Zugriffsbeschränkungen) von Beginn an integriert werden können.

Der EU AI Act (KI-Verordnung) legt einen europaweit verbindlichen Rechtsrahmen für den Einsatz von KI fest. Er ordnet KI-Systeme in Risikoklassen ein (z.B. inakzeptables, hohes, begrenztes oder minimales Risiko) und definiert für jede Klasse unterschiedliche Pflichten – etwa zu Dokumentation, Transparenz, Qualitätsmanagement, Konformitätsbewertung und menschlicher Aufsicht.
Auftraggeber sollten bereits in der Planungs- und Markterkundungsphase prüfen, in welche Risikoklasse das gewünschte System fällt, und daraus konkrete Anforderungen für Ausschreibung und Vertrag ableiten. Die KI-Verordnung beeinflusst somit mittelbar die Leistungsbeschreibung, Eignungs- und Zuschlagskriterien sowie die vertraglichen Pflichten zur Compliance und Nachweisführung.
Zeitlicher Hinweis: Die Verordnung ist seit 1. August 2024 in Kraft. Für neue Hochrisiko-KI-Systeme gelten die Anforderungen nach Ankündigung des Omnibus-Pakets vermutlich ab Mitte 2027. Für bereits im Verkehr befindliche Hochrisiko-Systeme gelten teilweise längere Übergangsfristen. Einige Verbote für unzulässige KI-Praktiken (etwa biometrische Echtzeit-Fernidentifizierung im öffentlichen Raum) gelten bereits heute. Bei aktuellen Vergabeverfahren sollte dies berücksichtigt und vertraglich vorgesorgt werden.

Aus vergaberechtlicher Sicht bestehen keine eigenen Pflichten für Anbieter oder Betreiber – entscheidend ist, was vertraglich geregelt wurde. Die KI-Verordnung (EU AI Act) ergänzt dies jedoch durch spezifische Rollen und Verantwortlichkeiten.
Die Person oder das Unternehmen, die oder das ein KI-System erstmals in Verkehr bringt oder in Betrieb nimmt – typischerweise der Auftragnehmer oder Hersteller – ist der Anbieter (Provider) und somit verantwortlich für:
Konformität des Systems mit den Anforderungen des EU AI Act
Risikomanagement, technische Dokumentation, Datenqualität
Transparenz, menschliche Aufsicht
Ggf. Konformitätsbewertung.
Diese umfassenden Pflichten gelten insbesondere für Hochrisiko-KI-Systeme (Anhang III AI Act), für andere Risikokategorien gelten deutlich geringere Anforderungen.
Die Person oder Einrichtung, die ein KI-System im eigenen Verantwortungsbereich anwendet oder betreibt ist der Betreiber (Deployer) – im öffentlichen Sektor meist der Auftraggeber. Der Betreiber ist verantwortlich für:
– Rechtmäßigen Einsatz
– Einhaltung von Nutzungsbeschränkungen
– Überwachung der Systemleistung
– Ergreifen von Korrekturmaßnahmen bei Risiken oder Fehlentscheidungen.
Hinweis: Wenn öffentliche Stellen selbst Hochrisiko-KI-Systeme entwickeln oder wesentlich modifizieren, können sie auch als Anbieter gelten (Art. 28 AI Act) und tragen dann beide Verantwortungsbereiche.
Regeln Sie,dass der Bieter seine Pflichten als Provider erfüllt (z.B. durch Konformitätserklärung, technische Dokumentation und Nachweise), während der Betreiber sicherstellt, dass das System gemäß Zweckbestimmung und Compliance-Vorgaben eingesetzt wird.
Zeitlicher Hinweis: Die Verordnung ist seit 1. August 2024 in Kraft. Für neue Hochrisiko-KI-Systeme gelten die Anforderungen nach Ankündigung des Omnibus-Pakets vermutlich ab Mitte 2027. Für bereits im Verkehr befindliche Hochrisiko-Systeme gelten teilweise längere Übergangsfristen. Einige Verbote für unzulässige KI-Praktiken (etwa biometrische Echtzeit-Fernidentifizierung im öffentlichen Raum) gelten bereits heute. Bei aktuellen Vergabeverfahren sollte dies berücksichtigt und vertraglich vorgesorgt werden.

Anforderungen an KI sollten funktional und überprüfbar beschrieben werden. Beschreiben Sie, was die KI leisten soll (z.B. automatische Texterkennung, Musteranalyse), nicht, wie sie es technisch umsetzt. Ergänzen Sie (messbare) Qualitätskriterien wie Genauigkeit, Erklärbarkeit oder Reaktionszeit. Legen Sie fest, welche Datenquellen verwendet werden dürfen und wer ihre Qualität verantwortet. Fordern Sie standardisierte Schnittstellen (z.B. REST, JSON, ONNX) für spätere Erweiterbarkeit. Berücksichtigen Sie den laufenden Betrieb – Monitoring, Nachtraining und Performancekontrolle. Unterscheiden Sie klar zwischen Muss-Anforderungen (Pflicht, z.B. Datenschutz, Mindestgenauigkeit) und Soll-Anforderungen (wünschenswert, z.B. verbesserte Erklärbarkeit).

Ja, beides ist zulässig.
Wer On-Premises will, verlangt dies. Wer Cloud will, verlangt dies. Eine klare Positionierung ist rechtlich zulässig und praktisch sinnvoll.
Ansätze, On-Premises und Cloud durch Kosten-Nutzen-Bewertung zu vergleichen (etwa durch eigene Kriterien oder Nebenangebote), erfordern erheblichen Aufwand und detaillierte Annahmen zu Betriebskosten, Skalierung und technischer Entwicklung über die gesamte Vertragslaufzeit. Unsicherheiten in der Prognose können die Vergleichbarkeit erschweren. Einen fairen und verlässlichen Vergleich solcher Varianten ohne signifikante Komplexität und Risiken durchzuführen, ist anspruchsvoller als es zunächst erscheint.

Ja, das ist zulässig. Die Leistungsbeschreibung sollte eindeutig formulieren, dass die Lösung lokal betrieben werden muss. Allerdings schränkt dies den Kreis potenzieller Anbieter ein und kann Kosten sowie Wartungsaufwand erhöhen. Eine Abwägung zwischen Sicherheit, Wirtschaftlichkeit, Zukunftsfähigkeit und Marktverfügbarkeit ist daher erforderlich.

Sie sollten bereits in den Unterlagen klarstellen, ob KI-Anteile verpflichtend, erwünscht, optional oder unerwünscht sind.
Wenn Sie keine KI wollen (z.B. eine rein deterministische Lösung bevorzugen), formulieren Sie dies als Anforderung: „Die Lösung darf keine Machine-Learning-Komponenten einsetzen.“ Entsprechende Angebote sind dann auszuschließen. Das ist eine restriktive Forderung, die dazu führen kann, dass Sie keine oder nur veraltete Angebote erhalten. Viele moderne IT-Lösungen integrieren zunehmend KI-Komponenten (z.B. KI-gestützte Geräuschunterdrückung, Spam-Filter, Bildoptimierung), sodass ein vollständiger Ausschluss von KI die Auswahl erheblich einschränken kann.
Ein besserer Ansatz wäre: Bewerten Sie KI-Aspekte in der Qualität, ggf. per hilfsweiser Bewertung. Wenn ein Bieter KI nutzt und das sein Angebot verbessert, erhält er mehr Punkte in der Qualität.
Entscheiden Sie vorab, ob KI-Einsatz zulässig sein soll, und gestalten Sie die Ausschreibung entsprechend. Ein Ausschluss ist nur möglich, wenn die Unterlagen dies hergeben.

Ja, auch Open-Source-KI-Modelle oder frei verfügbare Large Language Models (LLMs) können im Rahmen einer Ausschreibung beschafft werden. Zu prüfende Aspekte sind hierbei:
– Prüfen Sie sorgfältig, ob die Lizenzen mit Ihren Anforderungen (z.B. Weitergaberechte, Haftung, Gewährleistung) vereinbar sind.
– Klären Sie, wer Support, Wartung, Updates und Sicherheitspatches übernimmt – häufig werden ergänzende kommerzielle Dienstleistungen oder Serviceverträge benötigt.
– Prüfen Sie Nutzungsarten und Datenverarbeitung in Drittländern, auch in Verbindung mit Lizenzbedingungen.
– Klären Sie, welche Anforderungen hinsichtlich Sicherheit und Compliance erfüllt werden müssen.
Open Source bedeutet nicht automatisch Offenheit oder Nachhaltigkeit – entscheidend sind auch Rechtssicherheit, Wartbarkeit und verantwortlicher Betrieb.

Aus rein vergaberechtlicher Sicht gibt es keine allgemeine Pflicht zur vollständigen Erklärbarkeit jedes Algorithmus. Hier kommt die KI-Verordnung zum Zug. Auftraggeber sollten verlangen, dass Anbieter Mechanismen zur Nachvollziehbarkeit bereitstellen – etwa in der GUI, durch Berichte, Visualisierungen oder Audit-Module. Damit können Entscheidungen überprüft und Risiken (z.B. Diskriminierung, Fehlentscheidungen) reduziert werden. Ziel ist es wenigstens, dass Ergebnisse plausibel begründet und nachvollziehbar dokumentiert werden können.

Sie können Fairness und Nichtdiskriminierung in Leistungsbeschreibung und Zuschlagskriterien adressieren.
In der Leistungsbeschreibung können Sie z.B. formulieren: „Das System darf keine unzulässige Diskriminierung aufgrund von Geschlecht, Ethnie, Religion, Alter oder anderen geschützten Merkmalen vornehmen.“
In den Zuschlagskriterien können Sie die Konzepte bewerten, die der Bieter zum Thema „Fairness/Chancengleichheit“ einreicht. Wichtig ist eine transparente Bewertungsmethodik.
Im Vertrag können Sie Prüf- und Testrechte vereinbaren. Beispielsweise kann festgelegt werden, dass der Auftraggeber Stichprobentests durchführen darf und bei festgestellter systematischer Diskriminierung eine Nachbesserungspflicht besteht.
Rechtlich verbindlichen Standard-Metriken gibt es bisher nicht. Forschungsmetriken (z.B. Disparate Impact, Equal Opportunity Difference) können Orientierung bieten, sind aber in Vergabeverfahren noch nicht etabliert. Empfehlenswert ist eine Kombination aus klaren qualitativen Kriterien und laufendem Monitoring im Betrieb.
Wichtig: Auch gute vertragliche Vorkehrungen verhindern nicht, dass lernende Systeme im Betrieb neue Verzerrungen entwickeln. Eine laufende Kontrolle und Feedbackschleife sind daher unverzichtbar.

Bereits in der Leistungsbeschreibung sollte eindeutig festgelegt werden, mit welchen Datenformaten, Schnittstellen, Standards oder Vorgaben das KI-System kompatibel sein muss. Dazu gehören z.B. XÖV-Standards, OZG-konforme Datenmodelle oder behördenspezifische Datenstrukturen.
Anbieter können vertraglich verpflichtet werden, bei Änderungen dieser Vorgaben rechtzeitig Anpassungen vorzunehmen, sofern dies technisch zumutbar ist. Vereinbaren Sie regelmäßige oder anlassbezogene Tests, um sicherzustellen, dass das System dauerhaft funktionsfähig bleibt. Diese Anforderungen sollten auch Nachweis- und Mitwirkungspflichten regeln.

Datenschutzanforderungen sollten – wie bei IT-Ausschreibungen allgemein – bereits in den Vergabeunterlagen und Vertragsbedingungen eindeutig geregelt werden. Dazu gehören insbesondere Vorgaben zu Zweckbindung, Datenminimierung, Speicherort, Aufbewahrungsfristen und Löschkonzepten. Ergänzend sollten Nachweispflichten des Auftragnehmers (z.B. durch technische und organisatorische Maßnahmen nach Art. 32 DSGVO) sowie Kontroll- und Auditrechte der Vergabestelle vereinbart werden. Bei Cloud- oder KI-Diensten ist außerdem festzulegen, ob und in welchen Drittländern Daten verarbeitet werden dürfen. So wird sichergestellt, dass der Anbieter seine datenschutzrechtlichen Pflichten transparent erfüllt und der Auftraggeber seiner Rechenschaftspflicht nachkommen kann.

Diese Frage ist komplex – eine qualifizierte Vertrags- und IT-Rechtsberatung ist hier ratsam.
Unterscheiden Sie zwischen Haupt- und Nebenfunktionen der Lösung und deren Kommunikationswegen. Für Kernfunktionen sollten Sie entsprechende Datenschutzanforderungen definieren (sofern der Markt dies hergibt). Für Nebenfunktionen oder spezielle Funktionen können Ausnahmen notwendig sein. Solche Umstände lassen sich über dedizierte B-Kriterien bewerten. Achten Sie darauf, Ihre Grundanforderungen nicht zu konterkarieren.
Hinweis: Digitale Souveränität bedeutet nicht, ausschließlich deutsche IT zu beschaffen.

Sie können vertraglich fordern, dass der Auftragnehmer Quellcode offenlegt. Ob dies durchsetzbar ist, hängt von der Art der Software ab:
Individualentwicklungen: Quellcode-Übergabe ist üblich und oft Vertragsstandard.
Standardsoftware: Quellcode-Übergabe ist selten – außer bei Open Source. Als Kompromiss wird häufig eine Escrow-Lösung vereinbart (Treuhand-Hinterlegung mit Zugriff z.B. im Krisenfall).
KI-Systeme: Neben Quellcode sind auch Modellparameter, Trainingsdaten und Know-how für eine Weiterentwicklung erforderlich.
Quellcode-Offenlegung kann Transparenz, Auditierbarkeit oder langfristige Unabhängigkeit sicherstellen. Sie verhindert jedoch keinen Lock-in per se, da Betrieb und Weiterentwicklung erhebliches Fachwissen und Ressourcen erfordern.
Fazit: Ja, Sie dürfen es fordern, aber nicht jeder Anbieter wird bereit sein. Prüfen Sie vorab den Markt und erwägen Sie, ob Escrow oder andere Sicherungsmechanismen geeigneter sind.

Eignungskriterien beziehen sich nach vergaberechtlichen Vorgaben auf die Eignung des Unternehmens, nicht auf das Produkt selbst. Fachlich hilfreiche Kriterien sind Referenzen zu vergleichbaren Projekten, Nachweis von Fachpersonal mit KI-Expertise, Erfahrungen im Umgang mit sensiblen Daten oder Zertifizierungen, falls der entsprechende Markt dies hergibt (z.B. ISO 42001). Wichtig bei Eignungsleihe: Achten Sie darauf, dass Zertifizierungen und Kompetenzen tatsächlich das Unternehmen betreffen, das später den Auftrag oder Auftragsteil ausführt oder betreibt. So stellen Sie sicher, dass die geforderte Eignung tatsächlich gegeben ist.

Bei der Bewertung von KI-Angeboten sollten neben dem Preis qualitative Zuschlagskriterien berücksichtigt werden. Dazu zählen insbesondere:
– Die Genauigkeit und Robustheit des KI-Systems
– Die Nachvollziehbarkeit und Erklärbarkeit der Ergebnisse (Explainable AI)
– Die Qualität des Supports und der Schulungsangebote für Anwender
– Die Integrationsfähigkeit in bestehende IT-Systeme
– Das Datenmanagement und Sicherheitskonzepte
– Die Compliance-Konzepte
– Die Kontinuität der Weiterentwicklung.
Alle Kriterien müssen bewertbar und transparent formuliert sowie angemessen gewichtet werden, damit qualitative Unterschiede zwischen KI-Lösungen nachvollziehbar in die Wertung einfließen können.

Der Bieter bleibt für den Inhalt seines Angebots verantwortlich, unabhängig davon, ob es manuell oder mithilfe von KI erstellt wurde. Maßgeblich ist, dass das Angebot vollständig, zutreffend und prüfbar ist. Wenn die KI fehlerhafte Angaben erzeugt hat, trägt der Bieter das Risiko und haftet für die Richtigkeit.
Vergabestellen sollten pragmatisch vorgehen: Solange das Angebot die formalen und inhaltlichen Anforderungen erfüllt, besteht kein Anlass, es wegen der KI-Nutzung auszuschließen. Kritisch wird es, wenn inhaltliche Widersprüche, Unklarheiten oder falsche Leistungszusagen auftreten. Dann kann eine Aufklärung oder Nachforderung erforderlich sein.
Für künftige Verfahren können Sie in den Vergabeunterlagen klarstellen, dass Bieter KI-gestützte Inhalte kennzeichnen oder die Verantwortung für KI-erstellte Angebotsbestandteile ausdrücklich übernehmen müssen.
Bei dauerhaften Bedenken empfiehlt sich die Einführung hoch gewichteter bewertender Teststellungen und die Bewertung von Interviews (z.B. mit Schlüsselpersonal).

Wird im Vergabeverfahren eine KI zur Unterstützung der Angebotsbewertung eingesetzt, gelten dieselben Grundsätze wie bei einer manuellen Bewertung. Die Bewertungsmethodik muss für Bieter nachvollziehbar, transparent und dokumentiert sein. Der Einsatz der KI sollte in den Vergabeunterlagen beschrieben werden, insbesondere, welche Aufgaben sie übernimmt (z.B. Textanalyse, Plausibilitätsprüfung) und wie ihre Ergebnisse in die Entscheidungsfindung einfließen.
Die finale Bewertung und Zuschlagsentscheidung müssen stets durch Menschen verantwortet und geprüft werden. So bleiben Nachvollziehbarkeit, Gleichbehandlung und rechtliche Überprüfbarkeit des Verfahrens gewahrt und der KI-Einsatz wird als unterstützendes Werkzeug, nicht als Entscheidungsinstanz, klar abgegrenzt.

Unterscheiden Sie zwischen Tests im Vergabeverfahren und Test- bzw. Pilotphasen nach Zuschlag. Tests während der Vergabe dienen der Bewertung oder Verifizierung von Angeboten – etwa durch Vergleichstests oder Demonstrationen. Testphasen nach Zuschlag, z.B. Pilotphasen, sind Teil der Vertragsdurchführung und können zur Abnahme oder Anpassung des Systems genutzt werden. In beiden Fällen sollten Ziel, Ablauf, Bewertungsmaßstäbe, sowie Verantwortlichkeiten beschrieben werden.

Das kann passieren – insbesondere bei neuen oder komplexen Anforderungen, fehlender Markterkundung oder ungeeigneter Verfahrenswahl.
Optionen vor Ablauf der Angebotsfrist:
Durch Bieterfragen können Sie eine solche Situation frühzeitig erkennen und Gegenmaßnahmen ergreifen. Nutzen Sie diese Möglichkeit. Nicht jede Bieterfrage zielt auf Manipulation ab.
Optionen nach Ablauf der Angebotsfrist:
Prüfen Sie, ob Sie bei der Auswertung zu streng waren oder ob die Anforderungen auslegungsfähig waren.
Prüfen Sie, zu welchem Zeitpunkt die Anforderungserfüllung gefordert ist.
Bei Verfahren ohne Verhandlungen: Vergabeverfahren aufheben wegen fehlender geeigneter Angebote (wenn z.B. alle Angebote unvollständig oder unvertretbar sind). Dann: Neu konzipieren, Prämissen hinterfragen und den Markt erkunden.
Bei Verfahren mit Verhandlungen: Prüfen Sie anhand der gewonnenen Informationen, welche Optionen Ihnen noch offenstehen. Anforderungen anzupassen ist hier nicht unüblich. Kriterien anzupassen kann erhebliche Risiken mit sich bringen.
Fazit: Wahren Sie Ihre Flexibilität durch den richtigen Ansatz bei Leistungsbeschreibung und Kriterien. Notfalls: Aufhebung und Neukonzeption.

Verträge sollten regeln, ob, wann und in welchem Umfang Updates oder Anpassungen am KI-System vorgenommen werden dürfen. Dabei ist zwischen technischen Sicherheits- und Wartungsupdates, die in der Regel verpflichtend und ohne neue Abnahme zulässig sind, und Funktions- oder Leistungsupdates, die eine erneute Prüfung oder Freigabe durch den Auftraggeber erfordern können, zu unterscheiden– insbesondere, wenn sie das Verhalten des Systems verändern.
Für lernende oder selbstoptimierende KI-Systeme wirdein strukturierter Prozess empfohlen – entweder durch periodisches Retraining unter Aufsicht oder durch vertragliche Vorgaben, wie neue oder geänderte Fähigkeiten dokumentiert, getestet und freigegeben werden müssen. Nach der EU-KI-Verordnung bleibt der Betreiber verpflichtet, die Systemleistung kontinuierlich zu überwachen und sicherzustellen, dass das System nach Updates weiterhin konform und risikofrei arbeitet. Daher sollten Wartungs-, Update- und Lernprozesse in der Leistungsbeschreibung und im Vertrag Nachweis- und Freigabepflichten enthalten.

Ob der Auftragnehmer bei neuen gesetzlichen Regelungen kostenlos anpassen muss, hängt ausschließlich von der vertraglichen Vereinbarung ab. Gewährleistung bezieht sich auf Mängel zum Zeitpunkt der Abnahme und deckt keine neuen rechtlichen Anforderungen ab – es sei denn, dies wurde vertraglich vereinbart, durch z.B.:
Eine Compliance-Klausel: „Der Auftragnehmer gewährleistet, dass die Lösung während der Vertragslaufzeit den jeweils geltenden regulatorischen Anforderungen entspricht.“
Eine Kooperationsklausel: „Auftraggeber und Auftragnehmer verpflichten sich, bei regulatorischen Änderungen zusammenzuarbeiten und eine faire Lösung für erforderliche Anpassungen (einschließlich Kosten) zu finden.“
Kleinere Änderungen (z.B. Nachreichen von Konformitätsdokumenten, kleinere Software-Anpassungen) können im Rahmen eines Wartungs- oder Pflegevertrags enthalten sein. Größere Änderungen (z.B. grundlegende Neuentwicklungen oder Architekturänderungen) sind nicht automatisch kostenfrei. Hier sollte ein Mechanismus vereinbart werden, etwa über ein Change-Request-Verfahren oder eine Nachtragsvergütung.
Empfehlung: Ziehen Sie bei der Vertragsgestaltung eine qualifizierte Vertrags- oder IT-Rechtsberatung hinzu.

Ohne vertragliche Absicherung gibt es kein automatisches Recht auf Nachbesserung bei Model Drift. Ob Sie den Auftragnehmer verpflichten können, eine schlechter werdende KI nachzubessern, hängt von den vertraglichen Vereinbarungen ab.
Ein Mangel liegt nur vor, wenn eine konkrete Leistungszusage (z.B. „mindestens 90 % Genauigkeit“) im Vertrag dauerhaft garantiert wurde und diese nicht mehr erreicht wird. Ohne solche Zusage gilt die Abnahme als Erfüllung. Ein späteres Nachlassen der Modellqualität ist kein klassischer Gewährleistungsfall.
Leistungsabfall durch veränderte Daten oder Kontextverschiebungen ist ein bekanntes Phänomen im KI-Betrieb. Es fällt nicht automatisch unter Gewährleistung. Vertraglich sollten Pflege- oder Wartungspflichten geregelt sein:
Regelmäßiges Monitoring
Nachtraining mit neuen Daten
Performance-Tuning oder Aktualisierungen.
Ohne solche Regelungen gibt es keinen Anspruch auf kostenlose Nachbesserung. In vielen Fällen hängt es vom Goodwill des Anbieters ab.
Meine Empfehlung ist: Regeln Sie in künftigen Verträgen, wie mit Model Drift umzugehen ist (Schwellenwerte, Monitoring, Retraining, Kostenregelung).

Eine vollständige Vermeidung diskriminierender Entscheidungen durch KI-Systeme ist praktisch nicht möglich. Auftraggeber können jedoch risikomindernde Maßnahmen vorschreiben.
Nehmen Sie in der Leistungsbeschreibung Anforderungen an Fairness, Transparenz und Bias-Prüfung auf. Verpflichten Sie die Bieter:
Testverfahren zur Diskriminierungsfreiheit nachzuweisen (bisher kaum standardisiert)
Trainingsdaten oder Auditberichte offenzulegen
Unabhängige Prüfungen zuzulassen.
Ein kontinuierliches Monitoring der KI-Ergebnisse im laufenden Betrieb ist auch erforderlich, um systematische Verzerrungen frühzeitig zu erkennen. Entscheidungen mit Personenbezug sollten stets durch Menschen überprüft oder bestätigt werden.

Ein vollständiger Ausschluss ist in der Praxis kaum möglich, aber Abhängigkeiten lassen sich reduzieren. Maßnahmen zur Lock-in-Vermeidung können sein:
Bereitstellungsart beachten: Achten Sie auf Ihre Wahl (On-Premises, Cloud), die Architektur und die damit einhergehenden Abhängigkeiten.
Offene Standards fordern: Fordern Sie verbreitete Schnittstellenstandards (z.B. REST, OpenAPI, ONNX), um Daten und Modelle bei Bedarf exportieren oder anbinden zu können.
Datenexport sichern: „Das Modell muss seine Daten in einem gängigen Format (z.B. ONNX für neuronale Netze) bereitstellen können.“
Nutzungsrechte sichern: Sichern Sie sich dauerhafte Nutzungsrechte an Modell und Daten, sodass ein anderer Dienstleister übernehmen könnte. Beachten Sie: Was während der Vertragslaufzeit nicht in Ihren eigenen Rechenzentren lief, wird nicht ohne Weiteres übertragbar sein.
Kompetenzen aufbauen: Lassen Sie Personal nicht nur schulen, sondern ausbilden, sodass Sie entsprechende Kompetenzen im Haus haben. Dann kann notfalls intern überbrückt werden und Sie sprechen mit Dienstleistern auf Augenhöhe.
Modulare Architekturen: Bevorzugen Sie getrennte Daten-, Modell- und Anwendungsschichten, um Komponenten austauschbar zu halten. Prüfen Sie bei Erweiterungen, ob modulares Andocken anderer Auftragnehmer möglich ist.
Bewertungskriterium: Bewerten Sie „Vermeidung von Lock-in“ als Zuschlagskriterium. Bieter mit Open-Source-Komponenten und tiefgehender Dokumentation können als wirtschaftlicher eingestuft werden als solche mit proprietärer Blackbox. Beachten Sie jedoch:
Open Source bedeutet nicht automatisch: frei verfügbar, gut dokumentiert, aktiv gewartet oder rechtlich unbedenklich nutzbar. Prüfen Sie stets die konkrete Lizenz, die Community-Aktivität und die Governance-Struktur des Projekts.
Eine Open-Source-Lösung mit nur einem Hobby-Entwickler birgt Weiterentwicklungsrisiken.
Escrow-Lösungen: Treuhand-Hinterlegung aller Softwarebestandteile inklusive Quellcode, Trainingsdaten etc.. mit Zugriff z.B. im Krisenfall.
Übergabepflichten: Sie können vereinbaren, dass der Auftragnehmer im Falle eines Anbieterwechsels aktiv bei der Übergabe mitwirkt, erforderliche Dokumentationen, Werkzeuge und Daten bereitstellt – mit geregeltem Aufwand und Kosten. Das hilft manchmal, ist aber kein Allheilmittel und ggf. kostspielig.
Datenrechte: Sichern Sie sich Nutzungs-, Zugriffs- und Verfügungsrechte an allen relevanten Daten (Trainings-, Nutzungs- und Ausgabedaten) für ein mögliches Retraining oder einen Anbieterwechsel.
Eine vollständige Unabhängigkeit ist bei KI-Systemen kaum erreichbar. Wer jedoch auf offene Standards, klare Datenrechte, interne Kompetenz und vertraglich geregelte Übergabepflichten setzt, kann Lock-in-Risiken reduzieren.