Ein öffentlicher Dienst kann sein Urteilsvermögen nicht auslagern

Ein Lieferant kann Software, Belege und eine Stellungnahme liefern. Er kann nicht zur öffentlichen Stelle werden, die Zweck, Befugnis, Gründe, Abhilfe und...

Ein öffentlicher Dienst kann sein Urteilsvermögen nicht auslagern

Der Vertrag ist nicht die Entscheidung

Eine öffentliche Stelle kann Software kaufen. Sie kann Hosting, Analysen, eine Empfehlung, einen Arbeitsablauf, eine Übersetzung, ein Ranking oder einen Bericht kaufen. Was sie nicht kaufen kann, ist die Befreiung davon, die öffentliche Stelle zu sein, die handelt. Der Vertrag kann einem Anbieter Arbeit übertragen, aber er überträgt nicht den öffentlichen Auftrag der Institution, ihre rechtliche Befugnis, ihre Pflicht zur Begründung oder ihre Verpflichtung, Abhilfe zu schaffen. Diese Dinge folgen der Entscheidung, nicht der Rechnung.

Das klingt selbstverständlich, bis die Sprache der Vergabe ein Urteil in ein Lieferobjekt verwandelt. Eine Ausschreibung verlangt einen Risikowert. Ein Anbieter liefert einen Risikowert. Ein Vertrag bezeichnet das Ergebnis als beratend. Ein Dienst ändert leise seine Warteschlange, seine Aufmerksamkeit oder seinen Schwellenwert, weil der Wert praktisch ist. Wenn eine Person betroffen ist, kann jeder auf ein anderes Dokument zeigen. Der Anbieter zeigt auf die Leistungsbeschreibung. Das Vergabeteam zeigt auf den Zuschlag. Die Bedienerin zeigt auf den Bildschirm. Die Institution zeigt auf den Vertrag. Der Person, die eine Antwort braucht, bleibt ein Kreis aus zeigenden Fingern und keine verantwortliche Hand.

Öffentliche Arbeit war schon immer mit Delegation verbunden. Eine Gemeinde kann eine Inspektion in Auftrag geben, ein Ministerium kann ein Fallmanagementsystem kaufen und ein Krankenhaus kann einen Planungsdienst beschaffen. Delegation ist nicht das Problem. Das Problem beginnt, wenn der delegierte Bestandteil eine Entscheidung tragen darf, ohne die Befugnis, die Belege und die Überprüfung, die die Entscheidung legitim machen. Ein Werkzeug kann bei einer Aufgabe hervorragend sein und trotzdem der falsche Ort für ein öffentliches Urteil sein. Die Vergabe muss diesen Unterschied bewahren, bevor die Wortwahl eines Anbieters zum Betriebsmodell der Organisation wird.

Die europäische Tradition des öffentlichen Auftragswesens enthält bereits den richtigen Instinkt. Öffentliche Auftraggeber müssen transparent, verhältnismäßig, ohne Diskriminierung und ohne künstliche Einengung des Wettbewerbs handeln. Das ist nicht nur eine faire Art, eine Ausschreibung durchzuführen. Es ist eine Erinnerung daran, dass die Behörde im Kauf sichtbar bleibt. Die öffentliche Stelle wählt einen Zweck, definiert einen Bedarf, legt die Bedingungen fest und übernimmt die Konsequenzen. Ein kluges System lässt diese Entscheidungen nicht verschwinden. Es gibt ihnen lediglich eine teurere Oberfläche.

Urteil ist nicht dasselbe wie Ergebnis

Technische Systeme erzeugen Ergebnisse. Öffentliche Institutionen treffen Entscheidungen. Beides kann nebeneinander bestehen, aber es ist nicht austauschbar. Ein Klassifikator kann eine Kategorie zuweisen. Ein Suchsystem kann Dokumente abrufen. Ein Sprachmodell kann einen Brief entwerfen. Ein Optimierer kann einen Weg durch Beschränkungen finden. Keines dieser Verben enthält für sich genommen die rechtliche oder staatsbürgerliche Frage, was mit einer Person geschehen soll.

Urteil kommt ins Spiel, wenn eine Institution entscheidet, dass ein Ergebnis für eine bestimmte Handlung relevant, ausreichend und befugt ist. Es kommt ins Spiel, wenn konkurrierende Interessen abgewogen werden, wenn eine Ausnahme erwogen wird, wenn eine Regel im Kontext ausgelegt wird, wenn einer Person Gehör geschenkt wird, wenn eine Verzögerung akzeptiert wird, wenn ein Fehler behoben wird und wenn ein Grund genannt wird. Ein Modell kann zu diesen Momenten Informationen beitragen. Es erlangt keine öffentliche Befugnis, indem es genau, schnell oder selbstbewusst präsentiert wird.

Der Unterschied ist wichtig, weil die Vergabe Systeme oft in der Sprache der Fähigkeiten beschreibt. Der Anbieter wird erkennen, bewerten, priorisieren, empfehlen oder automatisieren. Die Sprache der Fähigkeiten ist nützlich, um einen Markt zu finden. Sie reicht nicht aus, um Verantwortung zuzuweisen. Die Ausschreibung muss sagen, welche menschliche oder institutionelle Rolle die Fähigkeit in eine Handlung verwandelt, welche Belege diese Rolle prüfen muss, welche Handlungen verboten sind und wie die betroffene Person das Ergebnis anfechten kann.

Dieser Übergang von Fähigkeit zu Verantwortung ist der erste ernsthafte Akt der Beschaffung. Ohne ihn kauft der Auftraggeber keinen abgegrenzten Dienst. Er kauft eine Lücke in seiner eigenen Verantwortungsbeschreibung. Lücken sind leicht zu ignorieren, solange ein Projekt gefeiert wird. Sie werden erstaunlich greifbar, wenn jemand fragt, warum eine Entscheidung getroffen wurde.

Beginnen Sie mit dem öffentlichen Zweck

