Warum KI Ihre Scans nicht lesen kann – und wie wir das gelöst haben

📚 Inhalt

• Wie alles begann: Der Kunde schickte 20 Seiten zum Test
• Warum ein Scan kein Dokument für KI ist
• Drei Probleme, die wir in einer Datei fanden
• Wie wir dem Dienst das automatische Scannen beigebracht haben
• Was das für Ihr Unternehmen bedeutet
• Die Grenzen der Technologie: Wenn selbst Vision OCR nicht mehr hilft
• Fazit: Keine Garantien, aber Ehrlichkeit

Wie alles begann: Der Kunde schickte ein Testpaket

Vor ein paar Wochen kontaktierte mich ein auf Baurecht spezialisierter Anwalt – er arbeitet mit einem Archiv von über 10.000 Dateien und suchte nach einer Lösung für die schnelle Informationssuche in Dokumenten. Nach einem kurzen Gespräch schickte er ein Testpaket: 21 Seiten aus seinem Archiv.

Ich lud die Datei hoch, startete die Indizierung und erstellte eine Liste mit 18 Testfragen – Fragen, deren Antworten definitiv im Dokument standen und die ich manuell überprüfen konnte. Das Ergebnis war unerwartet:

Ein wichtiger Hinweis: Diese Zahlen sind kein Indikator für den Dienst, sondern für die Qualität des Eingangsdokuments. Derselbe Pipeline mit einem reinen Text-PDF liefert 95–99% Genauigkeit. Das Problem lag nicht am Modell oder der Suchlogik – sondern daran, dass die meisten Seiten noch vor der Chance der KI, überhaupt zu antworten, als unlesbarer Müll indexiert wurden. Das ist genau das Thema dieses Falls.

Aber es gab noch ein zweites Problem – ein Verhaltensproblem: Der Dienst sagte nicht „Ich weiß es nicht“. Er antwortete selbstbewusst, verwies auf ein bestimmtes Fragment – aber 44% der Antworten enthielten Zahlen und Fakten, die im Dokument nicht existierten. Für juristische Dokumente, bei denen jede Zahl zählt – ist das kritisch.

Ich begann zu untersuchen, wo genau die Qualität verloren ging. Der erste Verdacht – das Modell oder die Suchlogik. Aber das Problem lag früher im Pipeline:

Scan-PDF
  ↓
OCR                    // Rausch-Injektionsschicht
  ↓
Chunking               // Text bereits verzerrt
  ↓
Embeddings             // semantische Verzerrung
  ↓
Vector DB              // irreversible Fehlerverbreitung

Von den 21 Seiten wurden nur **5–6** normal indexiert. Der Rest gelangte als Müll in die Datenbank – und aus diesem Müll baute die KI selbstbewusste Antworten. Im Folgenden analysiere ich, was genau schiefgelaufen ist und wie wir es behoben haben.

Warum ein Scan kein Dokument für KI ist

Das erste, was ich tat, nachdem ich die Datei erhalten hatte, war, sie zu öffnen und zu versuchen, den Text mit der Maus zu markieren. Es funktionierte nicht. Das Dokument stellte sich als Scan heraus: Papierseiten, die in einer PDF-Hülle ohne jegliche Textschicht darin gespeichert waren.

Die meisten Leute verstehen den Unterschied zwischen einem „Scan-PDF“ und einem „Text-PDF“ nicht. Sie sehen gleich aus. Sie lassen sich gleich öffnen. Aber für ein KI-System – sind das grundlegend unterschiedliche Dinge:

Mehr über die Vorbereitung verschiedener Dokumenttypen für die Indizierung – im Artikel Wie man Dokumente für einen KI-Assistenten 2026 vorbereitet und in der Übersicht OCR in modernen KI-Systemen: Von Scans zu RAG.

Scheinbar ist die Lösung einfach: OCR starten und das Ergebnis hochladen. Aber hier trat ein Problem auf, das ich nicht erwartet hatte: Die meisten Seiten waren schräg eingescannt – 90°, 180° oder 270° vom normalen Textbezug. Das ist eine typische Situation für alte Archive, wo Dokumente stapelweise ohne Kontrolle der Ausrichtung jedes Blattes gescannt wurden.

Wenn Standard-OCR auf eine umgedrehte Seite trifft – gibt es entweder ein leeres Ergebnis oder unlesbaren Müll aus, der äußerlich wie Text aussieht. Das System erhielt Zeilen wie:

аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E

