Lokale oder Cloud-KI für Rechnungsdaten?

„Lokal“ ist nicht automatisch sicher und „Cloud“ nicht automatisch riskant. Für KI mit Rechnungsdaten zählt, wer Daten verarbeitet, welche Informationen das System verlassen, wie Zugriffe kontrolliert werden und ob der Betrieb Updates, Protokolle und Löschung zuverlässig beherrscht. KMU sollten deshalb nicht mit einem Schlagwort entscheiden, sondern den konkreten Rechnungsprozess bewerten.

Eine lokale Lösung kann Daten im eigenen Verantwortungsbereich halten, verlangt aber Hardware, Betrieb, Absicherung und Modellpflege. Ein Cloud-Dienst kann aktuelle Modelle und skalierbare Verarbeitung bieten, schafft dafür zusätzliche Auftragsverarbeitung, Übertragungswege und Abhängigkeiten. Oft ist ein hybrider Ansatz sinnvoll: Vorverarbeitung oder Filter lokal, begrenzte Aufgaben in der Cloud, kritische Freigaben beim Menschen.

Drei Betriebsmodelle im Überblick

Modell	Stärken	Typische Pflichten und Risiken
Lokal oder On-Premises	Direkte technische Kontrolle, Daten können intern bleiben	Patchen, Monitoring, Kapazität, Backup und Modellpflege selbst leisten
Cloud-KI	Schneller Zugang, Skalierung, verwaltete Updates	Anbieter, Verträge, Speicherorte, Protokolle und Unterauftragnehmer prüfen
Hybrid	Datenminimierung mit leistungsfähigen Diensten kombinierbar	Mehr Schnittstellen, klare Trennung und Ende-zu-Ende-Protokollierung nötig

Die Tabelle ist kein Ranking. Ein schlecht gepflegter lokaler Server kann riskanter sein als ein professionell kontrollierter Cloud-Dienst. Umgekehrt ist ein Cloud-Angebot ungeeignet, wenn der Anbieter Inhalte für eigene Zwecke nutzt, Löschung nicht nachvollziehbar ist oder benötigte Vertragsinformationen fehlen.

Mit dem Anwendungsfall beginnen

„KI für Rechnungen“ umfasst sehr verschiedene Aufgaben: Scanverbesserung, Feldextraktion, Kontierungsvorschläge, semantische Suche, Anomaliehinweise oder Formulierung einer internen Zusammenfassung. Für jede Aufgabe unterscheiden sich Datenumfang und Fehlerfolgen. Ein Modell, das nur Bildqualität bewertet, braucht möglicherweise keine vollständigen Lieferanten- und Zahlungsdaten.

Beschreiben Sie Eingabe, Ausgabe und Folgeaktion. Darf die Ausgabe nur einen Vorschlag liefern oder löst sie eine Buchung aus? Welche Felder sind nötig? Wie lange müssen Eingaben, Prompts, Ausgaben und Protokolle gespeichert werden? Erst diese Prozessbeschreibung macht einen sachlichen Architekturvergleich möglich.

Welche Rechnungsdaten wirklich benötigt werden

Datenminimierung ist ein wirksamer Hebel. Für eine Positionsklassifikation können Bankverbindung, Kontaktname oder vollständige Adresse unnötig sein. Für eine Dublettenprüfung sind andere Merkmale erforderlich. Statt immer das gesamte Dokument zu übertragen, sollte der Prozess nur notwendige Felder oder geschwärzte Ausschnitte verwenden, sofern die Aufgabe dadurch zuverlässig lösbar bleibt.

Pseudonymisierung reduziert Risiken, beseitigt den Personenbezug aber nicht zwingend. Lieferanten-IDs können mit internen Daten wieder zugeordnet werden. Deshalb bleiben Zugriff, Zweckbindung und Löschung wichtig. Die österreichische Datenschutzbehörde erläutert in ihren KI-FAQ zentrale datenschutzrechtliche Fragen; der EDPB behandelt Risiken und Minderungsmaßnahmen bei großen Sprachmodellen.

Praxisbeispiel 1: Lokale Vorprüfung im Handwerksbetrieb

