Der öffentliche Sektor braucht eine Beschaffung, die Nein sagen kann.

Eine Behörde wird nicht rechenschaftspflichtig, wenn sie ein KI-System abnimmt. Sie wird es erst, wenn ihre Anforderungen, Nachweise, menschliche Autorität,...

Der öffentliche Sektor braucht eine Beschaffung, die Nein sagen kann.

The document that can end a purchase

A public procurement file often begins with a request that sounds harmless: find a system that can help with a task. The request moves through a problem statement, a market consultation, a set of requirements, an evaluation, a contract and, if the process is healthy, a decision that can still stop the work. That last possibility is easy to lose. Once money, calendars and political attention have gathered around a purchase, the word no starts to sound like a failure of delivery. In public work, it can be the most useful decision in the file.

European procurement law already treats a tender as more than a contest of attractive promises. Directive 2014/24/EU says that award criteria must allow effective and fair competition and must be accompanied by arrangements that let the contracting authority verify the information supplied by tenderers. The directive also says that criteria should not give the authority unrestricted freedom of choice. A public buyer has to describe what matters, explain how it will be weighed and check whether the offer actually meets it. This is not an administrative footnote. It is the legal shape of a decision that other people must be able to understand and challenge.

AI makes the old discipline harder because a supplier can offer a system whose behaviour depends on data, model updates, prompts, thresholds, integrations, people and a service that may change while the contract is still warm. The brochure can remain the same while the thing behind it moves. A procurement team therefore has to buy more than an interface. It has to buy a bounded capability, the evidence that the capability is suitable, the authority to supervise it and a credible way to stop or replace it.

The public sector needs procurement that can say no because the public sector cannot outsource its judgement. A supplier may provide a model, a workflow, a hosted service or a set of tools. It cannot provide the legitimacy of the decision made with them. The authority still has to know what problem it is solving, whose interests may be affected, what evidence supports the system, which person can intervene and how the service will continue if the supplier changes course. A signature is not a transfer of responsibility. It is a record that responsibility has been arranged.

This article follows that arrangement from the first sentence of a requirement to the last line of an exit record. It uses European public guidance and procurement material as evidence. The practical patterns are recommendations, not claims that every authority must use one form. Any invented situation is labelled as hypothetical. A plausible office, a neat tender and a dramatic failure are not evidence merely because they fit a familiar story.

A public buyer buys a promise twice

Every public purchase carries two promises. The first is the supplier’s promise about a product or service. The second is the authority’s promise to the people who depend on the work: that the money was spent for a defined public purpose, that the decision can be explained, that relevant rights were considered and that someone remains answerable when the system is wrong. The second promise is the one that survives the launch event.

AI procurement often makes the first promise vivid and the second one vague. A demonstration can show a fluent summary, a ranked list or a fast answer. It rarely shows who may reject the output, what happens when a source is missing, how a change is approved, whether the records can be exported, or which person can pause the service without negotiating their own authority in the middle of an incident. Those questions are less cinematic. They are also the questions that decide whether a public body can remain in charge.

Die Public Buyers Community der Europäischen Kommission beschreibt ihre aktualisierten EU-Modellklauseln für KI in Verträgen in drei Teilen: einer vollständigen Fassung für Hochrisiko-KI im Einklang mit dem KI-Gesetz, einer schlanken Fassung, die für Nicht-Hochrisiko-KI angepasst werden kann, sowie Erläuterungen zur Anwendung und Anpassung der Klauseln. Der Unterschied ist von Bedeutung. Eine Modellklausel ist kein Wundermittel, das eine Beschaffung automatisch geeignet macht. Sie ist ein Ausgangspunkt für die Verteilung von Pflichten zwischen einer öffentlichen Einrichtung und einem Lieferanten in einem Vertrag, dessen Umfang, Zweck und Nachweispflichten weiterhin vom Auftraggeber festzulegen sind.

Ein Auftraggeber sollte sich daher fragen, was er der Öffentlichkeit tatsächlich zusagt, bevor er fragt, was ein Anbieter nachweisen kann. Verspricht die Behörde einen schnelleren Weg durch den Rückstau, eine konsistentere Erstprüfung, eine sicherere Inspektion, eine bessere Nutzung knapper Fachkenntnisse oder schlicht ein Experiment mit sichtbaren Grenzen? Jeder Zweck erzeugt andere Nachweise und andere Gründe für einen Abbruch. Ein System, das interne Notizen entwirft, kann andere Befugnisgrenzen benötigen als eines, das Anträge für einen Dienst einstuft, den die Menschen nicht vermeiden können.

Stellen Sie sich ein hypothetisches Bewertungsteam vor, das ein Werkzeug prüft, das Angebote von Lieferanten zusammenfasst. Das Team könnte entscheiden, dass die Aufgabe für eine Unterstützung geeignet ist, jedoch nur, wenn die Zusammenfassung Ausschlüsse, Bedingungen und Fristen erhält und die Prüfer auf die zugrunde liegenden Textstellen verweist. Wenn der Lieferant nicht zeigen kann, wie diese Anforderungen getestet werden, sollte das Team das Werkzeug ablehnen oder den Vertrag eingrenzen können. Das ist keine Anschuldigung gegen den Lieferanten. Es ist eine Schlussfolgerung über die Nachweise, die für den festgelegten Zweck vorliegen.

Die gleiche Logik gilt, wenn das Problem attraktiv, aber schlecht abgegrenzt ist. Eine öffentliche Stelle möchte vielleicht Bedarf prognostizieren, Inspektionen priorisieren oder Korrespondenz weiterleiten. Diese Verben verbergen die Entscheidungen darunter. Was als Bedarf gilt. Was Priorität verändert. Welche Korrespondenz sicher weitergeleitet werden kann, ohne dass ein Mensch sie liest. Das erste Nein kann sich auf den Umfang des Problems beziehen, nicht auf den Einsatz von Software. Eine unklare Anschaffung abzulehnen, ist oft der Weg, mit dem eine Behörde den nützlichen Teil der Arbeit vor einem nicht testbaren Teil schützt.

Das Problem beschreiben, bevor die Lösung genannt wird

Beschaffung wird fragil, wenn eine Produktkategorie vor einem benannten öffentlichen Problem auftaucht. Künstliche Intelligenz ist besonders gut darin, diese Reihenfolge zu erzeugen, weil dasselbe Modell je nach Folie als Schreibassistent, Klassifikator, Suchschicht oder Agent präsentiert werden kann. Die Behörde muss die Arbeit in Begriffen beschreiben, die aussagekräftig bleiben, wenn Lieferant, Modellfamilie und Schnittstelle entfernt werden.

Der niederländische Algoritmekader, der für öffentliche Organisationen gepflegt wird, ordnet diese Arbeit seinen empfohlenen Maßnahmen zu. Er fordert Organisationen auf, den beabsichtigten Zweck und die verwendeten Daten zu beschreiben, die anwendbare Risikogruppe zu bestimmen, die Auswirkungen festzustellen, falls der Algorithmus nicht wie beabsichtigt funktioniert, und zu entscheiden, ob eine Lösung entwickelt oder gekauft werden sollte. Er verweist auch auf eine Projektstartarchitektur für die Entwicklung oder Beschaffung von Algorithmen. Das sind keine Beschaffungsdekorationen. Es sind Wege, das Problem lesbar zu machen, bevor eine Antwort angeboten wird.