Und baute darauf Antworten auf. KI wusste nicht, dass das Müll war – sie verwendete einfach das, was sie aus dem Index erhielt.

Das ist keine Ausnahme. Laut Analystenschätzungen wächst der Markt für intelligente Dokumentenverarbeitung um über 30% jährlich – gerade weil die meisten Unternehmen dieses Problem in großem Maßstab haben: Archive, in denen ein erheblicher Teil der Dateien entweder für KI unlesbar ist oder mit kritischen Fehlern gelesen wird wegen falscher Ausrichtung und schlechter Scan-Qualität.

Drei Probleme, die wir in einer Datei fanden

Um zu verstehen, wo genau die Qualität verloren ging, machte ich eine SQL-Abfrage an die Datenbank und sah mir den Inhalt der Chunks an, die tatsächlich in den Index gelangten. Das Bild war klar: Das Dokument enthielt drei unabhängige Probleme – und jedes davon allein reichte aus, um das Ergebnis zu ruinieren.

Problem 1: Umgedrehte Seiten

Die meisten Seiten waren um 90°, 180° und 270° gedreht – eine typische Situation für das Stapelscannen von Papierarchiven, bei denen der Bediener die Blätter stapelweise ablegt, ohne die Ausrichtung jedes einzelnen zu prüfen.

Standard-OCR gibt hierbei Müll aus, der äußerlich wie Text aussieht:

аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E

Die Vektorsuche fand diese Chunks als relevant – sie existierten formal in der Datenbank. Die KI erhielt sie als Kontext und synthetisierte eine Antwort. Ergebnis: selbstbewusste Antworten mit Zahlen, die nie im Dokument waren.

Problem 2: Schlechte Scan-Qualität

Einige Seiten wurden bei schlechter Beleuchtung oder ungleichmäßigem Kontrast gescannt. Gemäß den technischen Standards von OCR-Systemen beträgt die Erkennungsgenauigkeit bei einer Auflösung von 300+ DPI 98–99% – und fällt unter diesem Schwellenwert erheblich ab. Das gilt für alle OCR-Lösungen, einschließlich Vision AI-Modellen.

Ein Fehler in einem Ziffernzeichen ändert die Antwort vollständig. Wenn im Dokument „28.28 Perma“ steht und OCR „28.23“ liest – wird die KI falsch antworten, auch wenn die Suchlogik perfekt funktioniert hat.

Problem 3: Zusammengeklebter Text ohne Leerzeichen

Einige Seiten enthielten die Standard-Vertraulichkeitsmitteilung, bei der aufgrund besonderer Druck- oder Scan-Eigenschaften alle Wörter zu einer einzigen Zeile verschmolzen waren:

containconfidentialinformation,proprietary,and/orprivilegedmaterial

GPT-4o-mini erkennt diesen Text nicht als lesbar und gibt „[IMAGE - no text]“ zurück. Die Seite fällt vollständig aus dem Index. Auf diesen Seiten befanden sich Spezifikationen und technische Daten – genau das, was der Kunde suchen wollte.

Zusammenfassung der Diagnose:

Diese Zahlen sind ein Merkmal des spezifischen problematischen Dokuments, nicht des Dienstes. Auf einem reinen Text-PDF liefert derselbe Pipeline 95–99%. Aber gerade solche „komplizierten“ Archive sind die Norm für die meisten Unternehmen, die jahrelang Dokumente ohne Scan-Standards angesammelt haben.

Wie wir dem Dienst das automatische Scannen beigebracht haben

Nach der Diagnose wurde klar: Das Problem muss nicht auf der Seite der Dokumentenvorbereitung durch den Kunden gelöst werden, sondern auf der Ebene des Dienstes selbst. Der Kunde sollte sich keine Gedanken darüber machen müssen, in welchem Winkel sein Archiv gescannt wurde. Er lädt einfach die Datei hoch – und erhält das Ergebnis.

Ich habe die Lösung in vier aufeinanderfolgende Schritte unterteilt. So sieht der aktualisierte Pipeline aus:

Datei-Upload
  ↓
Textextraktion (Apache Tika)
  ↓
Müll-Detektor            // >40% ALL CAPS → Scan
  ↓ (wenn Müll)
Vision OCR (GPT-4o-mini)   // liest Seite als Bild
  ↓ (wenn [IMAGE - no text])
Automatische Ausrichtungskorrektur    // 90° → 180° → 270° → Wiederholung
  ↓
Chunking → Embeddings → Vector DB
  ↓
