In vielen KMU sieht der Ablauf gleich aus: Eine Bestellung, eine Anfrage oder eine Adressänderung kommt per E-Mail. Jemand liest sie, sucht den Kunden in Bexio, tippt Positionen ab, legt einen Auftrag an und erstellt vielleicht noch ein Ticket. Das ist Routine, kostet aber Zeit und ist fehleranfällig.
Ein Sprachmodell kann hier viel abnehmen. Aber nur, wenn es in einen Prozess eingebettet ist, der Fehler auffängt. Der folgende Aufbau ist eine illustrative Beispielarchitektur, keine Beschreibung eines bestimmten Kundenprojekts. Er zeigt die Bausteine, die sich in solchen Vorhaben bewährt haben.
Die Beispielarchitektur im Überblick
Das Beispiel: Ein Handelsunternehmen erhält Bestellungen von Geschäftskunden per E-Mail an bestellungen@, teils im Mailtext, teils als PDF. Ziel ist ein Auftragsentwurf in Bexio, den eine Person nur noch prüft und freigibt.
- Eingang: Mails im Postfach in Exchange Online.
- Abholen: Ein Dienst liest neue Mails über Microsoft Graph.
- Klassifizieren und extrahieren: Ein Sprachmodell bestimmt den Typ der Mail und liefert strukturierte Daten nach einem festen JSON-Schema.
- Validieren: Regeln im Code prüfen die extrahierten Daten gegen Bexio und gegen Plausibilitätsregeln.
- Freigeben: Eine Person sieht Original und Vorschlag nebeneinander, korrigiert und gibt frei.
- Anlegen: Über die Bexio-REST-API entstehen Kontakt und Auftragsentwurf.
- Nachverfolgen: Ein Ticket dokumentiert den Vorgang, Erinnerungen greifen, wenn etwas liegen bleibt.
- Auswerten: Ein einfaches Reporting zeigt Durchlaufzeiten, Korrekturquoten und offene Fälle.
Eingang und Extraktion: Graph und ein festes Schema
Der Dienst meldet sich als App-Registrierung mit Zertifikat an Microsoft Graph an. Die Berechtigung zum Lesen von Mails wird über RBAC for Applications in Exchange Online auf das eine Bestellpostfach beschränkt, nicht tenantweit vergeben. Neue Mails erkennt der Dienst über Änderungsbenachrichtigungen (Webhooks) oder durch regelmässiges Abfragen mit Delta-Abfragen. Anhänge werden über Graph geladen, PDFs bei Bedarf in Text umgewandelt.
Das Sprachmodell erhält Mailtext und Anhangsinhalt und muss in einem fest definierten Format antworten. Moderne Modelle und APIs unterstützen strukturierte Ausgaben, die an ein JSON-Schema gebunden sind. Ein vereinfachtes Beispiel:
{
"type": "object",
"required": ["mail_type", "customer", "items"],
"properties": {
"mail_type": { "enum": ["bestellung", "anfrage", "reklamation", "sonstiges"] },
"customer": {
"type": "object",
"properties": {
"company": { "type": "string" },
"customer_number": { "type": ["string", "null"] },
"uid": { "type": ["string", "null"] }
}
},
"items": {
"type": "array",
"items": {
"type": "object",
"required": ["description", "quantity"],
"properties": {
"article_number": { "type": ["string", "null"] },
"description": { "type": "string" },
"quantity": { "type": "number" }
}
}
},
"requested_delivery_date": { "type": ["string", "null"], "format": "date" },
"uncertain_fields": { "type": "array", "items": { "type": "string" } }
}
}Wichtig sind zwei Details: Felder dürfen null sein, damit das Modell nichts erfinden muss, wenn eine Angabe fehlt. Und das Modell meldet in uncertain_fields, wo es unsicher ist. Preise extrahieren wir bewusst nicht. Sie kommen aus Bexio, nicht aus der Mail.
Wo KI zuverlässig ist und wo nicht
Sprachmodelle sind stark darin, unstrukturierten Text zu verstehen: eine Bestellung zu erkennen, auch wenn sie in einem langen Mailverlauf steckt, Positionen aus Fliesstext herauszulösen, Firmennamen und Adressen zuzuordnen. Schwach sind sie bei allem, was exakt sein muss oder externes Wissen voraussetzt:
- Zahlen und Summen: Mengen werden meist richtig gelesen, Berechnungen gehören aber in den Code.
- Stammdaten: Das Modell weiss nicht, welche Artikelnummern es in Ihrem Bexio gibt. Es kann plausible, aber falsche Nummern liefern.
- Mehrdeutigkeit: «Wie letztes Mal» oder «das Übliche» kann das Modell nicht auflösen.
- Selbsteinschätzung: Die vom Modell gemeldete Unsicherheit ist ein Hinweis, keine verlässliche Wahrscheinlichkeit.
Deshalb folgt auf die Extraktion eine Validierung mit festen Regeln: Gibt es den Kunden in Bexio, per Kundennummer, UID oder exaktem Namensabgleich? Existiert jede Artikelnummer? Sind die Mengen positiv und plausibel? Ist das Lieferdatum in der Zukunft? Jede Regel, die fehlschlägt, wird im Freigabe-Dialog sichtbar markiert.
Tipp: Kombinieren Sie mehrere Signale zu einem Konfidenzwert: Schema gültig, alle Validierungen bestanden, keine unsicheren Felder, Kunde eindeutig gefunden. Nur wenn alle Signale grün sind, gilt ein Vorgang als «hohe Konfidenz». Den Schwellenwert legen Sie anhand der Pilotdaten fest, nicht vorher.
Human-in-the-Loop, Bexio und Audit Trail
Die Freigabeoberfläche ist der wichtigste Teil des Systems. Sie zeigt links die Originalmail, rechts den Vorschlag mit allen Feldern, markiert Validierungsfehler und unsichere Felder und lässt jede Angabe korrigieren. Erst nach der Freigabe spricht der Dienst mit Bexio.
Die Bexio-REST-API bietet Zugriff auf Kontakte, Artikel, Aufträge und Rechnungen. Der Dienst sucht oder erstellt den Kontakt, legt einen Auftrag als Entwurf mit den Positionen an und hinterlegt eine Referenz auf die ursprüngliche Mail. Rechnungen entstehen nicht automatisch, sondern im bestehenden Ablauf aus dem Auftrag. Die Authentifizierung erfolgt über das von Bexio vorgesehene Verfahren, die Zugangsdaten liegen in einem Secret Store, nicht im Code.
Danach legt der Dienst ein Ticket im eingesetzten Ticketsystem an oder aktualisiert es und plant Erinnerungen: etwa wenn ein Vorgang länger als einen Tag auf Freigabe wartet oder wenn der Auftrag nach einer definierten Frist nicht bestätigt wurde.
Jeder Schritt wird protokolliert: welche Mail, welche Modellversion und welcher Prompt, welche Ausgabe, welche Validierungen, wer was korrigiert und freigegeben hat, welche Objekte in Bexio entstanden sind. Dieser Audit Trail ist nicht nur für Fehleranalysen nötig. Die Korrekturen sind auch die beste Grundlage, um Prompt und Regeln zu verbessern.
Achtung: Lassen Sie ein Modell nie direkt und ohne Freigabe schreibend auf Buchhaltungs- oder ERP-Daten zugreifen. Auch bei hoher Konfidenz sollte der Weg in Bexio über Entwürfe laufen, solange die Fehlerquote nicht über längere Zeit belegt ist.
Datenschutz, Modellwahl und Kosten pro Dokument
Bestellmails enthalten Personendaten und Geschäftsinformationen. Für die Architektur heisst das:
- Hosting: Wählen Sie Anbieter und Regionen in der Schweiz oder der EU, prüfen Sie die Vertragsbedingungen zur Datenbearbeitung und stellen Sie sicher, dass Ihre Daten nicht zum Training verwendet werden. Grundlage ist das revidierte Datenschutzgesetz (DSG).
- Datenminimierung: Signaturen, Disclaimer und ältere Teile des Mailverlaufs vor dem Modellaufruf entfernen. Das Modell braucht nur, was es für die Extraktion benötigt.
- Modellwahl: Für Klassifikation und Extraktion reichen oft kleinere Modelle. Lokale Modelle auf eigener Infrastruktur sind eine Option, wenn Daten das Haus nicht verlassen dürfen. Sie verlangen aber Hardware, Betrieb und eigene Tests der Qualität.
- Aufbewahrung: Protokolle mit Mailinhalt nur so lange speichern, wie es für Nachvollziehbarkeit und Aufbewahrungspflichten nötig ist.
Die Kosten pro Dokument sind eine Designgrösse, kein Nebenaspekt. Sie hängen von der Textmenge, der Anzahl Modellaufrufe, der Modellgrösse und der Verarbeitung von Anhängen ab. Messen Sie im Pilot die tatsächlichen Kosten pro Vorgang und stellen Sie sie der eingesparten Bearbeitungszeit gegenüber. Oft lohnt sich eine Vorfilterung mit einfachen Regeln, damit Newsletter und Abwesenheitsnotizen gar nicht erst beim Modell landen.
Klein anfangen: ein Mailtyp, eine Woche Pilot
Der häufigste Fehler ist, gleich alle Mailtypen automatisieren zu wollen. Besser:
- Einen Mailtyp wählen: häufig, klar abgrenzbar, mit eindeutigem Zielobjekt in Bexio. Bestellungen von Stammkunden sind ein guter Kandidat.
- Beispiele sammeln: Einige Dutzend echte, anonymisierte Mails als Testsatz, inklusive schwieriger Fälle.
- Schattenbetrieb: Eine Woche lang läuft das System parallel. Die Mitarbeitenden arbeiten wie bisher, das System erzeugt nur Vorschläge, die verglichen werden.
- Auswerten: Wie oft war der Vorschlag ohne Korrektur richtig? Welche Felder werden am häufigsten korrigiert? Was hat die Validierung abgefangen?
- Entscheiden: Erst dann in den Freigabebetrieb wechseln und den nächsten Mailtyp angehen.
Checkliste
- Postfachzugriff über Graph mit Zertifikat, auf ein Postfach beschränkt
- Strukturierte Ausgabe mit JSON-Schema, fehlende Angaben als
null - Validierung gegen Bexio-Stammdaten im Code, nicht im Prompt
- Freigabeoberfläche mit Original und Vorschlag nebeneinander
- Bexio-Objekte als Entwürfe, Zugangsdaten im Secret Store
- Vollständiger Audit Trail inklusive Modellversion und Korrekturen
- Hosting, Datenminimierung und Modellwahl dokumentiert
- Kosten pro Vorgang im Pilot gemessen
KI ist in diesem Prozess ein Baustein, kein Ersatz für saubere Integration. Der Nutzen entsteht dort, wo Sprachverständnis, feste Regeln und menschliche Freigabe zusammenspielen.
Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.
Kontakt aufnehmen