Eine verantwortungsvolle Beschaffung beginnt mit dem öffentlichen Zweck, nicht mit einer Modellkategorie. Die Frage ist nicht, ob eine Behörde ein KI-System kaufen darf. Die Frage ist, welche öffentliche Aufgabe Unterstützung braucht, welches Ergebnis die Aufgabe erreichen soll, wer betroffen ist und was als Scheitern gelten würde. Ein enger Zweck macht spätere Entscheidungen möglich. Ein Slogan wie Effizienz steigern überlässt jede folgenreiche Entscheidung dem späteren Zeitpunkt, meist innerhalb einer Lieferantendemo.

Der Zweck sollte in der Sprache des Dienstes formuliert sein. Ein Team muss möglicherweise fehlende Informationen in einer Datei finden, Anfragen an die richtige Fachkraft weiterleiten, eine öffentliche Bekanntmachung übersetzen, eine interne Zusammenfassung entwerfen oder Fälle identifizieren, die Aufmerksamkeit benötigen. Dies sind unterschiedliche Aufgaben mit unterschiedlichen Folgen. Ein Entwurf kann abgelehnt werden. Eine Weiterleitung kann eine Person verzögern. Eine Übersetzung kann den Zugang verändern. Eine Priorisierung kann bestimmen, wer knappe Zeit erhält. Ein einziges Wort, Automatisierung, verbirgt eine ganze Landschaft öffentlicher Macht.

Die Zweckerklärung sollte auch festlegen, was das System nicht tun darf. Es darf einer Sachbearbeiterin helfen, aber nicht über die Anspruchsberechtigung entscheiden. Es darf eine Reihenfolge in der Warteschlange vorschlagen, aber keine Person aus dem Dienst entfernen. Es darf Dokumente sichtbar machen, aber nicht entscheiden, welche Beweise rechtlich relevant sind. Es darf eine Kommunikation vorbereiten, aber nicht ohne die benannte Genehmigung versenden. Der negative Raum ist kein redaktioneller Luxus. Er ist der Weg, wie eine Grenze einen hektischen Dienstag übersteht.

Es gibt einen praktischen Grund, hier streng zu sein. Die Nutzung eines Systems wächst durch Bequemlichkeit. Sobald ein Werkzeug verfügbar ist, fragt das nächste Team, ob es auch eine benachbarte Aufgabe übernehmen kann. Der ursprüngliche Zweck klingt nahe genug. Ein neues Feld wird hinzugefügt, eine neue Datenquelle wird angebunden und eine neue Gruppe von Menschen ist betroffen. Wenn der anfängliche Zweck vage war, kann niemand sagen, ob dies eine kleine Änderung oder ein neuer öffentlicher Akt ist. Die Beschaffung sollte eine Änderungsfrage schaffen, die die Organisation beantworten kann, bevor die neue Nutzung zur Routine wird.

Europäische Regeln machen Verantwortung schwerer zu verbergen

Die Richtlinie 2014/24/EU legt eine vertraute Grundlage für die öffentliche Beschaffung fest: Gleichbehandlung, Nichtdiskriminierung, Transparenz und Verhältnismäßigkeit. Diese Grundsätze schreiben keine bestimmte Technologie vor. Sie verlangen jedoch, dass der öffentliche Auftraggeber ein Verfahren gestaltet, das erklärt und verteidigt werden kann. Eine Anforderung, die nur ein Lieferant ohne einen echten betrieblichen Grund erfüllen kann, ist ein Governance-Problem, nicht nur ein Marktproblem. Eine Anforderung, die nicht geprüft werden kann, ist ein Versprechen mit einer Beschaffungsnummer.

Dieselben Grundsätze gelten, wenn das Beschaffte ein Modell, ein Agent oder ein Entscheidungsunterstützungsdienst ist. Die Behörde muss ihren Bedarf so beschreiben, dass ein fairer Wettbewerb und eine aussagekräftige Bewertung möglich sind. Sie muss Angebote anhand von Kriterien vergleichen, die für den Dienst von Bedeutung sind, nicht nur anhand einer bevorzugten Benchmark des Lieferanten. Sie muss die Belege für die Zuschlagserteilung aufbewahren und den Vertrag verwalten, wenn die Realität von der Ausschreibung abweicht. Transparenz endet nicht mit der Bekanntgabe des Zuschlags. Sie setzt sich durch Leistung, Änderung und Beendigung fort.

The EU AI Act adds a second layer for certain high-risk systems. Article 14 requires human oversight that is effective, proportionate to risk, level of autonomy and context, and capable of detecting anomalies, interpreting outputs, disregarding or reversing them and interrupting the system safely. Article 27 requires relevant public bodies and providers of public services to assess fundamental-rights impacts before deploying specified high-risk systems, and to update the assessment when the context changes. These are operational obligations, not decorative language for a policy page.

The AI Act does not turn every public software purchase into the same legal category. It does something more useful: it makes the relationship between provider, deployer, system and affected person harder to blur. A provider must describe capabilities and limitations. A deployer must use the system appropriately and keep responsibility for its use. Public authorities have registration and information duties for specified high-risk systems. The exact legal application depends on the use and the relevant provisions. The governance lesson is stable: the party buying the capability still owns the context in which the capability acts.

The supplier's output needs a home

Every output used in a public workflow should have a named home. That home is not merely a database table. It is a role with authority to decide whether the output is fit for purpose, what evidence supports it, what happens when it is wrong and which version produced it. If an output has no owner, it will be treated as everybody's concern until the first dispute, when it becomes nobody's job.

Ownership should be split without being fragmented. A service owner knows the public purpose and acceptable risk. A data owner knows the source, quality, access and correction path. A technical owner knows the deployment, security, capacity and integration. A model or supplier owner knows the evaluation, limits and changes. An operational reviewer knows the work and can stop a case from travelling further. These roles can belong to one small team. They cannot be replaced by the phrase human in the loop.

