Aus fünf Jahren Geschäftskommunikation eine Firmen-KI bauen

Teil 1: Konzept, Datenschutz und der überraschende Sieger im Anbieter-Vergleich

In jedem Unternehmen liegt das eigentliche Wissen verteilt in E-Mails, Angeboten, Rechnungen und Anhängen — meistens unzugänglich, sobald die Person, die einen bestimmten Vorgang im Kopf hatte, gerade nicht greifbar ist. Bei der MeiLuft-Gruppe haben wir uns dieses Themas in den letzten Wochen systematisch angenommen. Das hier ist die ehrliche Dokumentation, wie wir vorgegangen sind: was wir verworfen haben, warum, was funktioniert und was uns überrascht hat. Insbesondere Datenschutz und Kosten wollen wir transparent darstellen, weil genau dort die meisten Projekte dieser Art schief gehen oder unsauber werden.

Der Beitrag ist als erster Teil einer Serie gedacht. Hier geht es um die Konzeptionsphase und Anbieterwahl. Spätere Teile behandeln die Umsetzung, die ersten Voll-Läufe auf Echtdaten und die Anwendungen, die wir auf der entstehenden Wissensbasis aufsetzen.

Die Ausgangslage

Die MeiLuft-Gruppe besteht aus drei juristischen Personen — der MeiLuft GmbH & Co. KG als Mutter, der MeiLuft Factory UG als operativem Träger und der Kirsten Controlsystems GmbH als jüngerem Zukauf, dessen Marke in die Factory integriert wird. Zwei Geschäftsbereiche: Lüftungstechnik auf der einen Seite, Steuerungstechnik und Prüfstände aus dem Kirsten-Erbe auf der anderen.

Die Kommunikation läuft seit Gründung über ein einziges Postfach. Inzwischen liegen dort knapp 11.500 E-Mails, etwa 5,2 GB inklusive Anhängen, gesammelt über mehr als fünf Jahre — die älteste Nachricht stammt aus dem August 2020. Word-Dokumente, Excel-Tabellen, gescannte PDFs, technische Spezifikationen, Rechnungen, Förderbescheide, Investor-Korrespondenz, Gründer-interne Abstimmungen. Wissen, das sich vermutlich an dutzenden Stellen wiederholt und an noch mehr Stellen einander widerspricht.

Die nahe liegende Idee: „Lass uns das irgendwie durchsuchbar machen.” Die naheliegende Umsetzung wäre ein klassisches RAG-System gewesen — also alle Dokumente in kleine Stücke zerlegen, diese Stücke in einer Vektordatenbank ablegen, und bei jeder Anfrage die ähnlichsten Schnipsel an ein Sprachmodell weiterreichen. Das ist Standard-Vorgehen, und genau deshalb wollten wir es nicht so machen.

Warum klassisches RAG für uns zu plump war

RAG funktioniert gut für bestimmte Fälle — etwa eine technische Dokumentation, bei der man eine konkrete Antwort auf eine konkrete Frage finden will. Es bricht aber an genau den Fragen, die für uns am wertvollsten sind:

• „Was haben wir bei vergleichbaren Prüfstandsprojekten typischerweise berechnet?” — dafür müssen Preise aus zwölf verschiedenen Angeboten verglichen und aggregiert werden, nicht textuell wiedergefunden.
• „Stimmt diese Rechnung unseres Dienstleisters?” — dafür muss man Positionen mit unseren tatsächlich beauftragten Leistungen abgleichen. Beträge, Daten, Referenzen. Präzision, nicht Ähnlichkeit.
• „Wie ist der Status unseres Förderantrags X, und welche Fristen kommen als Nächstes?” — strukturierte Felder mit Zeitbezug, nicht ein bisschen Fließtext.

Klassisches RAG kann all diese Fragen ungefähr beantworten. „Ungefähr” reicht aber nicht, wenn es um Geld geht oder um Förderfristen, die nicht verpasst werden dürfen.

Unsere Schlussfolgerung: Wir brauchen eine echte strukturierte Verarbeitung der Inhalte — eine KI, die jede E-Mail liest, versteht, und das Verstandene in eine ordentliche Datenstruktur überführt. Mit Entitäten, mit Beträgen als Zahlen, mit Daten als Datumsfeldern, mit klaren Status-Werten. So eine Wissensbasis lässt sich präzise abfragen und ehrlich auditieren. Vektorsuche und freie Tags kommen oben drauf, dort wo sie wirklich helfen — als ergänzende Schicht für unscharfe Themen-Suche, nicht als alleiniges Rückgrat.

