KI-Beschaffungs-Checkliste für Behörden und Gesundheitseinrichtungen

Behörden und Gesundheitseinrichtungen sollten KI-Anbieter nach Nachvollziehbarkeit, Datenhaltung, manuellen Eingriffsmöglichkeiten und Exit-Bedingungen bewerten – bevor die Qualität der Demo ins Gewicht fällt. Diese Anforderungen gehören in die Ausschreibung selbst, denn sie nachträglich einzufordern, sobald ein System bereits Bürger- oder Patientendaten verarbeitet, ist langsamer, teurer und mitunter nur mit einem vollständigen Neuaufbau möglich.

Die meisten Beschaffungsteams führen die Anbieterauswahl für KI noch immer wie eine Standard-Software-Ausschreibung durch: Funktionen, Preis, Referenzen, Demo. Dieser Prozess übersieht genau die Schwachstellen, an denen Projekte im öffentlichen Sektor und im Gesundheitswesen tatsächlich scheitern: ein KI-System, das eine Entscheidung nicht begründen kann, Daten, die in der falschen Jurisdiktion landen, oder eine Anbieterbeziehung, aus der man nicht herauskommt, ohne die eigenen Daten zu verlieren. Hier ist eine Checkliste, die auf die Fragen ausgerichtet ist, die wirklich zählen.

Mit Nachvollziehbarkeit beginnen, nicht mit Genauigkeit

Eine Anbieter-Demo zeigt Ihnen immer den Idealfall. Was Sie sehen müssen, ist, was passiert, wenn das System falsch liegt – und ob Sie im Nachhinein rekonstruieren können, warum.

• Verlangen Sie einen protokollierten Fehlerfall. Kein Gedankenexperiment, sondern ein echtes Transkript, in dem das System einen Fehler macht, samt dem Audit-Trail, der es jemandem ermöglicht hat, diesen zu erkennen.
• Prüfen Sie, was tatsächlich protokolliert wird. Mindestens: Eingaben, Ausgaben, Modellversion und Zeitstempel. Wenn der Anbieter nur die finale Antwort protokolliert, haben Sie keine Möglichkeit, eine Beschwerde sechs Monate später zu untersuchen.
• Stellen Sie sicher, dass Logs exportierbar sind – nicht im Dashboard des Anbieters eingeschlossen. Wenn Ihr Rechts- oder Compliance-Team für eine Prüfung Aufzeichnungen benötigt, müssen Sie diese ohne Mitwirkung des Anbieters abrufen können.

Hier spielt die Systemarchitektur still eine wichtige Rolle. In unserer eigenen Agent-Arbeit haben wir festgestellt, dass ein einzelner, klar abgegrenzter Modell-Aufruf deutlich einfacher zu prüfen ist als eine fünfstufige Agent-Kette – weil es eine Eingabe, eine Ausgabe und einen einzigen Ort gibt, an dem man bei Problemen nachsehen kann. Ein Anbieter, der für eine einfache Frage eine lange Kette von Tool-Aufrufen und Sub-Agenten einsetzt, tut nicht automatisch etwas falsch, trägt aber eine größere Erklärungslast – und Sie sollten ihn fragen, wie er Zwischenschritte protokolliert, nicht nur finale Ausgaben. Wenn Sie Anbieter gezielt nach diesem Kriterium bewerten, lohnt es sich, single-call vs agent chains vor der Ausschreibung zu lesen.

Datenhaltung und Datenzugriff sind Vertragsthemen, keine technischen Details

Wo die Daten liegen, wer sie einsehen kann und was nach Vertragsende mit ihnen geschieht – das sind Beschaffungsfragen, keine IT-Fragen, die später geklärt werden.

• Holen Sie explizite Antworten ein, wo Daten verarbeitet und gespeichert werden, einschließlich aller Unterauftragsverarbeiter (der eigene LLM-Anbieter des Vendors, Cloud-Hoster oder Analyse-Tools).
• Fragen Sie, ob Ihre Daten für das Training der Anbietermodelle genutzt werden und wenn ja, für wen. Viele API-basierte KI-Produkte trainieren standardmäßig nicht auf Kundendaten, aber verwaltete oder feingranular trainierte Angebote tun dies mitunter doch – das muss opt-in sein, nicht im Kleingedruckten einer AGB-Änderung vergraben.
• Im Gesundheitsbereich: Stellen Sie sicher, dass der Anbieter ein Business Associate Agreement unterzeichnet, wenn PHI im Spiel ist. Ein Anbieter, der hier zögert, sagt Ihnen damit etwas darüber, wie ernst er den Rest der Checkliste nimmt.
• Bei allem, was EU-Bürgerinnen und -Bürger betrifft: Machen Sie sich Ihre Pflichten nach dem EU AI Act klar. Viele dieser Pflichten treffen die einsetzende Organisation, nicht nur den Anbieter. Ihr Vertrag muss daher regeln, wer was übernimmt: wer die Risikobewertung durchführt, wer die technische Dokumentation pflegt, wer auf Anfragen von Aufsichtsbehörden reagiert.

