Wissensarbeiter verlieren Stunden damit, 80-seitige Berichte, Vertragspakete, Studienpakete und Akten zu lesen, nur um herauszufinden, was wichtig ist. LLMs mit langem Kontext (Fenster mit 1 Mio. Token sind an der Spitze inzwischen Standard) können ein ganzes Dokument oder einen Stapel von Dokumenten lesen und eine auf den Leser zugeschnittene Vorlage erstellen: eine Seite, zentrale Risiken, Maßnahmen oder eine Vergleichstabelle – jede Aussage verknüpft mit der Seite, aus der sie stammt. Der Wert liegt in schnellerer Orientierung und Vorsortierung. Das Risiko liegt in plausiblen Auslassungen und Verzerrungen; gute Systeme sind daher auf Überprüfbarkeit ausgelegt, nicht nur auf Kürze.
Problem & Nutzen
- Heute: Führungskräfte, Juristen, Analysten, Sachbearbeiter und Forschende überfliegen oder lesen vollständig; Zusammenfassungen entstehen von Hand (Management-Vorlagen, Vermerke, Sachstandsberichte) oder gar nicht. Dokumentensammlungen (Datenräume, Ausschreibungspakete, Konsultationseingaben, Regulierungspakete) sind oft zu groß, um sie zu lesen.
- KI-Nutzen: Vorsortierung beim ersten Lesen in Minuten, einheitliche Vorlagen für Zusammenfassungen, dokumentübergreifende Synthese, für die Menschen selten Zeit haben, mehrsprachige Eingaben mit Zusammenfassungen in der Sprache des Lesers.
- Belege: Im ressortübergreifenden Experiment der britischen Regierung mit Microsoft 365 Copilot (20.000 Beamte, Sept.–Dez. 2024) berichteten Nutzer von durchschnittlich 26 Minuten Zeitersparnis pro Tag. Das Zusammenfassen von Dokumenten, E-Mails und Besprechungen gehörte zu den am häufigsten genannten Einsätzen, die Teilnehmenden meldeten aber auch ungenaue Ergebnisse bei nuanciertem, kontextreichem Material, und durchgängig war menschliche Aufsicht nötig [1].
- Realitätscheck zur Qualität: Auf dem Vectara-Leaderboard (kurze bis mittlere Dokumente bis ca. 24.000 Wörter) liegen die Halluzinationsraten aktueller Modelle im Okt. 2026 je nach Modell zwischen etwa 2 % und über 20 %, die Modellwahl ist also entscheidend [2]. Für Texte in Buchlänge stellte FABLES fest, dass Zusammenfassungen unzutreffende Aussagen über Ereignisse und Zustände von Figuren enthalten und das Textende überbetonen und dass LLM-basierte Treue-Prüfungen schlecht mit dem Urteil von Menschen übereinstimmen [3].
Varianten
- Einzelnes langes Dokument: Geschäftsberichte, Studien, Gutachten, Normen, Handbücher, Positionspapiere → Kurzfassung, Extraktion von Kennzahlen, abschnittsweise Übersicht.
- Dokumentensammlungen / Synthese über mehrere Dokumente: Datenräume (siehe DOC-011), Ausschreibungs- unterlagen, Dateiablagen, Literaturpakete (KNOW-008), Konsultationseingaben (LANG-026) → Themen, Widersprüche, Vergleichsraster.
- Fragegeleitete Zusammenfassung: „Fasse alles zu Gewährleistungsklauseln in diesen 40 Verträgen zusammen" – überschneidet sich mit RAG (KNOW-002) und GraphRAG (KNOW-013) bei Fragen über den gesamten Bestand.
- Änderungs-/Differenz-Zusammenfassungen: was sich zwischen Vertrag v3 und v4 oder zwischen zwei Fassungen einer Regelung geändert hat (speist LANG-020 Horizon Scanning).
- Öffentlicher Sektor: Zusammenfassungen von Akten (e-Akte), Ratsunterlagen, Drucksachen von Bundestag/Landtag und Gerichtsentscheidungen für interne Unterrichtungen (Vorlagen, Sprechzettel).
- Fachspezifische Varianten: Zusammenfassungen klinischer Akten (HLTH-018, eigene Regulierung), Log- und Störfallzusammenfassungen (CODE-011), Berichte zur Bedrohungslage (SEC-008), Besprechungs- transkripte (SPEECH-001).
- Formatvarianten: Audio-Übersichten / Kurzvorlagen im Podcast-Stil (SPEECH-006 TTS), Foliengliederungen, Zusammenfassungen in einfacher Sprache (LANG-010), Zusammenfassungen in einer anderen Sprache (LANG-009).
- Privatnutzung: lange Allgemeine Geschäftsbedingungen, Mietverträge, amtliche Schreiben (PERS-008), Versicherungspolicen und Studienmaterial verstehen – meist über Chat-Apps für Verbraucher oder lokale Modelle.
So funktioniert es
- Aufnahme (Upload, DMS-/SharePoint-Konnektor, E-Mail, Export aus Datenraum)
- Parsing (PDF/Scan
- Text + Layout + Tabellen per OCR/Dokument-Parsing; Seitenanker erhalten)
- Steuerung nach Größe: passt in den Kontext (bis einige Hundert Tsd. Token)
- ein einziger Aufruf mit langem Kontext zu groß / viele Dokumente
- Map (je Dokument/Abschnitt)
- Reduce (zusammenführen, Dubletten entfernen, ordnen) Fragen über den ganzen Bestand
- Retrieval oder Graph-Index (RAG/GraphRAG)
- fragegeleitete Zusammenfassung
- Erstellung der Zusammenfassung nach Vorgabe (Zielgruppe, Länge, Pflichtfelder, Vorlage)
- Prüfung der Quellenbindung (jede Aussage nennt Seite/Abschnitt; optional NLI-/Halluzinations-Bewertung)
- menschliche Prüfung (Entscheidungsverantwortlicher liest Zusammenfassung + springt zu den zitierten Stellen)
- Ausgabe (DMS-Vermerk, Word-/PDF-Vorlage, Ticket, CRM-/Aktenvorgang)
- Langer Kontext zuerst: Spitzenmodelle nehmen 1 Mio. Token auf (z. B. Claude Opus/Sonnet/Haiku 5.5 und Gemini-Modelle); für einzelne Dokumente ist das einfacher und meist besser als Aufteilen in Abschnitte [4][5]. Setzen Sie die Anweisungen nach das Dokument und verlangen Sie Zitate oder Seitenverweise [5].
- Map-Reduce / hierarchische Zusammenfassung bleibt bei sehr großen Sammlungen, günstigeren Modellen oder selbst betriebenen Modellen mit kleineren Fenstern nötig; als Nebenprodukt liefert sie auch Zusammenfassungen je Dokument.
- Indexierung im Stil von GraphRAG (Entitätengraph + vorab berechnete Zusammenfassungen von Gemeinschaften) schlägt einfaches RAG bei Fragen wie „Was sind die Hauptthemen im gesamten Bestand" [6].
- Mensch-in-der-Schleife (Human-in-the-Loop): die Zusammenfassung ist eine Lesehilfe. Entscheidungen, rechtliche Bewertungen und ausgehende Kommunikation stützen sich auf die Quelle; mit Quellenangaben sind Stichproben günstig.
Datenaufbereitung
Der Aufwand ist mäßig (etwa 20–30 %) und liegt vor allem darin, Dokumente lesbar zu machen, nicht im Annotieren. Benötigt werden: die Dokumente selbst (PDF, Word, Mails, Protokolle, Berichte, Verträge, Studien) und, bei wiederkehrender Nutzung, Vorlagen für das Format der Zusammenfassung.
Wo sie in einem KMU liegen: Dateiablagen, DMS, Postfächer, Teams oder SharePoint, Papierakten und Scans. Typische Lücken: gescannte PDFs ohne Textebene, mehrspaltige oder tabellenlastige Layouts, die das Parsing stören, Dubletten und Entwürfe neben den Endfassungen, keine Metadaten und vertrauliche Dokumente in Ordnern, die für alle offen sind.
Schritte der Aufbereitung: 1. Einige Dokumenttypen zum Einstieg wählen (zum Beispiel Verträge, Protokolle, Ausschreibungen) und je zehn Beispiele sammeln. 2. Scans per OCR lesbar machen und Formate umwandeln (PREP-006, PREP-007; DOC-014 für robuste Extraktion mit Docling). 3. Dubletten entfernen und Endfassungen kennzeichnen (PREP-009, PREP-010). 4. Die Ausgabeformate mit den Lesern festlegen (Kurzfassung, Risikoliste, Maßnahmen) und zwei oder drei Musterzusammenfassungen als Referenz aufbewahren (PREP-016, PREP-018). 5. Berechtigungen bereinigen, bevor ein Ordner an einen Assistenten angebunden wird (PREP-023), und Regeln festlegen, welche Klassen von Dokumenten in welches Werkzeug dürfen (PREP-024). 6. Bei personenbezogenen Daten in den Dokumenten eine Pseudonymisierung erwägen (PREP-022).
Werkzeuge: Paperless-ngx für Scans, Docling oder MinerU für das Parsing, eine Tabellenkalkulation für den Testdatensatz.
Umsetzungswege
Welcher Weg für wen
- KMU – Weg C: Verträge, Berichte und Kundendokumente sind oft vertraulich; Ollama oder Open WebUI mit einem Modell mittlerer Größe läuft auf HW2, und dieselbe Plattform bedient auch andere Anwendungsfälle (Baukasten-Effekt). Weg A ist für unkritisches Material in Ordnung, wenn Copilot oder Workspace bereits lizenziert ist.
- Großunternehmen – Weg B: eine gemeinsame interne KI-Plattform auf in der EU gehosteten APIs skaliert auf viele Dokumenttypen, mit Zugriffsrechten und Protokollierung.
- Entwickler – Weg C: vLLM oder Ollama mit Docling geben volle Kontrolle über Aufteilung, Umgang mit langem Kontext und Kosten.
- Privat – Weg C: lokale Apps wie LM Studio oder Ollama halten persönliche Dokumente (Gesundheit, Steuern, Verträge) auf dem eigenen Gerät.
- Öffentlicher Sektor – Weg C: selbst betriebene oder in einer souveränen Cloud laufende Modelle halten Akten mit personenbezogenen und amtlichen Daten unter eigener Kontrolle.
Weg A — Kaufen (Standardsoftware)
- In Büro-/Produktivitätssuiten eingebaut: Microsoft 365 Copilot (Word, Outlook, Teams, SharePoint; EU Data Boundary), Google Gemini in Workspace und Googles Recherche-Werkzeug für Notizbücher (früher NotebookLM) für quellenbasierte Zusammenfassungen und Audio-Übersichten, Adobe Acrobat AI Assistant für PDFs und PDF Spaces mit mehreren Dateien samt Quellenangaben auf Seitenebene [7].
- EU-/deutsche KI-Arbeitsplätze: Langdock (Berlin; Hosting in der EU, Optionen für eigene Cloud oder On-Premises) [8], Mistral Le Chat (Frankreich) und deutsche Assistenten für öffentliche Verwaltung und Unternehmen auf Basis souveräner Clouds.
- Fachwerkzeuge: Recht (Zusammenfassungen von Verträgen und Akten in Legal-Tech-Suiten – siehe DOC-010, KNOW-006), Plattformen für Finanzrecherche, DMS-/ECM-Anbieter, die Zusammenfassungen ergänzen (z. B. d.velop, DocuWare).
- Weg A wählen, wenn: die Dokumente in M365/Workspace/einem DMS liegen, das dies bereits anbietet, und ein AVV mit Hosting in der EU vorliegt. Prüfen: kein Training mit Kundendaten, Aufbewahrungseinstellungen, Anzeige der Quellenangaben.
Weg B — Auf Cloud-KI-Diensten aufbauen
- Modelle: Spitzenmodelle mit langem Kontext über Endpunkte mit Routing in der EU – Claude über Amazon Bedrock (Frankfurt/EU-Regionen) oder Google Cloud, Gemini auf Vertex AI in EU-Regionen, GPT-Modelle über die Azure EU Data Zone, Mistral Large/Medium über la Plateforme (EU-Anbieter) [4][9].
- In Deutschland gehostete offene Modelle als API: STACKIT AI Model Serving, IONOS AI Model Hub (z. B. gpt-oss-120b, Qwen3.5, Mistral Small) für Daten, die bei einem deutschen Anbieter bleiben müssen [10][11].
- Muster: Dokumentenparser (Docling, Azure Document Intelligence, Mistral OCR) → Prompt-Vorlage je Art der Zusammenfassung mit JSON-Schema (Felder + Quellenangaben) → Prompt-/Context-Caching bei wiederholten Fragen zum selben Dokument → Batch-API für Massenaufträge (bei Claude 50 % günstiger) [4][5].
- Orchestrierung: Zusammenfassungsketten mit LangChain/LangGraph oder LlamaIndex, n8n für DMS-/E-Mail- Auslöser; Prüfumgebung mit einer Halluzinationsbewertung (z. B. HHEM-2.1-Open) an Stichproben [2].
Weg C — Selbst betreiben (Open Source)
- Modelle: Qwen3-Familie (z. B. Qwen3-30B-A3B-Instruct-2507: Apache 2.0, 262K nativer Kontext, ca. 1M mit erweiterter Konfiguration) [12]; Mistral Small 4 und Ministral 3 (Apache 2.0) [9]; gpt-oss-120b; größere Qwen3.5-MoE-Modelle für HW3/HW4.
- Stack: vLLM (Prefix-Caching, OpenAI-kompatible API) oder SGLang/Ollama [13]; Open WebUI oder AnythingLLM als Oberfläche; Docling/MinerU für das Parsing; Qdrant/pgvector, falls fragegeleitetes Retrieval nötig ist; GraphRAG (Microsoft, Open Source) für die Synthese über den ganzen Bestand [6].
- Hardware: HW2 (GPU mit 24–32 GB) betreibt ein quantisiertes Modell mit 8–30 Mrd. Parametern und 32–128K Kontext – genug für Map-Reduce über beliebige Sammlungen. Sehr lange Kontexte sind speichergebunden: Der Aufbau von Qwen3-30B mit 1 Mio. Token braucht etwa 240 GB GPU-Speicher (HW4) [12]; HW3 ist der realistische Sweet Spot für Fenster von 128–256K.
- Betriebsaufwand: mäßig; die Hauptarbeit steckt in Parsing-Qualität, Prompt-Vorlagen und Bewertung.
Weg D — Eigenes Training
Lohnt sich selten. Ein Feintuning (LoRA an einem Modell mit 7–30 Mrd. Parametern) kommt nur für hochvolumige, stark vorlagenbasierte Zusammenfassungen in Betracht (z. B. Schadenakten von Versicherungen, standardisierte Vermerke in der öffentlichen Verwaltung), bei denen Hausstil und feste Felder zählen, oder um die Zusammenfassungen eines Spitzenmodells in ein günstigeres, selbst betriebenes Modell zu übertragen (Destillation). Dafür braucht es einige Hundert bis einige Tausend von Fachexperten freigegebene Paare aus Quelle und Zusammenfassung.
Stand der Technik (2026)
- Kontextfenster: 1 Mio. Token sind bei Spitzen-APIs Standard (Claude-5.5-Familie, Gemini-Modelle); offene Modelle erreichen nativ 256K und mit Erweiterungen ca. 1M [4][5][12].
- Lang ≠ verstanden: Modelle nutzen Informationen in der Mitte langer Eingaben weiterhin schlechter als am Anfang und Ende („lost in the middle") [14], und das Auffinden mehrerer Fakten im langen Kontext ist weniger zuverlässig als einzelne Abfragen [5]. Bei LongBench v2 (Kontexte von 8K–2M Wörtern) erreichten menschliche Experten unter Zeitlimit 53,7 %, das beste Modell mit direkter Antwort 50,1 % und ein Reasoning-Modell 57,7 % – Schlussfolgern hilft [15].
- Treue zur Quelle: Die Halluzinationsraten unterscheiden sich zwischen Modellen um eine Größenordnung; kleine Modelle und einige stark schlussfolgernde Modelle schneiden bei der Treue von Zusammenfassungen schlechter ab [2]. Auslassungen (die entscheidende Klausel fehlt) sind ebenso gefährlich wie Erfindungen und schwerer automatisch zu erkennen [3].
- Techniken: Ausgabe mit erzwungenen Quellenangaben, erst extrahieren, dann zusammenfassen (zuerst Kernstellen zitieren, dann zusammenfassen), Map-Reduce mit Dublettenentfernung, GraphRAG für globale Fragen [6] und Überprüfung auf Ebene einzelner Aussagen mit NLI-/Halluzinations-Bewertern [2].
- Grenzen: Tabellen und Abbildungen in Scans, Zahlen und Verneinungen, juristische Nuancen, Pakete mit gemischten Sprachen und selbstsichere Zusammenfassungen von Dokumenten, die nur teilweise eingelesen wurden.
Gemeinsame Bausteine & Kombinationen
- Derselbe Stack (llm-general + ocr-docparse + embedding/vector-db): KNOW-002 RAG-Assistent, KNOW-013 GraphRAG, KNOW-015 Deep Research, DOC-014 Dokument-Parsing – eine Parsing-Pipeline und ein LLM-Server (HW2/HW3, vLLM) bedienen alle.
- Typische Ketten: SPEECH-001 Transkript → LANG-008 Zusammenfassung; LANG-008 → LANG-009 Übersetzung oder LANG-010 einfache Sprache; LANG-008 → SPEECH-006 Audio-Kurzvorlage; LANG-016 Themenmodellierung + LANG-008 für Zusammenfassungen je Thema (auch LANG-026 Konsultationen).
- Fachliche Abnehmer: DOC-011 Due Diligence, DOC-010 Verträge, LANG-020 Beobachtung von Regulierung, HLTH-018 Patientenakten, CODE-011 Logs, SEC-008 Bedrohungsinformationen, PERS-008 amtliche Schreiben.
- Schutzmechanismen (Guardrails) (Schwärzen personenbezogener Daten, Filter gegen Prompt Injection bei nicht vertrauenswürdigen Dokumenten) werden mit jedem LLM-Anwendungsfall geteilt, der externe Inhalte aufnimmt.
Aufwand, Kosten & Kennzahlen
- Weg A: Tage; Lizenz pro Nutzer (Office-Copilots, KI-Arbeitsplätze) – der Hauptaufwand sind Einführung, saubere Berechtigungen (Copilot sieht, was der Nutzer sehen kann) und Schulung.
- Weg B: 2–6 Wochen für eine Pipeline mit DMS-Anbindung und Vorlagen; die Kosten werden von den Eingabe-Token bestimmt – bei langen Dokumenten sind Caching und Stapelverarbeitung wichtig.
- Weg C: 1–3 Monate einschließlich Hardwarebeschaffung; ein GPU-Server kann auch RAG und andere Textanwendungsfälle hosten.
- Kennzahlen: eingesparte Lese-/Vorbereitungszeit je Dokument, Anteil der ohne Korrektur akzeptierten Zusammenfassungen, Fehlerquote in stichprobenartigen Prüfungen auf Ebene einzelner Aussagen (nicht belegte Aussagen, kritische Auslassungen), Abdeckung mit Quellenangaben, Kosten je zusammengefasster Seite, Nutzerakzeptanz.
Menschen & Veränderung
Beziehen Sie die Geschäftsleitung ein (welche Dokumente in KI-Werkzeuge dürfen), die Abteilungsleitungen, deren Dokumente zusammengefasst werden, und die Endnutzer, die die Zusammenfassungen lesen und sich darauf verlassen. IT und IT-Sicherheit betreiben die Plattform und legen Zugriffsrechte fest; Datenverantwortliche geben die Ordner frei; die/der Datenschutzbeauftragte prüft personenbezogene Daten in Dokumenten (Personalakten, Kundenmails), den AVV mit jedem Anbieter und ob eine Datenschutz-Folgenabschätzung (DSFA) nötig ist.
Betriebsrat: kommt darauf an. Ein Zusammenfassungswerkzeug allein überwacht keine Beschäftigten, aber M365 Copilot oder ähnliche Assistenten protokollieren Nutzeraktivitäten und sind objektiv zur Überwachung geeignet (BAG), sodass dort § 87 Abs. 1 Nr. 6 BetrVG gilt; selbst betriebene Werkzeuge mit abgeschalteter oder anonymisierter Protokollierung sind weniger kritisch. Informieren Sie ihn in jedem Fall nach § 90 Abs. 1 Nr. 3 und erwägen Sie einen Sachverständigen nach § 80 Abs. 3. Öffentlicher Dienst: Personalrat.
Unterstützen Sie die KI-Kompetenz (Art. 4 KI-Verordnung): Vermitteln Sie, dass Zusammenfassungen Details auslassen oder verzerren können, wie man mithilfe der Quellenangaben gegen die Quelle prüft und dass man sich für rechtliche, medizinische oder sicherheitsrelevante Entscheidungen nie auf eine Zusammenfassung verlassen darf (GUIDE-006). Der Mensch behält die Kontrolle: Zusammenfassungen sind Lesehilfen, das Original ist maßgeblich. Starten Sie einen Pilot mit einem Team und einem Dokumenttyp über einige Wochen (GUIDE-009). Typische Sorgen: Angst vor Überwachung (erklären, was protokolliert wird), Vertrauen in die Richtigkeit (Quellenangaben und Stichprobenprüfungen zeigen) und Schatten-KI (ein freigegebenes Werkzeug anbieten, GUIDE-007).
Risiken, Regulierung & Compliance
- KI-Verordnung (AI Act): Zusammenfassen als Lesehilfe ist ein minimales Risiko (Pflicht zur KI-Kompetenz, Art. 4). Es wird hochriskant, wenn die Zusammenfassung Entscheidungen in Bereichen des Anhangs III wesentlich prägt – z. B. beim Zusammenfassen von Bewerbungsunterlagen im Recruiting, von Leistungs- oder Asylakten oder von Beweismitteln für Gerichte. Art. 6 Abs. 3 kann rein vorbereitende Tätigkeiten ausnehmen, das muss aber geprüft und dokumentiert werden. Art. 50 Abs. 4 (ab 2. Aug. 2026): KI-generierte Texte, die veröffentlicht werden, um die Öffentlichkeit zu informieren, müssen offengelegt werden, es sei denn, sie wurden menschlich geprüft und jemand trägt die redaktionelle Verantwortung [16][17].
- DSGVO: Akten, Personalunterlagen und E-Mails enthalten personenbezogene Daten → Rechtsgrundlage, AVV mit dem Anbieter, Verarbeitung in der EU, kein Training mit Eingaben, Datenschutz-Folgenabschätzung (DSFA) bei besonderen Kategorien oder umfangreichen Daten der öffentlichen Verwaltung; die Orientierungshilfe der deutschen DSK zu KI und Datenschutz gilt [18]. Zusammenfassungen sind neue personenbezogene Datensätze – es gelten Richtigkeit (Art. 5 Abs. 1 Buchst. d) und Aufbewahrungsregeln.
- Vertraulichkeit: Berufsgeheimnisse (§ 203 StGB für Rechtsanwälte, Ärzte, Steuerberater), Geschäftsgeheimnisse und eingestuftes Material (VS-NfD) sprechen für Weg C oder souveränes Hosting.
- Branche: GoBD, wenn Zusammenfassungen Teil buchungsrelevanter Unterlagen werden; MDR, wenn ein Werkzeug für klinische Zusammenfassungen für Diagnose-/Behandlungsentscheidungen gedacht ist (siehe HLTH-018); DORA-Regeln für IKT-Drittanbieter bei Finanzunternehmen, die Cloud-LLMs nutzen.
- Risiken & Gegenmaßnahmen: Auslassungen und Verzerrungen → verpflichtende Quellenangaben, ein Abschnitt „was nicht abgedeckt wurde", stichprobenartige Prüfungen durch Experten; in fremden Dokumenten versteckte Prompt Injection → Schutzmechanismen (Guardrails), keine Werkzeugaktionen aus Zusammenfassungs-Pipelines; Automatisierungsverzerrung → Nutzer schulen, Zusammenfassungen als Hinweise statt als Ersatz zu behandeln.
Erste Schritte
- Wählen Sie 2–3 Dokumenttypen mit hohem Volumen (z. B. Ausschreibungspakete, Lieferantenverträge, Monatsberichte) und legen Sie fest, was eine gute Zusammenfassung enthalten muss (Felder, Länge, Zielgruppe).
- Bauen Sie einen Testdatensatz aus 20–50 echten Dokumenten mit von Experten verfassten Referenzzusammenfassungen oder Checklisten auf.
- Vergleichen Sie an diesem Testdatensatz ein vorhandenes Werkzeug (Weg A, z. B. Ihren Office-Copilot oder einen EU-KI-Arbeitsplatz) mit einem Prompt für eine API mit langem Kontext und erzwungenen Quellenangaben (Weg B).
- Prüfen Sie an einer Stichprobe die Treue auf Ebene einzelner Aussagen und kritische Auslassungen; legen Sie die Prüfregeln entsprechend fest.
- Führen Sie das Ganze mit Vorlagen und Quellenangaben ein; sammeln Sie Korrekturen und prüfen Sie vierteljährlich oder bei einem Modellwechsel erneut.
Quellen
- UK Government — Microsoft 365 Copilot experiment: cross-government findings report — https://www.gov.uk/government/publications/microsoft-365-copilot-experiment-cross-government-findings-report/microsoft-365-copilot-experiment-cross-government-findings-report-html
- Vectara — Hallucination Leaderboard (HHEM-2.3, updated Oct 2026) — https://github.com/vectara/hallucination-leaderboard
- Kim et al. — FABLES: Evaluating faithfulness and content selection in book-length summarization — https://arxiv.org/abs/2404.01261
- Anthropic — Claude models overview (context windows, batch pricing) — https://platform.claude.com/docs/en/about-claude/models/overview
- Google — Gemini API long-context guide — https://ai.google.dev/gemini-api/docs/long-context
- Edge et al. (Microsoft) — From Local to Global: A Graph RAG Approach to Query-Focused Summarization — https://arxiv.org/abs/2404.16130
- Adobe — Acrobat AI Assistant for PDFs — https://www.adobe.com/acrobat/generative-ai-pdf.html
- Langdock — EU-hosted AI workplace — https://langdock.com/
- Mistral AI — Models overview — https://docs.mistral.ai/getting-started/models/models_overview/
- STACKIT — AI Model Serving documentation — https://docs.stackit.cloud/products/data-and-ai/ai-model-serving/
- IONOS — AI Model Hub — https://cloud.ionos.com/managed/ai-model-hub
- Qwen — Qwen3-30B-A3B-Instruct-2507 model card — https://huggingface.co/Qwen/Qwen3-30B-A3B-Instruct-2507
- vLLM — inference and serving engine — https://github.com/vllm-project/vllm
- Liu et al. — Lost in the Middle: How Language Models Use Long Contexts — https://arxiv.org/abs/2307.03172
- Bai et al. — LongBench v2 — https://arxiv.org/abs/2412.15204
- EU AI Act, Article 50 (transparency obligations) — https://artificialintelligenceact.eu/article/50/
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Datenschutzkonferenz — Orientierungshilfe Künstliche Intelligenz und Datenschutz (May 2024) — https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf