Ein Hochrisikosystem ist kein Hochrisikomodell

Risk lebt nicht in einem Modell wie ein Warnhinweis. Es entsteht aus dem beabsichtigten Zweck, der Bereitstellung, der Autorität, den Schnittstellen und den...

Ein Hochrisikosystem ist kein Hochrisikomodell

Das Etikett hängt an einer Verwendung, nicht an einer Box

Ein Modell kann von einem Server auf einen anderen kopiert werden, ohne etwas zu lernen. Seine Gewichte, sein Code und seine beworbenen Fähigkeiten können unverändert sein. Doch die Frage, die Europa an das Ding um es herum stellt, kann sich vollständig ändern. Wofür ist es da? Wer nutzt es? Wessen Position kann es verändern? Welcher Datensatz gelangt in den Arbeitsablauf? Wer kann die Antwort hinterfragen, korrigieren, stoppen oder später herausfinden, warum ihr gefolgt wurde?

Dies ist nicht der Versuch, ein einfaches Thema größer darzustellen, als es ist. Es ist der gewöhnliche Unterschied zwischen einer Komponente und einem System. Eine Bremsscheibe ist kein Straßenfahrzeug. Eine Tabellenkalkulationsformel ist keine Steuerentscheidung. Ein allgemeines KI-Modell ist für sich genommen nicht jedes KI-System, das später möglicherweise darum herum gebaut wird. Der Unterscheidung kann man leicht zustimmen, und sie geht bemerkenswert leicht verloren, sobald in einer Beschaffungsbesprechung über ein Modell gesprochen wird, als ob es bereits die gesamte zukünftige Bereitstellung in sich trüge.

Der EU-KI-Gesetzentwurf hält die Unterscheidung im Blick. Er definiert ein KI-System und definiert separat ein allgemeines KI-Modell. Seine Hochrisikoregeln betreffen KI-Systeme unter bestimmten Umständen, einschließlich Systemen, die Sicherheitskomponenten regulierter Produkte sind, und Systemen, die in aufgeführten Bereichen verwendet werden. Der Gesetzentwurf macht den beabsichtigten Zweck auch zentral für die Einstufung und Dokumentation eines KI-Systems. Er lädt ein Team nicht dazu ein, auf einen Modellnamen zu zeigen, ein rotes, gelbes oder grünes Etikett anzubringen und die Arbeit für erledigt zu erklären.

Das sollte ebenso befreiend wie anspruchsvoll sein. Ein Modell trägt kein dauerhaftes moralisches Horoskop. Eine sorgfältige Analyse kann eng gefasst sein, wo der beabsichtigte Zweck eng gefasst ist, und sie kann ernsthaft werden, wo Autorität, Exposition und Konsequenz ernsthaft werden. Der Haken ist, dass die Analyse dem tatsächlichen System folgen muss. Nicht der Demo. Nicht der Lieferantenpräsentation. Nicht der harmlosen Aufgabe, die das Projekt vor sechs Monaten eröffnet hat. Dem System, das Eingaben empfängt, Ausgaben verfügbar macht, eine Entscheidung formt und an einem gewöhnlichen Dienstag betrieben wird.

Betrachten wir eine bewusst hypothetische Veranschaulichung. Dasselbe Sprachmodell wird zuerst mit einem internen Wissenssuchwerkzeug verbunden. Es ruft Richtlinienpassagen für einen geschulten Kollegen ab, der die Originalquelle öffnen und seine eigene Antwort schreiben kann. Später verbindet eine Organisation das Modell mit einem Aufnahmeformular, gibt seiner Empfehlung einen Platz oben in einem Fallprotokoll, wendet einen Timer auf den Fall an und macht die Annahme der Empfehlung zum schnellsten Weg, die Warteschlange zu leeren. Kein fiktiver Rat, Patient, Mitarbeiter oder Vorfall ist nötig, um die Veränderung zu sehen. Das Modell mag identisch sein. Die Rolle der Ausgabe, der Datenpfad, der Anreiz, die betroffene Person und die praktische Autorität der Schnittstelle sind es nicht.

Das ist das Argument des Artikels: Ein Hochrisikosystem ist kein Hochrisikomodell. Ein Modell kann ein wichtiger Teil des Systems sein und eigene Pflichten haben. Aber die Risikoanalyse wird nur dann aussagekräftig, wenn sie den beabsichtigten Zweck, den Bereitstellungskontext, die Nutzer, die betroffenen Personen und die nachgelagerte Integration erreicht. Diese Details sind kein Papierkram, der nach der Technik angehängt wird. Sie sind die Umstände, die einer Ausgabe institutionelle Kraft verleihen.

Fahren Sie mit der Maus über eine Ebene oder wählen Sie sie aus. Das Modell ist nur eine Ebene; die Konsequenz entsteht erst, wenn die Ebenen zusammentreffen.

Europa verwendet bewusst zwei verschiedene Begriffe

Die Unterscheidung beginnt in den Definitionen der Verordnung. Ein KI-System ist ein maschinenbasiertes System, das so konzipiert ist, dass es mit unterschiedlichem Grad an Autonomie arbeitet und nach der Bereitstellung Anpassungsfähigkeit zeigen kann, und das aus Eingaben ableitet, wie Ausgaben wie Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen erzeugt werden, die physische oder virtuelle Umgebungen beeinflussen können. Ein Modell für allgemeine Zwecke der künstlichen Intelligenz ist anders: Es ist ein KI-Modell, das in der Lage ist, ein breites Spektrum unterschiedlicher Aufgaben kompetent auszuführen, unabhängig davon, ob es auf dem Markt bereitgestellt wird, und das in eine Vielzahl nachgelagerter Systeme oder Anwendungen integriert werden kann.

Diese Definitionen überschneiden sich im Alltag, weil dasselbe Wort KI eine große Menge unbezahlter Arbeit leistet. In einer Bewertung sollten sie sich nicht überschneiden. Ein Modell für allgemeine Zwecke ist dafür gemacht, zu reisen. Seine möglichen Verwendungen sind bewusst breit gefasst. Ein KI-System ist die operative Anordnung, durch die Ausgaben eine Umgebung beeinflussen. Es hat einen Zweck, eine Konfiguration, eine Schnittstelle und einen Kontext. Es kann ein Modell, mehrere Modelle, deterministische Regeln, Datenbanken, Sensoren, Personen, Verfahren und eine große Anzahl kleiner Entscheidungen umfassen, die niemand künstliche Intelligenz nennt, bis sie fehlschlagen.

