Skip to main content
Entwickler Themen
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

0.3. Probleme bei der Nutzung

Kurzfassung

Unter Was sind LLMs steht die Arbeitsweise: Das Modell setzt Text fort. Es sucht nicht die eine richtige Antwort. Genau daraus folgen die Fehler, die in der täglichen Nutzung spürbar sind — nicht als seltene Bugs, sondern als Normalfall, den ich einplanen muss.

Ich behandle jede Antwort als Entwurf. APIs, Pakete und Zitate prüfe ich gegen Dokumentation, Compiler oder Registry, nicht gegen den selbstsicheren Ton. Tests und Review sind die Leitplanken. Was in den Prompt geht, verlässt oft meinen Rechner. Sobald Werkzeuge mitreden, kann fremder Text zur Anweisung werden.

Nichts davon ist „gelöst“. Nachschlagen, Filter und Verträge verringern die Trefferquote. Sie schließen das Loch nicht. Wer Daten nicht in die Cloud geben will oder die Filter des Anbieters nicht übernehmen will, kann ein Modell lokal betreiben — mit anderen Grenzen.

Plausible Fortsetzung ist nicht wahr

Das Modell erzeugt flüssigen Text, der statistisch passt. Ob der Text stimmt, ist eine andere Frage. Genau das ist mit Halluzinationen gemeint: erfundene Fakten, Methoden, Parameter, Quellen — und im Code erfundene APIs und Abhängigkeiten.

Ein Java-Alltag reicht als Bild. Ich bitte um eine Maven-Dependency oder eine Spring-Methode. Die Antwort enthält groupId, Versionsnummer und einen fertigen Aufruf. Das liest sich wie Dokumentation. Es ist eine plausible Fortsetzung. Maven Central oder der Compiler entscheiden, ob sie existiert — nicht der selbstsichere Satz davor.

Dasselbe gilt für Paketnamen. Modelle erfinden immer wieder Namen, die wie PyPI, npm oder Maven Central klingen. Ein Angreifer kann genau diesen Namen mit Schadsoftware registrieren. Dann installiert pip install oder npm install aus dem Chat nicht „nichts“, sondern Malware. Deshalb übernehme ich keine Dependency ungeprüft aus einer Antwort.

OpenAI sagt das für GPT-4 selbst: Das Modell ist nicht vollständig zuverlässig, es halluziniert Fakten und macht Denkfehler. Bei wichtigen Einsätzen rät OpenAI zu menschlicher Prüfung, zu zusätzlichem Kontext — oder dazu, den Einsatz zu lassen. Nachschlagen und Werkzeuge helfen, weil Wissen in den Gewichten begrenzt und schwer zu aktualisieren ist. Sie machen das Modell nicht halluzinationsfrei. Der Generator bleibt ein Sprachmodell.

Der Ton ist kein Beweis

Das Modell klingt kompetent, auch wenn es falsch liegt. Unter Was sind LLMs steht dasselbe als Haltung: Ein selbstsicherer Ton sagt wenig über Wahrheit.

Dazu kommt Sycophancy: Größere Modelle neigen dazu, der Meinung im Dialog zu folgen. Rückmeldungen von Menschen belohnen oft Antworten, die zum Fragenden passen, nicht Antworten, die wahr sind. Das Modell „will“ nicht gefallen. Es ist auf plausible, bevorzugte Fortsetzung trainiert.

Deshalb lasse ich Widerspruch zu. Ich bitte um Quellen und prüfe sie. Eine zweite Meinung von einem anderen Modell ersetzt das nicht, sie reduziert nur, dass zwei Systeme denselben Fehler teilen.

Ich bleibe verantwortlich

Der Nutzungsfehler sitzt oft nicht im Modell, sondern bei mir: Ich übernehme Vorschläge, weil sie schnell und flüssig sind. Codex schreibt das offen: Das Modell kann undefinierte Symbole vorschlagen und Funktionen außerhalb des Scopes aufrufen. Menschliche Aufsicht sei nötig.