Eine gute Anforderung beginnt mit der Entscheidung oder Dienstleistung, die verbessert werden soll, den Personen, die sie ausführen oder erhalten, den Informationen, die das System verwenden darf, den Informationen, die es nicht verwenden darf, und der menschlichen Befugnis, die bestehen bleibt. Sie nennt die Bedingungen, unter denen das System nützlich ist, und die Bedingungen, unter denen es nicht verwendet werden darf. Sie benennt die Aufzeichnungen, die vorhanden sein müssen, wenn das Ergebnis angenommen, abgelehnt, korrigiert oder eskaliert wird. Sie muss die interne Gestaltung des Lieferanten nicht vorhersagen. Sie muss die öffentliche Fähigkeit definieren, die geprüft werden kann.

Hier kommen funktionale und Leistungsanforderungen ins Spiel. Die Richtlinie 2014/24/EU verlangt, dass technische Spezifikationen präzise genug sind, damit Bieter den Gegenstand verstehen und Behörden bewerten können, wie Angebote die Kriterien erfüllen. Eine Anforderung wie „eine intelligente Lösung bereitstellen“ ist kein brauchbarer Test. Eine Anforderung wie „die in einem Entwurf verwendeten Quellpassagen erhalten, das Abrufdatum anzeigen, es einem Prüfer ermöglichen, den Entwurf abzulehnen, und den resultierenden Datensatz exportieren“ kommt einem testbaren öffentlichen Bedarf näher. Sie beschreibt ein Verhalten und einen Nachweisweg und keine Modeerscheinung.

Anforderungen sollten auch die Grenzen der Aufgabe offenlegen. Eine öffentliche Behörde kann festlegen, dass ein System eine Route vorschlagen, aber nicht die endgültige Entscheidung treffen darf. Sie kann festlegen, dass eine Empfehlung nicht verwendet werden darf, wenn eine bestimmte Quelle fehlt oder widersprüchlich ist. Sie kann einen menschlichen Weg für eine betroffene Person verlangen, die das Ergebnis anfechten möchte. Das sind keine feindseligen Einschränkungen. Es sind die Bedingungen, unter denen der Kauf eine öffentliche Dienstleistung bleibt und nicht ein privater Arbeitsablauf mit einem Regierungslogo.

Eine enge Problemstellung ist kein Mangel an Ehrgeiz. Sie ist eine Möglichkeit, Ehrgeiz verantwortbar zu machen. Wenn die Behörde nicht erklären kann, welchen Schritt das System verändert, wer davon profitiert, was schiefgehen kann und was eine Person als Nächstes tun kann, ist sie nicht bereit, Anbieter zu vergleichen. Die richtige Maßnahme kann mehr Erkundung, eine Nicht-KI-Lösung, ein kleiner kontrollierter Pilot oder gar kein Kauf sein. Die Vergabeakte sollte Platz für jede dieser Antworten haben.

Anforderungen in Nachweise verwandeln

Das Wort Nachweis wird in der Technologiebeschaffung locker verwendet. Die Präsentation eines Anbieters, eine Produktvorführung und die Aussage, dass das System vertrauenswürdig ist, können allesamt nützliche Beiträge sein. Keiner davon ist automatisch ein Beweis dafür, dass eine Anforderung erfüllt ist. Ein Nachweis muss mit einer Behauptung, einem Test, einem Umfang und einer Person verbunden sein, die ihn prüfen kann. Ohne diese Verbindung wird die Bewertung zu einem Wettbewerb, bei dem der am besten formulierte Satz gewinnt.

Die Vergaberichtlinie ist klar über das grundlegende Verhältnis: Zuschlagskriterien müssen von Regelungen begleitet sein, die eine wirksame Überprüfung der von den Bietern übermittelten Informationen ermöglichen. Dieser Grundsatz ist für KI besonders wichtig, weil ein Ergebnis überzeugend aussehen kann, während die Bedingungen, die es hervorgebracht haben, verborgen bleiben. Der Käufer sollte fragen, was gezeigt wird, unter welchen Daten- und Aufgabenbedingungen, mit welcher Grundlinie und wie ein Prüfer das Ergebnis reproduzieren oder anfechten kann.

Der niederländische Algoritmekader stellt dieselbe Forderung in praktischer Sprache. Seine Maßnahmen zur öffentlichen Beschaffung umfassen die Aufnahme von Algorithmusanforderungen in die Vergabeunterlagen und den Vertrag, die Anforderung an Anbieter, Nachweise für die Erfüllung der Anforderungen als Teil der Bewertung zu erbringen, die Bewertung der Haftungsbedingungen der Anbieter, die Anforderung einer Prüffähigkeit im Vertrag, die Vereinbarung darüber, was mit Daten und Artefakten geschieht, und die Anforderung eines Plans zur Abschaltung des Algorithmus. Die Liste ist eine Orientierung, keine universelle rechtliche Checkliste. Ihr Wert liegt darin, dass sie den Nachweis als Gegenstand der Beschaffung behandelt.

Ein Käufer kann Nachweise in drei nützliche Kategorien unterteilen. Demonstrierte Nachweise sind das, was der Anbieter in einer kontrollierten Bewertung zeigt: Eingabe, Ausgabe, Fehlerbehandlung, Quellennutzung und menschlicher Weg können beobachtet werden. Prüfbare Nachweise sind das, was die Behörde ohne eine Vorführung untersuchen kann: Dokumentation, Testergebnisse, Protokolle, Schnittstellen, Änderungsaufzeichnungen, Datenbeschreibungen und die Möglichkeit, eine vereinbarte Prüfung durchzuführen. Vertragliche Nachweise sind das, was der Anbieter weiterhin erbringen muss: Mitteilungen über wesentliche Änderungen, Informationen über Vorfälle, Zugang für eine Prüfung, Dienstaufzeichnungen, Exportmöglichkeiten und Unterstützung für einen kontrollierten Ausstieg. Die Kategorien überschneiden sich, aber sie verhindern, dass eine einzige beeindruckende Sitzung den gesamten Vertrag trägt.

Evidenz braucht auch einen Geltungsbereich. Ein Anbieter kann zeigen, dass ein System bei einer Reihe von Beispielen gut funktioniert. Der Auftraggeber muss trotzdem wissen, ob die Beispiele die vorgesehene Sprache, die Dokumentqualität, die Fallmischung, die Anforderungen an die Barrierefreiheit und die betrieblichen Randbedingungen abbilden. Eine Aussage über ein Modell im Labor ist nicht automatisch eine Aussage über einen öffentlichen Dienst. Es ist eine Aussage über das Experiment, das durchgeführt wurde. Das Vergabeteam sollte die Aufgabe, die Datenbedingungen, die Version und das Ergebnis aufbewahren, damit die spätere Entscheidung nicht losgelöst vom Test schwebt.

Stellen Sie sich hypothetisch vor, dass ein Bieter eine Beispielsammlung generierter Zusammenfassungen und eine allgemeine Genauigkeitsaussage vorlegt. Die Behörde kann nach den Quelldokumenten, der Auswahlregel, der verwendeten Version, der Behandlung fehlenden Materials, dem Prüfverfahren und dem Artefakt fragen, das nach der Abnahme erhalten bleibt. Wenn die Antwort lautet, dass die Details proprietär sind und nicht eingesehen werden können, hat das Team etwas Wichtiges gelernt. Es hat nicht gelernt, dass das System schlecht ist. Es hat gelernt, dass die vorgeschlagene Evidenzgrenze für den öffentlichen Zweck möglicherweise zu schwach ist.

