Die Beschaffungsakte ist das Governance-System

Von Heather Grizzle, Novara Consulting Group

Zusammenfassung

Governance im Bereich künstliche Intelligenz drückt sich zunehmend durch Richtlinien, Ausschüsse, Grundsätze, Inventare und Risikoklassifizierungen aus. Diese Strukturen sind wichtig. Doch wenn eine öffentliche Institution tatsächlich ein KI-System erwirbt und einsetzt, muss Governance schließlich zu etwas viel Konkreterem werden. Sie muss zu einer Akte werden.

Jemand muss beschreiben, was das System tun darf. Jemand muss entscheiden, welche Nachweise ausreichen, um die Behauptungen des Anbieters zu stützen. Jemand muss die Personen identifizieren, die geschädigt werden könnten, wenn das System versagt. Jemand muss festlegen, welche Fehler ein menschliches Eingreifen erfordern, welche Änderungen eine erneute Prüfung verlangen und unter welchen Bedingungen das System ausgesetzt werden muss. Wenn diese Entscheidungen nicht vor der Einführung dokumentiert werden, heilt eine KI-Governance-Richtlinie dieses Versäumnis nicht. Die Beschaffungsakte ist der Ort, an dem institutionelle Grundsätze zu operativen Verpflichtungen werden.

Governance muss irgendwann bei der Transaktion ankommen

Ein Rückfallmechanismus ist nur dann eine Absicherung, wenn die Person, die ihn benötigt, ihn tatsächlich nutzen kann.

Heather Grizzle

Organisationen bauen zunehmend anspruchsvolle Strukturen für die KI-Governance auf. Sie legen Grundsätze für verantwortungsvolle KI fest, richten Prüfungsausschüsse ein, führen Inventare und klassifizieren Systeme nach Risiko. Sie verabschieden Richtlinien, die Fairness, Transparenz, Rechenschaftspflicht, Datenschutz, Barrierefreiheit und menschliche Aufsicht verlangen. Dann beginnt die Beschaffung. Ein Anbieter reagiert auf eine Ausschreibung. Produktvorführungen werden angesetzt. Dokumentation zur Barrierefreiheit wird eingeholt. Sicherheitsfragebögen werden ausgefüllt. Rechtliche Bedingungen werden verhandelt. Fachverantwortliche beschreiben die erwarteten Effizienzgewinne. Die Technologie passiert die etablierten Kontrollpunkte der Institution und wird in Betrieb genommen.

Das Vorhandensein solcher Kontrollpunkte kann zu erheblichem institutionellem Vertrauen führen, doch Vertrauen ist nicht dasselbe wie eine vertretbare Entscheidung. Die entscheidende Governance-Frage lautet nicht nur, ob das System den vorgeschriebenen Prozess durchlaufen hat. Sie lautet, ob die daraus resultierende Akte die Nachweise enthält, die notwendig sind, um den konkret genehmigten Einsatz zu rechtfertigen.

Diese Unterscheidung wird besonders wichtig, wenn KI den Zugang für behinderte Menschen vermittelt. Ein System kann Informationen zusammenfassen, mit Patienten kommunizieren, Bewerber bewerten, Sprache übersetzen, Unterrichtsmaterial erstellen, Fälle priorisieren, Mitarbeitende unterstützen, Nutzer authentifizieren, Fragen beantworten oder zunehmend im Namen einer Institution handeln. In jedem Fall ist Barrierefreiheit nicht einfach ein Merkmal der Benutzeroberfläche. Sie ist Teil der Entscheidungsarchitektur. Eine behinderte Person kann ein System anders erleben als die Bevölkerungsgruppe, für die es primär entworfen, getestet oder validiert wurde, und ein Zugänglichkeitsfehler kann die Informationen verändern, die diese Person erhält, die ihr zur Verfügung stehenden Optionen, ihre Fähigkeit zu reagieren oder die Interpretation ihres Verhaltens durch die Institution. Die Beschaffungsakte muss daher mehr belegen als die bloße Berücksichtigung von Barrierefreiheit. Sie muss festhalten, was berücksichtigt wurde, was getestet wurde, was weiterhin unbekannt ist und wie die Institution mit dieser Unsicherheit umzugehen entschieden hat.