The person who reviews an output needs time, information and authority. If the interface shows only a score, the reviewer cannot inspect its basis. If the queue makes review impossible, the reviewer cannot exercise meaningful oversight. If a policy says the output is advisory while the workflow treats it as the default answer, the reviewer is being asked to provide a signature rather than judgement. A button labelled approve is not a control point when the person behind it cannot safely choose anything else.

Procurement should therefore ask suppliers to describe the hand-off. What exactly enters the system. What comes out. Which uncertainty or limitation travels with the output. What can the operator see. What can the operator change. What does the system do when the input is outside its declared scope. How is a stop action exposed. Which records prove that a review happened. A supplier that can answer those questions is describing an operating service. A supplier that answers only with a performance score is describing a component.

The first visual: responsibility follows the chain

Verantwortung verschwindet nicht an der Grenze zum Lieferanten. Sie zieht sich durch Zweck, Nachweise, Prüfung, Handeln und Abhilfe.

Ein Wert ist kein Grund

Werte sind im Vergabewesen attraktiv, weil sie den Vergleich sauber aussehen lassen. Ein Lieferant kann Genauigkeit, Latenz, Abdeckung oder eine Reduzierung manueller Arbeit melden. Ein Auftraggeber kann die Zahlen in eine Tabelle setzen und das Gefühl haben, die Entscheidung werde objektiv. Messung ist wertvoll. Aber ein Wert beantwortet nur die Frage, für die er entworfen wurde. Er wird nicht allein dadurch zu einem Grund für öffentliches Handeln, dass er eine Dezimalstelle bekommt.

Angenommen, ein System reiht Fälle nach Priorität. Die Einstufung kann nützlich sein, aber der öffentliche Grund ist nicht einfach, dass eine Zahl hoch war. Die Behörde muss wissen, welcher rechtmäßige Zweck die Einstufung erlaubt, welche Daten berücksichtigt wurden, welche Fälle ausgeschlossen sind, was die Einstufung übersieht, wie eine prüfende Person sie korrigieren kann und wie eine Person das Ergebnis anfechten kann. Der Wert ist ein Signal innerhalb einer Entscheidung. Wenn es der einzige Satz ist, den die Behörde hervorbringen kann, ist er kein Beleg für Urteilsvermögen. Er ist ein Beleg dafür, dass die Behörde die Erklärung delegiert hat.

Auch Benchmark-Behauptungen brauchen einen Vertrag. Welche Grundgesamtheit getestet wurde. Welche Labels verwendet wurden. Welche Sprachen und Randfälle einbezogen wurden. Welche Basislinie verglichen wurde. Wie Fehler gewichtet wurden. Was mit fehlenden oder mehrdeutigen Eingaben geschah. Hat ein Mensch das Ergebnis während des Tests korrigiert. Wurde die Auswertung mit derselben Version durchgeführt, die später im Betrieb eingesetzt wird. Ohne diese Angaben kann ein Benchmark interessant sein, aber er kann nicht das volle Gewicht einer Vergabeentscheidung tragen.

Öffentliche Auftraggeber sollten Nachweise in der Form verlangen, die der Dienst später benötigt. Ein technischer Test kann zeigen, ob ein Modell eine Aufgabe erfüllt. Ein Workflow-Test kann zeigen, ob Menschen Fehler erkennen und korrigieren können. Ein Governance-Test kann zeigen, ob eine Entscheidung rekonstruiert und angefochten werden kann. Ein Kontinuitätstest kann zeigen, ob die Behörde handlungsfähig bleibt, wenn ein Lieferant ausfällt. Diese Tests beantworten unterschiedliche Fragen. Sie zu einem einzigen Lieferantenwert zu kombinieren, ist bequem und meist falsch.

Menschliche Aufsicht muss Zähne haben

Menschliche Aufsicht wird oft als das beruhigende letzte Substantiv in einem Systemdiagramm dargestellt. Ein Kasten mit der Beschriftung Mensch erscheint nach dem Modell und vor der Entscheidung. Das Diagramm wirkt verantwortungsvoll. Die eigentliche Frage ist, ob der Mensch das Ergebnis unter den Bedingungen, unter denen der Dienst läuft, verstehen, anfechten und ändern kann.

Artikel 14 des KI-Gesetzes ist in dieser Hinsicht ungewöhnlich konkret. Personen, die mit der Aufsicht betraut sind, sollten relevante Fähigkeiten und Grenzen verstehen, den Betrieb überwachen, Automatisierungsbias erkennen, Ergebnisse interpretieren, entscheiden können, das System nicht zu nutzen oder zu übersteuern, und über ein sicheres Verfahren eingreifen oder unterbrechen können. Das sind Befugnisse. Sie erfordern eine Schnittstelle, Schulung, Arbeitsbelastung, Nachweise, Autorität und Zeit. Sie erfordern außerdem eine Organisation, die eine prüfende Person unterstützt, wenn diese feststellt, dass das System außerhalb seines Anwendungsbereichs arbeitet.

Eine prüfende Person kann keine Aufsicht über ein Ergebnis ausüben, dem der Kontext entzogen wurde. Das Ergebnis benötigt die relevanten Quellenangaben, Warnungen zur Eingabequalität, Version und Zweck. Die prüfende Person braucht eine Möglichkeit, weitere Nachweise anzufordern oder den Fall als ungeklärt zu kennzeichnen. Wenn das System eine Antwort so präsentiert, dass Alternativen aufwendig werden, wird Automatisierungsbias in den Raum hineinkonstruiert. Wenn der einzige Weg, einen Arbeitsablauf zu stoppen, darin besteht, einen Anbieter anzurufen, hat die Behörde ein System gekauft, das sie nicht sicher betreiben kann.