Der DORA-Report 2025 (extern) beschreibt dieselbe Spannung in der Fläche. Etwa 90 Prozent der Befragten nutzen KI bei der Arbeit. Mehr als 80 Prozent glauben, sie steigere die Produktivität. Rund 30 Prozent haben wenig oder kein Vertrauen in den generierten Code. KI verstärkt vorhandene Stärken und Schwächen. Das Tempo der Auslieferung steigt; die Stabilität kommt nicht automatisch mit.

Ich prüfe KI-Diffs deshalb wie Diffs von Menschen. Tests sind der Harness: Was grün ist, darf weiter. Was ich nicht erklären kann, merge ich nicht. Kleine Änderungen sind leichter zu prüfen als große Batches. Das macht Entwickler nicht „dumm“. Es hält die Kompetenz dort, wo das Modell sie nicht ersetzen kann.

Code kann unsicher sein

Code-Modelle lernen von öffentlichem Code. Öffentlicher Code enthält Fehler. Pearce und Kollegen haben Copilot in Sicherheits-Szenarien zu bekannten Schwachstellenklassen (MITRE Top 25) getestet: Rund 40 Prozent der erzeugten Programme wurden als verwundbar bewertet. Das ist kein Anteil aller Pull Requests im Alltag. Es zeigt: Wenn die Aufgabe unsicheren Code nahelegt, liefert das Modell ihn häufig mit.

OpenAI nennt dasselbe für GPT-4: Das Modell kann Sicherheitslücken in erzeugten Code einbauen. GitHub macht die Prüfung zur Aufgabe der Nutzenden; Filter sollen unsichere Vorschläge teilweise blocken. Filter sind keine Garantie.

Ich übernehme deshalb keine Defaults, die ich bei Menschen auch ablehnen würde: zusammengebaute SQL-Strings, zu weite Rechte, Secrets im Klartext, ungeprüfte Shell-Aufrufe. Statische Analyse, Tests und Review gelten für KI-Code genauso. Die Ausgabe des Modells gehört nicht ungeprüft in die Shell, nach SQL oder nach eval.

Das Modell kennt nicht ‘jetzt’ und nicht ‘die ganze Datei’

Die Gewichte sind ein Snapshot. GPT-4 formuliert das als Trainingsstichtag: Reines Modellwissen endet irgendwann, und das Modell lernt nicht dauerhaft aus dem Gespräch. Neuere Produktmodelle haben spätere Stichtage und oft Suche. Das Konzept bleibt. Bibliotheken, JDK und Cloud-APIs ändern sich schneller als Gewichte.

Suche und ein Index helfen nur so weit, wie die Quelle aktuell und die zitierte Stelle echt ist. Halluzinierte URLs gibt es auch mit Browser.

Das Kontextfenster ist das Kurzzeitgedächtnis dieser Anfrage, nicht das Trainingskorpus. Anthropic beschreibt es als Working Memory: Systemhinweis, Verlauf, Werkzeuge, Dateien und die Antwort selbst zählen. Was nicht hineinpasst, fällt weg.

„Im Kontext“ heißt außerdem nicht „genutzt“. Liu und Kollegen zeigen: Die Leistung ist oft am Anfang und am Ende des Fensters am höchsten und in der Mitte deutlich schlechter. Länger ist nicht automatisch besser.

Deshalb pinne ich Versionen, lese die offizielle Dokumentation und führe Code aus. Ich hänge relevante Ausschnitte an, nicht das ganze Repository. Wichtiges gehört an den Rand oder kommt mehrfach — nicht in die Mitte eines 200-Dateien-Dumps.

Was ich hineinschreibe, verlässt meinen Rechner

Prompts, Dateien, Repo-Ausschnitte, Tickets und Secrets im Code kommen beim Anbieter an, sobald der Weg über die Cloud geht. Stehen personenbezogene Daten darin, gilt die Datenschutz-Grundverordnung: Minimierung, Zweckbindung, Sicherheit, eine Rechtsgrundlage — und bei US-Anbietern die Regeln für Drittlandübermittlung. Das ist der Gesetzestext, keine Sonderregel für ChatGPT.