Die Beschaffungsakte als Rechenschaftsinstrument

Beschaffungsakten werden häufig in erster Linie als Verwaltungsunterlagen verstanden. Bei KI sollten sie zunehmend als Governance-Instrumente verstanden werden. Eine ausgereifte Beschaffungsakte für KI sollte es einem unabhängigen Prüfer ermöglichen, die Überlegungen der Institution zu rekonstruieren, ohne sich auf das institutionelle Gedächtnis der am Kauf beteiligten Personen verlassen zu müssen. Das bedeutet, dass die Akte mehrere Fragen beantworten sollte:

1. Wozu genau wurde das System gekauft?
2. Was war ihm ausdrücklich untersagt?
3. Welche Bevölkerungsgruppen sollten voraussichtlich mit ihm in Berührung kommen?
4. Welche Nachweise stützten die Behauptungen, auf die sich die Genehmigung stützte, und wer hat diese Nachweise erstellt?
5. Welche Einschränkungen waren bekannt, und welche blieben unbekannt?
6. Was geschah, wenn das System unsicher oder falsch lag?
7. Wer behielt die Befugnis, es außer Kraft zu setzen?
8. Wie konnte eine betroffene Person sein Ergebnis anfechten?
9. Was würde die Institution dazu veranlassen, den Einsatz zu überdenken?
10. Wer hatte die Befugnis, es zu stoppen?

Dies sind keine Fragen für die Untersuchung eines Vorfalls nach einem Versagen. Es sind Fragen der Beschaffung.

1. Bestimmungsgemäßer Gebrauch und untersagte Nutzung

Die erste Anforderung ist trügerisch einfach: Definieren Sie, was die Institution kauft. KI-Systeme werden häufig anhand breit gefasster Fähigkeitsbeschreibungen erworben. Ein System kann als Assistent, Übersetzer, Barrierefreiheitswerkzeug, Entscheidungsunterstützungssystem, Chatbot, Agent, Screening-Tool oder Produktivitätsplattform beschrieben werden. Diese Bezeichnungen sind als Governance-Spezifikationen unzureichend. Die Beschaffungsakte sollte die tatsächliche institutionelle Funktion benennen.

Ein Kommunikationswerkzeug, das jemandem hilft, sich auf einer Website zurechtzufinden, birgt ein anderes Risiko als dieselbe Technologie, die bei der medizinischen Aufnahme eingesetzt wird. Ein automatisiertes Transkriptionssystem, das zur Erstellung von Sitzungsprotokollen verwendet wird, birgt ein anderes Risiko als eines, das die offizielle Aufzeichnung eines Disziplinarverfahrens erstellt. Ein Gebärdensprach-Erkennungssystem, das experimentell von einer Einzelperson genutzt wird, ist nicht gleichzusetzen mit einem System, das eine Institution als Ersatz für ein anderes Mittel des Kommunikationszugangs darstellt. Dieselbe Technologie kann sich daher zwischen Risikokategorien bewegen, ohne dass sich ihr zugrunde liegendes Modell ändert, weil sich der Einsatzkontext verändert hat.

2. Analyse der betroffenen Bevölkerungsgruppen

Bei der herkömmlichen Beschaffung von Technologie wird gefragt, wer das System nutzen wird. Die KI-Governance muss auch fragen, wer davon betroffen sein wird, und diese Gruppen sind nicht notwendigerweise identisch. Ein Mitarbeiter kann ein KI-System bedienen, während ein Patient, Student, Bewerber, Bewohner, Kunde oder Leistungsempfänger dessen Folgen erlebt. Behinderte Menschen können durch herkömmliche Nutzeranalysen besonders schwer zu identifizieren sein, da Behinderung häufig den Weg durch ein System verändert, statt die nominelle Nutzerkategorie zu betreffen.