Verhältnismäßigkeit ist wichtig. Ein Entwurfswerkzeug mit geringen Auswirkungen muss nicht dieselben Kontrollen haben wie ein System, das einen Anspruch, eine Inspektion oder den Zugang zu Versorgung unterstützt. Aber verhältnismäßig bedeutet nicht symbolisch. Je mehr das System Rechte, Sicherheit oder wesentliche Dienste beeinflussen kann, desto besser sollte die Behörde nachweisen können, dass Aufsicht möglich war, genutzt wurde und das Ergebnis hätte ändern können. Ein Mensch, der anwesend, aber machtlos ist, ist keine Aufsicht. Er ist ein gepolsterter Haftungsausschluss.

Anfechtbarkeit ist Teil der Dienstleistung

Eine öffentliche Entscheidung ist nicht abgeschlossen, wenn ein interner Arbeitsablauf „erledigt“ meldet. Sie ist ausreichend abgeschlossen, wenn die betroffene Person verstehen kann, was geschehen ist, sachlich relevante Tatsachen korrigieren und den verfügbaren Überprüfungs- oder Rechtsmittelweg nutzen kann. Anfechtbarkeit ist kein optionales Kundenerlebnismerkmal. Sie ist Teil des Verhältnisses der Einrichtung zur Öffentlichkeit.

Die Erläuterungen der Kommission zu den Garantien für automatisierte Entscheidungen in der DSGVO machen den grundlegenden Punkt deutlich. Eine Person sollte keiner ausschließlich automatisierten Entscheidung unterliegen, die rechtliche oder ähnlich erhebliche Auswirkungen hat, außer unter bestimmten Bedingungen und mit bestimmten Garantien. Wo die Garantien gelten, benötigen Personen Informationen, die Möglichkeit menschlichen Eingreifens und einen Weg, ihre Sichtweise darzulegen und die Entscheidung anzufechten. Der genaue rechtliche Weg hängt von der Verarbeitung und dem anwendbaren Recht ab. Das operative Prinzip ist weiter gefasst: Eine betroffene Person braucht einen echten Zugriff auf die Entscheidung, nicht ein allgemeines Versprechen, dass irgendjemand irgendwo sie sich ansehen kann.

Dieser Zugriff muss mit Nachweisen verbunden sein. Wenn eine Person eine Priorisierung anficht, muss die Behörde den relevanten Entscheidungskontext abrufen können, nicht nur die aktuelle Modellversion. Wenn ein Quelldatensatz später korrigiert wurde, muss die Organisation den ursprünglichen Zustand vom korrigierten Zustand unterscheiden und angeben, was sich geändert hat. Wenn eine menschliche Prüferin oder ein menschlicher Prüfer ein Ergebnis abgelehnt hat, sollte der Datensatz zeigen, dass das System nicht die endgültige Entscheidung getroffen hat. Anfechtbarkeit ohne Datensatz ist eine höfliche Einladung, die Frage zu wiederholen.

Anbieter können dazu beitragen, Anfechtbarkeit zu ermöglichen. Sie können versionierte Eingaben, Begründungen, Quellenlinks, Prüfstatus, Korrekturereignisse und Exportformate bereitstellen. Sie können den Dienst anhalten lassen, statt stillschweigend fortzufahren, wenn Nachweise fehlen. Sie können nicht entscheiden, welche Erklärung nach öffentlichem Recht geschuldet ist oder welchen Rechtsbehelf eine öffentliche Stelle gewähren muss. Das sind institutionelle Entscheidungen. Ein Anbieter kann Zugriffe bauen. Die Behörde muss entscheiden, wohin diese Zugriffe führen.

Datengrenzen sind öffentliche Grenzen

In Beschaffungsgesprächen wird Daten oft als eine Eingabe behandelt, die angeschlossen wird, nachdem der Anbieter ausgewählt wurde. In einem öffentlichen Dienst sind Datengrenzen auch Behördenzuständigkeiten. Die Quelle bestimmt, was das System wissen darf, was es ableiten darf, was es aufbewahren darf und welche Personen von einem Fehler betroffen sein können. Ein Anbieter sollte diese Grenzen nicht dadurch festlegen, dass er den Anschluss einfach macht.

Anforderungen sollten autorisierte Quellen, Zweck, Aktualität, Aufbewahrung, Zugriff, Korrektur und Löschung benennen. Sie sollten Primäraufzeichnungen von abgeleitetem Material wie Einbettungen, Zusammenfassungen, Beschriftungen, Caches und Bewertungen unterscheiden. Sie sollten festlegen, welche Daten die Behörde verlassen, welche Unterauftragnehmer sie verarbeiten dürfen und wie Supportzugriff protokolliert wird. Sie sollten definieren, was geschieht, wenn eine Quelle unvollständig, veraltet, umstritten oder außerhalb des ursprünglich erklärten Zwecks ist.

Dies ist nicht nur eine Frage des Datenschutzes. Quelldisziplin beeinflusst die Qualität und Rechtmäßigkeit einer Entscheidung. Eine öffentliche Stelle kann viele Aufzeichnungen besitzen und dennoch keine rechtmäßige oder zuverlässige Grundlage für deren Verwendung in einem bestimmten Arbeitsablauf haben. Ein Modell kann eine Korrelation finden, die technisch nützlich und institutionell inakzeptabel ist. Ein abgerufenes Dokument kann aktuell, aber nicht autoritativ sein. Die Ausschreibungsanforderung muss es einem Betreiber ermöglichen, verfügbare Informationen von gerechtfertigten Informationen zu unterscheiden.

Dieselbe Disziplin hilft dem Anbieter. Klare Quellengrenzen verringern die Versuchung zu versprechen, dass ein allgemeines Modell jede Frage beantworten kann. Sie machen Auswertungen reproduzierbar. Sie definieren, was der Dienst tun soll, wenn eine Eingabe außerhalb seines Vertrags liegt. Ein System, das unzureichende Beweise angeben kann, ist oft nützlicher als eines, das immer eine Antwort liefern kann. Öffentliche Auftraggeber sollten dieses Verhalten belohnen, anstatt eine Verweigerung als Fehler in der Demo zu behandeln.

Anforderungen müssen Fehlerfälle beschreiben