Die europäische Datenschutzbehörde (EDSA) sagt das für ChatGPT ausdrücklich: Technische Unmöglichkeit entbindet nicht. Prompts sind Inhalt. Nutzer müssen wissen, wenn Eingaben zum Training dienen. Halluzinationen über Personen sind ein Problem der Richtigkeit, nicht nur des Tons. Die DSGVO verbietet ChatGPT nicht. Sie verlangt, dass die Verarbeitung rechtmäßig, minimiert und absicherbar ist.

Die Kanäle sind nicht gleich. Stand der Anbieterdokumentation — das ändert sich:

  • Consumer-Chat (ChatGPT, Claude Free/Pro, Copilot für Einzelpersonen) kann Eingaben zum Training nutzen, oft mit Opt-out oder temporärem Chat.
  • API, Business, Enterprise trainieren OpenAI und Anthropic in der Regel nicht auf Kundeninhalten. Missbrauchsprotokolle bleiben oft einige Wochen stehen. „Zero Data Retention“ ist ein Vertrag und eine Freigabe, kein Schalter in der Chat-Oberfläche.
  • GitHub Copilot Business/Enterprise trainiert laut Dokumentation nicht. Bei den privaten Plänen können Interaktionen zum Training zählen; private Repos „in Ruhe“ sind nicht dasselbe wie Snippets während der Nutzung.

Ich schreibe keine Secrets, keine Kundenakten und keine Personaldaten in Prompts. Consumer-Chat ist nicht der Kanal für Firmen-Code. Einen Enterprise-Vertrag, eine Auftragsverarbeitung und eine klare Richtlinie, welcher Kanal wofür gilt, sind der erste Hebel. Sie ersetzen lokale Modelle nicht immer.

Lokal zu rechnen ist die schärfere Variante derselben Idee: Die Inferenz findet auf eigener Hardware statt. Ollama (extern) formuliert das für den lokalen Betrieb ausdrücklich: Prompts und Antworten gehen nicht an ollama.com. Die Gewichte liegen nach dem Download auf der Maschine. Unter Meine Entwicklungsumgebung betreibe ich genau das: Ollama mit Open WebUI auf dem eigenen Linux-Server.

Das entschärft das Cloud-Problem. Es beseitigt Datenschutz nicht magisch.

  • „Lokal“ gilt nur für lokale Modelle. Cloud-Tags und Websuche gehen wieder nach außen; Ollama sagt das selbst und bietet einen Schalter, Cloud-Funktionen auszuschalten.
  • Was die Oberfläche oder die Logs bei mir speichern, bleibt eine Verarbeitung — mit Personenbezug gilt die DSGVO weiter, nur ohne US-Anbieter in der Mitte.
  • Ich übernehme Betrieb, Updates, Hardware und die Qualität des kleineren Modells. Halluzinationen und unsicherer Code bleiben.
  • Die Ausrichtung sitzt oft schon in den Gewichten. Ein Chat-Llama verweigert Themen, auch wenn kein OpenAI-Server mehr in der Leitung ist.

Genau diese Verweigerung ist der zweite Grund, warum lokale Modelle in denselben Absatz gehören. Geschlossene Produkte entscheiden mit, was ich höre, nicht nur, wo der Prompt landet.

Das ist Absicht, kein Zufall. InstructGPT und Constitutional AI richten Modelle darauf aus, hilfreich und harmlos zu sein. Die OpenAI Model Spec (extern) nennt die Grenze „Stay in bounds“: keine detaillierten Anleitungen für illegale oder großflächig schädliche Handlungen (information hazards), keine gezielte politische Manipulation einzelner Gruppen, sexuelle und brutale Inhalte nur in engen Kontexten. Anthropic und Meta formulieren vergleichbare Nutzungsregeln — Meta auch für heruntergeladene Llama-Gewichte.

Labs nennen das Safety. Aus der Nutzung kann es wie Zensur wirken, sobald der Filter weiter greift als das Verbotene. Modelle verweigern dann harmlose Fragen, weil ein Wort wie in einer unsicheren Anfrage klingt. Röttger und Kollegen messen das als übertriebene Safety (Over-Refusal): Llama-2-Chat wies einen großen Teil klar sicherer Prompts zurück; ein Systemprompt verschiebt die Grenze, löscht sie nicht.