Konkret bauten wir eine dreischichtige Ablage:

1. Strukturierte Datenbank für alles, wo Präzision zählt: Kunden, Lieferanten, Projekte, Rechnungspositionen, Status-Felder, juristische Zuordnung.
2. Kategorisierte Tags für inhaltliche Themen, die wir vorher nicht alle aufzählen können — mit kontrolliertem Vokabular, damit nicht „Mielke”, „M. Mielke” und „Mielke GmbH” als drei separate Tags entstehen.
3. Markdown-Zusammenfassungen pro E-Mail-Thread als menschenlesbarer Digest und Grundlage für semantische Suche.

Genau diese Verarbeitung ist aber alles andere als trivial. Eine KI dafür einzuspannen kostet — entweder Geld pro API-Aufruf oder Strom für eigene Hardware. Und sie tut das mit unseren sensibelsten Geschäftsdaten. Damit kamen die zwei Fragen, die jedes ähnliche Projekt klären muss, bevor die erste Codezeile geschrieben wird.

Datenschutz, nicht nur als Pflichtübung

Wir verarbeiten in diesem System E-Mails, die personenbezogene Daten Dritter enthalten: Kunden-Kontakte, Investor-Korrespondenz, Lieferantenmails, Anwaltsschriftverkehr. Als Verantwortliche im Sinne der DSGVO haben wir hier konkrete Pflichten, die mit „Datenschutz ist uns wichtig” auf der Webseite nicht abgedeckt sind.

Auftragsverarbeitung verpflichtet

Sobald wir diese Daten an einen externen KI-Dienst schicken — egal ob OpenAI, Anthropic, Google oder Mistral — wird dieser Dienst zum Auftragsverarbeiter. Nach Art. 28 DSGVO muss zwischen uns ein Auftragsverarbeitungsvertrag (AVV, englisch DPA) bestehen, der die Pflichten, Weisungsrechte und Subunternehmer-Ketten regelt. Ohne diesen Vertrag ist die Verarbeitung formal unzulässig — unabhängig davon, was der Anbieter mit den Daten tatsächlich macht.

Wichtig zu wissen: ein AVV gibt es bei den großen KI-Anbietern nur über die Commercial Terms (geschäftliche Nutzungsbedingungen), nicht über die Standard-Abos für Privatpersonen. Ein ChatGPT-Plus- oder Claude-Pro-Account ist für die Verarbeitung von Kundendaten ungeeignet, selbst wenn man dort das Training-Opt-out aktiviert. Das ist eine vertragliche Frage, keine technische — und der Unterschied wird im Ernstfall (Beschwerde, Behördenanfrage) als Erstes geprüft.

Drittlandtransfer: das US-Cloud-Thema

Die meisten KI-Anbieter sind US-Unternehmen. Datenübermittlung in die USA ist seit dem Schrems-II-Urteil nur über sogenannte Standardvertragsklauseln (SCCs) zulässig, plus zusätzliche Schutzmaßnahmen. Das ist praktikabel, aber es bleibt ein Restrisiko durch den US CLOUD Act, unter dem US-Behörden theoretisch Daten von US-Unternehmen weltweit anfordern können. Für die meisten Geschäftsdaten ist das ein akzeptiertes Standardrisiko. Für besonders sensible Bereiche (Investor-Term-Sheets, vertrauliche Mandantenkorrespondenz) wollten wir das aber gar nicht erst auf den Tisch bekommen.

Hier kommt der erste interessante Befund: es macht einen Unterschied, wo der Dienst rechtlich sitzt. Ein in Frankreich ansässiges Unternehmen wie Mistral fällt nicht unter den CLOUD Act und unterliegt französischem Recht und EU-Jurisdiktion. Die Datenverarbeitungs-Infrastruktur kann zwar trotzdem teilweise auf US-Cloud laufen (Microsoft Azure beispielsweise nutzt Mistral als Compute-Partner), aber wenn diese Compute-Kapazitäten in EU-Rechenzentren stehen, ist die Risikolage juristisch deutlich entspannter.

Was wir konkret umsetzen mussten

Vor dem ersten echten Verarbeitungslauf:

• Account auf Commercial-Tarif anlegen, mit Firmendaten der entsprechenden juristischen Person, die das Projekt operativ trägt
• AVV abschließen (bei Mistral wird der über die Annahme der Commercial Terms automatisch Vertragsbestandteil, bei anderen Anbietern braucht es eine separate Aktivierung)
• Subprozessor-Liste prüfen und im Verarbeitungsverzeichnis dokumentieren
• Zero Data Retention aktivieren, sofern verfügbar — dann werden Inputs und Outputs gar nicht erst geloggt
• Verarbeitungsverzeichnis nach Art. 30 DSGVO ergänzen