Deshalb können ein Anbieter eines KI-Modells für allgemeine Zwecke und ein Anbieter oder Betreiber eines KI-Systems nicht einfach Checklisten austauschen. Die Leitlinien der Kommission zu KI-Modellen für allgemeine Zwecke besagen, dass Modellanbieter Informationen und Dokumentation für nachgelagerte KI-Systemanbieter bereitstellen müssen, damit diese die Fähigkeiten und Grenzen des Modells verstehen und ihren eigenen Pflichten nachkommen können. Dieser Satz ist interessanter, als er zunächst erscheint. Er setzt voraus, dass der nachgelagerte Anbieter Arbeit hat, die der Modellanbieter nicht erledigen kann. Die Modelldokumentation reist mit, aber sie beendet die Reise nicht.

Darin liegt eine praktische Bescheidenheit. Ein Modellanbieter kann Architektur, Trainingsprozess, Evaluierung, vorgesehene Aufgaben, Integrationsanforderungen, Eingaben und Ausgaben, Grenzen und bekannte Bedingungen beschreiben. Ein nachgelagertes Team weiß, ob ein Benutzer ein ausgebildeter Spezialist ist, ob eine betroffene Person ein Ergebnis anfechten kann, ob eine Empfehlung nur dem Namen nach beratend, in der Praxis aber bindend ist, ob ein Aufruf eines externen Dienstes einen Datensatz verändert und ob eine fehlerhafte Handlung rückgängig gemacht werden kann. Keine der beiden Seiten hat allein ein vollständiges Bild.

Die Aufteilung ist keine Hintertür. Sie ist eine Landkarte der Verantwortung. Sie besagt, dass ein System nicht dadurch regiert werden kann, dass man den Modellanbieter bittet, die Kontrolle über eine Bereitstellung zu versprechen, die er weder betreibt noch sieht. Sie besagt auch, dass ein Integrator sich nicht auf Unwissenheit berufen kann, wenn die Dokumentation eine wichtige Einschränkung sichtbar macht. Es geht nicht darum, eine saubere Übergabe zwischen juristischen Personen zu schaffen. Es geht darum, zu vermeiden, dass die Frage in der Lücke zwischen ihnen verloren geht.

Neben der ersten Unterscheidung gibt es eine zweite, die es wert ist, im Blick zu behalten. Eine Einstufung als Hochrisiko-System ist für sich genommen keine Erlaubnis, keine Zusicherung von Sicherheit, Fairness oder Rechtmäßigkeit. In ihrer gemeinsamen Stellungnahme zum ursprünglichen Kommissionsvorschlag betonten der Europäische Datenschutzausschuss und der Europäische Datenschutzbeauftragte, dass die Einstufung als Hochrisiko-System nicht zwangsläufig bedeute, dass ein System als solches rechtmäßig sei oder von seinem Nutzer als solches eingesetzt werden dürfe. Der endgültige Rechtsakt hat die Rechtslage seit dieser Stellungnahme verändert, doch die zugrunde liegende Warnung bleibt nützlich. Die Einstufung ist eine regulatorische Bedingung. Sie ist keine Quittung, die besagt, dass die Einrichtung aufhören darf nachzudenken.

Das ist von Bedeutung, weil ein Hochrisiko-Label zwei entgegengesetzte Fehler hervorrufen kann. Ein Team mag darin einen dauerhaften Makel für ein Modell sehen und zu dem Schluss kommen, die Lösung sei, einfach nicht weiter zu schauen. Ein anderes mag einen abgeschlossenen Konformitätsprozess als Freibrief für jeden späteren Kontext betrachten. Beide Ansätze setzen ein Label an die Stelle eines Arguments. Europa hat einen unbequemeren Weg gewählt: das System, seinen Zweck und seine Rolle identifizieren und dann die relevanten Risiken und Pflichten über seinen Lebenszyklus hinweg prüfen.

Der vorgesehene Zweck gibt der Analyse ihre Orientierung

Der vorgesehene Zweck klingt bescheiden, fast bürokratisch. Das ist er nicht. Der Rechtsakt definiert ihn als die Verwendung, für die ein KI-System vom Anbieter vorgesehen ist, einschließlich des spezifischen Kontexts und der Nutzungsbedingungen, die in den vom Anbieter bereitgestellten Informationen angegeben sind. Mit anderen Worten: Der Zweck ist kein Slogan auf einer Produktseite. Er umfasst den Kontext und die Bedingungen, unter denen der Anbieter angibt, dass das System verwendet werden soll. Eine brauchbare Zweckbeschreibung hat Konturen. Sie sagt, was das System tut, für wen, mit welchen Eingaben, in welchem Arbeitsablauf und wo seine Befugnis endet.

Man vergleiche zwei Beschreibungen. Die erste besagt, dass ein System KI einsetzt, um Organisationen zu besseren Entscheidungen zu verhelfen. Sie ist breit genug für eine Konferenzkulisse und zu breit, um handlungsleitend zu sein. Die zweite besagt, dass ein System mit Quellen verknüpfte Entwurfszusammenfassungen einer bestehenden Akte geschulten Prüfern präsentiert; es kann keine Entscheidung treffen, übermitteln oder umsetzen; der Prüfer muss die angegebenen Quellen verifizieren, bevor er eine Zusammenfassung verwendet; und die Funktion steht für Kategorien nicht zur Verfügung, die ein separates gesetzliches Verfahren erfordern. Die zweite Beschreibung ist weniger aufregend. Sie ist aber auch etwas, dem ein Ingenieur, eine Beschaffungsverantwortliche, ein Compliance-Kollege und eine betroffene Person in konkreten Begriffen widersprechen können.