Ein Elektrobetrieb erhält viele fotografierte Kleinbelege. Eine lokale Komponente prüft Auflösung, vollständige Ränder und Textschärfe. Nur ausreichend lesbare Bilder gelangen in den weiteren Rechnungseingang. Die Aufgabe benötigt weder Kontodaten noch Lieferantennamen und kann auf einem verwalteten Arbeitsplatz oder internen Dienst laufen.

Für komplexe Extraktion nutzt der Betrieb einen vertraglich geprüften Cloud-Dienst. Vor der Übertragung werden unnötige Metadaten entfernt. Die Ergebnisse lösen keine Zahlung aus, sondern landen mit Konfidenz und Originalbeleg in einer Prüfmaske. Das hybride Modell reduziert Cloud-Daten, ohne dass der Betrieb ein großes Modell selbst betreiben muss.

Praxisbeispiel 2: Lokales Modell mit veralteten Komponenten

Ein Großhändler entscheidet sich aus Vertraulichkeitsgründen für eine vollständig lokale Lösung. Nach dem Pilotbetrieb fehlt jedoch eine klare Betriebsverantwortung. Bibliotheken werden nicht aktualisiert, das Modell wird ohne dokumentierten Test ausgetauscht, und Protokolle wachsen unkontrolliert. Die Daten verlassen zwar nicht das Haus, doch Sicherheits- und Qualitätsrisiken steigen.

Der Betrieb korrigiert den Ansatz mit Patch-Verantwortung, Versionsinventar, beschränkten Dienstkonten, Backup-Konzept und wiederholbarem Testset. Das Beispiel zeigt: Lokaler Betrieb verschiebt Verantwortung zum Unternehmen. Er ist nur dann ein Vorteil, wenn diese Verantwortung personell und technisch getragen wird.

Cloud-Anbieter systematisch prüfen

Wer ist Vertragspartner und wer verarbeitet als Unterauftragnehmer?
In welchen Regionen werden Eingaben, Ausgaben, Protokolle und Backups verarbeitet?
Werden Kundendaten zum Training oder zu anderen eigenen Zwecken verwendet?
Welche Aufbewahrungs- und Löschfristen gelten?
Wie werden Daten bei Supportfällen zugänglich?
Welche technischen und organisatorischen Maßnahmen sind dokumentiert?
Wie werden Modell- oder Produktänderungen angekündigt?
Gibt es Export- und Exit-Möglichkeiten?

Marketingbegriffe wie „EU-Cloud“ beantworten diese Fragen nicht vollständig. Rechenzentrumsstandort, Unternehmenssitz, Fernzugriff und Unterauftragnehmer sind verschiedene Aspekte. Verträge und technische Konfiguration müssen zum tatsächlichen Dienst passen. Individuelle Rechtsprüfung kann bei sensiblen oder umfangreichen Verarbeitungen erforderlich sein.

Lokalen Betrieb realistisch kalkulieren

Neben Hardwarekosten gehören Strom, Redundanz, Monitoring, Updates, Sicherheitsprüfung und Arbeitszeit in die Rechnung. Modelle benötigen Speicher und Rechenleistung; Lastspitzen im Monatsabschluss können Kapazität binden. Ein System, das nur unter Idealbedingungen schnell genug ist, verlagert Aufwand in die Buchhaltung.

Berücksichtigen Sie auch Qualität und Aktualität. Ein kleineres lokales Modell kann für klar begrenzte Extraktion ausreichend sein, bei komplexen Fragen aber mehr Fehler erzeugen. Die Entscheidung sollte durch einen Benchmark mit eigenen Testrechnungen belegt werden, nicht durch allgemeine Modellranglisten.

Sicherheitskontrollen für beide Modelle

Unabhängig vom Ort braucht die Lösung minimale Rechte, getrennte Dienstkonten, verschlüsselte Übertragung, kontrollierte Protokolle und eine nachvollziehbare Löschung. Eingehende Rechnungen sind nicht vertrauenswürdig; eingebetteter Text darf keine Systemanweisungen überschreiben. Werkzeuge und Folgeaktionen müssen auf erlaubte Funktionen begrenzt sein.

Die Claribill-Sicherheitsseite beschreibt öffentlich dokumentierte Schutzprinzipien. Der Beitrag Prompt Injection in Rechnungsworkflows erklärt, warum Dokumenttext als Eingabe und nicht als Anweisung behandelt werden muss. Dieser Artikel behauptet keine lokale oder Cloud-KI-Funktion von Claribill.