Antwort mit hartem Prompt  // "Ich weiß nicht" statt Halluzinationen

Schritt 1: Müll-Detektor

Der Standard-Parser (Apache Tika) extrahierte Text aus PDFs, konnte aber normalen Text nicht von Müll aus Scans unterscheiden. Beides sah aus wie „Text vorhanden“ – und beides ging in den Index.

Ich habe einen einfachen Detektor hinzugefügt: Der Dienst analysiert die ersten 1000 Zeichen des extrahierten Textes und zählt den Anteil der Wörter, die vollständig in Großbuchstaben geschrieben sind.

Auslöseschwelle: >40% ALL CAPS → das Dokument wird als Scan markiert und weitergeleitet. Das filtert die Hauptursache für Halluzinationen schon vor der Indizierung heraus.

Schritt 2: Vision OCR über GPT-4o-mini

Standard-OCR liest Bilder als eine Reihe von Formen – es versteht keinen Kontext und kann eine Tabellenstruktur nicht wiederherstellen, wenn der Scan unscharf ist. GPT-4o-mini erhält die Seite als Bild und versteht sie wie ein Mensch: Es sieht eine Tabelle als Tabelle, eine Spalte mit Zahlen als Spalte mit Zahlen.

Prompt mit spezifischen Regeln für technische und juristische Dokumente:

- Extrahieren Sie den gesamten Text ohne Lücken.
- Behalten Sie die Tabellenstruktur mit dem Trennzeichen „|“ bei.
- Leere Zelle → Bindestrich
- Zahlen exakt wie geschrieben, ohne Rundung.
- Wenn die Seite nur eine Grafik ist → „[IMAGE - no text]“

Ohne klare Regeln konnte das Modell Zahlen runden oder Spalten zusammenführen – die Antwort hätte glaubwürdig ausgesehen, aber wäre ungenau gewesen.

Schritt 3: Automatische Ausrichtungskorrektur

Wenn die Seite beim ersten Durchgang „[IMAGE - no text]“ zurückgab – startet der Dienst automatisch drei zusätzliche Versuche:

0° → [IMAGE - no text]
  ↓ automatische Drehung
90° → [IMAGE - no text]
  ↓ automatische Drehung
180° → lesbarer Text ✓ → wir speichern

Sobald das Modell lesbaren Text findet – stoppen wir. Wenn keiner der vier Winkel ein Ergebnis liefert – wird die Seite als Bild markiert und ohne Fehler übersprungen.

Geschwindigkeit ist der einzige wirkliche Kompromiss: Jede umgedrehte Seite generiert bis zu 4 API-Aufrufe statt nur einem. Für ein 21-seitiges Dokument – etwa 5 Minuten. Aber das ist eine einmalige Operation beim Hochladen – nach der Indizierung kommen die Antworten sofort.

Schritt 4: Ehrlichkeit statt Halluzinationen

Die technischen Schritte lösten die Qualität der Indizierung. Aber das Verhaltenproblem blieb: Wenn keine relevanten Fragmente gefunden wurden – füllte das Modell die Lücken mit Allgemeinwissen, anstatt zu sagen „Ich weiß es nicht“.

Ich habe den System-Prompt aktualisiert und eine strenge Regel hinzugefügt:

Wenn in den gefundenen Fragmenten keine klare Antwort vorhanden ist →
  „Im Dokument wurden keine genauen Informationen zu dieser Frage gefunden.
   Versuchen Sie, die Frage umzuformulieren oder präzisieren Sie den Abschnitt des Dokuments.“

Verbotene Indikatorphrasen für Halluzinationen:
  - „normalerweise“
  - „in der Regel“
  - „typisch für solche Dokumente“

Wenn diese Phrasen in der Antwort erscheinen – bedeutet das fast immer, dass das Modell aus seinen Trainingsdaten antwortet und nicht aus dem Dokument.

Ergebnis nach allen Änderungen

Zur Erinnerung der Kontext: Diese Zahlen sind das Ergebnis bei einem problematischen Scan von niedriger Qualität. Derselbe Pipeline mit einem reinen Text-PDF liefert 95–99%. Die wichtigste Errungenschaft hier – nicht der Anstieg der Genauigkeit von 17% auf 50%, sondern das vollständige Verschwinden von selbstbewusst falschen Antworten. Für juristische Dokumente ist das wichtiger als jede andere Metrik.

Was das für Ihr Unternehmen bedeutet

