BriefWerk: Lokale KI für Schreiben – mit menschlicher Freigabe

Ein eingehendes Schreiben enthält häufig mehr als eine Frage. Zuständigkeiten müssen geklärt, interne Unterlagen gefunden und Aussagen fachlich geprüft werden. Ein sprachlich überzeugender Antworttext ist dabei nur ein Teil der Arbeit. Ebenso wichtig ist, worauf er sich stützt und wer ihn freigibt.

BriefWerk ist ein eigener, funktionsfähiger MVP für diesen Ablauf. Die Anwendung unterstützt Redaktionen, Abgeordnetenbüros, Fraktionen, Verbände und Fachabteilungen bei der Bearbeitung von Schreiben – mit KI, die in eigener Infrastruktur läuft. Sie bereitet Entwürfe vor, nimmt Menschen aber weder die fachliche Verantwortung noch die Entscheidung über eine Antwort ab.

Wichtig zum Projektstand: BriefWerk ist kein produktionsreifes oder zertifiziertes Produkt. Die gezeigten Ansichten verwenden ausschließlich synthetische Beispieldaten. Personen, Orte, Vorgänge und Zahlen in diesen Beispielen sind frei erfunden.

Für wen BriefWerk gedacht ist#

Eine Redaktion braucht einen respektvollen Umgang mit Leserbriefen. Ein Abgeordnetenbüro oder eine Fachabteilung muss Sachfragen nachvollziehbar beantworten und Zuständigkeiten beachten. Ein Verband benötigt möglicherweise eine andere Tonalität und andere freigegebene Textbausteine.

BriefWerk trennt diese Anforderungen über administrierbare Fachprofile. Bei der Erstanlage sind Profile für Redaktion, Politik und Verwaltung sowie eine allgemeine Fachabteilung vorgesehen. Sie beschreiben unter anderem Aufgabenbereich, Anrede, Tonalität, Ziel-Länge, Briefstruktur, zulässige Quellen, fachliche Grenzen und Prüfkriterien. Diese Regeln sind nicht als unveränderlicher Anwendungscode gedacht, sondern als pflegbare Arbeitsgrundlage.

Vom Eingang bis zum freigegebenen Entwurf#

Der vorgesehene Arbeitsablauf verbindet mehrere klar getrennte Schritte:

1. Schreiben erfassen: Text eingeben oder TXT, PDF, DOCX, PNG und JPG importieren; für Bilder steht lokale Texterkennung zur Verfügung.
2. Inhalt analysieren: Fragen, mögliche Zuständigkeiten und offene Prüfpunkte strukturiert herausarbeiten.
3. Fachprofil zuordnen: Aufgabenbereich, Tonalität und fachliche Grenzen berücksichtigen.
4. Wissensquellen finden: Freigegebene interne Dokumente und passende Abschnitte im jeweiligen Mandantenkontext suchen.
5. Antwort entwerfen: Einen bearbeitbaren Entwurf mit Bezug auf diese Quellen vorbereiten.
6. Menschlich prüfen und freigeben: Blockierende Hinweise klären oder begründet quittieren und die konkrete Entwurfsversion prüfen.
7. Exportieren: Das Ergebnis als DOCX, PDF oder TXT für die weitere Bearbeitung bereitstellen.

BriefWerk versendet keine Antworten automatisch. Es trifft keine verbindlichen Entscheidungen über Personen, erstellt keine politischen Gesinnungsprofile und bietet keine Überzeugungsstrategien oder Risikoeinstufungen von Absenderinnen und Absendern an.

Original, Analyse und Entwurf nebeneinander#

Der Arbeitsbereich stellt das eingegangene Schreiben, die Analyse mit Quellen und den Antwortentwurf nebeneinander dar. Das erleichtert den Abgleich: Welche Frage wurde tatsächlich gestellt? Welche Fundstelle wurde herangezogen? Welche Aussage steht anschließend im Entwurf?

