EU-souveräne Engine, die Alt-PDFs in barrierefreie, PDF/UA-konforme Dokumente umwandelt und mit veraPDF prüft. Läuft air-gapped ohne Cloud-KI.
Alte, oft gescannte PDFs barrierefrei und PDF/UA-konform machen: Seiten nach Komplexität triagieren, remediieren und das Ergebnis hart gegen veraPDF validieren, vollständig offline.
Am 5. Juni 2026 als erster Anwendungsfall des AI:AT-Local-Model-Stacks aufgesetzt und seither iterativ ausgebaut; die Live-Demo läuft intern. Iterativer Lieferplan bis v3.0 (BRZ-tauglich).
Air-gappable über eine austauschbare, OpenAI-kompatible Modell-Boundary (leer = reiner veraPDF-Modus), EU-souverän mit nur Apache/MIT-Modellen, und datensparsam: PDF-Bytes bleiben im Speicher und werden nie geloggt.
Barrierefrei-Engine ist eine EU-souveräne, air-gappable Engine zur Umwandlung von Alt-PDFs in getaggte, PDF/UA-konforme Dokumente. Das System ist darauf ausgelegt, auch große oder gescannte PDFs lokal zu verarbeiten, ohne Cloud-KI vorauszusetzen. Im Standardbetrieb kann die Engine ohne ausgehenden Netzwerkverkehr laufen; ein leer konfigurierter Modell-Endpunkt führt zu einem veraPDF-only-Modus. Der fachliche Kern liegt nicht allein in der formalen PDF/UA-Prüfung. Die Projektdokumentation hält ausdrücklich fest, dass ein veraPDF-PASS nicht automatisch vollständige Barrierefreiheit bedeutet: Eine gültige Tag-Struktur garantiert weder korrekte Lesereihenfolge noch sinnvolle Alternativtexte oder eine saubere Überschriftenhierarchie. Deshalb kombiniert die Engine die PDF/UA-Validierung mit zusätzlichen Qualitätsprüfungen entlang relevanter WCAG-2.1-AA-Anforderungen. Das Ergebnis eines Verarbeitungslaufs umfasst ein getaggtes PDF sowie prüfbare Reports, darunter ein veraPDF-Evaluationsbericht und ein Qualitätsbericht. Für bestehende PDFs ist außerdem ein Audit-Modus vorgesehen, der ohne Remediation bewertet. Der dokumentierte Projektstatus lautet „live“; zugleich ist die separate Kennzahl „Live“ mit „nein“ angegeben. Der Zeitpunkt der letzten Prüfung und der letzten Synchronisierung ist unbekannt.
Die jüngere Projektbeschreibung zeigt eine Erweiterung von einer reinen PDF/UA-Remediation hin zu einem mehrschichtigen Qualitätsmodell. Neben veraPDF wurde ein deterministisches Inline-WCAG-2.1-AA-Gate beschrieben, das im Remediation-Loop über den zusammengeführten StructureTree prüft. Abgedeckt werden unter anderem Alt-Text-Präsenz, Tabellenköpfe, Überschriftenhierarchie, Dokumenttitel, Sprach-Tag, Lesereihenfolge, Kontrast beziehungsweise Images-of-Text sowie Linkzweck und Name-Role-Value. Konservative Auto-Fixes sind für einzelne Befundarten vorgesehen; verbleibende Befunde werden im Job-Ergebnis und im deutschsprachigen Qualitätsbericht ausgewiesen. Ergänzend wurde ein Dual-Gate-Verdict dokumentiert: Ein Dokument gilt nur dann als „barrierefrei = fertig“, wenn veraPDF für PDF/UA-1 besteht und keine unfixierten ERROR-Findings aus dem Qualitätsgate verbleiben. Zusätzlich erzeugt das System einen Accessibility-Score von 0 bis 100, der nach Nutzerwirkung gewichtet ist. In der beschriebenen Rubrik haben Lesereihenfolge und Alternativtexte ein besonders hohes Gewicht, während die formale veraPDF-Konformität begrenzt gewichtet wird. Für tiefere Regressionsmessungen existiert eine Offline-Eval-Scorecard außerhalb des Produktionspfads. Dort werden Metriken wie CER, Structure-F1, TEDS, Reading-Order Kendall-τ und ein Alt-Text-CLIP-Wert genannt. Außerdem ist eine optionale Human-in-the-Loop-Review-Queue beschrieben. Sie ist standardmäßig deaktiviert und soll niedrig-konfidente Fälle, etwa unbestimmte Alternativtexte oder lesereihenfolgekritische Seiten, für manuelle Freigaben bereitstellen. Das maschinelle Urteil bleibt dabei deterministisch und wird nicht durch Review-Entscheidungen überschrieben.
Die Architektur folgt einer seitenorientierten Pipeline: Triage, parallele Verarbeitung über einen FAST-Pfad mit PyMuPDF und einen SLOW-Pfad mit VLM-OCR, Merge, Tag-Write, veraPDF-Prüfung und erneute Bearbeitung nur fehlerhafter Seiten. Die Remediation ist seitenweise parallelisierbar; PDF-Seiten werden gesplittet, parallel verarbeitet und anschließend wieder zusammengeführt. Eine zentrale Architekturentscheidung ist der air-gappable Modell-Seam. Die Kernlogik und veraPDF laufen lokal in einem CPU-only-Container; alle KI-Funktionen liegen hinter einem austauschbaren, OpenAI-kompatiblen Modell-Endpunkt. Ist dieser Endpunkt nicht gesetzt, validiert und berichtet die Engine ohne Modellaufrufe und ohne ausgehenden Netzwerkverkehr. Erst ein gesetzter Endpunkt aktiviert KI-gestützte Remediation für langsamere Pfade wie OCR oder Alternativtext-Erzeugung. Für das Schreiben getaggter PDFs setzt die Engine laut Dokumentation auf einen Reflow-Ansatz: Inhalte werden in HTML gerendert, über WeasyPrint als PDF/UA-1 ausgegeben und anschließend mit pikepdf nachbearbeitet. Der Entwurf vermeidet damit direktes Tagging ausschließlich über pikepdf. Optional kann die Verarbeitung über einen Out-of-Process-Worker und Broker orchestriert werden; standardmäßig bleibt der normale Betrieb jedoch in-process. Für Batch-Verarbeitung sind Mehrfach-Uploads, ein Batch-Dashboard und ein ZIP-Download der getaggten PDFs beschrieben. Die Betriebsmodi unterscheiden zwischen „Barrierefrei machen + prüfen“ und „Nur prüfen / Audit“. Zusätzlich sind Demo- beziehungsweise Deployment-Tiers dokumentiert, die alle auf demselben Modell-Endpunkt-Mechanismus beruhen. Der air-gapped Betrieb ist dabei als Default beschrieben; gehostete oder externe Modellpfade sind explizite Konfigurationen und nicht Voraussetzung für den Grundbetrieb.
Ein wesentliches fachliches Risiko bleibt die Differenz zwischen formaler PDF/UA-Konformität und tatsächlicher Nutzbarkeit. Die Projektdokumentation adressiert dieses Risiko durch das zusätzliche WCAG-Gate, den Dual-Gate-Entscheid und einen wirkungsgewichteten Score. Dennoch werden bestimmte Befunde bewusst als Findings ausgewiesen, wenn sie nicht deterministisch behoben werden können. Offen beziehungsweise besonders zu beachten sind Konfigurationsrisiken im KI-Pfad. Die Dokumentation nennt konkret, dass der Modell-Endpunkt als Basis-URL angegeben werden muss; ein falsch gesetztes URL-Suffix kann zu einem stillen OCR-Ausfall führen. Für kostenpflichtige oder gehostete Modellpfade sind außerdem Begrenzungen für Tokens, Seiten und Figuren vorgesehen, damit Jobs kontrolliert degradieren können, statt fehlzuschlagen. Für den öffentlichen Status ist die Datenlage uneinheitlich: Der Projektstatus ist als „live“ angegeben, die separate Live-Kennzahl jedoch als „nein“. Zudem sind „zuletzt geprüft“ und „zuletzt synchronisiert“ unbekannt. Diese Angaben sollten bei einer externen Einordnung nicht weiter interpretiert werden.