Evidenz sollte verhältnismäßig sein. Ein kleines internes Schreibhilfsmittel benötigt nicht dasselbe Prüfpaket wie ein System, das den Zugang zu einem öffentlichen Dienst beeinflusst. Verhältnismäßigkeit bedeutet nicht, bei geringem Risiko einen Slogan zu akzeptieren. Sie bedeutet, die Tiefe des Nachweises an die Konsequenz, die Umkehrbarkeit, die betroffenen Personen und die Fähigkeit anzupassen, einen Fehler zu erkennen und zu beheben. Der Anbieter sollte die geforderte Evidenz kennen, bevor das Angebot eingereicht wird. Sonst ändert die Behörde den Wettbewerb nach dem Rennen, was ein bekannter Weg ist, eine teure Überraschung zu erzeugen.

Eine Anforderung sollte zu einem Nachweis führen, und der Nachweis sollte die Zuschlagsentscheidung ändern dürfen.

Der Auftraggeber muss widersprechen können

Öffentliche Rechenschaftspflicht ist nicht dasselbe wie Transparenz des Anbieters. Ein Anbieter kann seinen Dienst erläutern, während der Behörde dennoch ein Weg für eine Einwohnerin, einen Arbeitnehmer, ein Unternehmen oder eine Fachperson fehlt, die Art und Weise der Nutzung des Dienstes anzufechten. Die Vergabeunterlagen sollten daher fragen, wie Widerspruch funktioniert, nicht nur, wie das System eine Antwort erzeugt.

Der Algoritmekader ordnet menschliche Kontrolle, Grundrechte, Transparenz und Beschwerdewege seinen Themen für den öffentlichen Sektor zu. Zu den empfohlenen Maßnahmen gehören eine sinnvolle menschliche Intervention bei der Entscheidungsfindung, ein Verfahren, über das Bürgerinnen und Bürger oder andere Interessengruppen eine Beschwerde, einen Einwand oder einen Rechtsbehelf einreichen können, eine öffentliche Entscheidung über den Einsatz des Algorithmus und eine Möglichkeit, auswirkungsbezogene Algorithmen im niederländischen Algorithmenregister zu veröffentlichen. Diese Maßnahmen machen nicht aus jedem Algorithmus ein öffentliches Spektakel. Sie machen die Verantwortung der Behörde sichtbar genug, um hinterfragt zu werden.

Eine Beschaffungsanforderung für menschliche Aufsicht sollte die menschliche Handlung benennen. Kann die prüfende Person die Informationen sehen, die die Empfehlung geprägt haben. Kann sie den Datensatz korrigieren. Kann sie das Ergebnis ablehnen, ohne zuvor die Erlaubnis des Systems einzuholen. Kann sie nach einem alternativen Weg fragen, wenn eine Quelle fehlt. Kann sie einen Stapel anhalten, eine Version isolieren oder ein Anliegen an eine Person mit Befugnis eskalieren. Wenn die Antwort nur lautet, dass eine Person irgendwo im Prozess anwesend ist, beschreibt die Anforderung Mobiliar, nicht Aufsicht.

Meinungsverschiedenheit braucht auch Zeit. Eine prüfende Person, die jedes Ergebnis kontrollieren soll und dabei die ursprüngliche Arbeitslast trägt, ist technisch gesehen in der Schleife und praktisch außerhalb. Die Beschaffung kann Schulung, Unterstützung, verwertbare Nachweise und eine Arbeitslastannahme für die Prüfung verlangen. Sie kann festlegen, welche Fälle eine Genehmigung vor der Maßnahme benötigen und welche umkehrbaren Maßnahmen mit geringen Folgen mit Protokollierung und späterer Stichprobenprüfung fortgesetzt werden dürfen. Sie kann vom Anbieter verlangen, den Weg zu unterstützen, statt ihn hinter einer Anwendungsprogrammierschnittstelle zu verstecken.

Die Behörde muss auch ihrer eigenen Begeisterung widersprechen. Ein erfolgreicher Pilotversuch kann Druck erzeugen, ein Werkzeug auf eine Personengruppe oder Entscheidung auszuweiten, die nie Teil des Tests war. Der Vertrag sollte den ursprünglichen Zweck bewahren und eine neue Entscheidung verlangen, wenn sich Zweck, Daten, betroffene Personen oder Konsequenz ändern. Ein Update ist nicht automatisch harmlos, nur weil es als Dienst bereitgestellt wird. Eine neue Nutzung ist nicht automatisch abgedeckt, nur weil dasselbe Logo oben auf dem Bildschirm erscheint.

Wenn ein Anbieter sagt, das Modell sei nur beratend, sollte die Behörde prüfen, was die Arbeit tatsächlich tut. Wenn Mitarbeitende angewiesen sind, die Rangfolge zu akzeptieren, wenn keine Zeit zur Prüfung bleibt oder wenn das System steuert, welche Fälle eine Person erreichen, kann Beratung in der Praxis zu einer Entscheidung geworden sein. Das Beschaffungsteam muss nicht über das perfekte Etikett streiten. Es muss den Weg vom Ergebnis zur Konsequenz dokumentieren und die Befugnis behalten, diesen Weg zu ändern.

Die Grenzen des Anbieters sind Teil des Vertrags

KI-Beschaffung wird oft als Wahl zwischen Bauen und Kaufen beschrieben. Die schwierigere Wahl ist, wie die Grenze zwischen Anbieter und öffentlicher Organisation zu ziehen ist. Der Anbieter kann ein Modell, einen Dienst, einen Update-Pfad, eine Infrastruktur, ein Support-Team und einen Teil der Datenverarbeitung kontrollieren. Die Behörde kontrolliert den öffentlichen Zweck, die Entscheidung, die betroffene Bevölkerung und die Pflicht, einen rechtmäßigen und nutzbaren Dienst bereitzustellen. Ein Vertrag muss diese Verantwortlichkeiten verbinden, statt sie als zwei höfliche Diagramme stehen zu lassen.

Die aktualisierten EU-Mustervertragsklauseln für KI sind nützlich, weil sie anerkennen, dass öffentliche Käufer unterschiedliche Ansätze für Hochrisiko-KI und Nicht-Hochrisiko-KI benötigen und eine Anleitung zur Anpassung der Klauseln in der Praxis brauchen. Sie ersetzen keine Beschaffungsstrategie oder rechtliche Prüfung. Sie sind eine gemeinsame Sprache, um Verantwortlichkeiten explizit zu machen. Der Käufer muss weiterhin entscheiden, welche Nachweise, Datenrechte, Prüfzugriffe, Änderungsmitteilungen, Unterstützung, Haftung und Ausstiegsbedingungen für das zu beschaffende System angemessen sind.

Daten und Artefakte verdienen besondere Sorgfalt. Ein System kann Quelldokumente, Beschriftungen, Eingabeaufforderungen, Einbettungen, generierte Entwürfe, menschliche Korrekturen, Bewertungssätze, Protokolle und endgültige Aufzeichnungen berühren. Der Vertrag sollte unterscheiden, was die Behörde bereitstellt, was der Anbieter erstellt, was jede Partei verwenden darf, was zurückgegeben werden muss, was gelöscht werden muss und welcher Nachweis der Löschung oder Aufbewahrung erforderlich ist. Zu sagen, dass die Behörde ihre Daten besitzt, beantwortet nicht, wo abgeleitete Artefakte liegen oder wie die Behörde die Aufzeichnungen abrufen kann, die ein Ergebnis erklären.