Nach allen Änderungen denkt der Kunde nicht mehr über das Dateiformat oder die Seitenorientierung nach. Er lädt einfach das Dokument hoch – der Dienst kümmert sich selbst darum, was damit zu tun ist: er erkennt, ob Vision OCR benötigt wird, korrigiert die Ausrichtung, indiziert das Ergebnis. Das ist eine einmalige Operation. Danach – normale Suche in Dokumenten ohne zusätzliche Kosten.

Für welche Branchen ist das relevant

Das Problem gescannter Archive ist für Anwälte nicht einzigartig. Es tritt in jeder Branche auf, in der Dokumente jahrelang in Papierform angesammelt wurden – und nach denen jetzt schnell gesucht werden muss.

Gemeinsam ist allen diesen Szenarien: Dokumente existieren bereits, es gibt viele davon, und sie sind von unterschiedlicher Qualität. Niemand wird ein Archiv neu scannen, nur um KI einzuführen. Deshalb muss der Dienst in der Lage sein, mit dem Vorhandenen zu arbeiten – und nicht ideale Dateien als Eingang zu verlangen.

Was kostet Vision OCR: Eine reale Berechnung

Das Wichtigste, was man verstehen muss: Vision OCR ist eine einmalige Ausgabe beim Hochladen. Nachdem das Dokument indiziert ist, erfordert jede Frage dazu keine zusätzlichen Kosten für OCR. Sie zahlen einmal für die Verarbeitung – und suchen dann beliebig viel.

Die Kosten berechnen sich einfach. GPT-4o-mini über OpenRouter kostet $0.15 pro Million Input-Token und $0.60 pro Million Output-Token. Eine A4-Seite in Vision OCR – das sind etwa 1.500–2.000 Input-Token (Bild) und 300–600 Output-Token (extrahierter Text).

Kosten für die Verarbeitung einer Seite:

Selbst im schlimmsten Fall – wenn jede Seite verdreht ist und vier Versuche benötigt – bleiben die Verarbeitungskosten unter einem halben Cent pro Seite.

Kosten für die Verarbeitung eines Archivs (Seitenberechnung):

Für den Mandanten-Anwalt, mit dem diese Geschichte begann – ein Archiv mit 10.000+ Dateien, wobei ein durchschnittliches Dokument 15–20 Seiten umfasst – das sind etwa 150.000–200.000 Seiten. Die Kosten für die Vision OCR-Verarbeitung: $150–400, abhängig von der Qualität der Scans. Die manuelle Verarbeitung des gleichen Umfangs für 15 $/Stunde hätte Jahre gedauert und Hunderttausende von Dollar gekostet.

Wichtiger Hinweis: Diese Zahlen sind die Kosten für den OCR-Aufruf an sich an die API. Dazu kommen die Kosten für das Service-Abonnement und die Datenspeicherung. Aber selbst unter Berücksichtigung dessen – ist die automatische Verarbeitung um zwei Größenordnungen günstiger als die manuelle.

Was Vision OCR nicht ersetzt

Automatische Verarbeitung senkt die Eintrittsschwelle – aber sie ersetzt nicht die Notwendigkeit der menschlichen Kontrolle, wo diese kritisch ist. Für medizinische und juristische Dokumente, bei denen jede Zahl rechtliche Folgen hat – beschleunigt Vision OCR die Arbeit, aber ersetzt nicht die Verifizierung durch einen Menschen.

Das richtige Nutzungsmodell: KI findet das benötigte Fragment in Sekunden, der Anwalt oder Arzt verifiziert die Antwort im Originaldokument. Das ist kein „KI statt Mensch“ – sondern „KI statt einer Stunde manueller Suche“.

Die Grenzen der Technologie: Wenn selbst Vision OCR nicht mehr hilft

Vision OCR ist keine Magie. Es liest, was es sieht. Die Qualität des Eingangsbildes bestimmt direkt die Qualität des Ergebnisses – und kein Modell kann Informationen wiederherstellen, die physisch nicht lesbar sind.

Selbst nach allen Verbesserungen blieben im Testdokument Seiten übrig, die der Dienst nicht normal lesen konnte. Hier ist das reale Bild nach Dokumententypen:

30% Fehler in einem technischen oder juristischen Dokument sind nicht „ein bisschen ungenau“. Es sind falsche Zahlen in Spezifikationen, falsche Beträge in Verträgen, falsche Dosen in medizinischen Protokollen. Deshalb ist die Qualität des Eingangsscans – kein technisches Detail, sondern eine Geschäftsentscheidung.

