Kosten: Rechnen statt schätzen
Abgerechnet wird nach Tokens, getrennt nach Ein- und Ausgabe, wobei Ausgabe-Tokens typischerweise vier- bis fünfmal so teuer sind. Zwischen der kleinsten und der größten Modellklasse liegt etwa Faktor 20.
Daraus folgt die wichtigste Betriebsentscheidung: nicht jede Anfrage braucht das stärkste Modell. Klassifikation, Extraktion und Routing erledigt ein kleines Modell zuverlässig und für einen Bruchteil. Nur die schwierigen Fälle gehen an das große – ein Muster, das die Kosten oft um 70 bis 90 % senkt, ohne dass die Qualität spürbar leidet.
Neben der Modellwahl gibt es drei weitere Hebel, die in dieser Reihenfolge wirken: kürzere Ausgaben verlangen, wiederkehrenden Kontext zwischenspeichern (Prompt-Caching) und den mitgeschickten Verlauf begrenzen, statt bei jeder Anfrage die gesamte Historie erneut zu senden.
| Hebel | Ersparnis | Aufwand | Risiko |
|---|---|---|---|
| Kleines Modell für einfache Aufgaben | 70 – 90 % | Mittel: Aufteilung und Messung nötig | Qualitätsverlust, wenn die Aufteilung schlecht gewählt ist |
| Ausgabelänge begrenzen | 20 – 50 % | Gering: eine Zeile im Prompt | Antworten werden zu knapp für den Zweck |
| Prompt-Caching | 50 – 90 % auf den wiederholten Teil | Gering, wenn der Kontext stabil bleibt | Wirkungslos bei ständig wechselndem Kontext |
| Verlauf kürzen | je nach Gesprächslänge erheblich | Mittel: Zusammenfassen statt Abschneiden | Das Modell verliert früheren Kontext |
Qualität messen, nicht behaupten
Der häufigste Fehler beim Einsatz von Sprachmodellen ist, Qualität nach Gefühl zu beurteilen. Wer keinen Testsatz hat, merkt Verschlechterungen erst durch Beschwerden – und kann nicht beurteilen, ob eine Prompt-Änderung wirklich geholfen hat.
Der Aufwand dafür ist geringer als befürchtet: 50 bis 100 typische Fälle mit erwartetem Ergebnis, festgehalten in einer Tabelle. Vor jeder Änderung durchlaufen lassen, Trefferquote vergleichen. Bei Aufgaben ohne eindeutige Lösung – Zusammenfassungen, Formulierungen – kann ein zweites Modell nach festen Kriterien bewerten, was für Rangfolgen erstaunlich gut funktioniert.
Und: Modelle werden von den Anbietern aktualisiert. Ein Prompt, der monatelang lief, kann sich nach einem Versionswechsel anders verhalten. Ohne Testsatz merkt man das nicht rechtzeitig.
- Testsatz mit erwarteten Ergebnissen anlegen – 50 bis 100 Fälle reichen für den Anfang
- Vor jeder Prompt- oder Modelländerung erneut durchlaufen lassen
- Im Betrieb Trefferquote und Konfidenz protokollieren, nicht nur Fehler
- Schwellwert definieren, ab dem ein Mensch übernimmt
- Modellversionen pinnen, wo möglich, und Wechsel bewusst testen
Prompt Injection: der Angriff über Inhalte
Sobald ein System fremde Inhalte verarbeitet – Dokumente, E-Mails, Webseiten, Kundennachrichten –, entsteht eine Angriffsfläche, die es bei klassischer Software so nicht gab. Für ein Sprachmodell sind Anweisung und Inhalt derselbe Text. Wer eine Anweisung in ein Dokument schreibt, kann versuchen, das Verhalten des Systems zu steuern.
Das ist keine theoretische Sorge. Die folgende Demo zeigt den in der Praxis relevantesten Fall: eine manipulierte Zahlungsanweisung in einer eingehenden Rechnung.
Datenschutz und Rechtsrahmen mitdenken
Sobald personenbezogene Daten an ein Modell gehen, gilt die DSGVO in vollem Umfang: Rechtsgrundlage, Auftragsverarbeitungsvertrag mit dem Anbieter, Prüfung des Drittlandtransfers, Löschkonzept, Eintrag im Verarbeitungsverzeichnis. Technisch entlastet, wer Daten vor der Übergabe minimiert oder pseudonymisiert – oft braucht das Modell den Namen gar nicht, um die Aufgabe zu lösen.
Dazu kommt der EU AI Act. Für die meisten Anwendungen im Mittelstand sind zwei Punkte unmittelbar relevant: die Pflicht zu ausreichender KI-Kompetenz der Mitarbeitenden und die Prüfung, ob eine Anwendung in einen Hochrisiko-Bereich fällt – bei KI im Personalwesen etwa ist das der Fall.
Auch die Betriebsarchitektur ist eine Datenschutzentscheidung: Anbieter-API mit Auftragsverarbeitungsvertrag, EU-Region beim Hyperscaler oder ein offenes Modell auf eigener Hardware. Der letzte Weg gibt volle Datenhoheit, kostet aber Betriebsaufwand und liegt bei der Modellqualität meist etwas zurück.
| Betriebsart | Datenhoheit | Modellqualität | Betriebsaufwand | Passt bei |
|---|---|---|---|---|
| Anbieter-API mit AV-Vertrag | Vertraglich geregelt, Daten verlassen das Haus | höchste | sehr gering | Allgemeine Aufgaben ohne besonders sensible Daten |
| Hyperscaler, EU-Region | Daten bleiben in der EU, AV-Vertrag inklusive | hoch | gering bis mittel | Unternehmen mit bestehender Cloud-Landschaft |
| Offenes Modell, eigene Hardware | vollständig im Haus | gut, meist etwas hinter der Spitze | hoch: GPUs, Updates, Fachpersonal | Besonders sensible Daten, hohe Compliance-Anforderungen |
Beispiel: Bewerbungsvorauswahl
Ein Unternehmen will eingehende Bewerbungen automatisch vorsortieren. Datenschutzrechtlich sind Bewerbungsunterlagen besonders sensibel; nach EU AI Act fällt KI-gestützte Bewerberauswahl unter Anhang III und damit in den Hochrisiko-Bereich. Praktikabler Zuschnitt: Das System extrahiert und strukturiert Angaben – Qualifikationen, Berufsjahre, Zertifikate – und erstellt daraus eine übersichtliche Vergleichstabelle. Die Bewertung und jede Ablehnung bleibt beim Menschen. Der Zeitgewinn ist fast derselbe, die rechtliche Lage grundlegend anders.
Die rechtlichen Anforderungen behandeln zwei eigene Kurse ausführlich – mit Fristen, Rollen und konkreten Umsetzungsschritten.
Zum Kurs EU AI ActVom Prototyp zum Produktivsystem
Zum Abschluss die Punkte, die den Unterschied ausmachen – und die erfahrungsgemäß in dieser Reihenfolge schmerzhaft werden, wenn sie fehlen.
- Fehlerfälle: Was passiert bei Zeitüberschreitung, Ratenbegrenzung oder Ausfall des Anbieters?
- Grenzen: Kosten- und Schrittlimits je Nutzer und je Vorgang, hart durchgesetzt
- Protokoll: Ein- und Ausgaben nachvollziehbar speichern – unter Beachtung der Löschfristen
- Mensch im Ablauf: klar definierter Schwellwert, ab dem übernommen wird
- Wechselmöglichkeit: Anbieter hinter einer eigenen Schnittstelle kapseln, statt sich fest zu binden
- Erwartungsmanagement: Nutzern sagen, was das System nicht kann – das verhindert mehr Schaden als jede Prompt-Optimierung
| Phase | Was gut läuft | Was regelmäßig fehlt |
|---|---|---|
| Prototyp (1–3 Wochen) | Beeindruckende Demo an ausgewählten Beispielen | Gegenprobe an unsauberen Echtdaten |
| Pilot (1–3 Monate) | Erste echte Nutzer, erste Zeitersparnis | Testsatz, Trefferquotenmessung, Kostengrenzen |
| Produktivbetrieb | Spürbare Entlastung im Alltag | Fehlerbehandlung, Protokoll, Freigabestufen, Monitoring |
| Nach 6–12 Monaten | Das System gehört zum Arbeitsalltag | Nachmessen: Passen die Daten von damals noch zur Realität? |
Das Wichtigste in Kürze
- Ausgabe-Tokens kosten ein Vielfaches der Eingabe – kurze Antworten sparen mehr als kurze Prompts.
- Modellwahl je Aufgabe senkt Kosten oft um 70 bis 90 % ohne spürbaren Qualitätsverlust.
- Ohne Testsatz ist Qualität nicht steuerbar – 50 bis 100 Fälle reichen für den Einstieg.
- Prompt Injection ist real: Für das Modell sind Inhalt und Anweisung derselbe Text.
- Schutz muss außerhalb des Modells liegen – in Rechten, Prüfungen und Freigaben.
- DSGVO und EU AI Act gehören in die Architekturentscheidung, nicht in die Abnahme.
?Wissens-Check
Beantworten Sie die Fragen, um Ihr Verständnis zu prüfen. Sie erhalten sofort eine Rückmeldung.
Frage 1.Wie lassen sich die Betriebskosten am wirksamsten senken, ohne die Qualität zu gefährden?
Frage 2.Was ist Prompt Injection?
Frage 3.Welche Maßnahme schützt wirksam gegen manipulierte Zahlungsdaten in eingehenden Dokumenten?
Frage 4.Warum braucht ein produktives KI-System einen Testsatz?