# Aufgaben-Fit — welche Arbeit zu einem Modell passt > Aufgaben anhand von Regelhaftigkeit, Prüfbarkeit, Fehlerkosten, Volumen und Eingabemodalität dem einfachsten tragfähigen Verfahren zuordnen. Track: [AI-Grundlagen für den IT-Betrieb](https://physar.tech/learn/ai-foundations) Kanonische Fassung: https://physar.tech/learn/ai-foundations/ai-task-fit Stand: 2026-09-04 Interaktiver Teil: 8 Checks (nur im Browser) ## Aufgaben-Fit — welche Arbeit zu einem Modell passt ### Die Entscheidung vor der Umsetzung Die meisten gescheiterten KI-Vorhaben scheitern nicht an der Technik, sondern an der Auswahl. Jemand nimmt die sichtbarste Aufgabe statt der passendsten — und stellt nach Monaten fest, dass Fehler teuer, unbemerkbar oder beides sind. Dieses Modul liefert vier Achsen für die Vorabprüfung. Sie kosten zusammen eine halbe Stunde und ersparen im Zweifel ein Quartal. _[Abbildung: Aufgaben-Fit ist eine Folge von Ausschlussfragen, nicht eine Bewertungsmatrix: Ein hartes Nein an einer Achse beendet die Prüfung.]_ **Aufgabenschnitt:** Die Zerlegung eines Geschäftsprozesses in Schritte mit jeweils eigener Eingabe, zulässiger Ausgabe, Fehlerfolge und Kontrollmöglichkeit. Die wichtigste Architekturentscheidung fällt vor dem Modellvergleich: **Welcher Teil der Arbeit soll probabilistisch werden?** Ein Vorgang wie Rechnungsprüfung enthält Dokumenterkennung, Feldextraktion, exakten Zahlenvergleich, Richtlinienprüfung und Freigabe. Diese Schritte haben verschiedene Fehlerkosten. Wer sie als eine Chat-Aufgabe formuliert, verliert die Möglichkeit, sichere Teile deterministisch zu bauen und unsichere Teile gezielt zu messen. NIST fordert in der `MAP`-Funktion, Zweck, Kontext, Anforderungen und betroffene Akteure zu verstehen. Für ein Ops-Team wird daraus ein kleines Entscheidungsblatt: Zielnutzer, Eingaben, erwartete Ausgabe, Baseline, Schaden eines Fehlers, Reversibilität und Eskalationsweg. **Preis:** Diese Vorarbeit bremst den ersten Demo-Tag; sie verhindert aber, dass eine technisch erfolgreiche Demo eine ungeeignete Prozessentscheidung zementiert. Schreibe für jede Teilaufgabe außerdem die **Nichtziele** auf. Ein System, das Tickets zusammenfasst, darf nicht still Priorität, Schuld oder Berechtigung ableiten. Diese negativen Grenzen reduzieren spätere Scope-Ausweitung durch bequeme Wiederverwendung desselben Modelloutputs. Wenn ein neuer Verbraucher entsteht, wird sein Zweck separat bewertet. **Preis:** Mehr Contracts und Versionen wirken redundant; sie verhindern aber, dass ein für harmlose Assistenz evaluiertes Ergebnis ungeprüft in eine schadensreiche Entscheidung fließt. ### Achse 1 — Form der Aufgabe Sprachmodelle sind am stärksten beim **Umformen** von Information: unstrukturierten Text in Struktur bringen, zusammenfassen, übersetzen, umformulieren, klassifizieren, Entwürfe erzeugen. Die Eingabe enthält dabei bereits alles Nötige; das Modell ändert nur die Form. Sie sind am schwächsten, wo etwas **entschieden** oder **berechnet** werden soll, das nicht in der Eingabe steht: Ermessensentscheidungen mit Rechtsfolge, exakte Rechnungen, Ansprüche und Genehmigungen. Dort ist das Modell bestenfalls Zulieferer für einen deterministischen Schritt. | | | | --- | --- | | Umformen (Text zu Struktur, Zusammenfassung, Entwurf) | starker Fit — die Information ist vorhanden | | Zuordnen (Klassifikation, Weiterleitung, Priorisierung) | guter Fit, wenn die Klassen stabil und die Fehler tragbar sind | | Entscheiden mit Außenwirkung (Genehmigung, Ablehnung, Zahlung) | kein Fit als Letztinstanz — Vorschlag ja, Beschluss nein | | Rechnen, Prüfen, Nachschlagen exakter Werte | kein Fit — Code oder Fachsystem | Form der Aufgabe meint mehr als „Text rein, Text raus“. **Transformation** bewahrt Bedeutung und ändert Darstellung, etwa Zusammenfassen oder Umformulieren. **Extraktion** zieht benannte Felder aus unstrukturiertem Material. **Klassifikation** wählt aus festen Klassen. **Generierung** entwirft offene Inhalte. **Entscheidung** wendet eine Regel oder ein Urteil mit Wirkung an. Ein LLM kann mehrere Formen imitieren, aber die passendste Kontrollstrategie hängt weiterhin von der eigentlichen Form ab. Für bekannte, stabile Regeln bleibt Code der Referenzweg. Für feste Labels mit vielen Beispielen ist ein Klassifikator ein ernsthafter Kandidat. Ein LLM gewinnt, wenn Sprache stark variiert, wenige Beispiele vorliegen oder die zulässige Ausgabe offen ist. **Nachteil der engeren Lösung:** Ein Klassifikator oder Parser muss bei neuen Klassen und Formaten angepasst werden. **Nachteil des LLM:** Mehr Laufzeitkosten und ein breiterer Fehlermodusraum. Achte auf Kopplung zwischen Teilaufgaben. Eine fehlerhafte Extraktion kann einen nachgelagerten exakten Vergleich korrekt, aber auf falschen Werten ausführen. Speichere deshalb Herkunft und Qualitätsstatus jedes Feldes, statt nur das Endergebnis weiterzugeben. Ein deterministischer Nachschritt macht die gesamte Pipeline nicht deterministisch, wenn seine Eingabe probabilistisch entstand. **Nachteil:** Provenienz pro Feld erhöht Datenmodell und UI-Aufwand; sie zeigt dafür, wo menschliche Prüfung ansetzen muss. ### Achse 2 — Prüfbarkeit des Ergebnisses Die entscheidende Frage lautet: **Wie teuer ist es, ein Ergebnis als richtig oder falsch zu erkennen?** Aufgaben, deren Ergebnis günstig prüfbar ist, sind hervorragende Kandidaten — der Mensch bleibt in der Rolle des Prüfers statt des Erzeugers, und genau dort liegt der Gewinn. Aufgaben, deren Prüfung genauso aufwendig ist wie die Ausführung, tragen den Nutzen nicht. Eine Zusammenfassung eines 80-seitigen Vertrags zu prüfen bedeutet, den Vertrag zu lesen — der Zeitgewinn ist dann nahe null, das Risiko aber real. > **Merksatz:** Erzeugen ist oft leichter als Prüfen. Wo diese Lücke groß ist, verlagert Automatisierung Arbeit statt sie zu sparen. Prüfbarkeit ist oft wichtiger als die beobachtete Demoqualität. Eine extrahierte Bestellnummer lässt sich gegen ein System of Record prüfen. Ob eine Eskalationsmail „gut“ klingt, braucht dagegen Rubrik oder menschliches Urteil. Je billiger ein Ergebnis geprüft werden kann, desto eher eignet sich ein Modell als Vorschlagsmaschine. Ist die Prüfung teurer als die ursprüngliche Arbeit, verschwindet der Automatisierungsnutzen trotz guter Modellqualität. Baue die Prüfung vor der Automatisierung: Schema, Wertebereiche, erlaubte IDs, Quellenbeleg oder Vergleich mit einem Referenzdatensatz. Eine selbstberichtete Modellkonfidenz ersetzt diese Prüfung nicht. **Empfehlung:** Definiere für jeden Output ein maschinelles oder menschliches Akzeptanzsignal. **Preis:** Manche sprachlichen Aufgaben lassen sich nur unvollkommen operationalisieren; dann muss die verbleibende Unsicherheit im Prozess sichtbar bleiben. Prüfbarkeit kann aus mehreren schwachen Signalen bestehen. Eine Zusammenfassung wird etwa auf Quellenabdeckung, verbotene neue Fakten, Länge und menschliche Nützlichkeit geprüft. Kein einzelner Wert beweist Gesamtqualität. Lege fest, welche Kriterien harte Gates sind und welche nur beobachtet werden. Ein LLM-Judge kann skalieren, braucht jedoch gelabelte Anker und Bias-Tests. **Nachteil:** Mehrdimensionale Evaluation erschwert eine einfache Rangliste; sie verhindert, dass ein Modell durch gutes Stilurteil einen kritischen Faktenfehler ausgleicht. ### Achse 3 — Fehlerkosten und Umkehrbarkeit Ein Fehler kostet unterschiedlich viel, je nachdem, wann er auffällt und ob er rückgängig zu machen ist. Ein falsch vorgeschlagener Formulierungsentwurf kostet Sekunden. Eine falsch verschickte Kündigungsbestätigung kostet einen Kunden und möglicherweise ein Verfahren. - Sofort sichtbar und leicht korrigierbar — hohe Automatisierungstiefe vertretbar. - Spät sichtbar, aber korrigierbar — Stichprobenkontrolle und Rückrollpfad nötig. - Unumkehrbar oder mit Außenwirkung — Vorschlagsbetrieb mit menschlicher Freigabe, nichts anderes. Diese Achse und die Prüfbarkeit hängen zusammen: Hohe Fehlerkosten sind tragbar, solange die Prüfung günstig ist. Sind Fehler teuer **und** schwer erkennbar, ist die Aufgabe unabhängig von der Modellqualität ungeeignet. Fehlerkosten bestehen aus Eintrittswahrscheinlichkeit und Schadensausmaß. Ein falscher interner Betreff ist leicht korrigierbar; eine gelöschte Ressource oder diskriminierende Personalentscheidung kann schwer reversibel sein. Das Modell muss nicht schlechter werden, damit der zweite Fall mehr Kontrolle verlangt — dieselbe Fehlerrate hat eine andere Wirkung. Deshalb folgt der Autonomiegrad dem Schaden und nicht allein einem durchschnittlichen Genauigkeitswert. Ein brauchbares Muster sind Stufen: **Vorschlag**, **Vorschlag mit Pflichtfreigabe**, **automatische Ausführung mit Stichprobe** und **automatische Ausführung mit technischem Rollback**. Die richtige Stufe kann je Fallklasse variieren. Ein System darf etwa harmlose Tickets automatisch taggen, aber Kontosperren nur vorbereiten. **Nachteil:** Mehrere Pfade erhöhen Prozess- und Testkomplexität; eine Einheitsautonomie versteckt dagegen unterschiedliche Risiken. Zeit bis zur Entdeckung gehört ebenfalls zum Schaden. Ein falsches Label wird vielleicht beim nächsten Klick bemerkt; eine plausible falsche Zusammenfassung kann monatelang in einer Wissensbasis weiterleben. Je später ein Fehler sichtbar wird, desto wichtiger sind Quellen, Stichproben und begrenzte Weiterverwendung. **Preis:** Zusätzliche Kennzeichnung und Ablaufdaten reduzieren bequeme Wiederverwendung, verhindern aber, dass ungeprüfter Modelltext still zum System of Record wird. ### Achse 4 — Volumen und Varianz Aufwand rechnet sich über Wiederholung. Eine Aufgabe, die dreißigmal im Jahr vorkommt, rechtfertigt selten eine Integration mit Betrieb, Monitoring und Datenschutzprüfung — dort gewinnt ein Skript, eine Vorlage oder schlicht Handarbeit. Die zweite Größe ist die **Varianz**. Bei hohem Volumen und geringer Varianz sind klassische Automatisierung oder ein Klassifikator oft überlegen. Der Sweet Spot für Sprachmodelle liegt bei **hohem Volumen und hoher Varianz** — viele Fälle, die sich alle ein wenig anders lesen. **Kurzcheck:** Zwei Vorschläge liegen vor: (a) 40.000 Support-Mails pro Jahr in Kategorien einsortieren, (b) einmal jährlich den 200-seitigen Wirtschaftsprüfungsbericht zusammenfassen. Welcher ist der bessere Kandidat? - [x] (a) — hohes Volumen, unterschiedliche Formulierungen, günstig prüfbares Ergebnis - [ ] (b) — dort ist die Zeitersparnis pro Fall am größten - [ ] Beide gleich gut, da beide Textverarbeitung sind > Richtig. Wiederholung trägt den Aufwand, und eine Kategorie lässt sich in Sekunden auf Plausibilität prüfen. Volumen allein rechtfertigt kein Modell. Multipliziere Fallzahl mit eingesparter Bearbeitungszeit und ziehe Prüf-, Fehler-, Plattform- und Pflegeaufwand ab. Bei niedriger Varianz lohnt sich oft ein Skript, weil einmalige Implementierung viele identische Fälle abdeckt. Bei hoher Varianz kann ein LLM mehr sprachliche Formen erfassen, verlangt aber ein breiteres Testset. Niedriges Volumen und hoher Schaden ist meist ein Kandidat für menschliche Arbeit mit punktueller Assistenz. Berücksichtige außerdem die **Driftgeschwindigkeit**. Eine stabile technische Klassifikation kann lange mit demselben Modell laufen. Eine Richtlinie, die wöchentlich wechselt, gehört als versionierte Regel oder Wissensquelle in den Laufzeitpfad. **Preis:** Externe Regeln brauchen Pflege und Verfügbarkeit. Sie sind dennoch leichter zu prüfen und zurückzurollen als Wissen, das in neu trainierten Gewichten verborgen ist. ### Multimodale Aufgaben zuerst zerlegen Ein PDF, Screenshot oder Audiomitschnitt macht aus einer Aufgabe noch keinen einheitlichen Modellfall. Zerlege die Kette in Wahrnehmung, Extraktion, Normalisierung, fachliche Prüfung und Wirkung. Ein spezialisiertes OCR-System kann gedruckten Text mit Koordinaten liefern; ein Vision-Language-Modell kann wechselnde Layouts semantisch interpretieren. Strukturierte Quelldaten wie XML oder CSV schlagen beide, wenn sie verfügbar und verbindlich sind. | | | | --- | --- | | Stabiles Formular, feste Felder | OCR oder Dokumentparser plus deterministische Validierung | | Wechselnde visuelle Struktur, semantische Frage | Vision-Language-Modell als Kandidat, gegen eigenes Bildset testen | | Maschinenlesbare Ursprungsdaten vorhanden | Ursprungsformat verwenden; Rendering nicht erneut interpretieren | > **Trade-off:** Spezialisierte Stufen machen Fehler lokalisierbar, erzeugen aber Schnittstellen. Ein End-to-End-Modell ist schneller prototypisiert, vermischt jedoch Wahrnehmungs- und Schlussfehler. Bei Bildern bestimmt die Auflösung nicht nur Kosten, sondern auch die sichtbare Information. Kleine Schrift, Tabellenstruktur oder entfernte UI-Elemente können in einem verkleinerten Bild verschwinden. Schneide relevante Bereiche gezielt aus und teste dieselben Dokumentklassen in mehreren Qualitätsstufen. Ein höher aufgelöstes Gesamtbild ist kein kostenloser Default. Es erhöht Eingabemenge und Latenz, während irrelevante Flächen weiterhin Kontext verbrauchen. ### Baseline und einfachste tragfähige Lösung Vergleiche nicht nur Modelle untereinander. Die wichtigste Baseline kann ein regulärer Ausdruck, eine Suchmaske, ein bestehender Klassifikator oder der heutige menschliche Prozess sein. Eine LLM-Lösung muss einen messbaren Vorteil gegen diese Baseline liefern und ihren zusätzlichen Kontrollaufwand rechtfertigen. Das verhindert den häufigen Fehler, eine eindrucksvolle absolute Trefferquote zu feiern, obwohl eine einfachere Lösung besser oder billiger arbeitet. ### Ticket-Routing mit zwei Unsicherheiten 10.000 Tickets pro Monat sollen Team und Priorität erhalten. Teams sind stabil, Priorität kann Kundenschaden auslösen. **Anforderungen** - Routing muss messbar sein. - Fehlerhafte Priorität braucht eine Eskalation. - Neue Teams kommen selten hinzu. **Schritte** - Regeln und bestehenden Klassifikator als Baseline messen. - Teamzuordnung und Priorität als getrennte Outputs evaluieren. - Nur die ausreichend prüfbare Teamzuordnung automatisieren. - Unsichere oder schadensreiche Prioritätsfälle zur Freigabe geben. **Merksatz:** Der Geschäftsprozess ist nicht die kleinste sinnvolle Automatisierungseinheit. ### Ein Entscheidungsscore ohne Scheingenauigkeit Du brauchst keine universelle Formel, wohl aber eine explizite Abwägung. Bewerte jede Teilaufgabe qualitativ entlang von **Regelhaftigkeit**, **Prüfbarkeit**, **Fehlerkosten**, **Reversibilität**, **Volumen**, **Varianz** und **Datenzugang**. Ein hoher Wert ist kein automatisches Go; er macht Annahmen sichtbar. Zwei Teams können dann über eine konkrete Achse streiten statt über diffuse Begeisterung oder Angst. - Code bevorzugen, wenn Regeln exakt und stabil sind. - Ein engeres Modell prüfen, wenn Klassen fest und Labels verfügbar sind. - Ein LLM als Vorschlagskomponente testen, wenn Sprache offen und Ergebnisse prüfbar sind. - Autonomie reduzieren, wenn Wirkung schwer reversibel oder Schaden hoch ist. - Nicht automatisieren, wenn Prüfung und Betrieb den Nutzen aufzehren. Die Baseline muss denselben fachlichen Scope haben. Ein Modell, das nur einfache Fälle bearbeitet, darf nicht gegen die durchschnittliche Zeit aller menschlichen Fälle verglichen werden. Segmentiere und berücksichtige die Arbeit der Eskalationen. Ebenso wird ein Klassifikator nicht dadurch schlechter, dass ein LLM zusätzliche Erklärungen erzeugt, wenn diese Erklärungen im Prozess keinen Wert haben. **Preis:** Faire Vergleiche sind weniger spektakulär, liefern aber eine belastbare Investitionsentscheidung. ### Vom Zuschnitt zum fairen Pilot Der Aufgabenschnitt liefert direkt das Pilotdesign: eine begrenzte Fallklasse, eine vorhandene Baseline, ein repräsentatives Testset, ein klarer Output-Contract und ein definierter menschlicher oder technischer Fallback. Miss Fehler nicht nur als Gesamtquote, sondern nach Fallklasse und Schaden. Ein System kann durchschnittlich gut aussehen und gerade bei den seltenen, teuren Fällen versagen. Gleich im Check entscheidest du, wann Transformation statt Entscheidung automatisiert wird, wie Fehlerkosten den Autonomiegrad verändern, wann Volumen die Investition trägt und wie OCR, Vision-Modell und strukturierte Quelle abgegrenzt werden. Jede richtige Wahl hat einen Preis: geringere Flexibilität, mehr Schnittstellen, mehr Review oder weniger Automatisierung. Der qualitative Score wird mit Evidenz versehen: beobachtete Regeländerungen, verfügbare Labels, konkrete Fehlerfolgen, gemessene Prüfzeit und Datenfreigabe. Unbekannt bleibt unbekannt und wird im Pilot getestet. Dadurch ist der Score kein mathematischer Wahrheitswert, sondern ein Review-Artefakt. Er kann zeigen, dass zwei Teilaufgaben trotz gleicher Sprache verschiedene Architekturen brauchen. **Nachteil:** Ein solcher Score automatisiert die Entscheidung nicht; er macht sie lediglich nachvollziehbar und aktualisierbar. ### Was der Check prüft - Aufgaben nach Form einordnen — umformen, zuordnen, entscheiden, rechnen. - Prüfkosten des Ergebnisses als Auswahlkriterium einsetzen. - Fehlerkosten und Umkehrbarkeit gegen Automatisierungstiefe abwägen. - Volumen und Varianz als Wirtschaftlichkeitsschwelle anwenden. Nach einem erfolgreichen Pilot wird der Aufgabenschnitt nicht aufgehoben. Neue Sprachen, Dokumenttypen, Nutzergruppen oder Schreibrechte sind eigene Scope-Änderungen mit neuem Testbedarf. Ein System, das in einem engen Segment funktioniert, hat nicht automatisch seine Eignung für den gesamten Prozess bewiesen. **Nachteil:** Stufenweiser Ausbau dauert länger; er bewahrt die Beweisgrenze jeder Freigabe. Dokumentiere zudem, welche bessere Lösung den Modellpfad ersetzen würde. Mehr strukturierte Quelldaten können OCR überflüssig machen; ein stabiler Regelkatalog kann freie Generierung in Code verwandeln. Eine AI-Architektur ist kein Endzustand, sondern eine Entscheidung unter heutigen Informations- und Integrationskosten. **Nachteil:** Ersatzoptionen erzeugen keine unmittelbare Demo, halten aber den Weg zu einfacheren Systemen offen. Nach dem Pilot werden nicht nur Modellmetriken, sondern auch neue API-, Daten- oder Prozessmöglichkeiten bewertet. So verhindert das Team, dass ein ursprünglich pragmatischer LLM-Schritt dauerhaft eine inzwischen lösbare Strukturaufgabe verdeckt. Ein letzter Check gilt der organisatorischen Eignung: Gibt es Owner, Labels, Reviewkapazität und einen manuellen Fallback? Eine technisch passende Aufgabe kann betrieblich ungeeignet sein, wenn niemand Fehler klassifiziert oder die Quelle pflegt. Dann ist der richtige nächste Schritt nicht ein Modellkauf, sondern das fehlende Prozessartefakt. **Nachteil:** Diese Grenze verschiebt sichtbare AI-Arbeit nach hinten. Sie verhindert, dass ein Team eine nicht betreibbare Komponente auf einen bereits unklaren Prozess setzt. Damit bleibt die einfachste tragfähige Lösung auch nach dem ersten Erfolg eine reale Option und nicht nur eine Folie aus der Voranalyse. Der Check prüft diese Entscheidung stets an einem abgegrenzten Prozessschritt mit sichtbarer Fehlerwirkung. ## Quellen - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Map-Funktion (Kontext und Eignung) - Amershi et al. — Software Engineering for Machine Learning: A Case Study, ICSE-SEIP 2019 - Sculley et al. — Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015 - Parasuraman, Sheridan & Wickens — A Model for Types and Levels of Human Interaction with Automation, IEEE SMC-A 2000 - NIST — AI Risk Management Framework Core, MAP 1 und MAP 2 — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ - NIST — Artificial Intelligence Risk Management Framework 1.0 — https://doi.org/10.6028/NIST.AI.100-1 - Sculley et al. — Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015 — https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/ - Xu et al. — LayoutLM: Pre-training of Text and Layout for Document Image Understanding, KDD 2020 — https://arxiv.org/abs/1912.13318 - Radford et al. — Learning Transferable Visual Models From Natural Language Supervision, ICML 2021 — https://proceedings.mlr.press/v139/radford21a.html - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Map-Funktion - Xu et al. — LayoutLM: Pre-training of Text and Layout for Document Image Understanding, KDD 2020 - ISO 13616-1 — IBAN-Struktur und Prüfziffernverfahren - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Map- und Measure-Funktionen - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Manage-Funktion - ISO/IEC 25012 — Data Quality Model (Genauigkeit und Nachvollziehbarkeit von Datenquellen) - Lewis et al. — Retrieval-Augmented Generation, NeurIPS 2020 — https://proceedings.neurips.cc/paper/2020/hash/6b493230-Abstract.html