Auditrechte brauchen eine praktische Form. Der Käufer sollte wissen, welche Aufzeichnungen geprüft werden können, wie der Zugriff beantragt wird, welche Frist angemessen ist, welche Vertraulichkeitsschutzmaßnahmen gelten und was passiert, wenn eine Prüfung eine Lücke aufdeckt. Eine Auditklausel ohne nutzbaren Weg ist ein Streitfall, der nur auf seinen Auslöser wartet. Gleiches gilt für eine Vorfallsklausel, die besagt, dass der Lieferant kooperieren wird, ohne die Informationen, den Zeitrahmen und die verantwortliche Stelle zu benennen, die für die Kooperation erforderlich sind.

Das Änderungsmanagement sollte nicht den Versionshinweisen überlassen bleiben. Die Behörde kann eine Benachrichtigung über eine wesentliche Änderung am Modell, an den Datenquellen, am Verarbeitungsort, an den Unterauftragnehmern, an den Schnittstellen, an den Schwellenwerten, an der Bewertungsmethode oder am menschlichen Eingriffspfad verlangen. Sie kann festlegen, welche Nachweise erforderlich sind, bevor eine geänderte Version für die öffentliche Aufgabe verwendet wird. Sie kann ein Recht auf Aussetzung, Ablehnung oder Rücknahme verlangen, wenn der geänderte Dienst eine wesentliche Anforderung nicht mehr erfüllt. Dies sind Empfehlungen, um den Vertrag handhabbar zu machen. Sie sind keine Behauptungen, dass eine einzige Klausel jede Lieferantenbeziehung lösen kann.

Zur Verantwortung gehört auch, was der Lieferant nicht bereitstellen kann. Ein Dienst kann von einem Drittanbietermodell oder einer Infrastruktur abhängen, deren Änderungen außerhalb der unmittelbaren Kontrolle des Lieferanten liegen. Der Käufer sollte über diese Abhängigkeit informiert werden und wissen, welche Verpflichtungen auf ihn durchschlagen. Eine öffentliche Organisation kann eine Lieferkette nicht bewerten, indem sie nur die Eingangstür inspiziert. Der Vertrag sollte einen Weg zu den relevanten Nachweisen erhalten, oder der Käufer sollte anerkennen, dass die Unsicherheit ein Grund ist, den Kauf einzuschränken oder abzulehnen.

Klare Grenzen schützen auch Lieferanten. Ein öffentlicher Käufer, der jedes mögliche Dokument, jedes Detail des Quellcodes und unbegrenzten Support ohne definierten Zweck verlangt, kann den Wettbewerb verringern und den Vertrag für kleinere europäische Anbieter unattraktiv machen. Verhältnismäßigkeit, Klarheit und ein glaubwürdiger Nachweisumfang ermöglichen es einem Lieferanten zu sagen, was er leisten kann, und einem Käufer zu sagen, was er braucht. Öffentliche Beschaffung sollte anspruchsvoll sein, ohne theatralisch zu wirken. Eine Mauer aus unmöglichen Anforderungen hält schlechte Systeme und gute gleichermaßen fern.

Änderungen nach der Vergabe sind weiterhin Beschaffung

Die Vergabe ist nicht das Ende der Entscheidung. Sie ist der Punkt, an dem der Dienst einer anderen Art von Prüfung unterliegt. Während des Betriebs verschieben sich Daten, Richtlinien ändern sich, Schnittstellen werden ersetzt, Mitarbeiter lernen Abkürzungen, Lieferanten überarbeiten Modelle, und ein System kann in Situationen eingesetzt werden, die sich das ursprüngliche Team nicht vorgestellt hat. Die Behörde braucht eine Möglichkeit, diese Änderungen zu bemerken, bevor sie versehentlich zu einem neuen öffentlichen Zweck werden.

Der Algoritmekader empfiehlt regelmäßige Prüfungen, dass ein Algorithmus wie vorgesehen funktioniert, die Überwachung von Datenänderungen und die Bewertung von Leistung und Ausgabe bei Datenänderungen sowie die Pflege eines Plans für kontinuierliche Überwachung. Er enthält auch eine Maßnahme für einen Notfallplan zum Stoppen des Algorithmus. Diese Empfehlungen setzen Zeit in das Governance-Modell. Eine Beschaffung, die nur die ursprüngliche Spezifikation erfasst, hat ein Foto eines sich bewegenden Dienstes gekauft.

Nicht jedes Update sollte dieselbe Zeremonie auslösen. Ein Sicherheitspatch, der Modell, Datengrenze und Entscheidungsrolle unverändert lässt, kann einem anderen Weg folgen als eine neue Modellfamilie, eine geänderte Abrufquelle oder ein neuer Schwellenwert. Der Vertrag kann die Wesentlichkeit in operativen Begriffen definieren: Eine Änderung ist wesentlich, wenn sie die Aufgabe, die betroffenen Personen, den Nachweispfad, die Entscheidungsfolge, den Einsatzstandort, den Unterauftragnehmer, die Datennutzung oder die Möglichkeit zum Eingreifen verändert. Die genaue Definition erfordert rechtliches und technisches Urteilsvermögen. Das Prinzip ist einfach: Änderung ist Teil der gekauften Leistungsfähigkeit.

Monitoring sollte die Informationen bewahren, die für eine Entscheidung nötig sind. Ein Dashboard kann zeigen, dass ein Dienst ausgelastet ist; es zeigt möglicherweise nicht, dass eine Quelle veraltet ist oder dass Prüfende dieselbe Empfehlung wiederholt überstimmen. Die Behörde sollte die relevante Version, den Aufgabenumfang, die Evidenzbedingungen, das menschliche Handeln und den Grund für eine Änderung festhalten. Sie sollte wissen, welche Änderungen angenommen, welche zurückgerollt, welche eingeschränkt wurden und welche eine neue Beschaffungsfrage aufgeworfen haben.

Ein Lieferant kann möglicherweise nicht jede interne Änderung im Voraus ankündigen. Der Vertrag kann dennoch eine brauchbare Benachrichtigung und ein Evidenzpaket verlangen, bevor das geänderte Verhalten genutzt wird. Die Behörde kann eine gestaffelte Einführung, eine kontrollierte Evaluierung oder eine vorübergehende Aussetzung wählen. Die Möglichkeit, anzuhalten, ist keine Bestrafung. Sie ist das, was es einem öffentlichen Dienst ermöglicht, rechenschaftspflichtig zu bleiben, während Fakten ermittelt werden.

Ein Änderungsprotokoll schützt auch vor falscher Gewissheit. Wenn die Behörde nicht feststellen kann, ob eine Abweichung von einem neuen Modell, einer Datenänderung, einem Prompt, einer manuellen Umgehung oder einer externen Abhängigkeit stammt, sollte sie nicht behaupten, dass das System konsistent funktioniert hat. Die richtige Reaktion kann sein, die Nutzung einzuschränken, bessere Evidenz zu sammeln oder den betroffenen Weg zu stoppen. Öffentliche Gelder werden nicht sicherer, nur weil die Erklärung ordentlich klingt.

Interoperabilität ist das höfliche Wort für Gehen

Interoperabilität wird oft diskutiert, als wäre sie eine technische Höflichkeit zwischen Systemen. Im öffentlichen Beschaffungswesen ist sie auch ein Kontinuitätskontrollinstrument. Wenn ein öffentlicher Dienst seine Aufzeichnungen, Konfigurationen, Evidenzen, Schnittstellen und Betriebswissen nicht auf einen anderen Weg übertragen kann, mag die Behörde rechtlich frei sein zu gehen, praktisch aber dazu nicht in der Lage sein. Der Vertrag hat eine Abhängigkeit geschaffen, die die Beschaffungsakte nicht benannt hat.