Das klingt nach Aufwand, ist aber überschaubar, wenn man weiß was man tut. Und es ist die Eintrittskarte, um überhaupt seriös mit KI zu arbeiten, sobald es um echte Geschäftsdaten geht.

Wo wir gerade stehen: Die in diesem Beitrag gezeigten Zahlen stammen aus einer begrenzten Testphase, mit der wir Vorgehen und Pipeline validiert haben. Den produktiven Voll-Lauf über den gesamten E-Mail-Bestand fahren wir bewusst erst, wenn diese datenschutzrechtlichen Grundlagen vollständig abgeschlossen sind — erst die Grundlage, dann die Daten.

Die Kostenfrage — und ein überraschendes Ergebnis

Parallel zur Datenschutzdiskussion haben wir die Kostenoptionen durchgerechnet. Die Bandbreite ist erstaunlich breit, und die Intuition trügt hier oft. Hier ein vereinfachter Vergleich für die einmalige Verarbeitung unserer 11.500 E-Mails:

Zwei (eigentlich drei) Dinge sind hier nicht intuitiv:

Erstens: Frontier-Modelle über professionelle APIs sind erstaunlich günstig geworden. Was vor zwei Jahren noch tausende Euro gekostet hätte, kostet heute den Gegenwert eines guten Abendessens. Insbesondere die Batch-APIs, bei denen man asynchron statt in Echtzeit verarbeitet, geben oft 50 % Rabatt — und für einmalige Großläufe wie unseren ist Echtzeit ohnehin überflüssig.

Zweitens: Mistral fällt aus der Reihe. Nicht nur ist der Anbieter wegen seines französischen Sitzes datenschutzrechtlich der schlankeste Pfad, das Pricing ist auch das attraktivste der Frontier-Klasse — und das, ohne in der Modellqualität nennenswert hinter den US-Wettbewerbern zurückzuliegen. Mistral Large 3 ist bei der strukturierten Datenextraktion, die wir brauchten, völlig auf Augenhöhe mit GPT-5 und Claude Sonnet. Wer das mit eigenen Daten getestet hat, weiß, dass die Benchmark-Unterschiede in der Praxis kleiner sind als Marketing-Materialien suggerieren.

Auch nicht ganz intuitiv: Mistral Large ist bei diesem Anbieter aktuell günstiger als Mistral Medium. Letzteres ist auf agentische Enterprise-Use-Cases positioniert, mit denen wir nichts zu tun haben. Für reine strukturierte Extraktion ist Large das Preis-Leistungs-Optimum.

Drittens: Eigene Hardware lohnt sich nicht für einmalige Verarbeitungsprojekte. Eine 5.000-Euro-Investition für einen Job, den die API für 15 Euro erledigt, rechnet sich erst, wenn die Maschine danach kontinuierlich für vergleichbare Aufgaben weiterläuft — und selbst dann muss man Strom, Wartung, Ersatzteile und vor allem die Halbwertszeit der Hardware gegenrechnen. Die Faustregel, die wir für uns abgeleitet haben: Eigene Hardware ist sinnvoll, wenn entweder Daten unter keinen Umständen das eigene Netz verlassen dürfen, oder wenn die Auslastung dauerhaft hoch genug ist, dass man die Anschaffungskosten innerhalb von ein bis zwei Jahren über eingesparte API-Kosten amortisiert. Für ein Backfill-Projekt wie unseres trifft beides nicht zu.

Lokale Modelle — ein Experiment, das aufschlussreich gescheitert ist

Bevor wir uns endgültig auf den Cloud-Pfad festgelegt haben, wollten wir quantifizieren, was mit eigener Infrastruktur heute realistisch erreichbar ist — auch um die Mischung zu kennen, falls für Folgeprojekte andere Konstellationen sinnvoll wären. Auf einem unserer Rackserver standen 8 GB GPU und 128 GB RAM zur Verfügung, und die aktuelle Generation kleiner Open-Source-Modelle (Gemma 4 E4B, Qwen 3.5 4B und 9B) ist auf ein Niveau gekommen, das vor wenigen Quartalen noch Modellen mit mehrfacher Größe vorbehalten war.

Wir haben ein systematisches Testprogramm gebaut, das 130 unserer realen E-Mails durch jedes der drei Modelle laufen lässt und die Ergebnisse vergleicht. Was wir gelernt haben:

