KI beschaffen: Ein Anforderungskatalog für private und öffentliche Auftraggeber

Bedarf und Einsatzgrenzen vor dem Markt festlegen

Vor der Produktauswahl muss der Auftraggeber beschreiben, welches Problem gelöst werden soll, welche Entscheidungen das System beeinflusst und welche Personen betroffen sind. Zu erfassen sind Datenarten, Nutzergruppen, Schnittstellen, menschliche Eingriffe und denkbare Fehlfolgen. Diese Festlegung verhindert, dass eine eindrucksvolle Demonstration den Bedarf nachträglich definiert oder ein ursprünglich enger Pilot unkontrolliert in sensible Prozesse wandert.

Die Vorprüfung sollte verbotene Praktiken, eine mögliche Hochrisikoeinstufung und Transparenzpflichten getrennt behandeln. Ein Branchenetikett genügt nicht; Zweckbestimmung und Einsatzmodalitäten sind entscheidend. Zugleich bleiben Datenschutz, Gleichbehandlung, Arbeitsrecht, Barrierefreiheit, Informationssicherheit und Sektorregeln relevant. Das Ergebnis ist kein endgültiges Rechtsgutachten, sondern ein belastbarer Rahmen für Leistungsbeschreibung, Auswahl, Tests, Vertrag und spätere Freigabe.

• Geschäftszweck und Nichtziele beschreiben
• Betroffene Personen und Fehlfolgen erfassen
• Rechts- und Risikoprüfungen als getrennte Arbeitspakete planen

Quellen: [3]

Muss-, Soll- und Nachweiskriterien trennen

Muss-Kriterien bezeichnen nicht verhandelbare Eigenschaften, etwa verbotene Datenverwendungen, notwendige Zugriffskontrollen oder definierte Exportfunktionen. Soll-Kriterien ermöglichen eine gewichtete Qualitätsbewertung. Nachweiskriterien legen fest, wodurch eine Behauptung belegt wird: technische Dokumentation, Testbericht, Zertifikat mit klarem Geltungsbereich, Demonstration oder vertragliche Zusage. Diese Trennung macht Angebote vergleichbar und reduziert Interpretationsspielräume nach Zuschlag oder Bestellung.

Der Katalog sollte Datenherkunft, Leistungsgrenzen, Genauigkeit, Robustheit, Protokollierung, menschliche Aufsicht, Sicherheit, Barrierefreiheit und Änderungsmanagement abdecken. Werte wie „hohe Genauigkeit“ sind ohne Messmethode, Datensatz und Akzeptanzschwelle unbrauchbar. Auch Anforderungen an Versionierung, Benachrichtigung, Rückfallbetrieb und Exit gehören früh hinein. Nicht jede Beschaffung benötigt dieselbe Tiefe; Umfang und Evidenz sollten dem konkreten Risiko entsprechen.

• Kriterien als Muss, Soll oder Information kennzeichnen
• Für jede Zusage einen akzeptierten Nachweistyp nennen
• Messmethode und Abnahmeschwelle vorab definieren

Quellen: [3] [4]

Anbieterbehauptungen durch Tests ersetzen

Selbstauskünfte sind ein Startpunkt, keine Abnahme. Der Auftraggeber sollte repräsentative Testfälle, bekannte Grenzfälle und missbräuchliche Eingaben einsetzen. Leistungstests müssen zum eigenen Prozess passen und dürfen nicht ausschließlich auf vom Anbieter ausgewählten Beispielen beruhen. Bei personennahen Entscheidungen sind unterschiedliche Gruppen, Fehlerverteilungen und Möglichkeiten menschlicher Korrektur besonders sorgfältig zu untersuchen und zu dokumentieren.

Eine Teststrategie benennt Datensätze, Verantwortliche, Erfolgskriterien und den Umgang mit Abweichungen. Sie unterscheidet Pilot, fachliche Abnahme, Sicherheitsprüfung und Produktionsfreigabe. Ein erfolgreicher Pilot mit wenigen Nutzern beweist weder Skalierbarkeit noch dauerhafte Eignung. Änderungen an Modell, Datenquelle oder zentraler Konfiguration müssen deshalb neue Tests oder mindestens eine dokumentierte Auswirkungsprüfung auslösen.

• Eigene repräsentative und missbräuchliche Testfälle verwenden
• Pilot und Produktionsabnahme nicht gleichsetzen
• Re-Tests bei wesentlichen Änderungen vereinbaren

Quellen: [3] [4]