Offene Prüfhinweise werden sichtbar angezeigt. In der folgenden Demoansicht konnten Zitate nicht wörtlich in den abgerufenen Abschnitten bestätigt werden. Diese Hinweise verschwinden nicht hinter einer vermeintlich fertigen Antwort, sondern stehen vor der Freigabe im Arbeitsbereich.

Der Posteingang bietet Filter nach Status, Fachprofil, Frist und offenen Prüfhinweisen. Das Dashboard bündelt offene Vorgänge, Prüfaufgaben, bestätigte Fristen und den Status der lokalen KI. Ein KI-Vorschlag für eine Frist ist dabei noch keine verbindlich bestätigte Frist.

Wissen aus freigegebenen Quellen#

Die Wissensbasis enthält die vom jeweiligen Mandanten eingestellten Quellen, einschließlich Freigabestatus, Gültigkeit und Abschnitten. Frühere Korrespondenz wird nicht automatisch zu einer freigegebenen Wissensquelle. Eine semantische Suche findet passende Stellen innerhalb der freigegebenen Dokumente; sie führt keine automatische Internetrecherche durch.

Belege werden gegen die tatsächlich abgerufenen Abschnitte geprüft. Auch ungültig werdende Fundstellen und widersprüchliche Quellen sollen sichtbar bleiben. Eine Fundstelle allein beweist allerdings noch nicht, dass die gesamte Antwort fachlich richtig oder vollständig ist. Genau diese Bewertung bleibt Teil der menschlichen Prüfung.

Freigabe gehört zum Ablauf – Versand nicht#

Die Freigabe bezieht sich auf eine konkrete Entwurfsversion. Das Vier-Augen-Prinzip trennt Erstellung und Freigabe; blockierende Prüfpunkte müssen vorher geklärt oder begründet quittiert werden. Änderungen am Entwurf erfordern eine erneute Prüfung des Freigabestands.

Eine begründete Quittierung ist dabei eine verantwortete menschliche Entscheidung und kein nachträglich erzeugter Quellenbeleg. Das System kann kontrollieren, ob die vorgesehenen Schritte erfolgt sind. Ob die prüfende Person fachlich richtig entscheidet, lässt sich damit nicht automatisieren.

Die technische Grundlage#

Die Anwendung verbindet eine Weboberfläche mit einer Python-API und eigener Hintergrundverarbeitung:

• Oberfläche: Next.js 15, React 19, TypeScript und Tailwind CSS.
• API: FastAPI und Pydantic v2.
• Datenbank und Suche: PostgreSQL 17 mit pgvector, HNSW-Index und Cosine-Ähnlichkeit.
• Verarbeitung: Ein eigener Worker arbeitet Aufträge aus einer Warteschlange in der Datenbank ab.
• Lokale Inferenz: Ollama; alternativ ist ein passend konfigurierter interner OpenAI-kompatibler Server vorgesehen.
• Textextraktion: pypdf, python-docx und Tesseract OCR.
• Betrieb: Docker Compose mit Nginx als einzigem vom Host erreichbaren Dienst im beschriebenen Aufbau.

Im vorgesehenen Laufzeitbetrieb gibt es keinen Cloud-KI-Fallback, keine Telemetrie, keine Laufzeit-CDNs und keine extern geladenen Schriftarten. Modelle werden ausdrücklich während der Einrichtung installiert, nicht automatisch während der Bearbeitung eines Schreibens heruntergeladen. Lokaler Betrieb ersetzt dabei weder eine geeignete Konfiguration noch ein Datenschutz- und Betriebskonzept.

Sicherheit braucht mehrere getrennte Prüfebenen#

Die Sicherheitsarchitektur berücksichtigt Mandantentrennung in Anwendung und Datenbank, rollenbasierte Zugriffe, serverseitige Sitzungen, CSRF-Schutz sowie Typ-, Größen- und Zeitlimits für Uploads. Audit-Einträge sollen keine Briefinhalte enthalten. Löschvorgänge berücksichtigen auch abgeleitete Daten; eine optionale Pseudonymisierung wird ausdrücklich nicht als Anonymisierung bezeichnet.