• Für reine Klassifikation reichen die kleinen Modelle erstaunlich weit. Eine E-Mail in eine von neun Kategorien einzusortieren bekommen sie zu 80–90 % richtig hin.
• Für komplexere Aufgaben fehlt es an Capability. Wenn eine E-Mail inhaltlich zwei Themen berührt (etwa eine interne Mail über einen Förderantrag), erkennt ein 4-Milliarden-Parameter-Modell das nicht zuverlässig — es wählt nur eine Kategorie. Mistral Large, ein deutlich größeres Modell, erkennt solche Mischfälle bei rund 12 % der Mails. Das ist nicht Prompt-Tuning-Sache, das ist eine harte Kapazitätsgrenze.
• Geschwindigkeit ist ein Problem. Auf unserer 8-GB-Karte schaffte das schnellste Modell etwa eine E-Mail in 13 Sekunden. Hochgerechnet auf 11.500 E-Mails sind das 40 Stunden reine Rechenzeit, verteilt auf einen Server, der ja eigentlich noch andere Aufgaben hat.
• Modell-Größe versus VRAM ist ein Optimierungsproblem für sich. Ein 9B-Modell passt knapp auf 8 GB — aber jeder zusätzliche Token KV-Cache, jede Kontextverlängerung, jeder parallele Request kann zum Engpass werden. Das frisst Iterations-Zeit, die für die eigentliche Aufgabe verloren ist.

Die Lehre: Lokale Modelle haben ihren Platz, vor allem wenn Daten unter keinen Umständen das eigene Netz verlassen dürfen. Für unseren Fall — Geschäftsdaten mit ordentlichem AVV, EU-hosted, gute Verschlüsselung — ist die Cloud-Verarbeitung sowohl billiger als auch qualitativ besser. Und sie ist schneller fertig, was bei einem Projekt mit Iterationsschleifen erheblich ins Gewicht fällt.

Die endgültige Architektur

Nach all den Vergleichen und Tests sieht die Architektur jetzt so aus:

• Mistral Large 3 als Hauptmodell, über die Batch-API mit Zero Data Retention.
• Mistral OCR für gescannte Anhänge — ein spezialisierter Dienst, der gescannte PDFs und Bilder in strukturierten Markdown-Text umwandelt, deutlich präziser als generische Vision-Modelle.
• Lokale Office-Parser für Word-, Excel- und Text-PDFs — diese werden ohnehin nicht über die KI verschickt, sondern direkt in Text umgewandelt und mit der zugehörigen E-Mail an die Hauptverarbeitung gereicht.
• Vereinte Pipeline statt Zwei-Stufen-Verarbeitung. Ursprünglich war geplant, erst leichtgewichtig zu klassifizieren und dann nur die „wichtigen” E-Mails ausführlich zu extrahieren. Mit Mistral Large in der Batch-API ist die Kosteneinsparung dieser Vorsortierung minimal, dafür entfällt das Risiko, dass eine wichtige Mail in der ersten Stufe fälschlich aussortiert wird.

Jede E-Mail bekommt am Ende:

1. Eine Klassifikation (Domäne, juristische Person, Geschäftsbereich, Hauptpartei, Confidence-Wert)
2. Bei relevanten Mails eine strukturierte Extraktion (Daten, Beträge, Aktionspunkte, Dokumentenreferenzen, plus domain-spezifische Felder — etwa Rechnungspositionen bei Kundenmails oder Programm und Status bei Fördermails)
3. Eine Markdown-Zusammenfassung für menschliche Augen
4. Tag-Vorschläge aus einem kontrollierten Vokabular, plus Neuvorschläge für eine spätere Kuratierungsrunde

Das alles in einem einzigen API-Aufruf pro Thread. Die Antwort ist ein einziges JSON-Dokument, das in der Datenbank, im Markdown-Archiv und im Tag-Index abgelegt wird.

Die Zahlen, die uns überzeugt haben

Am Ende unserer Test-Phase haben wir 130 echte E-Mails als repräsentatives Sample durch die finale Pipeline laufen lassen:

• 130 von 130 E-Mails sauber verarbeitet, keine Parse-Fehler im strukturierten Output.
• 91 Sekunden Wall-Clock-Zeit für den gesamten Batch, inklusive Upload, Warteschlange, Verarbeitung und Download.
• 0,16 Dollar Kosten für diesen Testlauf.
• Hochrechnung auf alle 11.500 E-Mails: etwa 13 bis 15 Dollar für den gesamten Korpus.