Eine Entscheidungsmatrix mit gewichteten Kriterien

Bewerten Sie nicht nur Kosten. Gewichten Sie Vertraulichkeit, Datenminimierung, Qualitätsniveau, Betriebsfähigkeit, Skalierung, Nachvollziehbarkeit, Abhängigkeit und Exit. Ein Kriterium mit hohem Schadenspotenzial kann ein Ausschlusskriterium sein, auch wenn die Gesamtnote gut ausfällt.

Kriterium	Prüffrage	Mögliche Evidenz
Datenkontrolle	Welche Daten verlassen welchen Bereich?	Datenfluss und Konfiguration
Qualität	Wie arbeitet die Lösung mit unserem Belegmix?	Goldstandard und Feldmetriken
Betrieb	Wer patcht, überwacht und reagiert?	Rollen- und Betriebskonzept
Änderungen	Wie werden Updates getestet?	Versionen und Regressionstest
Exit	Wie werden Daten und Protokolle entfernt?	Lösch- und Exportnachweis

Österreich und Deutschland

In beiden Ländern gilt die DSGVO. Bei einem externen Dienst können insbesondere Rollenverteilung, Auftragsverarbeitung, Drittlandbezug, technische Maßnahmen und Betroffenenrechte relevant sein. Die konkrete Bewertung hängt von Daten, Zweck und Dienst ab. Steuerliche Aufbewahrungspflichten bedeuten nicht, dass jeder technische KI-Cache ebenso lange gespeichert werden muss.

Trennen Sie Originalbeleg und temporäre KI-Artefakte. Der Beleg kann aufbewahrungspflichtig sein, während Promptkopien, Zwischendateien oder Debug-Protokolle nach kurzer Frist gelöscht werden sollten. Ein Löschkonzept muss lokale Datenträger, Cloud-Speicher, Backups und Support-Exporte berücksichtigen.

Checkliste vor dem Pilotbetrieb

Verdeckte Datenflüsse sichtbar machen

Die offensichtliche Modellanfrage ist nur ein Teil des Datenflusses. Browser-Erweiterungen, Telemetrie, Fehlerberichte, Content-Delivery-Netze, Supportwerkzeuge und Backups können zusätzliche Kopien erzeugen. Zeichnen Sie deshalb den Weg vom Eingang des Belegs bis zur Löschung aller temporären Artefakte. Für jeden Schritt werden Zweck, Empfänger, Region, Speicherfrist und verantwortliche Rolle festgehalten.

Bei lokalem Betrieb entstehen ebenfalls Nebenpfade: zentrale Protokollserver, Fernwartung, automatische Absturzberichte oder ausgelagerte Backups. Deaktivieren Sie nicht benötigte Diagnoseübertragungen und schwärzen Sie sensible Inhalte in Logs. Ein Fehlerprotokoll sollte Ereignis und technische Kennung enthalten, aber nicht automatisch die komplette Rechnung.

Der Datenfluss muss der tatsächlichen Konfiguration entsprechen. Eine Anbieterbeschreibung kann mehrere Produktvarianten abdecken. Prüfen Sie, welche Einstellungen im eigenen Mandanten aktiv sind und ob Administratoren sie verändern können. Änderungen an Region, Aufbewahrung oder Trainingsnutzung gehören in einen kontrollierten Freigabeprozess.

Ein vierwöchiger Pilot mit klaren Ausstiegspunkten

In Woche eins wird mit einem begrenzten, repräsentativen Belegset ohne automatische Folgeaktionen getestet. Das Team misst Feldgenauigkeit, Warnungen, Antwortzeit und manuelle Prüfminuten. Sicherheits- und Löschtests laufen parallel: Testdaten werden entfernt, Rechte entzogen und Protokolle kontrolliert.

In Woche zwei und drei verarbeitet die Lösung einen abgegrenzten Teil des laufenden Rechnungseingangs. Jede Ausgabe wird fachlich bestätigt. Neue Beleggruppen, ungewöhnliche Beträge und geänderte Bankdaten bleiben ausgeschlossen oder erhalten strengere Prüfung. Abweichungen werden mit Original, Ausgabe, Ursache und Bearbeitungszeit dokumentiert.