Der Zweck muss kein einzelner Satz sein. Bei einem ernsthaften System handelt es sich in der Regel um ein kompaktes Paket: Aufgabe, Ausgabe, Nutzer, betroffene Personengruppe, Umfeld, Befugnis, Ausschlüsse, Abhängigkeiten und Bedingungen. Die Anforderungen des Rechtsakts an die technische Dokumentation schaffen Raum für genau eine solche Darstellung. Anhang IV verlangt eine allgemeine Beschreibung des KI-Systems, einschließlich des vorgesehenen Zwecks, der Personen und Personengruppen, für die es verwendet werden soll, sowie der spezifischen Versionen oder Formen, in denen es auf dem Markt bereitgestellt wird. Außerdem werden Beschreibungen der Systemarchitektur, der Datenanforderungen, der Maßnahmen zur menschlichen Aufsicht, der Überwachung über den Lebenszyklus und der Risikomanagementmaßnahmen verlangt. Die Dokumentation hat diese Breite, weil eine Modellkarte allein einen Einsatz nicht beschreiben kann.

Der Zweck ist auch der Punkt, an dem ein Team entdeckt, dass es eher einen Anspruch als einen Betrieb beschrieben hat. „Wir werden Sachbearbeiter unterstützen“ kann ein Dutzend verschiedener Regelungen verbergen. Durchsucht das Werkzeug Dokumente, ordnet es Arbeit, entwirft es eine Antwort, empfiehlt es eine Kategorie, lehnt es einen Antrag ab, eskaliert es einen Alarm, setzt es eine Priorität oder ruft es einen anderen Dienst auf? Nutzt der Kollege es vor oder nach der Bildung einer unabhängigen Meinung? Ist die Ausgabe ein Vorschlag in einem Seitenbereich oder ein Feld, das ausgefüllt sein muss, bevor der Datensatz weiterbearbeitet werden kann? Ist die Wirkung unmittelbar, verzögert, umkehrbar oder schwer zu erkennen? Die Antwort verändert das System, selbst wenn die Benutzeroberfläche vertraut aussieht.

Die erklärte Zweckbestimmung eines Anbieters kann die Realität nicht verschwinden lassen. Ein Team kann einem System nicht umfassende praktische Befugnisse geben, es als harmlosen Assistenten beschreiben und erwarten, dass diese Beschreibung die Sache klärt. Aber eine klar begrenzte Zweckbestimmung ist dennoch ein Kontrollmittel. Sie sagt den Nutzern, welche Nachweise berücksichtigt wurden, sagt den Integratoren, was sie nicht beiläufig erweitern dürfen, und sagt den Prüfern, welche Änderung die Bewertung neu eröffnen würde. Eine vage Zweckbestimmung macht aus jeder späteren Frage einen Streit darüber, was gemeint war. Eine begrenzte Zweckbestimmung ermöglicht es einer Organisation zu fragen, ob sie noch das tut, was sie genehmigt hat.

Dies wird besonders wichtig, wenn eine Organisation eine wesentliche Änderung vornimmt. Das Gesetz enthält Regelungen für Fälle, in denen ein Vertreiber, Importeur, Bereitsteller oder ein anderer Dritter zum Anbieter werden kann, unter anderem wenn er ein System unter eigenem Namen auf dem Markt bereitstellt, eine wesentliche Änderung vornimmt oder die Zweckbestimmung so ändert, dass das System hochriskant wird. Die genaue rechtliche Anwendung hängt von den Umständen ab und sollte im jeweiligen Kontext geprüft werden. Die operative Lehre ist einfacher: Eine Integrationsänderung kann ein Governance-Ereignis sein. Das Verschieben einer Modellausgabe aus einem Entwurfsbereich in eine Entscheidungswarteschlange kann zugleich eine Produktänderung, eine Workflow-Änderung und eine Änderung der Rechenschaftspflicht sein.

Kontext ist keine Kulisse

Der Bereitstellungskontext wird oft als der Teil behandelt, der nach der eigentlichen Arbeit kommt: eine Liste von Ländern, eine Hosting-Entscheidung, ein paar Nutzerprofile, vielleicht ein Diagramm mit Pfeilen, die gefällig von links nach rechts führen. Aber der Kontext gibt dem Risiko seine Form. Dieselbe Art von Ausgabe kann in einem Umfeld lästig und in einem anderen folgenreich sein. Ein fehlerhafter Textvorschlag in einem Schreibwerkzeug kann im nächsten Satz korrigiert werden. Eine fehlerhafte Priorisierung in einem Arbeitsablauf mit knappen Ressourcen kann entscheiden, welche Datei eine Person zuerst sieht. Ein Wert, der nur einer von vielen Eingaben zu sein scheint, kann entscheidend werden, wenn alle anderen Eingaben langsam, vage oder hinter einem anderen Team verborgen sind.

Der Hochrisiko-Ansatz des Gesetzes spiegelt dies wider. Artikel 6 verbindet die Einstufung als Hochrisiko mit Systemen, die dazu bestimmt sind, als Sicherheitskomponenten bestimmter Produkte verwendet zu werden, oder mit Systemen, auf die in Anhang III Bezug genommen wird. Anhang III listet Bereiche auf, in denen KI-Systeme ein hohes Risiko aufweisen können, weil sie für bestimmte Verwendungen bestimmt sind, etwa bestimmte biometrische Verwendungen, kritische Infrastruktur, allgemeine und berufliche Bildung, Beschäftigung, Zugang zu wesentlichen privaten und öffentlichen Diensten und Leistungen, Strafverfolgung, Migration und Grenzkontrolle sowie Justiz und demokratische Prozesse. Das rechtliche Detail ist wichtig, aber auch die Grammatik. Es wird nicht gesagt, dass ein technisches Artefakt abstrakt ein hohes Risiko darstellt. Es wird wiederholt gesagt, dass es für die Verwendung bestimmt ist.