Diese Zahlen sind das, was uns endgültig zur jetzigen Architektur überzeugt hat. Vor zwei Jahren hätte ein vergleichbarer Lauf wahrscheinlich vierstellige Beträge gekostet und Tage gedauert. Heute kostet er weniger als ein gemeinsames Mittagessen und ist über die Mittagspause durchgerechnet.

Wichtiger noch als die Zahlen: Wir können iterieren. Wenn wir an den Klassifikationsregeln oder am Extraktionsschema noch etwas verfeinern wollen, kostet uns ein erneuter Voll-Lauf wiederum 15 Dollar und eine Stunde Wartezeit. Diese Iterations-Ökonomie ist es, die ein Projekt dieser Art überhaupt erst zu einem laufenden, weiterentwickelbaren System macht — statt zu einem einmaligen, sofort veraltenden Datenexport.

Was als nächstes kommt

In Teil 2 schauen wir auf die Engineering-Seite: wie das System konkret gebaut wurde, welche Rolle agentic coding und unsere eigene Engineering-Plattform XaresAICoder dabei gespielt haben, und welche Anforderungen ein produktiv genutztes KI-System an Architektur, Code-Qualität und Testbarkeit stellt — Anforderungen, die in vielen „Schnell mal was zusammengebaut”-Projekten unterschätzt werden.

In Teil 3 berichten wir vom ersten Voll-Lauf auf allen 11.500 E-Mails: welche Überraschungen die Realität für unsere Schema-Annahmen bereithält, wie wir mit gescannten Anhängen aus 2018 umgehen, und wie die ersten echten Auswertungen auf der entstehenden Wissensbasis aussehen.

In Teil 4 schauen wir uns an, was wir auf dieser Basis bauen können: ein internes Abfrage-Werkzeug, das uns Antworten auf Fragen wie „Was haben wir bei vergleichbaren Projekten kalkuliert?” oder „Welche Förderfristen kommen in den nächsten 30 Tagen?” liefert — und perspektivisch auch ein Kunden-orientiertes Werkzeug, mit dem unsere Kunden auf das ihnen zustehende Wissen selbst zugreifen können.

Beobachtungen, die für vergleichbare Projekte hilfreich sein dürften

Falls Sie selbst gerade an einem vergleichbaren Vorhaben sitzen oder es planen, sind dies die Punkte, die für unsere Entscheidungen am ehesten den Ausschlag gegeben haben:

Beginnen Sie nicht mit der KI, sondern mit der Frage, was Sie eigentlich beantworten wollen. „Wir bauen einen Chatbot” ist eine Lösung auf der Suche nach einem Problem. „Wir wollen Rechnungen unserer Dienstleister automatisch gegen unsere Aufträge prüfen können” ist eine konkrete Fragestellung, aus der sich eine konkrete Architektur ableitet.

Datenschutz ist keine Hürde, sondern eine Entscheidungshilfe. Sobald Sie wissen, welche Compliance-Anforderungen Sie haben, fällt die Anbieterwahl deutlich leichter. Und es gibt erstaunlich saubere EU-Optionen, wenn man bereit ist, kurz zu recherchieren.

Frontier-Modelle sind günstiger geworden, als die meisten denken. Wenn Sie das letzte Mal vor 18 Monaten Kosten kalkuliert haben, lohnt sich ein erneuter Blick. Was damals unbezahlbar wirkte, ist heute oft im niedrigen zweistelligen Euro-Bereich.

Vergleichen Sie nicht Marketingmaterial, sondern reale Outputs. Wir haben mit allen relevanten Anbietern dieselben echten E-Mails gegen dieselben Prompts laufen lassen. Die Unterschiede zwischen den Anbietern in dieser konkreten Aufgabe waren oft kleiner als die Unterschiede zwischen verschiedenen Prompt-Versionen bei demselben Anbieter.

Sparen Sie nicht an der Vorarbeit zum Schema. Die Frage „Welche Felder soll ein verarbeitetes Dokument haben?” klingt langweilig, ist aber die wichtigste Entscheidung des gesamten Projekts. Sie entscheidet, was Sie später abfragen können — und was nicht.

Wir freuen uns darauf, den ersten echten Voll-Lauf zu fahren, sobald die datenschutzrechtlichen Grundlagen vollständig stehen — und Ihnen dann davon zu berichten.

Bei Fragen zum Projekt sprechen Sie uns gerne an — gerne auch dann, wenn Sie selbst an einem vergleichbaren Vorhaben sitzen. Solche Projekte begleiten wir auch für andere Unternehmen.