Der JRC-Bericht der Kommission zur Förderung der KI-Übernahme in öffentlichen Verwaltungen der EU bezeichnet die Beschaffung als entscheidende unterstützende Rolle und sagt, dass Interoperabilität von Anfang an eingebettet sein sollte. Er stellt die strategische Beschaffung auch als einen Weg dar, die Abhängigkeit von Anbietern außerhalb der EU zu verringern und europäische KI-Startups, Open-Source- und GovTech-Lösungen zu unterstützen. Dies ist kein Argument, europäisch aus Slogans zu kaufen oder Open Source als automatische Garantie zu behandeln. Es ist ein Argument, die technische und institutionelle Fähigkeit zur Kursänderung zu einem Teil des gekauften Werts zu machen.

Der Ausstieg beginnt mit einer Liste dessen, was überleben muss. Dazu können Quelldatensätze, Kennungen, Beschriftungen, Prompts, Modell- und Konfigurationsversionen, Evaluierungssätze, Prüfprotokolle, Nutzer- und Rollenzuordnungen, Integrationsverträge, Aufbewahrungsstatus, Sicherheitsmaterial und die Bedeutung von Feldern gehören. Die Liste hängt vom Dienst ab. Eine portable Datei ohne Kontext kann weniger nützlich sein als ein kleinerer Datensatz mit intakter Semantik und Berechtigungen. Export ist eine Fähigkeit, die getestet werden muss, kein Kästchen zum Abhaken.

Interoperabilität bedeutet auch, dass die Behörde einen aussagekräftigen Vergleich durchführen kann. Kann ein Zielsystem die Datensätze verarbeiten, ohne ihre Bedeutung stillschweigend zu verändern. Können Prüfende eine alte und eine neue Ausgabe unter denselben Aufgabenbedingungen vergleichen. Kann der öffentliche Dienst in einem reduzierten Modus weiterarbeiten, wenn eine Abhängigkeit nicht verfügbar ist. Kann Evidenz lesbar bleiben, nachdem die Schnittstelle verschwunden ist. Diese Fragen gehören in die Anforderungen, die Evaluierung und den Vertrag, denn ein Ausstieg, der während eines Notfalls entdeckt wird, ist meist eine archäologische Ausgrabung.

Portabilität bedeutet nicht zwangsläufig, dass ein Anbieter jedes interne Implementierungsdetail herausgeben muss. Sie bedeutet jedoch, dass die Vergabestelle die öffentliche Funktion und die Aufzeichnungen, für die sie verantwortlich ist, unter Beachtung rechtmäßiger Rechte und Sicherheitsbeschränkungen bewahren kann. Die Grenze sollte vor der Unterzeichnung festgelegt werden. Wenn das Modell des Anbieters nicht zugänglich ist, kann die Vergabestelle dennoch portable Eingaben, Ausgaben, Entscheidungsaufzeichnungen, Auswertungen, Konfiguration und einen Weg zur Rekonstruktion der öffentlichen Verpflichtungen des Dienstes verlangen. Wenn sie diesen Weg nicht erhalten kann, sollte sie die Abhängigkeit ehrlich bepreisen oder darauf verzichten.

Eine Exit-Probe ist wertvoll, weil sie ein vertragliches Versprechen in eine beobachtete Fähigkeit verwandelt. Ein öffentlicher Auftraggeber kann einen Export testen, die Felder prüfen, eine repräsentative Arbeitslast in einem kontrollierten Zielsystem ausführen und die resultierenden Aufzeichnungen vergleichen. Er kann festhalten, was sich nicht bewegt hat, und entscheiden, ob die Lücke akzeptabel ist. Die Übung muss nicht dramatisch sein. Eine kleine Probe vor der Verlängerung ist besser als eine heroische Migration, die durchgeführt wird, nachdem der Anbieter die einzige Person geworden ist, die sich an das System erinnert.

Das Verlassen ist eine Abfolge von Autorität, Export, Bedeutung, Verifizierung, Kontinuität und Abschluss. Ein mit Export beschrifteter Button ist nicht die Abfolge.

Kosten sind mehr als die Zeile in der Ausschreibung

Der Preis ist leicht zu vergleichen, wenn das gekaufte Objekt stabil ist. KI-Beschaffung hat einen längeren Kostenvorlauf. Es kann Integrationsarbeit, Quellaufbereitung, Prüfzeit, Sicherheitskontrollen, Speicherung, Auswertung, Modellaktualisierungen, Barrierefreiheitsarbeit, Vorfallreaktion, Support, Export und Ersatz geben. Einige Kosten trägt die Vergabestelle. Andere werden auf Beschäftigte oder auf die Öffentlichkeit übertragen, wenn ein Dienst schwerer anfechtbar wird. Eine Beschaffung, die nur die anfängliche Gebühr vergleicht, ist nicht unbedingt wirtschaftlich. Sie zählt lediglich einen sichtbaren Teil.

Die Richtlinie 2014/24/EU sieht die Lebenszykluskostenrechnung vor, wenn die Vergabestelle diesen Ansatz wählt. Die Richtlinie beschreibt Kosten wie Anschaffung, Nutzung, Wartung, Entsorgung und, soweit relevant und überprüfbar, Umweltexternalitäten. Sie verlangt außerdem, dass die Vergabeunterlagen die Daten angeben, die Bieter vorlegen müssen, sowie die Methode zur Bewertung der Lebenszykluskosten. Dies ist eine nützliche Disziplin für KI, weil sie den Käufer dazu zwingt, festzulegen, was gezählt wird, anstatt jedem Anbieter zu erlauben, eine eigene Definition von billig mitzubringen.

Dasselbe Prinzip gilt für menschliche Aufmerksamkeit. Wenn ein System Empfehlungen erzeugt, die geprüft werden müssen, gehört die Arbeit des Prüfens in das Betriebsmodell. Wenn ein öffentlicher Dienst einen Weg zur Korrektur braucht, braucht der Weg einen Verantwortlichen und Zeit. Wenn ein Update eines Anbieters eine neue Bewertung erfordert, braucht die Behörde die Fähigkeit, diese durchzuführen. Das sind keine Argumente gegen Automatisierung. Es sind Erinnerungen daran, dass Automatisierung verändert, wo Arbeit stattfindet. Eine Ersparnis auf der Rechnung kann ein Aufwand in der Warteschlange sein, wenn die Beschaffung die neue Arbeit nicht benennt.

Zu den Kosten sollte auch die Kosten gehören, nicht gehen zu können. Eine Abhängigkeit mag neu günstig erscheinen und teuer werden, wenn sich Aufzeichnungen, Fachwissen, Integrationen und öffentliche Erwartungen darum angesammelt haben. Der Käufer kann eine Migrationsschätzung, ein Daten- und Artefaktinventar, eine Supportverpflichtung und einen Probenplan verlangen. Er kann diese Bedingungen als Teil des Werts des Angebots vergleichen. Die Wahl ist nicht zwischen Optimismus und Pessimismus. Sie ist zwischen einer Abhängigkeit, die sichtbar ist, und einer, die in der Zukunftsform versteckt ist.

Lebenszyklusdenken hilft einem Beschaffungsteam, Nein zu sagen, ohne so zu tun, als sei das günstigste sichtbare Angebot die neutrale Option. Das Team kann einen Vorschlag ablehnen, weil seine Beweise, sein Prüfaufwand, sein Änderungspfad oder seine Ausstiegskosten nicht mit dem öffentlichen Zweck vereinbar sind. Es kann die Entscheidung anhand veröffentlichter Kriterien erklären. Das ist keine marktfeindliche Geste. Es ist das, was ein Markt mit überprüfbaren Anforderungen ermöglichen soll.