Artikel 6 enthält auch eine Einschränkung für bestimmte Systeme nach Anhang III: Sie gelten nicht als Hochrisiko, wenn sie kein erhebliches Risiko einer Schädigung der Gesundheit, der Sicherheit oder der Grundrechte natürlicher Personen darstellen, auch indem sie das Ergebnis der Entscheidungsfindung nicht wesentlich beeinflussen. Anbieter müssen diese Bewertung dokumentieren, bevor sie das System auf dem Markt bereitstellen oder in Betrieb nehmen. Dies ist keine allgemeine Ausnahmekarte. Es ist eine Erinnerung daran, dass die tatsächliche Wirkung des Systems zählt. Eine nützliche Analyse enthält genügend Details, um zu erklären, warum ein System ein Ergebnis wesentlich beeinflusst oder nicht. Wenn diese Erklärung nicht ohne vage Umschreibungen geschrieben werden kann, hat das Team vor der Veröffentlichung etwas gelernt.

Zum Kontext gehört die Zeit. Eine Empfehlung zu Beginn einer breit angelegten Untersuchung hat eine andere Wirkung als eine Empfehlung in dem Moment, in dem eine Person nur eine einzige Chance hat, fehlendes Material nachzureichen. Zum Kontext gehört der Umfang. Ein einzelner Prüfer mag ein Ergebnis infrage stellen, wenn täglich fünf Fälle eintreffen, und es standardmäßig übernehmen, wenn vor dem Mittagessen fünfhundert eintreffen. Zum Kontext gehört die Sprache. Ein Prüfer, der die Belege in seiner eigenen Arbeitssprache lesen kann, mag eine andere Form der Aufsicht ausüben als ein Prüfer, der eine bestimmte Zusammenfassung von Material erhält, das er nicht selbstständig einsehen kann. Zum Kontext gehören das lokale Verfahren, Rechtsmittelrechte, Personalausstattung, der Zugang zu einer Fachkraft, die Verfügbarkeit einer Ausweichmöglichkeit und die Frage, ob ein Ergebnis eine Person erreicht, die über genug Befugnis verfügt, um etwas Sinnvolles zu tun.

Nichts davon setzt voraus, dass ein erfundener Katastrophenfall wahr sein muss. Es ist schlicht die Funktionsweise von Systemen. Eine formale Richtlinie kann einen Menschen im Kreislauf vorsehen, aber das System kann dennoch faktisch automatisch arbeiten, wenn die Person keine Zeit, keine Informationen, keine Befugnis und keinen praktischen Weg hat, Einspruch zu erheben. Artikel 14 der Verordnung spricht daher von einer wirksamen menschlichen Aufsicht, die den Risiken, dem Grad der Autonomie und dem Nutzungskontext angemessen ist. Er verlangt, dass Hochrisikosysteme so konzipiert und entwickelt werden, dass Menschen relevante Fähigkeiten und Grenzen verstehen, sich einer Tendenz zur automatischen Übernahme von Ergebnissen bewusst bleiben, Ergebnisse korrekt interpretieren, entscheiden können, sie nicht zu verwenden, sie zu übersteuern oder umzukehren, und das System bei Bedarf sicher anhalten können. Das sind operative Fragen. Sie lassen sich nicht allein anhand einer Modell-Benchmark beantworten.

Wählen Sie eine Einsatzform. Das Modell bleibt, wo es ist; die Systemgrenze, die Befugnis und die benötigten Belege tun das nicht.

Nutzer sind Teil der Steuerungsoberfläche

Es ist verlockend, über Nutzer so zu sprechen, als säßen sie außerhalb des Systems, hielten eine Tastatur in der Hand und sorgten für den menschlichen Anteil. Sie sind Teil der Betriebsvereinbarung. Ihr Wissen, ihre Arbeitsbelastung, ihre Befugnis, ihre Anreize und ihre Wege zu Unterstützung bestimmen, was das Ergebnis bewirkt. Ein System, das für eine Fachkraft entwickelt wurde, die Quellenmaterial prüfen kann, ist nicht automatisch für eine allgemeine Kraft geeignet, von der erwartet wird, dass sie zügig arbeitet. Ein Werkzeug, das für einen Prüfer nützlich ist, der eine Empfehlung ablehnen kann, ist nicht automatisch für eine Kollegin oder einen Kollegen geeignet, die oder der nur auf Genehmigen klicken oder auf jemand anderen warten kann.

Das bedeutet nicht, dass eine Nutzerin oder ein Nutzer jedes Mal jedes Bauteil hinterfragen muss. Das wäre eine seltsame Definition von nützlicher Technologie. Es bedeutet, dass Aufsicht als echte Aufgabe gestaltet sein sollte. Die Person muss wissen, wann das System verwendet wird, worin die relevante Einschränkung besteht, welche Belege verfügbar sind, welche Art von Einspruch sie einlegen kann und was nach dem Einlegen geschieht. Sie braucht Befugnisse, die der Verantwortung entsprechen. Jemanden zu bitten, ein Ergebnis zu beaufsichtigen, das sie nicht anhalten, korrigieren oder weiterleiten kann, ist weniger menschliche Aufsicht als menschliche Dekoration.

Die Verordnung weist den Betreibern hier eine Rolle zu. Artikel 26 verlangt von Betreibern von Hochrisikosystemen, geeignete technische und organisatorische Maßnahmen zu ergreifen, um sicherzustellen, dass sie die Systeme gemäß der beigefügten Anleitung verwenden. Er fordert die Betreiber auf, die menschliche Aufsicht natürlichen Personen zu übertragen, die über die erforderliche Kompetenz, Schulung und Befugnis verfügen, und den Betrieb auf der Grundlage der Anleitung zu überwachen. In bestimmten Fällen verlangt er außerdem, automatisch erzeugte Protokolle unter ihrer Kontrolle zu halten. Das ist keine Aufforderung, eine sachkundige Person in der Nähe zu halten, falls die Schnittstelle nervös wird. Es ist eine Anforderung, eine Arbeitspraxis zu gestalten.

Schulung wird oft als die vollständige Antwort behandelt. Das ist sie nicht. Schulung kann einer Person helfen, eine Einschränkung zu erkennen, aber sie kann keinen Quelldatensatz erzeugen, den die Schnittstelle verbirgt. Sie kann keine Zeit erzeugen, die ein Warteschlangendesign verbraucht. Sie kann keine Befugnis erzeugen, die ein Vertrag anderweitig vorbehält. Sie kann keine Integration reparieren, die eine vorsichtige Empfehlung in eine unumkehrbare Handlung umwandelt. Eine Organisation sollte Menschen natürlich schulen. Sie sollte auch die Aufgabe, für die sie geschult werden, in dem System möglich machen, das ihnen tatsächlich gegeben wird.

