Ein Modell, das Sie einkaufen und unverändert nutzen, ist eine andere Situation als ein Modell, das Sie finetunen, mit eigenen Daten nachtrainieren oder mit anderen Systemen zusammenführen. Die dazu passende Frage ist nicht, ob das erlaubt ist, sondern was sich dadurch an Ihrer Rolle ändert. Diese Seite beschreibt, wovon diese Einordnung abhängt. Der aktuelle Regelungsinhalt steht an anderer Stelle; hier geht es um den Mechanismus, der bestimmt, wann sich etwas ändert und was Sie intern damit tun.
Ob die Anpassung eines Modells Ihre Rolle verändert, hängt von einer Reihe von Faktoren ab, die Sie pro Situation feststellen müssen, nicht von einer festen Grenze, die für jedes Modell gleich ist.
Diese Faktoren wirken zusammen. Keiner dieser Punkte ist für sich allein entscheidend; die Kombination bestimmt, ob die Anpassung Ihre Position verändert.
Wenn die Anpassung schwer genug ist, ändert sich in der Regel nicht nur die Einordnung des Modells, sondern auch das, was von der Organisation erwartet wird: andere Dokumentation, andere interne Verantwortlichkeit, möglicherweise eine andere Partei, die für das Gesamtsystem ansprechbar ist. Dieser Mechanismus, und die Unterscheidung zwischen einer Partei, die ein Modell nur nutzt, und einer Partei, die das Modell mitgestaltet, ist ausgeführt auf der Seite, die den Unterschied zwischen Anbieter und Nutzer beschreibt. Wann eine Anpassung genau schwer genug ist, um diese Rolle kippen zu lassen, ist eine Frage, die pro System einzeln beantwortet werden muss; der allgemeine Mechanismus dahinter steht auf der Seite über den Zeitpunkt, an dem sich Ihre Rolle ändert.
Die Folgen dieser Kippung hängen ihrerseits wieder vom Risikoniveau ab, das das angepasste Modell erhält. Ein angepasstes Modell, das in eine Hochrisikokategorie fällt, bringt andere Pflichten mit sich als ein angepasstes Modell, das außerhalb davon bleibt. Was ein hohes Risikoniveau in der Praxis für interne Prozesse und Aufsicht bedeutet, steht beschrieben auf der Seite über die Folgen eines hohen Risikoniveaus für Ihre Organisation. Umgekehrt ist es auch möglich, dass eine Anpassung ein System gerade außerhalb der schwersten Kategorie hält, oder dass der Anwendungsbereich schlicht nicht unter die Regelung fällt; welche Anwendungen außerhalb des Anwendungsbereichs fallen und warum, steht auf der Seite über Anwendungen, die außerhalb des Anwendungsbereichs fallen.
Anpassungen an Modellen geschehen oft nah an der eigentlichen Arbeit: ein Team, das ein externes Modell mit eigenen Dokumenten finetunt, ein Entwickler, der zwei Systeme miteinander verknüpft, eine Abteilung, die einen Chatbot mit internen Wissensdatenbanken füttert. Das sind genau die Anpassungen, die nicht über einen zentralen Beschaffungsprozess laufen und daher nicht automatisch auf einer IT-Liste stehen. Wer wissen möchte, ob und wo dies innerhalb der Organisation geschieht, muss danach fragen — und das funktioniert nur, wenn die Frage nicht mit einer Abrechnung verknüpft ist. Ein Team, das ein Modell angepasst hat, ohne dafür um Erlaubnis zu bitten, meldet das nicht, wenn die Antwort eine Sanktion nach sich zieht.
Weil die Einordnung von Anpassungen nicht feststeht, sondern pro Situation ermittelt wird, reicht es nicht aus, einmalig festzulegen, welche Rolle ein Modell hat. Anpassungen, die nach der ersten Beurteilung erfolgen, müssen erneut dieselben Fragen durchlaufen. Eine Richtlinie, die dies unterstützt, muss in gewöhnlicher Sprache beschreiben, wann eine Anpassung gemeldet werden muss und an wen; wie eine solche Richtlinie lesbar bleibt, statt ein Text zu sein, den niemand konsultiert, steht auf der Seite über eine KI-Richtlinie, die tatsächlich gelesen wird. Darüber hinaus ist es wichtig, dass Entscheidungen über Anpassungen — wer zugestimmt hat, aufgrund welcher Abwägung, mit welchem Risikoniveau als Ergebnis — an einer Stelle festgehalten werden, an der sie wiederauffindbar sind. Wie eine solche Dokumentation in der Praxis aussieht, steht auf der Seite über eine Oversight-Entscheidungsliste.
Die Einordnung eines angepassten Modells bestimmt, welche Pflichten gelten, sagt aber nichts darüber aus, was das Modell in der Praxis mit der eigentlichen Arbeit macht. Für diese Frage — welcher Teil einer Aufgabe von KI übernommen wird, welcher Teil bei einem Mitarbeiter bleibt, und was eine Anpassung darin verschiebt — ist ein anderer Blick nötig als eine Risikobeurteilung. Der Werkscan von FTE TO AI berechnet pro Aufgabe, welcher Teil der Arbeit von KI übernommen werden kann, unabhängig von der Frage, welche Governance-Regeln auf das Modell anwendbar sind.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.