Die Unterscheidung bleibt wichtig. Kindesmissbrauch, Waffenbau, klare Straftaten: hier soll das Modell nicht mitmachen, und der Gesetzgeber verlangt das teilweise. Die Grauzone ist der Rest: NSFW-Politik des Anbieters, Themen, die er nicht bedienen will, und die übervorsichtige Absage bei Sicherheitsforschung, Medizin oder Politik. Die Policy schreibt der Anbieter. Ich kann sie in der Cloud nicht abwählen.

Lokal verschiebt, wer die Policy setzt. Es löscht sie nicht. Wer Filter in den Gewichten oder davor abstreift, übernimmt das Missbrauchsrisiko selbst. Für den Alltag reicht die Haltung: Der Assistent in der Cloud ist weder ein Notar noch ein unparteiisches Archiv. Er ist ein Produkt mit Regeln.

Sobald Tools mitreden

Ein reiner Chat ohne Werkzeuge kann halluzinieren. Er kann meinen Rechner nicht löschen. Sobald Suche, Dateizugriff, Browser, MCP oder „Computer Use“ dazukommen, ändert sich die Grenze.

Sprachmodelle trennen Anweisung und Daten nicht sauber. Beides sind Tokens. Indirect Prompt Injection legt Anweisungen in Inhalte, die die Anwendung selbst holt: eine Webseite, eine E-Mail, eine Datei im Repository. Der Angreifer braucht keine Chat-Oberfläche. Greshake und Kollegen haben das 2023 gezeigt. OWASP führt Prompt Injection als zentrale Klasse für LLM-Anwendungen; es gibt kein zuverlässiges Gegenstück zu Prepared Statements.

Anthropic benennt dasselbe für Computer Use: Isolation, Allowlists, Bestätigung durch Menschen. OpenAI Function Calling macht die Grenze deutlich: Das Modell erzeugt strukturierte Aufrufe. Die Anwendung führt aus. Die Vertrauensgrenze liegt in meinem Code, nicht im Modell.

Zu viele Werkzeuge, zu weite Rechte, zu viel Autonomie — OWASP nennt das Excessive Agency. Anthropic rät bei Computer Use zu Aufgaben mit geringem Risiko und zu Bestätigung, bevor in der echten Welt etwas passiert: Mails, Zahlungen, rm, Push, Produktionsdatenbank.

Was hilft, begrenzt den Schaden, beseitigt den Angriff nicht:

  • Fremder Inhalt ist nicht automatisch eine Anweisung.
  • Zugangsdaten und zerstörerische Aktionen gehören in Anwendungsregeln, nicht ins Modell.
  • Menschen bestätigen Seiteneffekte.
  • Least Privilege, Allowlists, Sandbox.
  • Fremde MCP-Server behandle ich wie fremde Pakete: beschreiben, prüfen, nicht wild einstecken.

Lizenz und Kennzeichnung, ohne Anwalt zu spielen

Ich bin kein Anwalt. Was folgt, ist Textnähe zu Dokumentation und Vorschriften, keine Beratung.

GitHub dokumentiert, dass Vorschläge in seltenen Fällen mit öffentlichem Code übereinstimmen können. Es gibt einen Abgleich gegen indizierte Repositories und die Option, Treffer zu blocken oder mit Herkunft anzuzeigen. Der Index ist lückenhaft. Die Lizenz klärt nicht der Assistent. Filter ersetzen keine Prüfung, bevor Copyleft-Schnipsel in das eigene Repository wandern. „Der Copilot hat es vorgeschlagen“ ist keine Rechtfertigung.

Ob das Training auf urheberrechtlich geschütztem Material in jedem Fall erlaubt ist, entscheiden Gerichte fallweise. In der EU gibt es Text-und-Data-Mining-Ausnahmen, gekoppelt an rechtmäßigen Zugang und an den Vorbehalt der Rechteinhaber. Der AI Act verpflichtet Anbieter von General-Purpose-AI, solche Vorbehalte zu beachten. Das entlastet mich nicht beim Einfügen von Output.