Die Beschaffungsakte sollte daher vorhersehbare Wechselwirkungen mit Barrierefreiheit identifizieren. Verarbeitet das System Sprache? Erzeugt oder interpretiert es Sprache? Hängt es von Sehvermögen, Hörvermögen, Feinmotorik, Kognition, Timing, biometrischen Merkmalen oder einer bestimmten Kommunikationsform ab? Schließt es auf Absicht oder Fähigkeit aus Verhalten, das durch Behinderung beeinflusst sein kann? Verändert eine nicht barrierefreie Ausgabe die Fähigkeit einer Person, an einer nachfolgenden Entscheidung teilzunehmen? Diese Fragen machen aus Barrierefreiheit nicht mehr nur ein Compliance-Artefakt, sondern eine Untersuchung des Systemrisikos.

3. Das Register der Anbieteraussagen

Jede wesentliche Behauptung eines Anbieters, auf die sich die Beschaffung stützt, sollte einen eindeutigen Nachweisstatus haben. Nicht jede Behauptung erfordert eine unabhängige Prüfung, aber Institutionen sollten mindestens drei Kategorien unterscheiden. Eine Fähigkeit gilt als behauptet, wenn der Anbieter erklärt, dass sie besteht. Sie gilt als nachgewiesen, wenn Belege zeigen, dass sie unter bestimmten Bedingungen beobachtet wurde. Sie gilt als für den Einsatz abgesichert, wenn Belege eine Verlässlichkeit im vorgesehenen institutionellen Kontext angemessen stützen. Diese Kategorien sind nicht austauschbar.

Eine Vorführung kann belegen, dass ein System in der Lage ist, ein bestimmtes Ergebnis zu erzeugen. Sie belegt nicht zwangsläufig, wie zuverlässig es dieses Ergebnis über verschiedene Bevölkerungsgruppen, Umgebungen oder folgenreiche Anwendungsfälle hinweg liefert. Ebenso kann Dokumentation belegen, was ein Anbieter über sein System behauptet. Sie kann nicht unabhängig belegen, dass diese Behauptung zutrifft. Die Beschaffungsakte sollte diese Unterscheidung bewahren. Andernfalls werden Behauptungen allmählich zu Feststellungen, nur weil sie in genügend vielen Dokumenten wiederholt wurden.

Für den Einsatz abgesichert

A vendor claim status meaning evidence reasonably supports reliance on the capability in the institution’s actual, intended context, not merely that the capability has been observed under demonstration conditions.

4. Independent Assurance

Vendor evidence has a legitimate role in procurement. Vendors know their systems better than purchasers do and should be expected to disclose testing, architecture, limitations, known failure conditions, and relevant performance evidence. But the commercial relationship matters. The party seeking the contract should not be the only party determining whether the evidence is sufficient to award it.

Independent assurance does not mean recreating the vendor’s engineering program. It means testing the claims that matter to the purchasing decision under conditions capable of disproving them. For accessibility-related AI, this may require evaluation involving people with the relevant disability and, where linguistic access is involved, qualified members of the language community. The objective is not ceremonial participation. It is evidentiary authority. The people capable of identifying a consequential failure must have a mechanism for causing that failure to affect the procurement decision. Otherwise, participation exists without governance.

5. Failure and Fallback Architecture

Every AI procurement should contain a written answer to a single question: what happens when the system does not work? “Human in the loop” is not an adequate answer. The record should identify the human, the trigger, the authority, the response time, and the alternative pathway available to the affected person.

For disabled users, the fallback itself must also be accessible. An AI communication system that fails and directs a Deaf person to make a telephone call has not produced a fallback. An automated digital process that becomes inaccessible and requires a blind user to complete the same inaccessible interface has not transferred the person to human oversight in any meaningful sense.

Ein Rückfallmechanismus ist nur dann eine Absicherung, wenn die Person, die ihn benötigt, ihn tatsächlich nutzen kann.

Heather Grizzle

6. Performance Boundaries and Known Unknowns

Procurement documents tend to record what products can do. Governance records also need to state where confidence ends. AI performance is conditional. It may vary according to language, dialect, accent, signing style, lighting, camera position, disability, device, environment, domain terminology, interaction length, demographic characteristics, or countless other variables. Institutions should require vendors to disclose known performance boundaries and should separately document areas that have not been evaluated.

That distinction matters. Not evaluated is not the same finding as failed, but it is also not the same finding as safe. Uncertainty is not a procurement defect if it is recognized and governed. Undocumented uncertainty is.

7. Logging, Traceability, and Reconstruction