Zwei Erfahrungen aus der Projektdokumentation zeigen, warum einzelne Schutzbehauptungen nicht genügen:

• Row-Level Security hängt von der Datenbankrolle ab. PostgreSQL-Superuser können RLS auch bei FORCE umgehen. BriefWerk sieht deshalb eine Laufzeitrolle ohne BYPASSRLS und eine Prüfung beim Anwendungsstart vor.
• Eine Feldliste im Prompt ist noch kein verlässliches Datenformat. Kleine Modelle lieferten im dokumentierten Entwicklungsstand frei erfundene Schlüssel. Die Ausgabestruktur wird deshalb über ein JSON-Schema vorgegeben. Formal gültige Daten sind trotzdem kein Nachweis inhaltlicher Richtigkeit.

Schreiben und Wissensquellen werden als zu prüfendes Datenmaterial behandelt, nicht als Befehle, die zusätzliche Werkzeuge oder Rechte erhalten. Prompt-Injection-Prüfungen und Belegabgleich sind technische Leitplanken – keine Garantie für fehlerfreie Antworten.

Lokale KI hat Hardwarekosten#

Ohne GPU kann der Ablauf erheblich Zeit benötigen. In der dokumentierten CPU-Umgebung mit 16 Kernen und ungefähr 15 GB RAM benötigte qwen2.5:3b-instruct mehrere Minuten für die Analyse und ungefähr fünf bis sieben Minuten für einen Entwurf. Das sind Messwerte dieser Umgebung, keine allgemeine Laufzeitgarantie.

Für die Wissenssuche wird nomic-embed-text verwendet. Das kleinere qwen2.5:1.5b-instruct lieferte in den beschriebenen Versuchen keine brauchbaren Antwortentwürfe. Die Auswahl darf sich deshalb nicht allein an Modellgröße oder Geschwindigkeit orientieren.

Für eine synchrone Arbeit am Schreibtisch ist ausreichend leistungsfähige Hardware einzuplanen. GPU-Betrieb und größere Modelle müssen auf dem jeweiligen Zielsystem erprobt werden; aus den dokumentierten CPU-Messungen lässt sich kein konkretes GPU-Geschwindigkeitsversprechen ableiten.

Was Tests und Lizenz aussagen – und was nicht#

Der dokumentierte Testumfang umfasst unter anderem Mandantentrennung einschließlich Vektorsuche und Downloads, Rollen und Freigaben, gefährliche Uploads, fehlende oder widersprüchliche Quellen, Löschung und Export ohne interne Kommentare.

Mock und echte KI sind ausdrücklich getrennt. Ein erfolgreicher Standardlauf mit dem Mock-Anbieter ist kein Nachweis einer funktionierenden Modellanbindung. Tests mit einem echten lokalen Modell müssen gesondert und ausdrücklich aktiviert werden.

Die Anwendung und die mitgelieferte Marke sind als Projektbeispiel MIT-lizenziert. Das ist eine Lizenz zur Nutzung und Weiterentwicklung, keine Zertifizierung und kein Beleg für Produktionsreife. Für Modelle und andere Drittkomponenten gelten deren jeweilige Lizenzbedingungen.

Offen bleiben insbesondere Last- und Wiederherstellungstests, die Erprobung des GPU-Betriebs und die fachliche Klärung rechtlicher Anforderungen. Die Datenschutzvorlagen benennen unter anderem Rechtsgrundlagen, Auftragsverarbeitung, besondere Datenkategorien und die Frage einer Datenschutz-Folgenabschätzung. Sie entscheiden diese Fragen nicht.

BriefWerk zeigt damit einen konkreten Ansatz für lokal unterstützte Fachkorrespondenz: Informationen ordnen, Belege sichtbar machen und Entwürfe zur verantworteten Prüfung vorlegen. Vor einem Einsatz mit echten Schreiben müssen Organisation, Fachprüfung, Datenschutz und Betrieb gemeinsam geklärt werden.