Die meisten Ausschreibungen beschreiben den gewünschten Weg: Daten empfangen, verarbeiten, ein Ergebnis liefern, Leistung messen. Öffentliche Dienste brauchen auch die unerwünschten Wege. Ein Datensatz fehlt. Eine Sprache wird nicht unterstützt. Das Modell ändert sich. Eine Quelle widerspricht einer Regel. Ein Anbieter ist nicht verfügbar. Ein Prüfer ist anderer Meinung. Eine Person legt Widerspruch ein. Die Ausgabe wird außerhalb des vorgesehenen Zwecks verwendet. Eine betroffene Person bittet um Korrektur. Ein Vorfall wird Monate nach der Entscheidung entdeckt.

Fehleranforderungen sollten testbar sein. Das System muss anhalten, wenn ein erforderliches Feld fehlt. Es muss die Version und den Quellbereich hinter einer Empfehlung identifizieren. Es muss ein sicheres Stoppverfahren bereitstellen. Es muss Aufzeichnungen in einem dokumentierten Format exportieren. Es muss die Behörde über wesentliche Änderungen informieren. Es muss einen Korrekturpfad für abgeleitete Artefakte unterstützen. Es muss genügend Kontext für eine autorisierte Untersuchung bewahren. Es darf nicht stillschweigend ein anderes Modell oder eine andere Quellenklasse einsetzen, wenn die erklärte nicht verfügbar ist.

Diese Anforderungen sind keine Versuche, jeden schlechten Tag vorherzusagen. Sie machen die Sicherheitshaltung des Dienstes sichtbar. Ein Anbieter kann eine andere Umsetzung vorschlagen, aber die Behörde kann Vorschläge anhand beobachtbaren Verhaltens vergleichen. Die Ausschreibung dreht sich weniger um eine Liste von Funktionen und mehr darum, ob der Dienst unter Druck Verantwortung tragen kann.

Fehlersprache verbessert auch das kommerzielle Gespräch. Ein Anbieter, der keinen sicheren Stopp, keinen zuverlässigen Export oder keinen Versionshinweis anbieten kann, kann dennoch für eine Aufgabe mit geringen Folgen geeignet sein. Die Behörde kann das offen entscheiden. Sie muss die Einschränkung nicht erst nach der Unterzeichnung entdecken. Niemand braucht eine Ausschreibung, die technisch aufregend und betrieblich belastend ist.

Der Vertrag ist ein Betriebsentwurf

Ein Vertrag für einen KI-gestützten öffentlichen Dienst sollte mehr beschreiben als Verfügbarkeit und Supportzeiten. Er sollte Beweise, Änderungen, Zugriff, Prüfung, Vorfallreaktion und Ausstieg beschreiben. Diese Bedingungen prägen, was die Behörde wissen und tun kann, sobald der Dienst läuft. Sie sind Teil der Architektur, auch wenn sie in rechtlichen Anhängen erscheinen.

Änderungskontrolle ist zentral. Was als wesentliche Änderung von Modell, Prompt, Daten, Abruf oder Richtlinie gilt. Wie viel Vorlauf erforderlich ist. Welche Evaluierungen erneut durchgeführt werden müssen. Wer die Änderung freigeben darf. Was geschieht, wenn sich die Leistung für eine Untergruppe oder eine Sprache verschiebt. Kann die Behörde ein Update aufschieben. Kann sie es zurückrollen. Der Anbieter benötigt möglicherweise Flexibilität, um einen Dienst aufrechtzuerhalten, aber Flexibilität ohne Aufzeichnung ist eine Risikoübertragung, die als Agilität getarnt ist.

Zugriffsbedingungen sollten über Dashboards hinausgehen. Die Behörde benötigt möglicherweise Protokolle, Konfiguration, Testartefakte, Quellkennungen, Supportaufzeichnungen und einen Verlauf der Änderungen. Der Zugriff muss verhältnismäßig und sicher sein, mit geschützten personenbezogenen Daten und getrennten Geheimnissen. Es geht nicht darum, jedes interne Implementierungsdetail zu verlangen. Es geht darum, sicherzustellen, dass die Behörde überprüfen kann, was der Dienst im Kontext seiner Nutzung getan hat.

Störungsbedingungen benötigen benannte Wege und Zeitgrenzen, die den Folgen des Systems entsprechen. Sie sollten festlegen, wer eine Störung melden darf, wer den Arbeitsablauf anhalten kann, welche Beweise aufbewahrt werden, wie betroffene Personen berücksichtigt werden und wie die Behebung überprüft wird. Ein Dienst, der nur Ausfälle der Infrastruktur meldet, meldet nicht die Störungen, die eine öffentliche Stelle am ehesten erklären können muss.

Die Verantwortlichkeit des Anbieters ist real, aber anders

Es ist falsch zu behaupten, dass ein Anbieter keine Verantwortung trägt. Anbieter entwerfen Systeme, machen Zusagen, setzen Grenzen, verwalten Updates, wählen Unterauftragnehmer und kontrollieren Teile der Beweise. Eine öffentliche Behörde sollte sie an diese Zusagen binden. Die technische und vertragliche Verantwortlichkeit des Anbieters ist wichtig, insbesondere wenn die Behörde nicht jede Komponente unabhängig nachvollziehen kann.

Es ist ebenso falsch, die Verantwortlichkeit des Anbieters als Ersatz für institutionelle Verantwortung zu behandeln. Der Anbieter hat den öffentlichen Zweck nicht gewählt, die betroffene Gruppe nicht definiert, nicht entschieden, dass ein Ergebnis für den Dienst ausreichend war, den Rechtsweg nicht festgelegt und nicht bestimmt, welches Risiko die Öffentlichkeit akzeptieren sollte. Diese Entscheidungen gehören der Behörde und dem rechtlichen Rahmen, der sie umgibt. Eine öffentliche Stelle, die sagt, das Modell habe entschieden, beschreibt damit ihr eigenes Versagen, die Entscheidung in öffentlicher Hand zu behalten.