Öffentliche Käufer brauchen die Befugnis, Nein zu sagen

Ein Beschaffungsteam kann eine Befugnis nicht ausüben, die ihm die Organisation nicht gegeben hat. Viele Behörden haben Personen, die rechtliche, technische, finanzielle und dienstliche Fragen bewerten können, aber die Befugnis, diese Bewertungen zu einer Pause oder Ablehnung zusammenzuführen, ist unklar. Das Ergebnis ist bekannt: Bedenken werden in einem Dokument festgehalten, Begeisterung in einem anderen, und die Vergabe schreitet voran, weil niemand weiß, welche Rolle das Tor schließen darf.

Die Behörde sollte die Rollen benennen, die einen Kauf in jeder Phase annehmen, ablehnen, eingrenzen oder pausieren können. Die Rollen brauchen Zugang zu den relevanten Beweisen und einen Weg, den Grund festzuhalten. Ein Beschaffungsbeauftragter kann den Prozess besitzen, ein Dienstverantwortlicher den öffentlichen Zweck, ein Datenschutzbeauftragter eine Datenschutzbedingung, ein Sicherheitsverantwortlicher eine Kontrolle, ein technischer Prüfer einen Test und eine leitende rechenschaftspflichtige Rolle die endgültige Entscheidung. Die genaue Regelung variiert. Das Fehlen einer Regelung ist der gefährliche Teil.

Eine nützliche Stoppbedingung ist kein rotes Abzeichen, das hohes Risiko anzeigt. Es ist eine Tatsache, die die nächste Entscheidung blockiert. Der beabsichtigte Zweck ist nicht ausreichend definiert. Der Anbieter kann keine Beweise für eine wesentliche Anforderung liefern. Die betroffene Person hat keinen nutzbaren Überprüfungsweg. Die Behörde kann die relevante Änderung nicht prüfen. Die Daten- oder Artefaktrechte sind unklar. Das System kann nicht im Rahmen des Kontinuitätsplans exportiert oder ersetzt werden. Der menschliche Prüfer hat Verantwortung, aber keine Befugnis. Jede Bedingung kann ein anderes Mittel haben. Einige erfordern Klärung, einige eine Vertragsänderung, einige einen engeren Umfang und einige ein Nein.

Stoppbedingungen sollten bekannt sein, bevor das Angebot bewertet wird. Sie sollten mit Vergabekriterien und mit dem Vertrag verbunden sein, damit ein Käufer keinen neuen Standard erfindet, nachdem er die Antwort des Anbieters gesehen hat. Sie sollten auch nach der Vergabe überprüft werden. Eine Anforderung, die beim Start erfüllt war, kann nach einer wesentlichen Änderung oder einer neuen Nutzung unerfüllt werden. Die Fähigkeit, Nein zu sagen, ist kein einzelnes Tor am Ende. Sie ist eine aufrechterhaltene Befugnis während der gesamten Lebensdauer des Dienstes.

Stellen Sie sich eine hypothetische öffentliche Einrichtung vor, die einen Dokumentenweiterleitungsdienst beschaffen möchte. Zu den veröffentlichten Anforderungen gehören die Rückverfolgbarkeit der Quelle, ein menschlicher Prüfpfad, ein Hinweis auf wesentliche Modelländerungen, ein Export der Aufzeichnungen und ein definiertes Beendigungsverfahren. Ein Bieter bietet eine überzeugende Demonstration an, kann der Behörde jedoch nicht erlauben, die Quellenauswahl zu prüfen oder die versionierten Weiterleitungsnachweise aufzubewahren. Ein anderer Bieter bietet weniger Funktionen, erfüllt aber die Anforderungen an Nachweise und Ausstieg. Die Einrichtung ist nicht verpflichtet, der lauteren Demonstration den Vorzug zu geben. Sie kann die festgelegten Kriterien anwenden, angemessene Fragen stellen und das erste Angebot ablehnen, wenn eine wesentliche Anforderung unbewiesen bleibt.

Diese Entscheidung sollte nicht als moralisches Urteil über den Lieferanten oder die Technologie formuliert werden. Sie sollte den öffentlichen Zweck, die Anforderung, die erhaltenen Nachweise, die ungeklärte Bedingung und die in den Vergabeunterlagen vorgesehene Entscheidung darlegen. Ein klares Nein ist respektvoller als ein vages Vielleicht, das später zu einer verpflichtenden Verlängerung wird. Es sendet auch ein nützliches Signal an den Markt: Öffentliche Käufer werden für Nachweise und Kontrolle zahlen, nicht nur für Fähigkeits-Theater.

Die menschliche Befugnis zu stoppen, muss in einem Vorfall nutzbar sein. Die Bediener sollten wissen, wen sie anrufen müssen, welchen Systemzustand sie bewahren müssen, welche Dienstrouten fortgesetzt werden können und welche Kommunikation erforderlich ist. Der Entscheidungsbericht sollte die unmittelbare Eindämmung von einer längerfristigen Beschaffungsentscheidung unterscheiden. Eine öffentliche Einrichtung muss nicht auf eine perfekte Untersuchung warten, bevor sie weiteren Schaden verhindert, sollte aber vermeiden, mehr Gewissheit zu behaupten, als sie hat. Der Stopp ist eine Kontrolle. Die Erklärung kann sich weiterentwickeln.

Beschaffung prägt den Markt

Die öffentliche Beschaffung ist einer der Wege, auf denen Europa entscheidet, welche Fähigkeiten es zu entwickeln lohnt. Der JRC-Bericht zur Förderung der KI-Einführung in öffentlichen Verwaltungen der EU beschreibt den öffentlichen Sektor als eine wichtige marktprägende Kraft. Er verbindet eine erfolgreiche Einführung mit Governance, Personalbereitschaft, verantwortungsvoller Beschaffung, Interoperabilität und öffentlichem Vertrauen. Er sagt auch, dass strategische Beschaffung die Abhängigkeit von Anbietern außerhalb der EU verringern und europäische Start-ups, Open-Source- und GovTech-Lösungen unterstützen kann. Es geht nicht darum, dass eine öffentliche Behörde zu einem Wagniskapitalfonds werden soll. Es geht darum, dass ihre Anforderungen entweder verantwortungsvolle Fähigkeiten belohnen oder eine überzeugende Verpackung um Abhängigkeit belohnen können.

Der Sonderbericht Nr. 28/2023 des Europäischen Rechnungshofs trägt den Titel „Öffentliche Auftragsvergabe in der EU: weniger Wettbewerb bei Aufträgen für Bauleistungen, Lieferungen und Dienstleistungen in den zehn Jahren bis 2021“. In seiner öffentlichen Zusammenfassung wird der Wettbewerb um öffentliche Ausschreibungen in Europa als schrumpfend beschrieben. Ein Markt mit weniger wirksamen Wettbewerbern ist ein schlechter Ort, um vage Anforderungen zu verstecken. Wenn die Behörde keine Nachweise vergleichen kann, wählt sie möglicherweise zwischen Marketingstilen statt zwischen Dienstleistungen. Ein Nein zu einem nicht prüfbaren Angebot kann die Bedingungen für einen besseren Wettbewerb später erhalten.