Woche vier dient nicht nur der Erfolgspräsentation. Vergleichen Sie tatsächliche Kosten, Prüfaufwand, Fehlerarten und offene Betriebsrisiken mit den vorher definierten Kriterien. Ein Pilot darf mit „nicht geeignet“ oder „nur für Aufgabe A“ enden. Diese begrenzte Entscheidung ist wertvoller als ein breiter Rollout, der auf wenigen überzeugenden Beispielen beruht.

Definieren Sie Ausstiegspunkte vor Beginn: kritischer Datenabfluss, nicht erklärbare Feldfehler, fehlende Löschbarkeit, unklare Vertragslage oder überschrittene Prüfzeit. Dann muss das Team nicht unter Zeitdruck darüber streiten, ob ein Problem ernst genug ist. Die Regel steht bereits fest und kann nachvollziehbar angewendet werden.

Gesamtkosten statt Preis pro Anfrage

Cloud-Kosten werden häufig pro Anfrage oder Datenmenge angegeben, lokale Kosten über Hardware. Beides greift zu kurz. Addieren Sie Einrichtung, Integration, Testdaten, fachliche Prüfung, Monitoring, Sicherheitsarbeit, Ausfallreserve und Exit. Ein günstiges Modell kann teuer werden, wenn jede zweite Rechnung manuell nachbearbeitet werden muss.

Rechnen Sie außerdem mit Änderungen. Cloud-Preise und Produktgrenzen können sich verschieben; lokale Hardware altert und Modelle benötigen neue Ressourcen. Eine Sensitivitätsrechnung mit normaler Last, Monatsabschluss und Wachstum zeigt, ob die Entscheidung auch nach zwölf Monaten tragfähig bleibt.

Aufgabe, Eingaben, Ausgaben und Folgeaktionen beschreiben.
Nicht benötigte Rechnungsfelder entfernen oder maskieren.
Lokale Betriebsverantwortung und Cloud-Vertrag vergleichen.
Unterauftragnehmer, Regionen, Protokolle und Training klären.
Beide Optionen mit identischem Testset prüfen.
Kritische Felder und Ausschlusskriterien definieren.
Rechte, Verschlüsselung und Löschung testen.
Modellupdates nur nach Regressionstest übernehmen.
Manuelle Freigabe für risikoreiche Folgeaktionen behalten.
Exit und Rückgabe oder Löschung der Daten vorbereiten.

Die wichtigsten Takeaways

Lokal, Cloud und Hybrid sind Betriebsformen, keine Sicherheitsurteile. Die passende Wahl entsteht aus dem konkreten Anwendungsfall, dem notwendigen Datenumfang, messbarer Qualität und der Fähigkeit, den Betrieb dauerhaft zu kontrollieren.

Für viele KMU ist ein begrenzter hybrider Pilot pragmatisch: lokal minimieren und prüfen, einen vertraglich kontrollierten Dienst nur für notwendige Verarbeitung nutzen und kritische Entscheidungen beim Menschen belassen. Maßgeblich ist die dokumentierte Gesamtkontrolle, nicht der Standort als Etikett.

FAQ

Ist eine lokale KI immer DSGVO-konform?

Nein. Auch lokal gelten Zweckbindung, Rechte, Sicherheit, Löschung und Transparenz. Der Betriebsort ersetzt keine datenschutzrechtliche Bewertung.

Darf ein Cloud-Dienst Rechnungen zum Training nutzen?

Das hängt von Vertrag, Zweck und Rechtsgrundlage ab. Für betriebliche Rechnungsdaten sollte die Nutzung zu fremden Trainingszwecken nicht stillschweigend akzeptiert werden; Bedingungen und Konfiguration müssen eindeutig sein.

Wann ist Hybrid unnötig kompliziert?

Wenn eine klar begrenzte lokale oder geprüfte Cloud-Lösung alle Anforderungen erfüllt, kann Hybrid zusätzliche Schnittstellen ohne Mehrwert schaffen. Die Matrix sollte auch Komplexität und Betriebskosten berücksichtigen.

Lokal oder Cloud? Wie KMU KI für Rechnungsdaten auswählen