Die sinnvolle Beziehung ist ausdrückliche gegenseitige Abhängigkeit. Der Anbieter liefert eine Komponente oder einen Dienst unter dokumentierten Bedingungen. Der Betreiber integriert sie in einen Zweck, einen Prozess und eine Rollenstruktur. Beide Parteien bewahren Beweise für den Teil auf, den sie kontrollieren. Die Behörde bleibt in der Lage, den Anbieter herauszufordern, die Nutzung auszusetzen und das öffentliche Handeln zu erklären. Wenn das Design eines Anbieters diese Fähigkeiten unmöglich macht, wird die Beschaffungsentscheidung selbst Teil des Risikos.

Gute Verträge verlangen nicht, dass der Anbieter jede unbekannte Haftung übernimmt. Sie verteilen Pflichten so, dass jede Partei sie erfüllen kann. Die Behörde muss einen rechtmäßigen, angemessenen Kontext bereitstellen. Der Anbieter muss Einschränkungen und Änderungen offenlegen. Der Betreiber muss das System im Rahmen des Zwecks nutzen. Der Prüfer muss echte Befugnis haben. Die Aufzeichnungen müssen den Streit überdauern. Präzision bei den Rollen ist freundlicher als eine Klausel, die besagt, dass die Parteien zusammenarbeiten werden, und hofft, dass alle dasselbe Wörterbuch mitbringen.

Portabilität ist eine Beurteilungsanforderung

Der Ausstieg wird oft als kommerzielles Thema behandelt. Für öffentliche Dienste ist er auch ein Beurteilungsthema. Wenn die Behörde die Beweise, die Konfiguration, die Aufzeichnungen und die Entscheidungen nicht abrufen kann, die erforderlich sind, um einen Dienst fortzuführen oder seine Vergangenheit zu untersuchen, kann sie die Entscheidungen, die über den Dienst getroffen wurden, nicht vollständig selbst verantworten. Ein System, das nicht gehen kann, nimmt einen Teil des institutionellen Gedächtnisses mit.

Portabilität sollte den operativen Zustand abdecken, nicht nur die Zeilen in einer Datenbank. Die Behörde benötigt möglicherweise Eingabe- und Ausgabedatensätze, Quellreferenzen, Modell- und Prompt-Versionen, Richtlinieneinstellungen, Überprüfungsentscheidungen, Audit-Ereignisse, Korrekturhistorie, Aufbewahrungsmetadaten und die Schemata, die diese erklären. Die genaue Zusammenstellung hängt vom Dienst ab. Das Prinzip ist, dass ein künftiger Betreiber nachvollziehen können sollte, was geschehen ist, ohne das private Dashboard eines Anbieters zurückentwickeln zu müssen.

Der Ausstieg sollte getestet werden, bevor er dringend wird. Eine kurze Probe kann aufdecken, ob ein Export vollständig ist, ob Identifikatoren stabil bleiben, ob Datensätze ohne Lizenz gelesen werden können, ob abgeleitete Daten abgeglichen werden können und ob der Dienst während eines Übergangs betriebsfähig bleibt. Der Test zeigt auch, welche Teile des Arbeitsablaufs nie wirklich im Besitz der Behörde waren. Ein erfolgreicher Ausstiegstest ist kein Misstrauensvotum gegenüber dem Anbieter. Er ist der Beleg, dass der öffentliche Dienst über einen Ausschalter verfügt.

Kontinuität ist auch dann wichtig, wenn ein Vertrag gut läuft. Anbieter können Eigentümer, Preise, Bedingungen, Infrastruktur oder strategische Ausrichtung ändern. Eine öffentliche Einrichtung sollte keine Krise brauchen, um festzustellen, dass die einzigen Personen, die ihre Entscheidungsabläufe verstehen, für jemand anderen arbeiten. Die Beschaffung ist der Zeitpunkt, an dem Kontinuität zur Normalität statt zur Heldentat wird.

Die zweite Visualisierung: ein Urteilsgatter, kein Abnickstempel

Ein Prüfer ist nur dann ein Kontrollpunkt, wenn der Fall noch geändert werden kann, die Belege sichtbar sind und ein Abhilfeverfahren möglich bleibt.

Die Fähigkeit kaufen, Nein zu sagen

Die stärkste Beschaffungsanforderung ist manchmal eine Ablehnung. Die Behörde sollte Nein sagen können zu einer Nutzung, die nicht belegt werden kann, Nein zu einer Änderung, die nicht bewertet wurde, Nein zu einem Ergebnis außerhalb des Geltungsbereichs und Nein zu einem Anbieter, der keinen funktionsfähigen Ausstieg bieten kann. Das ist keine Technologiefeindlichkeit. Es ist die Mindestunabhängigkeit, die erforderlich ist, um Technologie für einen öffentlichen Zweck zu wählen, statt einen Zweck zu wählen, der zu der bereits gekauften Technologie passt.

Nein zu sagen braucht einen internen Weg. Ein Prüfer muss wissen, wer entscheiden kann, dass ein Fall für die Automatisierung unsicher ist. Ein Dienstverantwortlicher muss pausieren können, ohne auf einen Lenkungsausschuss zu warten, der erst im nächsten Monat tagt. Die Beschaffung muss anerkennen, dass ein Angebot mit weniger Funktionen sicherer sein kann, weil seine Grenzen klarer sind. Rechts-, Technik- und Betriebsteams müssen den bevorzugten Anbieter herausfordern können, bevor die Entscheidung sozial unangenehm wird.

Vendors benefit from this discipline too. A clear no gives them a defined scope in which to improve. It prevents a promising prototype from being sold as a universal answer. It makes acceptance criteria meaningful. It also stops the supplier's most enthusiastic interpretation from becoming the de facto policy. Enthusiasm is a useful fuel for exploration. It is not a substitute for a brake.

