Es reicht nicht aus, dass ein Unternehmen eine Richtlinie für die verantwortungsvolle Nutzung von KI veröffentlicht und dann annimmt, dass sich das Verhalten danach richtet. Entwickler arbeiten unter Zeitdruck und stehen vor unklaren Problemen. Daher greifen sie möglicherweise auf nicht genehmigte Tools zurück, wenn der offizielle Kanal langsam wirkt oder von den Einzelheiten der technischen Arbeit losgelöst ist. Daraus leitet der auf dem Stack Overflow Blog veröffentlichte Artikel eine zentrale Idee ab: Die Begrenzung der „Schatten-KI“ beginnt mit der Gestaltung des Workflows und nicht damit, dem Lernportal ein weiteres Dokument hinzuzufügen.
Der Beitrag stützt sich auf Ergebnisse von Stack Overflow zur Einführung von KI und zum Vertrauen der Entwickler. 84 % der Befragten gaben an, KI-Tools zu nutzen oder deren Nutzung zu planen, während es mehr Entwickler gibt, die der Genauigkeit dieser Tools nicht vertrauen, als solche, die ihnen vertrauen. Ergebnisse, die beinahe richtig erscheinen und anschließend zusätzliche Korrekturen erfordern, gehörten zu den wichtigsten Frustrationsquellen.
Nicht autorisierte Nutzung ist ein Hinweis auf einen Fehler im Workflow
Der Artikel schlägt vor, dass das Management jede nicht autorisierte Nutzung nicht als vollständig ausgeprägten Compliance-Verstoß behandeln sollte. Wenn ein Ingenieur sensible Inhalte in ein öffentliches Modell kopiert oder einen nicht genehmigten Programmierassistenten installiert, kann dies darauf hindeuten, dass der autorisierte Weg nicht die Daten, den Kontext, die Integrationen oder die Berechtigungen bereitstellt, die für die Erledigung der Aufgabe erforderlich sind.
Die praktische Reaktion beginnt mit diagnostischen Fragen: Welche Aufgaben treiben Entwickler zu externen Tools? Und welche Reibung behindert die genehmigte Alternative? Lässt sich das Experimentieren über genehmigte Plattformen und überwachte Gateways ermöglichen, die die Nutzung protokollieren, anstatt zu versuchen, sie durch ein pauschales Verbot zu verhindern? Aus dieser Perspektive wird die informelle Nutzung zu einem Beleg, der dem Unternehmen hilft, das System zu verbessern, und nicht automatisch zu einem Grund, Mitarbeiter dazu zu zwingen, ihre Experimente zu verbergen.
Die Richtlinie in eine technische Schnittstelle übersetzen
Eine gute Richtlinie legt den Zweck fest, doch ein guter Betrieb übersetzt ihn in Entscheidungen, die Entwickler während ihrer täglichen Arbeit treffen können. Der Artikel verweist auf die Funktionen des NIST-Rahmens für das Management von KI-Risiken: Govern, Map, Measure und Manage. In der Praxis sollten die Regeln erläutern, wie ein Anwendungsfall klassifiziert wird, welche Modelle und Datenquellen zulässig sind, wie Ergebnisse getestet werden, welche Stelle für die Genehmigung verantwortlich ist und welche Nachweise im Entwicklungsprotokoll aufbewahrt werden müssen.
Zu den Fragen, die eine Richtlinie direkt beantworten sollte, gehören: Welche Daten dürfen in jedes Tool eingegeben werden? Auf welche Repositorys oder Systeme darf das Tool zugreifen? Welcher Prüfungsumfang ist für generierten Code erforderlich? Wann ist das Eingreifen eines menschlichen Entscheidungsträgers erforderlich? Wie meldet ein Entwickler schädliche, unsichere oder unzuverlässige Ergebnisse? Und wann wird aus einem Experiment ein Produktionssystem? Der Artikel nennt Sicherheit und Datenschutz als wichtige Gründe dafür, dass Entwickler Technologien ablehnen. Klare Regeln können daher die Einführung unterstützen, wenn sie Unklarheit verringern.
Kontrollen dort einrichten, wo die Arbeit stattfindet
Eine in einem Schulungsportal gespeicherte Richtlinie hat es schwer, mit einem in die integrierte Entwicklungsumgebung eingebetteten Assistenten zu konkurrieren. Deshalb schlägt der Artikel vor, Kontrollen in Repositorys, Merge Requests, Build-Pipelines, Zugriffssystemen und Bereitstellungs-Workflows zu verankern. Beispiele sind das Speichern der Einstellungen genehmigter Modelle in einem Versionskontrollsystem, die rollenbasierte Beschränkung des Zugriffs, die Prüfung von Prompts und Ausgaben auf Geheimnisse, die Aufbewahrung von Protokollen bei risikoreicheren Anwendungsfällen sowie das Erzwingen von Tests vor der Zusammenführung generierter Änderungen.
Auch die Aussage „Überprüfe die KI-Ausgaben“ sollte in wiederholbare Schritte übersetzt werden, etwa Funktionstests, eine Prüfung der Kontextangemessenheit, eine Überprüfung der Abhängigkeiten und bei Bedarf ein gemeinsames Review. Nicht für alle Anwendungsfälle ist derselbe Genehmigungsgrad geeignet: Ein Tool, das Code erklärt, birgt andere Risiken als ein Agent, der Schreibrechte in Produktionssystemen besitzt. Der Artikel nennt Risiken aus der OWASP-Liste für generative KI-Anwendungen, darunter Prompt Injection, die Offenlegung sensibler Informationen, Schwächen in der Lieferkette, der unsachgemäße Umgang mit Ausgaben und übermäßige Berechtigungen.
Verantwortlichkeit, Schulung und Messung
Für jeden Anwendungsfall sollte ein eindeutig benannter menschlicher Verantwortlicher bestimmt werden, der das gewünschte Ergebnis versteht und befugt ist, den Prozess anzuhalten oder zu ändern. Nach der vorgeschlagenen Aufteilung tragen Produktverantwortliche die geschäftliche Entscheidung, technische Leiter die Qualität der Umsetzung, Sicherheits- und Datenschutzspezialisten legen die geeigneten Kontrollen fest, Entwickler sind für den von ihnen eingereichten Code verantwortlich, Reviewer für die Genehmigungsentscheidung und Betreiber für Überwachung und Reaktion auf Vorfälle.
Der Artikel plädiert außerdem für Schulungen, die an tatsächliche Entscheidungen der Entwickler anknüpfen, statt für eine allgemeine Sensibilisierungssitzung. Dazu gehören genehmigte Tools, zulässige Daten, Fehlermuster, Prüfungsanforderungen, Eskalationswege und Beispiele aus der Unternehmensumgebung. Die Schulung sollte nutzbare Elemente für den Workflow hervorbringen, etwa Repository-Anweisungen, Checklisten, Testsammlungen, genehmigte Prompt-Muster und dokumentierte Beispiele. Ein Zertifikat bestätigt die Teilnahme, doch diese Elemente beeinflussen das Verhalten.
Die Erfolgsmessung sollte sich nicht auf die Zahl der Lizenzen, Prompts oder aktiven Nutzer beschränken. Der Artikel schlägt vor, den Workflow vor und nach der Einführung des Tools anhand von Kennzahlen zu vergleichen, etwa Zykluszeit, in die Produktion gelangende Fehler, Rollbacks, Ergebnisse von Sicherheitsprüfungen, Review-Aufwand, Dokumentationsqualität, Vorfälle, Entwicklerzufriedenheit und den für die Korrektur von Ausgaben aufgewendeten Zeitaufwand. Dieser Punkt verdient besondere Aufmerksamkeit, weil die DORA-Ergebnisse für 2024 eine höhere Einführung mit einer verbesserten Qualität der Dokumentation und des Codes sowie einer höheren Review-Geschwindigkeit in Verbindung brachten, zugleich aber auch potenzielle negative Auswirkungen auf die Leistung der Softwarebereitstellung feststellten. Auch die Stack-Overflow-Umfrage verwies auf mögliche individuelle Vorteile durch Agenten, ohne entsprechende Vorteile bei der Zusammenarbeit im Team.
Die redaktionelle Einordnung von certi.news
Die vom Beitrag vorgeschlagene tatsächliche Veränderung liegt nicht in der Formulierung einer neuen Richtlinie, sondern in der Verlagerung der Verantwortung von der Dokumentationsebene auf die Ebene der Tools und Prozesse. Der sichere Weg wird nutzbar, wenn er genehmigte Tools, hilfreichen Kontext, klare Grenzen, eine schnelle Eskalation und Kontrollen bereitstellt, die der Sensibilität der Daten, dem Grad der Autonomie und der Reversibilität der Auswirkungen entsprechen.
Dies ist kein Rezept zur Abschaffung menschlicher Urteilsfähigkeit, sondern ein Versuch, sie zu einem sichtbaren Bestandteil des Entwicklungszyklus zu machen. Die Wirksamkeit der Vorschläge hängt weiterhin davon ab, inwieweit jedes Unternehmen seine Anwendungsfälle bestimmen und ihre tatsächlichen Ergebnisse messen kann. Außerdem fassen die im Artikel genannten Zahlen Ergebnisse mehrerer Studien und Umfragen zusammen und belegen allein nicht, dass jede Entwicklungsumgebung dasselbe Ergebnis erzielen wird.