Ab August 2026 gilt Art. 50 des AI Act zur Transparenz: Wer direkt mit einem KI-System spricht, soll das erfahren, sofern es nicht offensichtlich ist. Bestimmte synthetische Inhalte sollen maschinenlesbar markiert werden. Deepfakes und KI-Text zu Themen öffentlichen Interesses brauchen Kennzeichnung — mit Ausnahmen, etwa wenn ein Mensch redaktionell verantwortlich zeichnet. Nicht jedes interne Copilot-Fenster ist deshalb ein Hochrisiko-System. Hochrisiko hängt am Einsatzzweck (etwa Bewerbungsscreening), nicht daran, dass ein LLM in der IDE läuft.

Was ich nicht vertiefe

Ein paar Risiken gehören auf die Landkarte, sprengen dieses Kapitel aber:

  • Memorization: Trainingsdaten können wörtlich wieder auftauchen, auch aus Produktionsmodellen. Secrets gehören nicht ins öffentliche Repository — und Consumer-Chats sind kein Tresor.
  • Bias: Trainingskorpora tragen Stereotypen. Bei Recruiting-Texten und öffentlichkeitswirksamer Copy bleibt die Freigabe beim Menschen.
  • Nicht-Determinismus: Dieselbe Anfrage liefert nicht bitgleich dieselbe Antwort. Für Audits versioniere ich Prompt und Modell und teste Verhalten, nicht Prosa.
  • Kosten und Modellwechsel: Große Kontexte und Agent-Schleifen werden teuer und unzuverlässiger. Geschlossene Modelle ändern sich mit Updates. Offene Gewichte verschieben Betrieb und Datenschutz auf mich; halluzinationsfrei sind sie deshalb nicht.

Rahmen wie die Risikotaxonomie von Weidinger, das NIST AI Risk Management Framework oder die OWASP Top 10 für LLM-Anwendungen ordnen das Feld. Dieses Kapitel folgt der Nutzung, nicht der Behördentabelle.

Was man davon mitnehmen sollte

Die Arbeitsweise aus Was sind LLMs und die Linien aus der Geschichte ändern sich hier nicht. Es ändert sich, was ich tue:

  • Jede Antwort ist ein Entwurf. Flüssige Sprache ist kein Beleg.
  • Tests, Compiler, Docs und Review sind der Harness. Ohne sie ist der Assistent eine ungeprüfte Quelle.
  • Consumer-Chat, API und lokales Modell sind verschiedene Verarbeitungen. Secrets und Kundendaten gehören in keinen Prompt, der das nicht tragen darf. Der Cloud-Anbieter filtert außerdem, was er antwortet; lokal verschiebt das die Kontrolle, nicht die Verantwortung.
  • Werkzeuge vergrößern den Hebel und den Schaden. Menschen bestätigen, bevor etwas in der echten Welt passiert.
  • Filter, RAG und Verträge verringern das Risiko. Sie beseitigen Halluzination, Injection und unsicheren Code nicht.

Genau deshalb bleiben Clean Code, Architektur und Tests auf dieser Seite zentral. Sie sind Handwerk für Menschen — und Leitplanken für die KI.

Quellen und Vertiefung

Die Aussagen oben stützen sich auf Originalarbeiten, Systemkarten der Labore, First-Party-Dokumentation und Amtstexte. Die meisten Quellen sind Englisch. Zahlen (Anteile, Stichtage, Aufbewahrungsfristen) sind Belegstand; im Fließtext trägt das Konzept.

Note
Wer nur wenige Quellen lesen will: den GPT-4-Bericht (Halluzination und Prüfung), Codex zu Oversight und OWASP zu Prompt Injection und Excessive Agency.

Halluzinationen, Code, Oversight

Ton, Übernahme, Alltag

Stichtag und Kontext

Datenschutz

Tools, Injection, Agenten

Lizenz und Regulatorik

Rahmen (nicht Kapitelstruktur)