The ability to refuse is part of sovereignty at the service level. It says the authority can keep a task human, narrow the data, require more evidence, choose a different supplier or stop a deployment without losing the public purpose. That is a better definition of technological independence than the number of products in a catalogue.

Procurement should include the people who will carry the work

Buying teams need more than a technical evaluation and a legal review. The people who will operate the service should help define the task, the failure modes and the evidence they can realistically inspect. Caseworkers, inspectors, administrators, translators, clinicians, teachers or planners know where a neat output becomes a difficult case. They also know which workarounds will appear when a system does not fit.

Involvement should be specific. Ask operators to walk through representative and difficult cases. Ask them what they need to see before accepting a recommendation. Ask where an appeal begins, where a source is corrected and which deadlines make a pause dangerous. Ask what a safe refusal looks like. These are not user-research gestures. They are requirements discovery for a service that will be operated by humans rather than by the slide deck.

Affected people should be considered as well. Their perspective may reveal that a technical distinction does not make an intelligible explanation, that a correction route is too slow or that a translated notice changes the practical meaning. Public procurement cannot turn every service into a consultation, but it can test whether the proposed boundary is visible from outside the institution. A person should not have to understand the architecture to understand how to challenge an outcome.

The result is usually less elegant than a demo and more durable than one. Real work contains interruptions, exceptions, language differences, old records, accessibility needs and people who do not behave like test data. That is not a failure of public service. It is the public service. Procurement should buy for that world.

Monitoring is how ownership continues

Ownership does not end at launch. Models, source systems, policies, staff behaviour and public needs change. A system can keep returning outputs while its meaning drifts. Monitoring should therefore connect technical signals to the public action they support. Uptime and latency matter, but so do overrides, corrections, appeals, queue effects, missing evidence, subgroup outcomes, language coverage and the severity of errors.

The monitoring plan should state what happens when a signal crosses a threshold. Who investigates. Who can pause. What records are preserved. Which people may have been affected. Whether the supplier is contacted. When the authority communicates. How a remedy is verified. A dashboard that has no response rule is not governance. It is a very colourful suggestion.

Evaluation should be repeated after material changes and at intervals appropriate to the use. A model update may alter output even when the supplier says the interface is unchanged. A policy change may alter what a correct output means. A new data source may introduce a proxy or a different error pattern. A public body needs enough version history to compare states and enough authority to decide that an apparently small change requires a wider review.

Monitoring schützt auch die prüfende Person. Wenn erwartet wird, dass eine Person ein System übersteuert, sollte die Organisation nachvollziehen, ob Arbeitsaufwand, Schnittstelle oder Anreize dies praktisch ermöglichen. Hohe Übersteuerungsraten können auf ein schwaches Modell, eine unklare Richtlinie oder eine prüfende Person hinweisen, die die eigentliche Arbeit rund um ein schlecht gestaltetes Werkzeug leistet. Jede Übersteuerung als menschliches Rauschen zu behandeln, ist ein einfacher Weg, die tatsächliche Spezifikation des Systems zu übersehen.

Ein hypothetischer Dienst macht die Grenze sichtbar

Betrachten wir einen hypothetischen öffentlichen Dienst, der Anträge erhält und ein System eines Anbieters nutzt, um fehlende Informationen zu erkennen und eine Route für die Prüfung vorzuschlagen. Das System darf nicht über die Berechtigung entscheiden. Die Behörde hat den Zweck, die Datenquellen und die Fälle, die besondere Aufmerksamkeit erfordern, dokumentiert. Eine prüfende Person sieht die Quellenverweise, die Erklärung zu fehlenden Feldern, die Systemversion und eine klare Option, den Vorschlag zu ignorieren. Der Datensatz bewahrt die Aktion der prüfenden Person und die an die antragstellende Person gesendete Mitteilung.

In diesem Beispiel hat der Anbieter eine sinnvolle Aufgabe. Er kann die Extraktion verbessern, Unsicherheit offenlegen, sichere Aktualisierungen unterstützen und seine Pflichten bei Vorfällen und Exporten erfüllen. Die Behörde behält den Zweck des Dienstes, den rechtlichen Standard, die Prüfrolle und den Rechtsbehelf. Wenn ein Feld falsch ist, kann die antragstellende Person es korrigieren. Wenn der Vorschlag außerhalb des Rahmens liegt, kann die prüfende Person ihn ablehnen. Wenn das System ausfällt, kann die Behörde die Route pausieren und mit einer dokumentierten Alternative fortfahren. Der Nutzen ergibt sich aus der Grenze, nicht aus der Annahme, der Anbieter sei zur Institution geworden.

Nun ändern wir eine Bedingung. Die vorgeschlagene Route des Systems wird als Standard behandelt, prüfende Personen sehen nur eine Farbe und ein Konfidenzabzeichen, und der Anbieter kann das Modell aktualisieren, ohne dass eine Mitteilung den Verantwortlichen des Dienstes erreicht. Der Vertrag nennt die Ausgabe weiterhin beratend. Der Arbeitsablauf hat sie zu einer Autorität gemacht. Deshalb können rechtliche Bezeichnungen ein Betriebsdesign nicht retten, das der Ausgabe die Macht zur Entscheidung verleiht.

Das hypothetische Beispiel ist bewusst schlicht. Es enthält keine erfundene Gemeinde, keinen Vorfall und keine Kundschaft. Sein Zweck ist es, die Entscheidungen sichtbar zu machen, die die Beschaffung treffen muss. Reale Dienste werden Komplexität hinzufügen. Die Fragen bleiben: Wer definiert die Nutzung, wer sieht die Belege, wer kann das Ergebnis ändern, wer hält den Grund fest und wer kann den Schaden beheben.

Was eine öffentliche Beschaffungsstelle fragen sollte