Gleichzeitig kann ein Käufer versehentlich nützliche Anbieter ausschließen, indem er Nachweise in einer Form verlangt, die nur der größte Anbieter erbringen kann. Angemessene Anforderungen, klare Schnittstellen, offene Formate und gestaffelte Bewertungen können kleineren Organisationen ermöglichen, eine begrenzte Fähigkeit nachzuweisen, ohne so zu tun, als hätten sie die Ressourcen eines multinationalen Konzerns. Der Käufer sollte beim öffentlichen Zweck streng sein und bei der Umsetzung flexibel, solange die Umsetzung diesen Zweck nicht beeinträchtigt. So wird aus einem Nein eine bessere Frage statt einer verschlossenen Tür.

Marktprägung bedeutet auch, sich zu weigern, die private Architektur eines einzelnen Anbieters zur Definition des öffentlichen Bedarfs zu machen. Wenn eine Anforderung ein bestimmtes Modell, eine bestimmte Cloud oder einen bestimmten proprietären Workflow nennt, ohne einen begründeten Bezug zur Aufgabe, kann der Wettbewerb eingeschränkt werden, bevor Nachweise geprüft werden. Funktionale Anforderungen und überprüfbare Ergebnisse geben öffentlichen Käufern mehr Spielraum, um Ansätze zu vergleichen. Sie machen den Vertrag auch weniger anfällig, wenn sich die gewählte Komponente ändert.

Eine öffentliche Stelle kann ein anspruchsvoller Auftraggeber sein, ohne ein schwieriger Auftraggeber zu werden. Sie kann die Nachweise veröffentlichen, die sie erwartet, den Grund für eine Abbruchbedingung erläutern, einen Weg für Rückfragen anbieten und für Arbeit bezahlen, die dauerhafte öffentliche Leistungsfähigkeit schafft. Der Markt hat dann etwas, worauf er reagieren kann. Er muss nicht raten, ob der entscheidende Faktor eine versteckte Präferenz, eine schöne Demo oder der Preis eines künftigen Problems war.

Ein Arbeitsmuster für eine Beschaffung, die ablehnen kann

Das folgende Muster ist eine praktische Empfehlung, kein neues rechtliches Verfahren. Es ist eine Möglichkeit, die öffentliche Entscheidung sichtbar zu halten, während sich ein System von der Idee zum Betrieb entwickelt. Eine Stelle sollte es an ihr Recht, ihren Sektor, ihr Risiko und ihre Beschaffungsmethode anpassen. Wichtig ist, dass jedes Tor einen Verantwortlichen, Nachweise und ein zulässiges Ergebnis hat, das Pause oder Ablehnung einschließt.

Erstens: die öffentliche Zweckbestimmung formulieren. Benennen Sie den Dienst, die Personen, die ihn erbringen, die Personen, die ihn erhalten, die Entscheidung oder Handlung, die sich ändern kann, und den Grund, warum ein System in Betracht gezogen wird. Legen Sie dar, was außerhalb des Rahmens liegt. Wenn sich der Zweck nicht ohne die Produktsprache des Anbieters beschreiben lässt, befindet sich die Stelle noch in der Markterkundung. Das Ergebnis dieses Tors ist eine Problembeschreibung und eine Entscheidung darüber, ob die Beschaffung der richtige nächste Schritt ist.

Zweitens: die Nachweisgrenze formulieren. Legen Sie für jede wesentliche Behauptung dar, was zeigen würde, dass sie in der vorgesehenen Aufgabe zutrifft. Benennen Sie die Datenbedingungen, die Sprache, die Barrierefreiheitsanforderungen, die Quelldatensätze, die Version, die Ausgangsbasis und den Prüfweg, die den Test aussagekräftig machen. Legen Sie fest, was prüfbar sein muss, was vertraulich bleiben kann und was als Vertragsdokument geliefert werden muss. Das Ergebnis dieses Tors ist ein Satz von Anforderungen, die Bieter verstehen können, und ein Bewertungsplan, der den Zuschlag ändern kann.

Drittens: die Befugnisgrenze formulieren. Benennen Sie die Handlungen, die das System vorschlagen darf, die Handlungen, die es ausführen darf, die Handlungen, die einer Genehmigung bedürfen, und die Handlungen, die untersagt sind. Benennen Sie, wer eine Quelle korrigieren, ein Ergebnis ablehnen, eine Regel ändern, einen Dienst pausieren und mit einer betroffenen Person sprechen darf. Legen Sie fest, was geschieht, wenn das System unsicher ist oder die Nachweise widersprüchlich sind. Das Ergebnis dieses Tors ist ein menschlicher Weg, der konkreter ist als ein Kontrollkästchen.

Viertens: die Änderungsgrenze formulieren. Identifizieren Sie die Änderungen, die eine Ankündigung, eine Bewertung, eine Genehmigung oder eine neue Beschaffungsentscheidung erfordern. Schließen Sie Modell, Daten, Anbieter, Unterauftragnehmer, Infrastruktur, Verarbeitungsort, Schnittstelle, Schwellenwert, Personengruppe, Zweck und menschlichen Weg ein. Entscheiden Sie, welche Nachweise beim Änderungsprotokoll verbleiben und welche aus rechtmäßigen Gründen geschwärzt werden können. Das Ergebnis dieses Tors ist ein gepflegtes Protokoll und nicht das Versprechen, dass das System unverändert bleibt.

Fünftens: die Ausstiegsgrenze formulieren. Listen Sie die Datensätze, Daten, Konfiguration, Nachweise, Berechtigungen, Integrationen und das Betriebswissen auf, die erhalten bleiben müssen. Legen Sie Formate, Zeitplan, Unterstützung, Verifizierung, reduzierten Dienst, Umstellung, Zugangsschließung und Löschung fest. Probieren Sie vor einer Verlängerung oder einer wesentlichen Erweiterung einen kleinen Export aus. Das Ergebnis dieses Tors ist ein Weg, der getestet werden kann, solange der Anbieter noch ein Partner ist, und nicht erst, wenn aus der Beziehung ein Streit geworden ist.

Sechstens: das öffentliche Protokoll formulieren. Entscheiden Sie, was über den Zweck, die Rolle des Systems, die Nachweise, den menschlichen Weg, Änderungen, Vorfälle und die Kontaktstelle für Einwände veröffentlicht werden kann. Schützen Sie vertrauliche und personenbezogene Informationen, ohne die gesamte Entscheidung in ein privates Gespräch zu verwandeln. Ein öffentliches Protokoll kann sagen, was bekannt ist, was nicht bekannt ist und wann die nächste Überprüfung stattfindet. Seine Aufgabe ist es nicht, das System perfekt erscheinen zu lassen. Es soll das Urteil der Stelle prüfbar machen.

Schreiben Sie schließlich die Ablehnung. Die Ablehnung ist keine dramatische Pressemitteilung. Sie ist ein normales Ergebnis im Entscheidungsprotokoll: Die Anforderung war wesentlich, die Nachweise erfüllten sie nicht, der Abhilfevorschlag wurde geprüft, und die Behörde entschied sich, abzulehnen, einzuschränken, auszusetzen oder einen anderen Weg zu suchen. Ein Beschaffungsvorgang, der dieses Protokoll nicht vorweisen kann, hat den Kauf als unvermeidlich erscheinen lassen, bevor diese Schlussfolgerung verdient war.

Diese Tore können in einer Angebotsantwort, einer Projektstartarchitektur, einem Vertragszeitplan, einem Überprüfungstermin und einem Vorfallhandbuch dargestellt werden. Sie sollten nicht um ihrer selbst willen zu einem größeren Formular werden. Wenn ein Tor nicht ändert, was das Team entscheiden kann, ist es wahrscheinlich Dokumentationstheater. Wenn es einer Person Nachweise und Befugnis zum Handeln gibt, ist es Teil des Dienstes.