Es gibt einen nützlichen Test: Beschreiben Sie die Handlung der Nutzerin oder des Nutzers, ohne das Verb prüfen zu verwenden. Was lesen sie? Welchen Vergleich können sie anstellen? Was können sie ablehnen? Wohin geht der Grund? Wer sieht ihn? Was geschieht mit der Empfehlung nach der Ablehnung? Kann die von dem Ergebnis betroffene Person fragen, was geschehen ist? Kann eine spätere Kollegin oder ein späterer Kollege den relevanten Zustand rekonstruieren? Wenn die Antworten allgemein bleiben, ist das Aufsichtsdesign wahrscheinlich ebenfalls allgemein.

Dieser Test gilt über Hochrisikosysteme hinaus. Das Gesetz hat einen spezifischen Anwendungsbereich und spezifische Daten; gutes operatives Urteilsvermögen wartet nicht auf eine Kategoriebezeichnung, bevor es fragt, ob eine Person in eine rein darstellende Rolle versetzt wurde. Es ist durchaus möglich, ein Werkzeug mit geringen Konsequenzen zu bauen, das Menschen in Bezug auf ihre eigene Arbeit dümmer macht, weil das Ergebnis zu glatt ist, um es anzufechten. Es ist auch möglich, ein eingeschränktes Werkzeug zu bauen, das die Fähigkeit einer Person erhöht, gute Fragen zu stellen, weil es Belege bewahrt, seine Befugnisse begrenzt und Unsicherheit sichtbar macht. Das Modell kann zu beiden Ergebnissen beitragen. Das System entscheidet, welches Ergebnis einen Ort hat, an dem es geschehen kann.

Betroffene Personen sitzen außerhalb der Konsole

Viele der wichtigsten Personen in einem KI-System berühren es nie. Sie können eine Kandidatin, ein Schüler, eine Arbeitnehmerin, ein Patient, eine Fahrgästin, ein Anwohner, eine Kundin, ein Antragsteller, eine Darlehensnehmerin, ein Zeuge oder ein Mitglied der Öffentlichkeit sein. Sie wissen möglicherweise nicht, dass ein Modell beteiligt war. Sie erleben möglicherweise nur eine Antwort, die schnell eintrifft, eine Anfrage, die verzögert wird, einen Dienst, der nicht mehr verfügbar ist, eine Priorität, die sich verschiebt, oder eine Entscheidung, die unmöglich zu verstehen scheint. Ihre Abwesenheit von der Schnittstelle macht sie nicht abwesend vom System.

Dies ist einer der Gründe, warum sich die Risikorahmung der Verordnung auf Gesundheit, Sicherheit und Grundrechte bezieht. Sie lenkt die Aufmerksamkeit auf Folgen, die nicht darauf reduziert werden können, ob einer angemeldeten Kollegin das Werkzeug gefallen hat. Es ist auch der Grund, warum eine Zweckbestimmung die Personen und Gruppen benennen sollte, auf die das System angewendet werden soll, wie Anhang IV es verlangt. Ein System, das um eine Kategorie namens Nutzer herum aufgebaut ist, kann stillschweigend einen Unterschied zwischen der Person, die die Schnittstelle bedient, und der Person, die mit dem Ergebnis lebt, verbergen.

Betroffene Menschen verändern die Fragen, die ein Team stellen muss. Gibt es eine Möglichkeit zu erkennen, dass das System eine bedeutsame Rolle gespielt hat? Basiert die Entscheidung auf Informationen, die korrigiert werden können? Erschweren eine Sprache, eine Behinderung, ein Gerät, ein Standort oder ein Verwaltungsstatus die Teilnahme? Erhält das betreibende Team Signale von den betroffenen Menschen oder nur vom Dashboard? Erreicht eine Korrektur die Daten, die Empfehlung, die Entscheidung und alle nachgelagerten Texte, die darauf beruhten? Diese Fragen sind keine Aufforderung, jedes System in eine öffentliche Konsultation zu verwandeln. Sie sind eine Aufforderung, der Konsequenz weit genug zu folgen, um den Menschen am anderen Ende zu sehen.

Das Datenschutzrecht ist relevant, wenn personenbezogene Daten verarbeitet werden, neben dem Rahmenwerk des KI-Gesetzes. Der EDPB und der EDPS haben dies in ihrer gemeinsamen Stellungnahme von 2021 zu dem Vorschlag deutlich gemacht: Das bestehende EU-Datenschutzrecht gilt für die Verarbeitung personenbezogener Daten im Anwendungsbereich des Vorschlags. Die genaue rechtliche Analyse hängt von der Verarbeitung und den beteiligten Akteuren ab. Die Lehre für die Governance ist einfach. Eine Einstufungsübung kann nicht jede andere Verpflichtung absorbieren. Datenschutz, Nichtdiskriminierung, sektorale Pflichten, Anforderungen des Verwaltungsrechts, Verbraucherregeln und vertragliche Verpflichtungen verschwinden nicht, nur weil ein Team ein gut aussehendes Risikoregister erstellt hat.

Es gibt auch eine grundlegende Frage der Lesbarkeit. Eine Person muss keine Spezialistin für maschinelles Lernen werden, um zu verstehen, wie eine Korrektur beantragt werden kann. Aber ein System darf technische Komplexität nicht als Grund nutzen, um eine Korrektur unmöglich zu machen. Ein guter Weg unterscheidet, was das System aufgezeichnet hat, was ein Mensch entschieden hat, welche Beweise berücksichtigt wurden, was ungewiss bleibt und was noch geändert werden kann. Er behauptet keine Präzision, die die Aufzeichnungen nicht stützen können. In diesem Bereich ist Ehrlichkeit nicht nur ein Tonfall. Sie ist Teil des Dienstes.

Integration ist der Punkt, an dem Verantwortung übergeht