Ein praktisches Beschaffungspaket kann diese Prinzipien in Fragen umwandeln, die Bieter und interne Teams beantworten müssen. Die Liste ist keine universelle Vorlage, und jeder Sektor benötigt seine eigenen rechtlichen und operativen Details. Sie ist ein Weg, die Grenze frühzeitig in den Raum zu holen.

  • Welche öffentliche Aufgabe wird unterstützt, und welche Handlungen sind ausdrücklich außerhalb des Rahmens?
  • Wer ist betroffen, was könnte eine falsche Ausgabe ändern und wie reversibel ist diese Änderung?
  • Welche Daten, Quellen, Versionen und Annahmen werden verwendet, und wer kann sie korrigieren?
  • Welche Belege begleiten eine Ausgabe, und kann eine autorisierte prüfende Person sie einsehen und anfechten?
  • Was passiert, wenn die Eingabe fehlt, widersprüchlich, nicht unterstützt oder außerhalb der erklärten Verteilung liegt?
  • Welche Rolle kann ablehnen, übersteuern, pausieren, stoppen oder eskalieren, und ist diese Rolle besetzt und autorisiert?
  • Wie werden Änderungen an Modell, Prompt, Abruf, Richtlinie und Daten identifiziert, getestet, genehmigt und rückgängig gemacht?
  • Wie erhält eine betroffene Person Mitteilung, Korrektur, Erklärung und einen praktikablen Prüfweg?
  • Welche Protokolle, Datensätze und Exporte bleiben der Behörde während des Vertrags und nach dem Ausstieg verfügbar?
  • Was meldet der Anbieter als Vorfall, und wie wird die Behebung nachgewiesen?

Diese Fragen ersetzen weder eine Ausschreibung, eine Folgenabschätzung noch eine Rechtsberatung. Sie machen es für jedes Dokument schwerer, davon auszugehen, dass ein anderes Dokument den schwierigen Teil übernimmt. Sie ermöglichen es einem Käufer außerdem, Anbieter nach den Dingen zu vergleichen, die einen Dienst steuerbar machen, und nicht nur nach den Dingen, die eine Demo beeindruckend wirken lassen.

Unsere kleine Anmerkung, spät und mit Absicht

Bei Dweve arbeiten wir an gesteuerten Systemen, daher kennen wir die Versuchung, das Produkt zur Hauptsache zu machen. Die nützlichere Disziplin ist kleiner: den Zweck benennen, die Befugnis binden, Nachweise verknüpft halten, Übergaben nachvollziehbar machen und einen Weg für Korrekturen offenlassen. Unser eigenes Beschaffungs- und Governance-Material geht von diesen Grenzen aus, denn ein rechenschaftspflichtiger Arbeitsablauf ist wichtiger als eine überzeugende Beschreibung eines Werkzeugs. Das ist ein Beispiel für eine Designposition, kein Beleg dafür, dass ein Produkt eine öffentliche Einrichtung ersetzen kann.

Es geht nicht darum, dass jeder öffentliche Käufer unsere Software nutzen sollte oder dass eine einzige Architektur die Beschaffung löst. Es geht darum, dass für uns derselbe Test gilt wie für alle anderen. Kann ein Käufer verstehen, was gekauft wird, was es tun darf, welche Nachweise es hinterlässt, wie es sich verändert und wie der Käufer aussteigt. Wenn die Antwort Nein lautet, hat der Käufer einen Grund, weiter Fragen zu stellen, egal wie europäisch, offen oder wohlerzogen der Anbieter klingt.

Die Entscheidung bleibt bei der öffentlichen Stelle

Öffentliche Beschaffung wird oft als Weg zu einem guten Preis-Leistungs-Verhältnis beschrieben. Das stimmt, aber Wert ist nicht nur ein niedrigerer Preis oder ein schnellerer Prozess. Ein öffentlicher Dienst braucht auch die Fähigkeit, Gründe anzugeben, Fehler zu korrigieren, Prüfungen standzuhalten, Rechte zu schützen und weiterzuarbeiten, wenn sich eine Komponente ändert. Ein System, das Zeit spart und diese Pflichten zugleich unmöglich macht, ist kein gutes Preis-Leistungs-Verhältnis. Es ist ein künftiger Streit, der mit Rabatt gekauft wurde.

Ein Anbieter kann Leistungsfähigkeit, Nachweise, Wartung und einen Weg zur Verbesserung bereitstellen. Die Behörde muss Zweck, Befugnis, Urteilsvermögen, Abhilfe und Eigentümerschaft bereitstellen. Der Vertrag sollte diese Beziehungen ausdrücklich regeln. Der Arbeitsablauf sollte sie sichtbar machen. Die Aufzeichnung sollte sie wiederherstellbar machen. Die betroffene Person sollte die Tür finden können, durch die eine Korrektur eintreten kann.

Deshalb kann ein öffentlicher Dienst sein Urteilsvermögen nicht auslagern. Die Einrichtung darf eine Aufgabe delegieren, aber sie kann die öffentliche Bedeutung des Ergebnisses nicht delegieren. Sie darf ein Modell nutzen, aber sie darf die Zuversicht des Modells nicht als Grund nutzen, mit dem Nachdenken aufzuhören. Sie darf einen Assistenten kaufen, aber sie kann nicht einen Assistenten kaufen und den Assistenten dann als rechenschaftspflichtige Partei bezeichnen. Öffentliche Befugnis wandert nicht allein deshalb, weil ein Softwarediagramm einen Pfeil hat.

Die ehrliche Beschaffungsfrage lautet daher nicht, ob der Anbieter dies automatisieren kann. Sie lautet, ob die öffentliche Stelle in der Lage bleibt, zu verstehen, infrage zu stellen, anzuhalten, zu korrigieren, zu erklären und auszusteigen, während der Anbieter hilft. Wenn die Antwort Ja lautet, hat die Technologie einen Platz in einem steuerbaren Dienst. Wenn die Antwort Nein lautet, kann die richtige Entscheidung darin bestehen, die Nutzung einzuschränken, den Vertrag zu ändern oder den Kauf abzulehnen. Eine öffentliche Stelle, die Nein sagen kann, tut immer noch ihre Arbeit.

Quellen