Die endgültige GSA-LLM-Regelung grenzt ihren Anwendungsbereich ein, nimmt KI-Auftragnehmer jedoch weiter in die Pflicht
Die endgültige GSA-LLM-Regelung tritt am 19. Oktober 2026 in Kraft und hat einen engeren Anwendungsbereich, bringt für erfasste KI-Auftragnehmer des Bundes jedoch weiterhin erhebliche Compliance-Pflichten mit sich.
Die General Services Administration richtet sich nun auf Systeme, bei denen Funktionen großer Sprachmodelle ein wesentliches Merkmal darstellen und Regierungsdaten direkt in das Modell eingegeben werden oder aus ihm hervorgehen. Interne Backoffice-Tools und beiläufige KI-Funktionen können außerhalb der Klausel fallen.
Mit dieser Änderung reagiert die Behörde auf einige der stärksten Einwände der Technologiebranche gegen frühere Entwürfe. Die endgültige Fassung setzt sich jedoch weiterhin über widersprechende kommerzielle Vereinbarungen hinweg, erfasst relevante Unterauftragnehmer und enthält detaillierte Vorgaben für Datensicherheit, Dokumentation, Meldung von Vorfällen, Modelländerungen und Vertragsabschluss.
Das Ergebnis ist ein Kompromiss, kein weitreichender Rückzug. Die GSA hat das Risiko verringert, dass gewöhnliche Software in ein KI-spezifisches Vertragsregime einbezogen wird. Anbieter, die tatsächliche LLM-Produkte an die Regierung verkaufen, müssen weiterhin ein Maß an operativer Transparenz ermöglichen, das bei vielen kommerziellen Bereitstellungen nicht erforderlich ist.
Die endgültige GSA-LLM-Regelung verwendet einen zweiteiligen Anwendungsbereichstest
Die endgültige Klausel konzentriert sich auf KI-Systeme, die die Regierung gezielt beschafft, statt auf jedes Auftragnehmersystem, das zufällig ein LLM verwendet.
Die GSA führte die Klausel 552.239-7001, Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems, mittels einer Klassenabweichung von der General Services Acquisition Regulation ein. Eine Klassenabweichung ermöglicht es der Behörde, Beschaffungsvorgaben anzuwenden, bevor die übliche Kodifizierung abgeschlossen ist.
Die Änderung erscheint im September-Update der GSA zu der endgültigen Klausel. Das Update ist Teil von RGO-2026-01, einer umfassenderen Überarbeitung der Beschaffungsvorschriften der Behörde.
Die Klausel gilt, wenn zwei Bedingungen erfüllt sind. Erstens muss die GSA ein LLM, einen generativen Assistenten, einen Chatbot, ein agentisches System, ein LLM-gestütztes Produktivitätstool oder ein ähnliches Produkt beschaffen, bei dem LLM-Funktionalität wesentlich ist.
Zweitens müssen Regierungsdaten direkt an das LLM übermittelt oder von ihm erzeugt werden. Diese zweite Bedingung verknüpft den Compliance-Aufwand mit tatsächlichen Modellinteraktionen statt mit dem bloßen Vorhandensein von KI irgendwo im Technologie-Stack eines Auftragnehmers.
Das ist deutlich enger gefasst als der Vorschlag vom Juni. Der vorgeschlagene Text galt im Allgemeinen, wenn Regierungsdaten von einem LLM verarbeitet würden – eine Formulierung, die unterstützende Systeme und beiläufige Nutzungen hätte erfassen können.
Die endgültige Klausel enthält zudem eine selbstaufhebende Regelung. Sofern ein Beschaffungsbeauftragter nichts anderes bestimmt, begründet sie keine Verpflichtung, wenn die LLM-Nutzung auf interne Geschäfts-, Backoffice-, Betriebs- oder Leistungsunterstützungssysteme beschränkt bleibt, auf die die Regierung nicht zugreift.
Ein zweiter Ausschluss betrifft kommerzielle Produkte, deren LLM-Funktion beiläufig oder ergänzend ist. Der Ausschluss greift, wenn KI weder der Hauptzweck des Produkts noch eine Vertragsanforderung oder eine von der Regierung genutzte Funktion ist und keine Regierungsdaten verarbeitet.
Diese Unterscheidungen sind für Auftragnehmer wichtig, die generative KI einsetzen, während sie eine andere Dienstleistung erbringen. Ein Beratungsunternehmen könnte einen internen Assistenten zur Organisation seiner Arbeit nutzen, ohne diesen Assistenten an die GSA zu verkaufen. Ein herkömmliches Softwareprodukt könnte eine optionale KI-Funktion enthalten, die die Behörde nie aktiviert.
Für solche Situationen spricht nun mehr für einen Ausschluss. Die endgültige Klausel macht jedoch nicht jeden internen KI-Workflow unsichtbar. Auftragnehmer müssen weiterhin prüfen, ob Regierungsdaten in eine erworbene, zugängliche oder vertraglich vorgeschriebene LLM-Funktion eingegeben werden.
Auch die Definition von Regierungsdaten wurde präziser. Erfasste Dateneingaben werden von oder im Namen der Regierung übermittelt, statt lediglich für sie erstellt zu werden. Metadaten und Protokolle sind von den erfassten Datenausgaben ausgenommen.
Diese Anpassung begrenzt den Umfang der von der Klausel kontrollierten Informationen. Sie beseitigt jedoch nicht die Notwendigkeit einer Datenzuordnung, denn Prompts, abgerufene Inhalte, generierte Antworten, Embeddings und Materialien für Fine-Tuning können weiterhin erfasste Grenzen überschreiten.
Die Ausschlüsse funktionieren daher eher als Klassifizierungsregeln denn als pauschale Ausnahmen. Anbieter benötigen Nachweise darüber, was die Regierung erwirbt, auf welche Funktionen sie zugreift, wohin Daten fließen und ob ein LLM wesentlich zur erbrachten Dienstleistung beiträgt.
Der offizielle Text schafft zudem ein Auslegungsproblem. Sein selbstaufhebender Absatz nennt den Backoffice-Ausschluss und den Ausschluss für beiläufige Funktionen, ohne sie eindeutig mit „und“ oder „oder“ zu verbinden.
Diese Formulierung lässt offen, ob jede Bedingung für sich die Klausel ausschließt oder ob beide Bedingungen erfüllt sein müssen. Beschaffungsbeauftragte müssen die Antwort möglicherweise während Ausschreibungen oder Verhandlungen klären.
Die praktische Lehre ist eindeutig. Auftragnehmer sollten nicht annehmen, dass eine KI-Funktion allein deshalb erfasst ist, weil sie existiert. Ebenso sollten sie nicht annehmen, dass die Bezeichnung einer Funktion als beiläufig die Frage abschließend klärt.
Eine Leistungsbeschreibung, Produktbeschreibung, Systemarchitektur und der tatsächliche Datenfluss werden mehr Gewicht haben als ein Produktetikett. Das ist die erste große Verschiebung, die durch die endgültige GSA-LLM-Regelung eingeführt wird.
Ein NIST-Framework ersetzt vier starre Lieferkettenrollen
Die GSA ist von festen Anbieterbezeichnungen zu Lebenszyklusaufgaben übergegangen, doch Hauptauftragnehmer bleiben dafür verantwortlich, jeden erfassten Beteiligten zu identifizieren.
Der Vorschlag vom Juni teilte die LLM-Lieferkette in vier definierte Rollen ein: Entwickler, Systembetreiber, Systemintegrator und Dienstleister. Jede Rolle war mit einer zugehörigen Klausel und einem vorgeschriebenen Satz von Weitergabepflichten verbunden.
Weitergabe bedeutet, dass ein Hauptauftragnehmer relevante staatliche Anforderungen in Vereinbarungen mit Unterauftragnehmern aufnehmen muss. Sie verhindert, dass eine Verpflichtung auf der ersten Vertragsebene endet, wenn ein anderes Unternehmen die Technologie oder Daten tatsächlich verarbeitet.
Die endgültige Klausel ersetzt diese vier formalen Kategorien durch Aufgabenbeschreibungen aus dem vom National Institute of Standards and Technology veröffentlichten KI-Risikoframework.
Die genannten Aufgaben umfassen KI-Design, KI-Entwicklung, KI-Bereitstellung sowie Betrieb und Überwachung. Sie erstrecken sich auf Tätigkeiten wie die Definition von Systemanforderungen, die Entwicklung von Modellen, die Integration von Komponenten, die Überführung von Systemen in den Produktivbetrieb und die Bewertung von Ausgaben nach dem Start.
Dieser Ansatz bildet besser ab, wie moderne KI-Produkte zusammengesetzt werden. Ein Unternehmen kann ein Modell hosten, ein anderes die Retrieval-Infrastruktur bereitstellen und ein drittes das System mit Regierungsabläufen verbinden.
Eine traditionelle Rollenbezeichnung kann diese überlappenden Verantwortlichkeiten verschleiern. Ein aufgabenbasierter Test fragt, was jeder Beteiligte tatsächlich tut und ob er dabei Regierungsdaten verarbeitet.
Der Hauptauftragnehmer muss an Unterauftragnehmer, die diese Aufgaben ausführen, die anwendbaren Anforderungen weitergeben, wenn diese Regierungsdaten erfassen, verarbeiten, speichern, aufbewahren, zum Training oder Fine-Tuning verwenden oder anderweitig handhaben.
Diese Formulierung reicht über Modellentwickler hinaus. Cloud-Anbieter, Hosting-Unternehmen, Systemintegratoren, Retrieval-Anbieter, Evaluierungsdienste und Partner für Managed Operations können alle Teil der Compliance-Kette werden.
Die Klausel verlangt angemessene Bemühungen bei der Auswahl und Überwachung dieser Unterauftragnehmer. Auftragnehmer können sich auf Bestätigungen, unabhängig überprüfbare Nachweise, Model Cards, System Cards, Sicherheitsdokumentation, Audit-Unterlagen und relevante Zertifizierungen stützen.
Bestehende Unterlagen können die Anforderung erfüllen, wenn sie die Compliance nachvollziehbar belegen. Der Auftragnehmer muss nicht allein zur Erfüllung der Klausel doppelte Aufzeichnungen erstellen.
Der Hauptauftragnehmer muss diese Unterlagen jedoch weiterhin mit dem erfassten System verknüpfen. Eine allgemeine Sicherheitszertifizierung erklärt nicht automatisch, ob ein Anbieter auf Regierungs-Prompts trainiert, generierte Ausgaben aufbewahrt oder die erforderliche Löschung unterstützt.
Die endgültige Fassung behandelt vollständig offene Modelle und Open-Source-LLM-Komponenten besonders. Auftragnehmer müssen für diese Komponenten keine Bestimmungen zu Herkunft, Eigentum, Gerichtsbarkeit oder ausländischer Kontrolle weitergeben.
Die GSA definiert ein vollständig offenes Modell strenger als die vage Formulierung „Open Source AI“, die häufig im Marketing verwendet wird. Architektur, Gewichte, relevanter Code sowie Trainings-, Validierungs- und Testdatensätze müssen unter geeigneten Lizenzen öffentlich einsehbar sein.
Open-Weight-Modelle erhalten nicht dieselbe Einstufung, nur weil ihre Parameter herunterladbar sind. Wenn der zugehörige Code und die Daten weiterhin nicht verfügbar sind, behandelt die GSA das System anders als ein vollständig offenes Modell.
Diese Unterscheidung beeinflusst die Due Diligence. Offene Komponenten können durch öffentlich verfügbare Gewichte, technische Berichte, Modelldokumentation und Offenlegungen zu Trainingsdaten dokumentiert werden. Eine separate vertragsbezogene Bestätigung ist nicht immer erforderlich.
Open-Weight-Modelle erfordern weiterhin eine dokumentierte Prüfung nach bestem Bemühen. Der Auftragnehmer muss die Dokumentation, Tests, technischen Berichte und die Rolle des Modells bei der Vertragserfüllung berücksichtigen.
Die NIST-Struktur gibt Auftragnehmern mehr Flexibilität als die Taxonomie vom Juni. Gleichzeitig erhöht sie den Druck, eine genaue Lieferkettenkarte zu pflegen.
Ein Hauptanbieter kann nicht einfach jedem Unternehmen eine Bezeichnung zuweisen und weitermachen. Er muss verstehen, welche Lebenszyklusaufgaben jede Partei ausführt, welche Regierungsdaten jede Partei verarbeitet und welche Absätze der Klausel gelten.
Diese Arbeit kann schwierig werden, wenn kommerzielle KI-Dienste ihre Unterauftragsverarbeiter, Hosting-Standorte oder Modellfamilien ändern. Vertragsteams benötigen Engineering- und Beschaffungsunterlagen, die während der gesamten Leistungserbringung konsistent bleiben.
Die endgültige Klausel tauscht somit starre Kategorisierung gegen fortlaufende faktenbasierte Analyse. Die Struktur ist anpassungsfähiger, aber bei komplexen Bereitstellungen nicht unbedingt weniger aufwendig.
Erweiterter IP-Schutz bewahrt nicht jede kommerzielle Vertragsbedingung
Auftragnehmer behalten stärkere Rechte an bereits bestehender Technologie, während die Regierung ihrer Klausel weiterhin Vorrang vor widersprechenden Anbietervereinbarungen einräumt.
Geistiges Eigentum war einer der umstrittensten Aspekte des früheren GSA-Ansatzes. Der Entwurf vom März enthielt eine umfassende staatliche Lizenz und Beschränkungen, die Anbieter alarmierten, deren Produkte auf wiederverwendbarer kommerzieller Technologie beruhen.
Die Juni-Fassung änderte diese Struktur, doch die Bedenken der Branche blieben bestehen. Die endgültige Klausel bietet nun ausdrücklicheren Schutz für Materialien, die vor dem Vertrag geschaffen oder unabhängig für eine breitere kommerzielle Nutzung entwickelt wurden.
Die Regierung erwirbt weder Eigentum an bereits bestehenden kommerziellen Produkten eines Auftragnehmers noch an proprietärer Technologie oder Materialien, die bei mehreren Kunden eingesetzt werden. Die Anerkennung umfasst Software, Konfigurationen, Workflows, Dokumentation, Modelle, Skripte, technische Methoden und Know-how.
Sie schützt auch dienstgenerierte Informationen, Analysen, Inhalte von Wissensdatenbanken und verwandte Materialien, wenn diese als bereits bestehende oder unabhängig entwickelte kommerzielle Vermögenswerte gelten.
Dieser Schutz erkennt ein zentrales Merkmal von KI-Verträgen an. Anbieter entwickeln nur selten ein vollständiges Modell und eine unterstützende Plattform für einen einzigen Regierungskunden. Sie passen gemeinsame Infrastruktur, Workflows, Evaluierungen und technische Komponenten für viele Bereitstellungen an.
Der endgültige Text grenzt auch die Abtretung von Verbesserungen ein, die aus Regierungsdaten abgeleitet werden. Allgemeine Verbesserungen der Leistungsfähigkeit verbleiben beim Auftragnehmer, sofern sie keine erfassten Regierungsinformationen einbeziehen, offenlegen, preisgeben oder daraus abgeleitet werden.
Diese Ausgliederung verringert das Risiko, dass gewöhnliche Plattformverbesserungen automatisch Eigentum der Regierung werden. Ein Anbieter kann eine allgemeine Planungsmethode verfeinern oder die Systemzuverlässigkeit verbessern, ohne diese Arbeit allein deshalb abtreten zu müssen, weil die Erkenntnisse während eines Bundesauftrags gewonnen wurden.
Die Abgrenzung wird schwieriger, wenn eine Verbesserung unmittelbar von Regierungsdaten abhängt. Fine-Tuning, Retrieval-Indizes, spezialisierte Evaluierungsdatensätze oder domänenspezifische Workflows können wiederverwendbares Engineering mit kundenbezogenen Informationen verbinden.
Auftragnehmer müssen diese Unterscheidung dokumentieren, bevor es zu einer Auseinandersetzung kommt. Getrennte Repositories, Aufzeichnungen zur Datenherkunft, Modellinventare und Änderungshistorien können zeigen, ob eine Verbesserung verallgemeinert oder regierungsspezifisch ist.
Die Klausel erweitert außerdem den Begriff der Hintergrunddaten. Auftragnehmer dürfen das Eigentum an qualifizierenden Informationen behalten, die sie besitzen, kontrollieren oder lizenzieren, einschließlich Material, das zur Entwicklung oder Verbesserung eines LLM verwendet wird.
Frühere Formulierungen bezogen sich auf Hintergrunddaten in ihrer ursprünglichen Form. Die Aufhebung dieser Einschränkung unterstützt den fortdauernden Eigentumsanspruch des Auftragnehmers, wenn qualifizierendes Material während der Vertragserfüllung verändert oder verbessert wird.
Die IP-Verbesserungen erhalten jedoch nicht jede übliche kommerzielle Bedingung. Die endgültige Klausel besagt, dass sie bestehende Bedingungen der Federal Acquisition Regulation und GSAR ergänzt, behält jedoch Vorrang gegenüber kollidierenden kommerziellen Vereinbarungen.
Diese Regel kann mit gewöhnlichen Cloud- und KI-Verträgen kollidieren. Standardbedingungen von Anbietern beschränken häufig den Prüfzugang, legen einseitige Rechte zu Modelländerungen fest, erlauben Serviceverbesserungen unter Nutzung von Kundeninteraktionen oder definieren weitreichende Aufbewahrungspraktiken.
Ein Bundesvertrag kann sich nicht sicher auf diese Standardvorgaben stützen, wenn die GSA-Klausel etwas anderes bestimmt. Hauptauftragnehmer müssen ihre Vereinbarungen mit vorgelagerten Anbietern prüfen, bevor sie der Regierung Compliance zusagen.
Am akutesten ist das Problem für Wiederverkäufer und Integratoren. Sie können gegenüber der GSA für eine Verpflichtung verantwortlich sein, die der zugrunde liegende Modellanbieter vertraglich nicht akzeptiert hat.
Ein Wiederverkäufer könnte eine Vorankündigung einer wesentlichen Modelländerung zusagen, ohne von seinem Anbieter eine entsprechende Zusage zu erhalten. Er könnte zudem staatliche Löschanforderungen akzeptieren, die über die üblichen technischen Kontrollen des Anbieters hinausgehen.
Der erweiterte IP-Schutz löst daher nur einen Teil des kommerziellen Konflikts. Anbieter erhalten klarere Eigentumsgrenzen, müssen die staatlichen Anforderungen jedoch weiterhin mit den operativen Bedingungen jedes wichtigen Lieferanten in Einklang bringen.
Die endgültige Regel begünstigt Auftragnehmer gegenüber früheren Entwürfen, macht die Beschaffung von LLMs durch Bundesbehörden jedoch nicht zu einem gewöhnlichen Software-Abonnement.
Datenkontrollen und Vorfallmeldungen bleiben von großer Bedeutung
Der engere Anwendungsbereich schwächt die Klausel nicht, sobald ein System qualifiziert ist – insbesondere wenn Regierungsinformationen über Modelle, Embeddings und Unterauftragnehmer fließen.
Erfasste Auftragnehmer dürfen Regierungsdaten nicht verwenden, um ein LLM für andere Kunden oder kommerzielle Zwecke zu trainieren oder feinabzustimmen. Sie dürfen sie auch nicht für Werbung verwenden oder an Dritte verkaufen.
Diese Beschränkungen erfordern eine technische Trennung, nicht lediglich eine Datenschutzerklärung. Anbieter benötigen Kontrollen, die verhindern, dass Regierungs-Prompts, Ausgaben und abgerufene Inhalte in allgemeine Trainings- oder Produktverbesserungspipelines gelangen.
Verschlüsselung, Zugriffskontrollen, Protokollierung, Aufbewahrungsgrenzen und Löschverfahren werden allesamt zu Bestandteilen der Nachweise für Compliance. Auftragnehmer benötigen außerdem Aufzeichnungen darüber, wo Informationen in ihren eigenen Systemen und Umgebungen von Unterauftragnehmern gespeichert sind.
Retrieval-augmented Generation stellt eine besondere Herausforderung dar. Diese Technik stellt einem Modell zum Zeitpunkt der Antwort ausgewählte externe Informationen bereit, häufig über Embeddings und Vektordatenbanken.
Diese unterstützenden Speicher können Regierungsmaterial enthalten, selbst wenn das Basismodell nie damit trainiert wird. Auftragnehmer müssen daher die umgebende Anwendung verwalten, nicht nur das Basismodell.
Der Vertragsabschluss wirft ein damit verbundenes Problem auf. Relevante Embeddings, feinabgestimmte Gewichte, gespeicherte Eingaben, Ausgaben und abgeleitete Artefakte müssen möglicherweise gelöscht oder zurückgegeben werden, wenn der Auftrag endet.
In verteilten Systemen kann die Löschung schwierig sein. Backups, replizierte Datenbanken, Telemetrie-Pipelines, Evaluierungsumgebungen und Kopien für die Notfallwiederherstellung können Daten bewahren, nachdem die Hauptanwendung sie entfernt hat.
Ein glaubwürdiger Abschlussplan muss diese Speicherorte im Voraus identifizieren. Erst bis zum Vertragsende zu warten, kann offenlegen, dass ein Lieferant die Informationen eines einzelnen Kunden nicht isolieren oder löschen kann, ohne ein gemeinsam genutztes System zu beeinträchtigen.
Die endgültige Klausel behält außerdem ein 72-Stunden-Fenster für die Meldung erfasster Ereignisse bei. Der Auslöser ist enger gefasst als im Vorschlag vom Juni, der Vorfälle irgendwo in einem breiten Auftragnehmernetzwerk hätte erfassen können.
Nun muss der relevante Vorfall ein für den Vertrag eingesetztes LLM betreffen und möglicherweise die Vertraulichkeit, Integrität oder Verfügbarkeit von Regierungsdaten beeinträchtigen. Das richtet die Verpflichtung stärker am tatsächlichen Vertragsrisiko aus.
Der 72-Stunden-Zeitraum beginnt, nachdem der Auftragnehmer tatsächlich Kenntnis vom relevanten Ereignis erlangt hat. Auftragnehmer sollten festlegen, wer diese Kenntnis erlangen kann und wie Informationen von Ingenieuren oder Anbietern zum Team des Hauptauftragnehmers für Regierungsverträge gelangen.
Meldungen an FedRAMP, die Cybersecurity and Infrastructure Security Agency oder andere Bundesstellen können die Klausel erfüllen, wenn sie im Wesentlichen gleichwertige Informationen enthalten und gleichzeitig beim Vertragsbeauftragten eingehen.
Dieser Safe Harbor reduziert doppelte Meldungen. Er beseitigt die Koordinierung nicht, da der Auftragnehmer bestätigen muss, dass eine bestehende Meldung die von der GSA erwarteten Informationen enthält.
Die Klausel verlangt separat eine Mitteilung nach tatsächlicher Kenntnis von einem wesentlichen Verstoß. Ein Verstoß ist wesentlich, wenn er erhebliche Schäden für die Leistungserbringung, Regierungsrechte, Sicherheit, Vertraulichkeit, Rechtskonformität oder Vertragsverwaltung verursacht oder vernünftigerweise voraussichtlich verursachen würde.
Dieser Maßstab erfordert eine schnelle rechtliche und technische Beurteilung. Teams benötigen einen gemeinsamen Eskalationsprozess, da ein Ingenieur eine Datenoffenlegung erkennen kann, bevor er weiß, ob sie die Wesentlichkeitsschwelle des Vertrags erreicht.
Modelländerungen schaffen eine zusätzliche operative Belastung. Die Regierung kann Benachrichtigung und Zugang im Zusammenhang mit Änderungen erwarten, die Vertrauenswürdigkeit, Sicherheit oder operative Integrität betreffen.
Bei gehosteten KI-Diensten können Modellupdates häufig und ohne Kontrolle des Kunden erfolgen. Ein Auftragnehmer, der von einem sich rasch verändernden kommerziellen Endpunkt abhängt, benötigt von seinem Anbieter eine vertragliche Benachrichtigung und einen Prozess zur Prüfung des aktualisierten Modells.
Diese Pflichten erklären, warum der engere Anwendbarkeitstest so bedeutsam ist. Ein Unternehmen außerhalb der Klausel vermeidet ein anspruchsvolles Kontrollsystem. Ein Unternehmen innerhalb der Klausel sieht sich Verpflichtungen gegenüber, die Sicherheit, Produktmanagement, Rechtsprüfung, Beschaffung und KI-Evaluierung umfassen.
Der berichtete Arbeitsaufwand für Auftragnehmer umfasst eine Offenlegungsfrist von 120 Tagen, Vorfallmeldungen, Löschung beim Vertragsabschluss, Benachrichtigung vor wesentlichen Modellwechseln und Evaluierungsrechte der Regierung.
Nicht jeder Auftragnehmer wird jede Verpflichtung auf dieselbe Weise erleben. Bereitstellungsdesign, Beziehungen zu Unterauftragnehmern, Systemautorisierung und die Anweisungen des Vertragsbeauftragten werden die Umsetzung prägen.
Dennoch sollten erfasste Anbieter die Klausel als Engineering-Anforderung behandeln. Ein Richtliniendokument allein kann keine Kontrolle über Trainingspipelines, Datenspeicher, Modellversionen, Zugriffsprotokolle oder Löschvorgänge nachweisen.
Der Bias-Standard wird enger, doch staatliche Tests bleiben bestehen
Die GSA hat detaillierte ideologische Regeln durch einen Standard angemessener Bemühungen ersetzt und damit einen Compliance-Streitpunkt verringert, ohne zu klären, wie die Modellqualität gemessen wird.
Der Vorschlag vom Juni enthielt umfangreiche „Unbiased AI Principles“. Er forderte wahrheitsgemäße, neutrale und unparteiische Systeme und beschränkte zugleich ideologischen Einfluss durch Trainingsdaten, Prompts, Retrieval-Quellen und andere Konfigurationsentscheidungen.
Diese Bestimmungen spiegelten eine bundesweite Beschaffungsanordnung vom Juli 2025 wider, die Behörden anwies, LLMs zu beschaffen, die mit Grundsätzen der Wahrheitssuche und ideologischen Neutralität im Einklang stehen.
Branchenverbände und zivilgesellschaftliche Organisationen stellten infrage, ob sich diese Ideen in objektive Vertragstests überführen lassen. Modellausgaben variieren je nach Prompt, Kontext, Sampling-Einstellungen, abgerufenen Informationen und Systemkonfiguration.
Die endgültige Klausel streicht den Großteil des präskriptiven Rahmens. Stattdessen müssen Auftragnehmer angemessene Bemühungen unternehmen, erfasste LLMs so zu entwerfen, zu trainieren und zu konfigurieren, dass sie Genauigkeit, wissenschaftliche Untersuchung und Objektivität priorisieren, wenn Nutzer faktische Informationen oder Analysen anfordern.
„Angemessene Bemühungen“ sind ein flexiblerer Standard als eine Garantie neutralen Verhaltens. Er erkennt an, dass probabilistische Modelle unter jedem Prompt keine perfekte Genauigkeit oder konsistente Antworten versprechen können.
Die überarbeitete Sprache streicht außerdem das ausdrückliche Verbot, parteipolitische oder ideologische Wertungen einzubetten. Sie schafft nicht länger dieselbe fortlaufende Überwachungspflicht, die spezifisch an den früheren Bias-Rahmen gebunden war.
Das ist ein wesentliches Zugeständnis. Es verringert das Risiko, dass eine einzelne umstrittene Antwort automatisch ein vertragliches Versagen begründet.
Angemessene Bemühungen benötigen jedoch weiterhin Nachweise. Auftragnehmer könnten Evaluierungspläne, dokumentierte System-Prompts, Benchmark-Ergebnisse, Berichte über bekannte Einschränkungen, Modellkarten und Aufzeichnungen über Abhilfemaßnahmen benötigen.
Die Regierung behält außerdem die Möglichkeit, eingesetzte Systeme zu evaluieren. Auftragnehmer können nicht davon ausgehen, dass ihre internen Behauptungen zu Genauigkeit oder Objektivität ohne Tests akzeptiert werden.
Hier wird das NIST-Framework mehr als ein Vokabular für die Lieferkette. Sein Lebenszyklusansatz behandelt Tests, Evaluierung, Verifizierung und Validierung als Aktivitäten, die sich über Entwurf, Entwicklung, Bereitstellung und Betrieb hinweg fortsetzen.
Kein einzelner Benchmark kann entscheiden, ob ein Allzweckmodell genau oder objektiv ist. Die Leistung verändert sich je nach Domäne, Sprache, Retrieval-Quelle, Werkzeug und Anwendungsfall der Regierung.
Eine Beschaffung zur Zusammenfassung von Dokumenten benötigt Tests für Auslassungen, Zitattreue und den Umgang mit eingeschränktem Material. Ein öffentlich zugänglicher Assistent benötigt Prüfungen zu Faktentreue, Ablehnungsverhalten, Barrierefreiheit, Datenschutz und nicht fundierter Beratung.
Agentische Systeme schaffen zusätzliche Risiken, weil sie Werkzeuge aufrufen oder Maßnahmen ergreifen können. Ihre Evaluierung muss Workflow-Logik und Autorisierungsgrenzen abdecken, nicht nur die Qualität generierter Prosa.
Die Klausel erlaubt es der Regierung, die Nutzung eines erfassten LLM jederzeit auszusetzen. Frühere Formulierungen stellten die Aussetzung direkter in den Zusammenhang mit ungelösten Leistungsproblemen.
Dieses weiter gefasste Recht schafft kommerzielle Unsicherheit. Ein technisch konformes System kann dennoch mit einer Betriebsunterbrechung konfrontiert sein, während die Behörde ein Problem untersucht.
Die endgültige Klausel ändert außerdem die Haftung bei Außerbetriebnahme. Sie knüpft diese Kosten an eine Kündigung nach Mitteilung über die Nichteinhaltung der Klausel, statt nur an Verstöße gegen die früheren Bestimmungen zu unvoreingenommener KI.
Die Haftung des Auftragnehmers für diese Außerbetriebnahmekosten ist auf 25 Prozent des betroffenen Task Order oder Delivery Order begrenzt. Kosten für eine Neubeschaffung und die Entwicklung eines Ersatzsystems sind von dieser Berechnung ausgenommen.
Die Obergrenze gibt Anbietern eine klarere Begrenzung. Dennoch kann eine Aussetzung oder Kündigung Reputationsschäden, entgangene Einnahmen und Engineering-Kosten verursachen, die über den definierten Außerbetriebnahmebetrag hinausgehen.
Die größte ungeklärte Frage ist die Konsistenz der Evaluierung. Unterschiedliche Behörden, Vertragsbeauftragte und technische Teams können unterschiedliche Prompts, Datensätze oder Schwellenwerte verwenden.
Ein Modell kann bei einem allgemeinen Benchmark gut abschneiden und dennoch in einem spezialisierten Regierungs-Workflow versagen. Es kann auch die Faktentreue verbessern und zugleich weniger nützlich werden, weil es zu häufig ablehnt.
Auftragnehmer sollten Bewertungen daher mit dem beschafften Anwendungsfall verknüpfen. Allgemeine Marketingkennzahlen sind weniger relevant als Nachweise dafür, wie sich die eingesetzte Konfiguration bei repräsentativen Regierungsaufgaben verhält.
Die endgültige Formulierung vermeidet klugerweise das Versprechen eines unmöglichen Zustands vollständiger Neutralität. Ihr Maßstab angemessener Bemühungen lässt weiterhin Raum für Streit darüber, welche Bewertungen angemessen sind und welche Leistung als akzeptabel gilt.
Drei Signale werden zeigen, ob die Regel funktioniert
Der nächste Test ist die Umsetzung: Vergabebeauftragte, Hauptauftragnehmer und Modellanbieter müssen die Klausel in praktikable Vertrags- und Engineering-Praktiken überführen.
Das erste Signal ist, wie die GSA den zweiteiligen Geltungstest nach dem 19. Oktober anwendet. Ausschreibungen sollten benennen, ob LLM-Funktionalität wesentlich ist und ob Regierungsdaten direkt in das System eingegeben werden oder aus ihm hervorgehen.
Klare Feststellungen würden die Einschätzung stärken, dass die GSA die Regel tatsächlich eingegrenzt hat. Eine routinemäßige Aufnahme in Verträge wegen nebensächlicher KI-Funktionen würde diese Schlussfolgerung schwächen und die Unsicherheit wiederherstellen, die die endgültige Formulierung beseitigen wollte.
Auftragnehmer sollten darauf achten, ob Ausschreibungen erläutern, warum die Klausel gilt. Sie sollten außerdem prüfen, wie Vergabebeauftragte die beiden selbstaufhebenden Bedingungen auslegen.
Das zweite Signal ist die Qualität der Weitergabeklauseln an Unterauftragnehmer. Hauptauftragnehmer benötigen Vereinbarungen, die den NIST-Lebenszyklusaufgaben und den von jedem Lieferanten verarbeiteten Daten entsprechen.
Modellanbieter und Cloud-Plattformen werden unter Druck geraten, regierungsgeeignete Bedingungen anzubieten, die Aufbewahrung, Trainingsbeschränkungen, Benachrichtigungen über Vorfälle, Modelländerungen, Zugang zu Bewertungen und Löschung abdecken.
Standardisierte Zusatzvereinbarungen würden kleineren Integratoren die Compliance erleichtern. Wenn große Lieferanten die Annahme dieser Bedingungen verweigern, würden sich Bundesgeschäftsmöglichkeiten bei Anbietern mit größerer Verhandlungsmacht oder speziellen Regierungsangeboten konzentrieren.
Offene und Open-Weight-Modelle liefern einen weiteren Test. Die endgültige Klausel unterscheidet Modelle mit vollständigen öffentlichen Artefakten von Produkten, die nur ihre Gewichte veröffentlichen.
Auftragnehmer müssen nachweisen, dass ihre Klassifizierungen technisch korrekt sind. Mehrdeutige Marketingsprache über Offenheit sollte die Prüfung von Lizenzen, Quellcodeverfügbarkeit, Datensätzen und Dokumentation nicht ersetzen.
Das dritte Signal ist, wie die GSA mit Modellbewertungen und Nichteinhaltung umgeht. Angemessene Bemühungen bieten Flexibilität, doch diese Flexibilität erfordert wiederholbare Tests und verhältnismäßige Abhilfemaßnahmen.
Regierungsbewertungen sollten den beschafften Anwendungsfall, die offengelegte Konfiguration, verfügbare Nachweise und bekannte technische Grenzen widerspiegeln. Ein einzelner adversarialer Prompt sollte nicht automatisch die Leistung einer komplexen Bereitstellung definieren.
Gleichzeitig sollten Anbieter Modellvariabilität nicht als Ausrede für schwache Kontrollen nutzen. Sie können Testsuiten, Bewertungsdatensätze, Schwellenwerte für menschliche Überprüfung, Retrieval-Quellen und Sanierungsentscheidungen dokumentieren.
Organisationen, die derzeit Angebote vorbereiten, sollten vor Beginn der Vertragsverhandlungen ein Nachweispaket erstellen. Es sollte Architekturdiagramme, Datenflusskarten, Verzeichnisse von Unterauftragnehmern, Aufbewahrungspläne, Verfahren für Modelländerungen, Bewertungsergebnisse und Abschlusspläne enthalten.
Ein durchsuchbares technisches Archiv kann Teams dabei helfen, diese Artefakte über Engineering, Sicherheit, Beschaffung und Rechtsprüfung hinweg zu verknüpfen. Das System muss weiterhin Vertragsbeschränkungen für Regierungsdaten einhalten.
Die endgültige GSA-LLM-Regel ist enger gefasst als ihre Vorgänger, aber nicht leichtgewichtig. Ihr zentraler Kompromiss besteht aus klareren Grenzen im Austausch für tiefere Rechenschaftspflicht, wenn die Regierung gezielt ein LLM-System beschafft.
Für KI-Auftragnehmer lautet die unmittelbare Frage nicht, ob sie irgendwo generative KI einsetzen. Entscheidend ist, ob die Regierung diese Fähigkeit beschafft, ob Regierungsdaten damit in Berührung kommen und ob jeder Beteiligte die Compliance nachweisen kann.
Vor dem 19. Oktober sollten Anbieter diese Antwort anhand ihrer tatsächlichen Architektur und Verträge prüfen. Wenn ein Anbieter sein Modell morgen änderte, könnte der Hauptauftragnehmer die Auswirkungen identifizieren, die GSA benachrichtigen, Nachweise sichern und Regierungsdaten schützen, ohne improvisieren zu müssen?