Manueller Eingriff ist eine Designanforderung, kein nettes Extra

Bei allem, was Leistungsansprüche, eine Diagnose oder ein Rechtsergebnis beeinflusst, muss eine echte Person eingreifen können, bevor ein Schaden entsteht – nicht danach.

• Bitten Sie den Anbieter, Ihnen die tatsächliche Eingriffsoberfläche zu zeigen, nicht nur zu beschreiben. Wo sieht ein Sachbearbeiter oder ein Arzt den Konfidenzwert des KI-Systems, und wie kann er eine Entscheidung ablehnen oder eskalieren?
• Stellen Sie sicher, dass der Eingriffspfad schnell genug ist, um zu wirken. Ein Prüfverfahren, das drei Tage dauert, hilft jemandem nicht, dem heute eine Leistung verweigert wird.
• Verstehen Sie das Standardverhalten bei einem Fehler. Schlägt das System geschlossen fehl (zur menschlichen Prüfung weiterleiten) oder offen (mit einer besten Schätzung fortfahren)? Bei folgenreichen Entscheidungen wollen Sie „closed" als Standard – nicht als Konfigurationsoption, die jemand vergessen hat zu setzen.

Das hängt direkt damit zusammen, wie das zugrundeliegende System aufgebaut ist. Wenn Sie das intern konzipieren oder spezifizieren, statt es fertig einzukaufen, beschreibt court-ready architecture for healthcare AI, wie eine prüfbare und verteidigungsfähige Systemarchitektur auf Infrastrukturebene aussieht.

Vertragsklauseln, die Sie nach der Unterzeichnung schützen

Die Beschaffung endet nicht mit der Vertragsunterzeichnung. Die wichtigsten Klauseln sind die, von denen Sie hoffen, sie nie zu brauchen.

• Daten- und Modell-Exportrechte. Wenn Sie den Anbieter verlassen – behalten Sie Ihre historischen Daten und etwaige feingranular trainierte Modellgewichte, oder beginnt alles von vorne?
• Benachrichtigungspflicht bei Modell-Updates. LLM-basierte Systeme ändern ihr Verhalten, wenn sich das zugrundeliegende Modell ändert. Sie möchten frühzeitig informiert werden und idealerweise ein Staging-Fenster, bevor eine neue Modellversion in der Produktion aktiv wird.
• Incident-Response-SLAs, die sich spezifisch auf das KI-System beziehen, nicht nur auf allgemeine Verfügbarkeit. Eine falsche Diagnose oder eine zu Unrecht verweigerte Leistung hat eine andere Schweregrad-Klasse als eine langsam ladende Seite – der Vertrag sollte das abbilden.
• Haftungs- und Freistellungsklauseln, die KI-spezifische Fehlerszenarien benennen (Halluzinationen, Bias, Datenlecks) – statt generischer Software-Mängelsprache aus einer Zeit, in der es noch keine LLMs gab.

Wenn Sie einen allgemeineren Rahmen zur Anbieterbewertung suchen, der über diese Checkliste hinausgeht, deckt unsere KI-Agent-Anbieter-Evaluierungscheckliste die breiteren Kriterien ab (Kostenstruktur, Latenz, Support-Modell), die auch außerhalb compliance-intensiver Branchen gelten. Und wenn Evals Teil Ihres Bewertungsprozesses sind – oder sein sollten –, lohnt es sich, Evals in den Vertrag selbst einzubauen zu lesen, bevor Sie die Konditionen finalisieren.

Wie das in der Praxis aussieht

All das setzt keinen KI-Spezialisten in Ihrem Beschaffungsteam voraus. Es erfordert, Belege statt Versprechen einzufordern: einen echten Fehlerfall statt einer makellosen Demo, einen tatsächlichen Log-Export statt einer Beschreibung dessen, was protokolliert wird, eine Live-Demonstration der Eingriffsoberfläche statt einer Folie über „Human-in-the-Loop". Anbieter, die wirklich verteidigungsfähige Systeme gebaut haben, werden das parat haben. Anbieter, die das nicht getan haben, werden Wochen brauchen, um es beizubringen – was an sich schon eine nützliche Information ist, bevor Sie irgendetwas unterzeichnen.

Wenn Sie ein KI-System für einen behördlichen oder gesundheitsbezogenen Kontext konzipieren und eine zweite Meinung zur Ausschreibung oder zur Anbieterliste wünschen, sprechen Sie uns an.