Teams zeichnen eine KI-Architektur manchmal als saubere Kette: Modell, Eingabeaufforderung, Antwort, Nutzer. Reale Bereitstellungen ähneln eher einem Stadtplan, nachdem jemand an die Versorgungsleitungen gedacht hat. Es gibt Identitätssysteme, Abrufspeicher, Tool-Berechtigungen, Warteschlangen, Schemata, Caches, Beobachtbarkeitsplattformen, Browsererweiterungen, Stapelverarbeitungen, Genehmigungsregeln, Aufbewahrungseinstellungen, Lieferanten und Menschen, die eine Aufgabe übernehmen, weil die vorherige Person im Urlaub ist. Das Modell ist wichtig. Es ist selten allein.

Jede Integration kann verändern, was das System tun kann und wie sich ein Fehler bewegt. Der Abruf kann dazu führen, dass eine Modellausgabe fundiert erscheint, während die Quelle veraltet, unvollständig oder falsch abgegrenzt ist. Ein Tool-Aufruf kann einen Entwurf in eine Zustandsänderung verwandeln. Eine Warteschlange kann aus einer rechtzeitigen Empfehlung eine verspätete machen. Eine Orchestrierungsebene kann eine andere Modell- oder Eingabeaufforderungsversion auswählen. Eine Benutzeroberfläche kann Ungewissheit verbergen, die in einer unteren Ebene besteht. Eine Identitätsintegration kann einem hilfreichen Tool Zugriff auf Material geben, das ein Nutzer sonst nicht öffnen könnte. Keine dieser Beobachtungen beschuldigt ein bestimmtes Produkt oder eine bestimmte Organisation. Sie beschreiben gewöhnliche Systemeigenschaften, und genau deshalb sollten sie dokumentiert werden, bevor sie überraschend werden.

Die GPAI-Leitlinien der Kommission sind hier nützlich, weil sie Informationen am Übergabepunkt platzieren. Die Dokumentation für nachgelagerte Anbieter soll ihnen helfen, die Fähigkeiten und Grenzen des Modells, seine vorgesehenen Aufgaben, technische Integrationsanforderungen, Eingabe- und Ausgabespezifikationen und Informationen zu den Trainingsdaten zu verstehen. Diese Informationen sind notwendig. Sie reichen nicht aus. Nachgelagerte Teams müssen dennoch entscheiden, wie das Modell aufgefordert wird, ob eine Ausgabe mit Belegen angezeigt wird, welche Tool-Berechtigungen erlaubt sind, wie eine Änderung getestet wird, welche Protokolle aufbewahrt werden und ob eine Empfehlung einen bestimmten Arbeitsablauf beeinflussen darf.

Deshalb ist der Kauf eines Modellservices nicht der Kauf einer vollständigen Risikoposition. Die Dokumentation des Anbieters mag einem Team mitteilen, dass ein Modell eine bekannte Einschränkung hat oder dass es unter bestimmten Bedingungen evaluiert wurde. Sie kann nicht beweisen, dass der eigene Retrieval-Index des Käufers aktuell ist, dass die Mitarbeiter des Käufers über die erforderlichen Befugnisse verfügen oder dass eine betroffene Person Zugang zu einem Beschwerdeweg hat. Umgekehrt kann der Käufer nicht verlangen, dass ein Modellanbieter Kenntnis von jeder lokalen Richtlinie oder jedem nachgelagerten Prozess hat. Das Verantwortungsvolle ist nicht, so zu tun, als könne eine Seite das gesamte System kennen. Es geht darum, die Grenze explizit zu machen und die Nachweise über sie hinweg in Bewegung zu halten.

Artikel 25 bietet einen nützlichen rechtlichen Anhaltspunkt für diese operative Realität. Er legt Umstände fest, unter denen eine andere Partei als der ursprüngliche Anbieter als Anbieter eines Hochrisiko-KI-Systems gilt. Dazu gehören das Inverkehrbringen des Systems unter dem Namen oder der Marke dieser Partei, eine wesentliche Änderung oder eine Änderung des Verwendungszwecks, die dazu führt, dass das System zu einem Hochrisiko-System wird. Die Bestimmung ist technisch und stark einzelfallabhängig; niemand sollte sich anhand eines Blogbeitrags selbst einstufen. Aber ihre Richtung ist klar. Integration und Zweckänderung können ändern, wer die Pflichten des Anbieters trägt. Eine nachgelagerte Vereinbarung ist nicht für immer nachgelagert, nur weil das ursprüngliche Modell von anderswo stammt.

Es gibt einen institutionellen Grund, das ernst zu nehmen. Wenn sich Verantwortung stillschweigend ändert, werden Sicherheit und Rechtsbehelf zu einem organisatorischen Ping-Pong-Spiel. Der Modellanbieter verweist auf die Bereitstellung. Der Bereitsteller verweist auf das Modell. Der Integrator verweist auf den Cloud-Dienst. Der Diensteigentümer verweist auf eine Konfiguration, die es nicht mehr gibt. Betroffene Personen erhalten eine glatte Erklärung, wie komplex alles ist. Das mag zutreffend sein, aber es ist keine Antwort. Das System benötigt eine Aufzeichnung darüber, welche Organisation an jeder Grenze für die Frage zuständig ist, und einen Weg, auf dem die Frage weitergeleitet wird, wenn die Antwort woanders liegt.

Die Dokumentation sollte ein System beschreiben, das sich noch ändern kann

Technische Dokumentation hat den Ruf, am Ende eines Projekts mit einem leichten Hauch von Panik zu kommen. Die Verordnung beschreibt eine andere Rolle. Für Hochrisiko-Systeme muss die technische Dokumentation vor dem Inverkehrbringen oder der Inbetriebnahme des Systems erstellt und auf dem neuesten Stand gehalten werden. Die Liste in Anhang IV geht über das Modellverhalten hinaus und umfasst Verwendungszweck, Versionen, Systemarchitektur, Entwicklung, Datenanforderungen, Validierung und Tests, menschliche Aufsicht, Genauigkeit und Cybersicherheitsmaßnahmen, Risikomanagement, Änderungen und Überwachung nach dem Inverkehrbringen. Das ist kein dekorativer Anhang. Es ist der Versuch, genügend Gedächtnis zu bewahren, damit jemand das System inspizieren kann, nachdem das Launch-Meeting zur Legende geworden ist.