Vertragsrechte für den Betrieb sichern

Die Leistungsbeschreibung muss in durchsetzbare Vertragspflichten übersetzt werden. Dazu gehören dokumentierte Versionen, vereinbarte Servicequalität, Sicherheitsmaßnahmen, Vorfallmeldungen, Unterauftragnehmerkontrolle, Auditnachweise und Unterstützung bei Betroffenenrechten. Änderungsrechte des Anbieters benötigen Grenzen, Vorlauf und gegebenenfalls Widerspruchs- oder Kündigungsrechte. Ohne solche Mechanismen kann eine sorgfältig geprüfte Lösung nach einem Update wesentlich anders funktionieren.

Der Vertrag sollte Verantwortung nicht nur abstrakt verteilen, sondern konkrete Mitwirkungspflichten festlegen. Benötigt der Betreiber Anleitungen, Protokolle oder technische Informationen, müssen Format und Zeitpunkt bestimmt sein. Haftungsregelungen, Freistellungen und Versicherungen sind risikobasiert zu verhandeln, geben aber keine Gewähr für regelkonformen Betrieb. Zusätzlich braucht der Auftraggeber eigene Kontrollen, qualifizierte Nutzer und einen Prozess für Stopp, Korrektur und Wiederfreigabe.

• Dokumentation und Betreiberunterstützung konkretisieren
• Änderungen, Vorfälle und Subprozessoren regelbar machen
• Exit, Datenrückgabe und Löschung vertraglich absichern

Quellen: [3] [4]

Öffentliche Beschaffung wettbewerbsoffen gestalten

Öffentliche Auftraggeber müssen Anforderungen mit dem Auftragsgegenstand verbinden und transparent, verhältnismäßig sowie gleichbehandelnd anwenden. Technische Spezifikationen können leistungs- oder funktionsbezogen formuliert werden. Verweise auf eine bestimmte Herstellung, Herkunft, Marke, ein Patent oder einen Typ sind nur unter den gesetzlichen Voraussetzungen zulässig und grundsätzlich mit „oder gleichwertig“ zu versehen. Eignungs-, Auswahl- und Zuschlagskriterien sind sauber zu unterscheiden; Nachweise und Bewertungsmethoden müssen in den Unterlagen nachvollziehbar angekündigt werden.

KI Anforderungen dürfen anspruchsvoll sein, müssen aber prüfbar und sachlich begründet bleiben. Ein pauschales Verlangen nach proprietären Zertifikaten kann Wettbewerb unnötig beschränken, wenn gleichwertige Nachweise möglich sind. Umgekehrt darf die Sorge vor Komplexität nicht zu reinen Preisentscheidungen führen. Lebenszykluskosten, Datenmigration, menschliche Kontrolle, Schulungsaufwand und Anbieterwechsel können wirtschaftlich entscheidend sein und sollten rechtzeitig in Bewertung und Vertragsmodell einfließen.

• Vergabe- und Leistungskriterien eindeutig zuordnen
• Funktional und produktneutral formulieren
• Gleichwertige Nachweise sowie Lebenszykluskosten berücksichtigen

Quellen: [1] [2]

Fristen realistisch in die Roadmap übersetzen

Der AI Act ist am Stichtag in geänderter Fassung maßgeblich. Die zentralen Hochrisikoanforderungen für Systeme nach Anhang III gelten grundsätzlich ab 2. Dezember 2027, für produktbezogene Systeme nach Anhang I ab 2. August 2028. Diese Verschiebung bedeutet nicht, dass Verbote, Transparenzpflichten, Datenschutz oder andere anwendbare Regeln ruhen. Jede Beschaffung braucht eine nach Pflichtenbereichen getrennte Terminplanung.

Bei langfristigen Verträgen muss die künftige Umsetzungsfähigkeit bereits heute bewertet werden. Der Auftraggeber sollte Aktualisierungen der Dokumentation, Unterstützung bei Klassifizierung und Konformitätsfragen sowie genügend Vorlauf für technische Anpassungen vereinbaren. Die EU-Modellvertragsklauseln können bei der Struktur helfen, sind aber kein Gesetz und ersetzen keine Anpassung an Einsatz, Rollen und Vergabeverfahren. Vor Zuschlag ist ein Rechtsstandscheck einzuplanen.

• Geltende und spätere Pflichten getrennt terminieren
• Künftige Nachweise und Anpassungen vertraglich vorbereiten
• Modellklauseln an den konkreten Auftrag anpassen

Quellen: [3] [4]

Häufige Fragen