GPT-4o-mini vs. GPT-4o: Wann sich ein Wechsel lohnt

GPT-4o-mini – das Modell, das ich standardmäßig für Vision OCR verwende. Es ist schnell und kostengünstig, hat aber Grenzen bei komplexen Dokumenten. GPT-4o erzielt merklich bessere Ergebnisse – ist aber 5-10 Mal teurer in der Verarbeitung.

Zeichenfehlerrate (CER, Character Error Rate) – der Anteil der Zeichen, die das Modell falsch gelesen hat. CER 10% bedeutet, dass jedes zehnte Wort einen Fehler enthält. Für einen Vertrag, in dem „28,28 qm“ steht – kann daraus „28,23 qm“ oder „2B,28 qm“ werden. Rechtlich gesehen sind das unterschiedliche Dokumente.

Mein Ansatz: Beginnen Sie mit GPT-4o-mini für das gesamte Archiv. Seiten, bei denen Mini „[IMAGE - no text]“ oder ein offensichtlich unlesbares Ergebnis zurückgab – verarbeiten Sie erneut mit GPT-4o. Das bietet ein Gleichgewicht zwischen Qualität und Kosten: 90–95% der Seiten werden kostengünstig verarbeitet, komplizierte Fälle – präzise.

So testen Sie ein Archiv vor der Skalierung

Der teuerste Fehler bei der Implementierung von RAG für Scan-Archive – alle Dokumente auf einmal hochzuladen und die Probleme erst danach zu erfahren. Der richtige Ansatz: Zuerst auf einer kleinen Stichprobe messen, dann skalieren.

Hier ist der Schritt-für-Schritt-Prozess, den ich Kunden vor der vollständigen Implementierung empfehle:

Schritt 1: Repräsentative Stichprobe – 15–20 Dokumente.
Wählen Sie nicht die besten Dateien aus – wählen Sie typische aus. Ein Archiv enthält normalerweise mehrere Qualitätskategorien: aktuelle Scans von Büro-Scannern, alte Scans aus den 1990ern, Fotos von Dokumenten mit dem Smartphone, Faxe. In der Stichprobe sollten jeweils 3–5 Dokumente jedes Typs enthalten sein. Wenn das Archiv handschriftliche Dokumente oder Dokumente mit Stempeln enthält – sollten diese ebenfalls in die Stichprobe aufgenommen werden.

Schritt 2: Fragen mit bekannten Antworten – 20–30 Stück.
Nicht allgemeine („Worum geht es in diesem Dokument?“), sondern spezifische und überprüfbare:

• „Wie hoch ist der Gesamtbetrag für den Vertrag vom 12.03.2021?“
• „Welche Frist für die Leistungserbringung ist im Akt Nr. 47 angegeben?“
• „Wie lautet der Name des Auftragnehmers in der Spezifikation auf Seite 4?“

Genau solche Fragen decken die tatsächliche Genauigkeit auf – besonders bei Zahlen und Eigennamen, wo OCR-Fehler am kritischsten sind.

Schritt 3: Messen Sie drei Kennzahlen, nicht zwei.
Die meisten Tests zählen nur „korrekt / inkorrekt“. Das ist nicht ausreichend. Es ist wichtig, drei Antwortkategorien zu unterscheiden:

Die dritte Kategorie ist die gefährlichste. „Nicht gefunden“ ist eine akzeptable Antwort des Systems. Eine selbstbewusst falsche Antwort – das ist ein Problem, das vor der Skalierung gelöst werden muss.

Schritt 4: Entscheidung basierend auf dem Ergebnis.
Nach dem Test sind drei Szenarien möglich:

Genau so habe ich dem Mandanten-Anwalt, mit dem diese Geschichte begann, geraten. Nicht „laden Sie alle 10.000 Dateien hoch und wir schauen mal“ – sondern „testen Sie auf 20 repräsentativen Dateien und messen Sie die Genauigkeit bei Fragen, die für Ihre Praxis wichtig sind“. Das ist der einzige Weg, die tatsächliche Eignung des Archivs zu verstehen, bevor Zeit und Budget in die vollständige Implementierung investiert werden.

Mehr über die Vorbereitung von Dokumenten verschiedener Formate für die Indizierung – im Artikel Wie man Dokumente für einen KI-Assistenten vorbereitet: Formate, OCR, Checkliste 2026. Darüber, wie OCR-Fehler den gesamten RAG-Pipeline beeinflussen – im Material OCR in modernen KI-Systemen: Von Scans zu RAG.