Dokumentation funktioniert nur, wenn sie Beziehungen aufzeigen kann. Eine Modellversion muss mit der Systemversion verbunden sein, die sie verwendet hat. Ein Test muss mit seinen Eingabebedingungen und seinem Zweck verbunden sein. Eine Richtlinie muss mit einem Durchsetzungspunkt verbunden sein. Eine Benutzerrolle muss mit der Berechtigung verbunden sein, die sie in der Benutzeroberfläche hat. Eine Protokollierungsrichtlinie muss mit dem Ereignis verbunden sein, das sie rekonstruieren kann. Eine Änderung muss mit der Bewertung verbunden sein, die sie ausgelöst hat. Andernfalls hat ein Team eine Bibliothek guter Dokumente, aber keine Möglichkeit, eine bestimmte Frage zu beantworten.

Logs sind ein ähnlicher Fall. Artikel 12 verlangt, dass Hochrisiko-KI-Systeme über technische Fähigkeiten zur automatischen Aufzeichnung von Ereignissen über die gesamte Lebensdauer des Systems verfügen, im Verhältnis zum vorgesehenen Zweck. Logs können Rückverfolgbarkeit, Überwachung nach dem Inverkehrbringen und Betriebsüberwachung unterstützen. Sie erklären eine Entscheidung nicht durch Magie. Ein Log kann einem späteren Ermittler sagen, dass ein Tool aufgerufen wurde, dass eine Version aktiv war oder dass ein Prüfer ein Bedienelement angeklickt hat. Es kann für sich genommen nicht feststellen, ob der Prüfer die Beweise verstanden hat, ob die Eingabequelle maßgeblich war oder ob ein Verfahren fair war. Aufzeichnungen sind wertvoll, weil sie einer Untersuchung einen ehrlichen Ausgangspunkt geben, nicht weil sie die Notwendigkeit von Urteilsvermögen beseitigen.

Die Überwachung nach dem Inverkehrbringen vervollständigt das Bild. Artikel 72 verlangt, dass Anbieter von Hochrisiko-Systemen ein System zur Überwachung nach dem Inverkehrbringen einrichten und dokumentieren, und zwar in einer Weise, die der Art der Technologien und den Risiken des Hochrisiko-KI-Systems angemessen ist. Das hat eine einfache Konsequenz für Bereitstellungsteams: Eine Veröffentlichung ist nicht der Zeitpunkt, an dem das System vollständig bekannt wird. Die Organisation braucht einen Weg, um relevante Informationen zu erhalten, ein Signal von einer Schlussfolgerung zu unterscheiden, zu entscheiden, ob die Grenze des vorgesehenen Zwecks noch gilt, und eine Änderung vorzunehmen oder eine Nutzung zu stoppen, wenn die Beweise es erfordern.

Diese Arbeit ist nicht glamourös. Sie sieht aus wie Versionskennungen, klare Veröffentlichungskriterien, eine Aufzeichnung von Abhängigkeiten, ein Test für einen Umkehrweg, ein benannter Verantwortlicher für eine Einschränkung und eine Entscheidung, die sichtbar bleibt, nachdem die Person, die sie getroffen hat, die Rolle gewechselt hat. Sie sieht aus wie die Frage, ob sich eine Integration geändert hat, bevor man fragt, ob sich das Modell geändert hat. Sie sieht aus wie das Aufbewahren ausreichender Beweise, um eine Konsequenz zu korrigieren, anstatt sie nur im Nachhinein zu erklären. Langweilig ist hier nicht das Gegenteil von ambitioniert. Es ist der Teil, der Ehrgeiz in eine Institution passen lässt.

Wie man über das gesamte System nachdenkt, ohne Sicherheit vorzutäuschen

Eine vollständige Analyse ist keine Suche nach einer universellen Risikobewertung. Sie ist eine Abfolge von Fragen, die genauer wird, je genauer ein Design wird. Die erste Frage ist der Zweck: Was soll dieses System tun, und was soll es ausdrücklich nicht tun? Die zweite ist die Konsequenz: Wer kann betroffen sein, wie und durch welche Entscheidung oder Dienstleistung? Die dritte ist die Autorität: Welche Ausgabe kann einen Zustand verändern, eine Entscheidung beeinflussen, eine Priorität setzen oder ändern, was eine Person erhält? Die vierte ist die Evidenz: Was stützt die Nutzung des Systems in diesem Kontext, und welche Bedingungen lassen diese Evidenz übertragbar sein?

Dann kommen die unbequemen Fragen. Was passiert, wenn das Modell unsicher, falsch, nicht verfügbar oder außerhalb seiner angegebenen Grenze verwendet wird? Was ändert sich, wenn eine Quelle veraltet ist oder ein Tool verweigert wird? Was, wenn ein Nutzer es eilig hat, neu in der Rolle ist oder das zugrunde liegende Material nicht einsehen kann? Was, wenn eine betroffene Person eine Korrektur verlangt? Was, wenn ein Update eine Eingabeaufforderung, einen Abrufkorpus, einen Schnittstellendefault, eine Modellversion oder eine Rollenberechtigung ändert? Die Antwort ist manchmal eine technische Kontrolle, manchmal ein Verfahren, manchmal eine kleinere Nutzung, manchmal ein anderer Verantwortlicher und manchmal eine Entscheidung, nicht bereitzustellen. Governance, die die letzte Antwort nie zulässt, ist nur Genehmigung in einer hübscheren Jacke.

Es hilft, mehrere Aussagen getrennt zu halten. Eine bestätigte Tatsache sagt, was der Modellanbieter dokumentiert hat oder was die Organisation in einem definierten Test beobachtet hat. Eine Schlussfolgerung sagt, warum diese Tatsache in einem bestimmten Arbeitsablauf von Bedeutung sein kann. Eine vorgeschlagene Kontrolle sagt, was das Team umzusetzen beabsichtigt. Ein Restrisiko sagt, was nach der Kontrolle bleibt. Eine rechtliche Schlussfolgerung sagt, was nach dem Gesetz gilt. Diese sind nicht austauschbar. Ein gutes Dokument kennzeichnet sie, weil der Leser möglicherweise eine davon in Frage stellen muss, ohne die anderen zu verwerfen.