Fragen, die sich für eine Ausschreibung lohnen

Die besten Fragen sind nicht die, die einen Anbieter dazu bringen, seine Marketing-Sprache zu wiederholen. Es sind die, die den öffentlichen Zweck und die Nachweisgrenze sichtbar machen. Ein Auftraggeber kann die folgenden Fragen an das System und das Verfahren anpassen:

  • Welche konkrete öffentliche Aufgabe unterstützt die vorgeschlagene Fähigkeit, und welche Aufgaben liegen außerhalb ihres vorgesehenen Verwendungszwecks?
  • Welche Personen, Aufzeichnungen und Datenquellen sind im Geltungsbereich, und welche müssen ausgeschlossen werden?
  • Welche Ausgabe erzeugt das System, und welche Entscheidung oder Handlung kann daraus folgen?
  • Welche Anforderung kann nachgewiesen, welche geprüft und welche vertraglich aufrechterhalten werden?
  • Wie wird die Behörde ein Ergebnis mit der relevanten Version, den Quellen, der Konfiguration und den Aufgabenbedingungen reproduzieren?
  • Was kann ein menschlicher Prüfer sehen, ändern, ablehnen, eskalieren oder stoppen, bevor eine folgenreiche Handlung eintritt?
  • Welche Änderungen an Modell, Daten, Infrastruktur, Unterauftragnehmern oder Richtlinien erfordern eine Benachrichtigung und Neubewertung?
  • Welche Aufzeichnungen und Artefakte kann die Behörde exportieren, in welchen Formaten, mit welcher Bedeutung, welchen Rechten und welchem Aufbewahrungsstatus?
  • Was passiert, wenn der Dienst nicht verfügbar ist, die Nachweise unvollständig sind oder eine Person das Ergebnis anficht?
  • Welche Verpflichtungen zu Support, Prüfung, Vorfällen, Schulung und Ausstieg bestehen nach der ersten Veröffentlichung fort?

Diese Fragen ersetzen nicht die Beschaffungsrichtlinie, das KI-Gesetz, das Datenschutzrecht oder die Branchenvorschriften. Sie sind Aufforderungen an die Behörde, ihre eigenen Verpflichtungen operativ umzusetzen. Ein Anbieter, der sie klar beantworten kann, ist möglicherweise dennoch nicht der richtige Anbieter. Ein Anbieter, der sie nicht beantworten kann, mag dennoch eine nützliche Komponente haben, aber die Behörde sollte eine nützliche Komponente nicht mit einer vollständigen öffentlichen Fähigkeit verwechseln.

Unsere kleine Anmerkung

Bei Dweve umfasst unser AI Compas einen anbieterneutralen Beschaffungs- und Governance-Pfad für regulierte europäische Organisationen. Das RFI- und RFP-Material fordert Teams auf, den Anwendungsfall zu klassifizieren, Ausschlusskriterien anzuwenden, Anbieter zu vergleichen, einen Proof-of-Concept durchzuführen und Nachweise durch Überwachung aufzubewahren. Das ist unser Umsetzungskontext, keine unabhängigen Nachweise über öffentliche Beschaffung und keine Behauptung, dass ein Rahmenwerk zu jeder Behörde passt. Wir erwähnen es, weil die hier beschriebene Disziplin auch die Disziplin ist, die wir in unserer eigenen Arbeit anzuwenden versuchen: die Grenze definieren, Nachweise verlangen, die Entscheidung menschlich halten und den Ausstieg sichtbar machen.

Unser Trust Centre macht dieselbe Unterscheidung in einem anderen Register. Ein öffentlicher Datensatz kann beschreiben, was dokumentiert ist, was vorbereitet ist und was ein zukünftiges Ereignis bleibt, ohne eine Absichtserklärung in einen Nachweis zu verwandeln. Ein Beschaffungsteam verdient dieselbe Ehrlichkeit von seinen Anbietern. Der Käufer sollte den Status einer Behauptung, die Nachweise dahinter und den Weg zu ihrer Anfechtung sehen können.

Die Lektion

Eine öffentliche Behörde wird nicht rechenschaftspflichtig, wenn sie ein KI-System unterzeichnet. Sie wird rechenschaftspflichtig, wenn die Beschaffung erklären kann, warum das System in die Arbeit gehört, welche Belege diese Schlussfolgerung stützen, wer eingreifen darf, was geschieht, wenn sich das System ändert, und wie die öffentliche Funktion fortgeführt werden kann, wenn der Lieferant ausfällt.

Die europäischen Vergabevorschriften bieten bereits wichtige Gewohnheiten: Die Kriterien sollten mit dem Auftragsgegenstand verbunden sein, die Informationen sollten überprüfbar sein, die Gewichtungen sollten angegeben werden und die Vertragsbedingungen sollten klar sein. Die KI-Vergabeklauseln der Europäischen Kommission geben öffentlichen Auftraggebern eine Möglichkeit, über Hochrisiko- und Nicht-Hochrisiko-Systeme zu sprechen und Verantwortlichkeiten zuzuweisen. Das niederländische Algoritmekader verwandelt verantwortungsvolle Beschaffung in praktische Maßnahmen zu Zweck, Daten, Belegen, Prüfung, menschlicher Kontrolle, Stopp und Ausstieg. Der JRC-Bericht ordnet die Beschaffung in die europäische Debatte über Fähigkeiten und Souveränität ein. Die Warnung des EuRH vor schrumpfendem Wettbewerb ist eine Erinnerung daran, dass ein schwacher Wettbewerb nicht durch eine selbstbewusste Zuschlagserteilung repariert wird.

Das schwierige Wort ist immer noch nein. Nein, der Zweck ist nicht definiert. Nein, die Belege können nicht eingesehen werden. Nein, der menschliche Weg ist nur Dekoration. Nein, der Änderungspfad ist unsichtbar. Nein, das öffentliche Protokoll kann nicht geführt werden. Nein, der Dienst kann nicht gehen, ohne die Arbeit zu verlieren, die er schützen sollte. Jedes Nein kann eine Ablehnung sein, eine Eingrenzung, eine Pause oder eine Bitte um eine bessere Antwort. Die Behörde sollte entscheiden, welche dieser Bedeutungen gemeint ist, dies begründen und die Entscheidung für Anfechtungen offenhalten.

Eine Beschaffung, die Nein sagen kann, ist keine Beschaffung, die Technologie fürchtet. Es ist eine Beschaffung, die den Unterschied zwischen einer Fähigkeit und einem Versprechen kennt. Sie bezahlt für ein System, das getestet, überwacht, verändert und verlassen werden kann. Sie bietet Lieferanten einen faireren Wettbewerb, weil die Frage sichtbar ist. Sie gibt öffentlich Bediensteten einen Weg, einzugreifen, bevor ein Problem zur Politik wird. Sie gibt den Menschen, die von dem Dienst betroffen sind, etwas Nützlicheres als die Aussage, dass ein Anbieter zugelassen wurde.

Ein öffentlicher Kauf sollte mit einem Dienst enden, den die Behörde weiterhin steuern kann. Wenn die Belege stark sind, ist ein Ja bedeutungsvoll. Wenn die Belege schwach sind, ist ein Nein die öffentliche Arbeit. Die Beschaffungsakte sollte in der Lage sein, beide Sätze zu enthalten.

Quellen