When an AI-mediated interaction produces harm, the institution should be able to reconstruct what happened, and that requires decisions about logging before deployment. What system version was operating? What inputs were received? What output was generated? Was the output modified? Did a human review it? What information did that reviewer see? What action followed? Can the institution reproduce the event without retaining data that should never have been retained in the first place?

Traceability and privacy can create legitimate competing requirements. That conflict should be resolved through system design and governance rather than discovered during litigation, an accessibility complaint, or an internal investigation. The procurement file should document the resolution.

8. Complaint, Contestability, and Redress

A person affected by AI needs more than a mechanism for reporting a technical problem. They may need to contest what the institution did because of the system, and that is a different function. If an AI system mistranslates communication, incorrectly characterizes behavior, produces inaccessible information, generates a false inference, or contributes to an adverse institutional action, the affected person needs a pathway to challenge the resulting decision.

The institution should know before deployment who receives the challenge, who investigates it, what evidence is preserved, whether the contested AI output remains operative during review, what remedies are available, and how quickly the institution must respond.

9. Model Change and Revalidation

AI procurement creates a problem that traditional software contracts were not designed to handle particularly well: the product that was evaluated may not remain the product that is deployed. Models are updated. Guardrails change. Training data changes. Interfaces change. Third-party dependencies change. Vendors replace underlying models. Performance can improve in one domain and degrade in another without the purchasing institution initiating any change itself.

The procurement file therefore needs a change-control rule. The relevant question is not whether the vendor is permitted to update its product. It is which changes invalidate the evidence on which the institution relied. Contracts should identify material changes requiring notice, reevaluation, renewed acceptance testing, or approval before continued use in specified contexts. Otherwise, an institution can perform rigorous assurance at acquisition and still find itself governing a materially different system six months later using evidence produced for the previous one.

10. Suspension and Exit Authority

Governance without stop authority is advisory. Someone within the institution must have the authority to restrict, suspend, or terminate an AI deployment when evidence no longer supports its use, and the triggering conditions should not have to be invented during a crisis.

The procurement record should identify both the triggers and the decision authority.

It should also address exit. Who owns or receives institutional data when the relationship ends? What records must be retained? What must be deleted? How does the institution restore the previous service pathway? What happens to people who have become dependent on the AI-mediated process? Exit planning is not merely vendor management. It is continuity-of-access planning.

From AI Policy to Institutional Evidence

The emerging challenge for AI governance is not a shortage of principles. It is translation. Fairness has to become an evaluation criterion. Transparency has to become a disclosure requirement. Human oversight has to become an assigned authority. Accessibility has to become a deployment condition. Accountability has to become a named office and a documented remedy. Monitoring has to become a trigger for action. And responsible AI eventually has to become something a procurement officer can place in a file.

This is particularly important in public institutions because procurement is where abstract institutional commitments encounter money, contracts, vendors, statutory duties, and people who cannot simply choose another government, school, hospital, court, or public service when the technology does not work for them. The procurement file therefore performs a function much larger than recordkeeping. It establishes the institution’s theory of acceptable risk.

NCG Policy Position

Novara Consulting Group holds that AI systems affecting disabled people should not be approved solely because they have satisfied an organization’s general AI governance process. The procurement record should contain sufficient evidence to reconstruct and defend the specific deployment decision.

The standard is not perfect knowledge. No procurement process can eliminate uncertainty. The standard is governed uncertainty: knowing what has been established, what has not, what evidence justified proceeding anyway, and who bears responsibility for the decision.

Closing Position

After an AI failure, institutions often ask whether the vendor should have warned them. Sometimes the answer will be yes. But public accountability requires another question: what evidence did the institution require before it agreed to proceed? That question cannot be outsourced. The vendor can supply evidence. An assessor can evaluate it. A committee can advise. Disabled stakeholders can identify failures that others cannot see. Lawyers can negotiate the allocation of contractual risk. The institution still makes the decision, and its procurement record should prove that it knew what decision it was making.

An AI system is not governed because an organization has an AI policy. It is governed when the institution can show why this system, for this purpose, affecting these people, under these conditions, was permitted to operate.

Heather Grizzle

The procurement file is where that accountability begins.