Fazit: Keine Garantien, aber Ehrlichkeit

Nach Abschluss aller Änderungen schrieb ich dem Kunden einen ehrlichen Bericht: die Dokumente sind komplex, einige Seiten sind umgedreht, einige wurden aufgrund von zusammengeklebtem Text übersprungen. Das haben wir mit derselben problematischen Datei erreicht:

Ich habe dem Kunden keine Perfektion versprochen. Der Kontext ist wichtig: 17% am Anfang sind kein Urteil über den Dienst, sondern ein Urteil über die Qualität des Eingangsdokuments. Derselbe Pipeline mit einem reinen Text-PDF liefert 95–99%. Aber für ein echtes Archiv mit Scans unterschiedlicher Qualität – ist 50% Genauigkeit und keine Halluzinationen bereits ein Werkzeug, das man nutzen kann. Und gerade diese Ehrlichkeit ist meiner Meinung nach der richtige Ansatz für die Arbeit mit KI für Unternehmen.

Vier Schlussfolgerungen aus diesem Fall

1. Ein Scan ist nicht standardmäßig ein Dokument für KI.
Die meisten Unternehmen erfahren das erst, nachdem sie das gesamte Archiv hochgeladen haben. Testen Sie mit einem einfachen Test: Öffnen Sie die Datei und versuchen Sie, den Text mit der Maus zu markieren. Wenn es nicht funktioniert – handelt es sich um einen Scan und er benötigt OCR vor der Indizierung. Das ist kein Problem – es ist der Ausgangspunkt.

2. Halluzinationen sind gefährlicher als „Ich weiß nicht“.
Ein Dienst, der ehrlich sagt „Die Information wurde im Dokument nicht gefunden“ – ist viel nützlicher als einer, der selbstbewusst falsche Zahlen liefert. Besonders in den Bereichen Recht, Medizin und Technik, wo Genauigkeit entscheidend ist. Ein paar verbotene Phrasen im System-Prompt und die strenge Regel „Wenn du es nicht weißt – sag es“ ändern das Verhalten des Modells dramatisch. Das ist nicht schwierig – aber die meisten Implementierungen tun es nicht.

3. Qualität am Eingang bestimmt Qualität am Ausgang – und das ist keine Metapher.
Unternehmen investieren Monate in die Anpassung von Pipelines, die Auswahl von Embedding-Modellen, die Optimierung von Chunking-Strategien – und erhalten unbefriedigende Ergebnisse, weil 40% des Archivs Scans von schlechter Qualität sind. Überprüfen Sie die Qualität der Eingangsdokumente, bevor Sie alles andere optimieren.

4. Test mit echten Fragen – das einzige ehrliche Kriterium.
Nicht die Anzahl der indizierten Dokumente und nicht die Demonstration an idealen Dateien. 20–30 spezifische Fragen, deren Antworten Sie genau kennen – und drei Ergebnis-Kategorien: richtig / „nicht gefunden“ / selbstbewusst falsch. Diese einfache Methode wird mehr sagen als jeder Marketing-Benchmark.

So beginne ich jetzt ein Gespräch mit einem Kunden

Dieser Fall hat meinen Ansatz bei der Präsentation des Dienstes verändert. Früher begann ich mit den Möglichkeiten: Was das System kann, welche Modelle es verwendet, wie die Architektur aussieht. Jetzt beginne ich mit einer Frage:

„Zeigen Sie mir 5 Dokumente aus Ihrem Archiv und sagen Sie mir, welche Fragen Sie stellen möchten.“

Fünf Dokumente und zwanzig Minuten – und es ist klar, ob die Technologie für das spezifische Archiv geeignet ist. Wenn die Dokumente lesbar und die Fragen spezifisch sind – können wir beginnen. Wenn nicht – ist es besser, das von Anfang an ehrlich zu sagen, als nach einem Monat Arbeit.

Wenn Sie ein Archiv gescannter Dokumente haben und verstehen möchten, ob KI-Suche für Ihr Szenario geeignet ist – schreiben Sie uns auf Telegram oder probieren Sie das Live-Demo auf der Startseite. Der erste Test – kostenlos.

• Wie man Dokumente für einen KI-Assistenten vorbereitet: Formate, OCR, Checkliste 2026
• KI für Anwaltskanzleien: Datensicherheit und Vertraulichkeit
• KI-Sicherheit: Checkliste mit 20 Fragen vor der Implementierung
• OCR in modernen KI-Systemen: Von Scans zu RAG