Zum Beispiel lässt sich sagen: Die Dokumentation des Anbieters stellt fest, dass das Modell eine bestimmte Einschränkung hat; das Bereitstellungsteam schließt daraus, dass die Einschränkung eine bestimmte Verwendung beeinträchtigen könnte; das Team schlägt ein Prüfverfahren zur Quellenverifizierung vor; das Prüfverfahren wurde unter der vorgesehenen Arbeitslast noch nicht getestet; und die Rechtsabteilung muss die resultierende Verwendung nach geltendem Recht bewerten. Dieser Satz ist weniger befriedigend als ein grüner Haken. Er ist nützlicher als ein grüner Haken, weil er keinen Zweifel daran lässt, was festgestellt wurde und was nicht.

Teams sollten mit dem Wort menschlich besonders vorsichtig sein. Eine menschliche Rolle kann eine Kontrolle sein, aber nur dort, wo sie eine definierte Aufgabe, ausreichende Informationen, Zeit, Schulung, Befugnis und einen Handlungsweg hat. Eine menschliche Rolle kann auch zu einer Möglichkeit werden, die Verantwortung auf die Person zu übertragen, die dem Bildschirm am nächsten sitzt. Der Unterschied ist nicht philosophischer Natur. Er ist im Arbeitsablauf sichtbar. Wenn ein Prüfer nur genehmigen kann, wenn Widerspruch in einem unbeaufsichtigten Kommentarfeld verschwindet oder wenn niemand die nachgelagerte Konsequenz korrigieren kann, hat das System keine bedeutsame Aufsicht gewonnen, nur weil eine Person etwas angeklickt hat.

Die gleiche Vorsicht gilt für Transparenz. Ein langes Dokument kann ein System beschreibbar machen, ohne es anfechtbar zu machen. Ein Dashboard kann es sichtbar machen, ohne es verständlich zu machen. Eine Offenlegung kann einem Nutzer mitteilen, dass KI beteiligt ist, ohne zu sagen, was gegen einen Fehler getan werden kann. Die nützliche Frage ist praktisch: Kann die betreffende Person die Grenze, die Belege, die verantwortliche Rolle und den Korrekturweg an dem Punkt finden, an dem diese Dinge von Bedeutung sind? Wenn nicht, existieren die Informationen am falschen Ort, als dass Governance stattfinden könnte.

Eine kleine Anmerkung von uns

Bei Dweve behandelt unser öffentliches Trust Centre den Modellbericht und die nachgelagerte Integration als zusammenhängende, aber getrennte Datensätze. Die Seite zur nachgelagerten Integration besagt, dass Teams, die Loom integrieren oder bereitstellen, aktuelle Fähigkeiten, Grenzen, Schnittstellen, Evaluationskontext und Änderungen benötigen, während der öffentliche Bericht feststellt, dass ein Modell ein Faden in einem breiteren Geflecht aus Komponenten und Betriebsgrenzen ist. Dies ist eine dokumentarische Haltung, keine Behauptung, dass eine öffentliche Seite jede mögliche Bereitstellung klassifiziert oder die Einhaltung von Vorschriften für einen Integrator nachweist. Der Zweck der Trennung ist bescheidener: Ein Modellbericht sollte mit der Integration reisen, ohne vorzugeben, die eigene Systemanalyse des Integrators zu ersetzen.

Das ist der Standard, den es zu bewahren gilt. Ein Modellanbieter sollte nützliche Informationen bereitstellen. Eine Organisation, die das Modell bereitstellt oder integriert, sollte das tatsächliche System beschreiben, das sie geschaffen hat: Zweck, Personen, Daten, Schnittstellen, Befugnis, Überwachung und Korrektur. Keine Seite sollte Dokumentation als zeremoniellen Austausch nutzen, bei dem eine Partei ein PDF erhält und die andere Absolution.

Die schwierigere Frage ist meist die bessere

Wenn ein Team fragt, ob ein Modell ein hohes Risiko darstellt, sucht es möglicherweise nach einer schnellen Antwort auf eine berechtigte Sorge. Aber die nützlichere Frage ist meist länger: Welches System bauen wir aus diesem Modell, für welchen Zweck, in welchem Kontext, mit welchen Personen, und was passiert, wenn es falsch liegt? Diese Frage lässt sich nicht immer in einer Besprechung beantworten. Sie kann aufdecken, dass die vorgesehene Verwendung enger ist als erwartet, dass die Belege unvollständig sind, dass einer Benutzerrolle die Befugnis fehlt, dass ein Vertrag eine wichtige Grenze ohne Verantwortlichen lässt oder dass eine nachgelagerte Integration stillschweigend zum Zentrum des Systems geworden ist.

Keiner dieser Befunde ist ein Versagen der Innovation. Es sind die Dinge, die eine Institution lernt, bevor sie einem System die Macht gibt, die Optionen eines anderen Menschen zu gestalten. Der europäische Ansatz wird oft als eine Reihe von Verpflichtungen beschrieben. Er ist auch eine Disziplin des Benennens: den Zweck benennen, den Akteur, den Kontext, die Version, die betroffene Person, die Einschränkung, die Evidenz und den Weg zum Eingreifen. Einmal benannt, können diese Dinge getestet, geändert und infrage gestellt werden. Bevor sie benannt werden, neigen sie dazu, später als Überraschung wieder aufzutauchen.

Ein Modell kann leistungsfähig, sorgfältig dokumentiert und wertvoll sein. Es kann auch in ein System eingebettet sein, das zu viel von ihm verlangt, zu viel vor seinen Nutzern verbirgt oder zu wenig Raum für eine von dem Ergebnis betroffene Person lässt. Der Unterschied entsteht außerhalb der Gewichte. Dort liegt die schwierige Arbeit, und dort liegt auch die ernsthafte Chance: Systeme zu bauen, deren Autorität zu ihrer Evidenz passt, deren Grenzen die Integration überstehen und deren Betreiber weiterhin Nein sagen können.

Quellen