Unter der Haube lässt sich eine gut konzipierte massgeschneiderte Lösung fast immer auf vier Bausteine zurückführen: eine schlanke Oberfläche, eine Engine – ein KI-Modell, das je nach Sensibilität der Daten lokal ausgeführt oder per API aufgerufen wird –, eine einfache Datenbank und optional ein Konversationsagent, der das Ganze in natürlicher Sprache befragt. FiscalDoc, die Anwendung, die ich für die Verwaltung meiner eigenen Steuerunterlagen gebaut habe, zeigt dieses Muster in seiner schlankesten Form. Im Folgenden wird diese Architektur verallgemeinert und ehrlich erklärt, was sie wachsen lässt.
Welche vier Komponenten kehren fast immer wieder?
Der erste Baustein ist die Oberfläche: die Schnittstelle, über die ein Nutzer eine Information einreicht oder ein Ergebnis liest. Bei FiscalDoc ist das ein einfaches Webformular – ich lade ein PDF oder ein Foto hoch, und das Tool erledigt den Rest. In dieser Grössenordnung rechtfertigt nichts ein schweres Frontend-Framework oder eine native mobile App: Ein sauberes Formular, eine filterbare Tabelle und ein paar Schaltflächen reichen für fast alle internen Anwendungsfälle eines KMU. Visuelle Raffinesse wird vor allem dann wichtig, wenn Personen ausserhalb des Unternehmens das Tool nutzen – das verändert die Lage, worauf ich weiter unten zurückkomme.
Der zweite Baustein, die Engine, ist die Entscheidung, die alles Weitere strukturiert. Ein offenes, lokal ausgeführtes KI-Modell drängt sich auf, wenn keine Daten das Unternehmen verlassen dürfen – das ist die Wahl, die ich für FiscalDoc getroffen habe: ein offenes Modell, das auf meinem eigenen Mac läuft, ohne einen einzigen Netzwerkaufruf für den Kern der Verarbeitung. Ein API-Aufruf an ein proprietäres Modell bleibt umgekehrt völlig vertretbar, wenn die verarbeiteten Daten wenig sensibel sind und die Umsetzungsgeschwindigkeit Priorität hat. Zwischen beiden gibt es keine universelle Antwort, sondern nur eine für jeden Anwendungsfall spezifische Abwägung, die ich in Gut gebautes KI-Projekt: die drei tragfähigen Muster ausführe – der Direktaufruf, RAG und Agenten werden dort als die drei Muster dargestellt, die den Grossteil der Projekte abdecken, unabhängig von der Wahl zwischen lokal und API.
Der dritte Baustein, die Datenbank, überrascht oft durch ihre Bescheidenheit. FiscalDoc indexiert mehrere Hundert Dokumente pro Jahr in einer lokalen SQLite-Datenbank – einer Datei, keinem Server. Für eine Nutzung, die auf eine Handvoll Anwender und einige Tausend Einträge begrenzt ist, leistet eine einfache Datenbank das, was man für eine schwere Infrastruktur reserviert glaubt. Der Wechsel zu einem robusteren System – gehostete Datenbank, Replikation, automatisierte Backups – wird erst nötig, sobald mehrere Personen gleichzeitig schreiben oder das Volumen übersteigt, was eine einzelne Maschine komfortabel bewältigt.
Der vierte Baustein ist optional, und das ist wichtig, klar zu sagen: ein Konversationsagent, der die Datenbank und die Dokumente in natürlicher Sprache befragt. Bei FiscalDoc kann ich verlangen, alle MCVA-Rechnungen über 2'000 CHF im letzten Quartal zu finden, und erhalte eine spontan erstellte Antwort. Diese Schicht bringt echten Komfort, ist aber nie das Erste, was man bauen sollte: Ein filterbares Dashboard deckt bereits den Grossteil der Suchbedürfnisse ab, und der Konversationsagent rechtfertigt seine Entwicklungskosten erst, wenn die gestellten Fragen wirklich vielfältig und unvorhersehbar sind.
Wo sollen diese vier Bausteine gehostet werden?
Die Wahl des Hostings folgt unmittelbar der Wahl der Engine, nicht umgekehrt. Ein lokaler Rechner – ein Arbeitsplatz mit ausreichend Arbeitsspeicher – genügt für die individuelle Nutzung oder ein kleines Team, mit einem offenen Modell, das für den Kern der Verarbeitung nie eine Internetverbindung herstellt. Eine Schweizer oder europäische Infrastruktur wird relevant, sobald mehrere Nutzer von unterschiedlichen Arbeitsplätzen aus auf dasselbe Tool zugreifen müssen, ohne die Daten dennoch einer Cloud ausserhalb der eigenen Rechtsordnung anvertrauen zu wollen. Eine Anbieter-Cloud mit vertraglichen Nichtaufbewahrungs-Verpflichtungen bleibt eine vernünftige Option für die am wenigsten sensiblen Daten, wenn die Umsetzungsgeschwindigkeit mehr zählt als die vollständige Kontrolle über den Ausführungsort. Dieses dreistufige Raster – vertragliche Verpflichtungen, Schweizer oder europäisches Hosting, offenes Modell auf kontrollierter Infrastruktur – habe ich in dem Artikel zur Architektur von KI-Projekten dargelegt, und ich greife es bei jeder Rahmung einer massgeschneiderten Lösung wieder auf.
Warum reichen oft wenige hundert Codezeilen?
FiscalDoc passt in einen Ordner mit wenigen hundert Codezeilen. Das ist keine Meisterleistung, sondern die direkte Folge eines bewusst eng gehaltenen Umfangs. Ein Tool, das einem Nutzer oder einem kleinen Team dient und eine präzise, klar beschriebene Funktion erfüllt, muss weder Tausende gleichzeitige Verbindungen bewältigen noch Fälle vorwegnehmen, die nie eintreten werden. Die lohnendste Disziplin bei dieser Art von Projekt besteht darin, der Versuchung zu widerstehen, für einen hypothetischen Gebrauch zu bauen statt für den tatsächlichen, zu Beginn formulierten Bedarf.
Was sich in achtzehn Monaten ebenfalls verändert hat, sind die Produktionskosten selbst. Ich habe FiscalDoc nicht Zeile für Zeile geschrieben: Ich habe es Abend für Abend im Dialog mit einem Code-Assistenten entwickelt, bis ich ein Tool erhielt, das zu mir passt – diese Methode habe ich in meinem Erfahrungsbericht zur assistierten Entwicklung ausführlich beschrieben. Was ich im Massstab eines Einzelbüros zeige, erlaubt dieselbe Logik, Funktion für Funktion, auch für umfassendere KMU-Bedürfnisse. Der vollständige Fall – Kosten, Abwägungen, Grenzen – ist dokumentiert in FiscalDoc: 1'400 CHF/Jahr SaaS-Kosten durch eine lokale KI ersetzen.
Was lässt ein Projekt wachsen?
Bisher habe ich öffentlich nur einen einzigen vollständigen, nach diesem Muster gebauten Fall dokumentiert – FiscalDoc. Doch seine Architektur ist keineswegs zufällig: Sie entspricht dem, was übrig bleibt, wenn man das Überflüssige entfernt, und sie verändert sich, sobald sich eine der folgenden drei Bedingungen ändert.
- Die Integrationen. Die Verbindung des Tools mit einem bestehenden Buchhaltungssystem, einem ERP oder einer geschäftlichen Mailbox vervielfacht die Fehlerquellen: Jede Integration bringt ihren eigenen Schnittstellenvertrag, ihre eigene Fehlerbehandlung und ihre eigene laufende Wartung mit sich.
- Mehrere Nutzer. Sobald mehrere Personen mit unterschiedlichen Rechten auf dasselbe Tool zugreifen müssen, braucht es eine echte Authentifizierung, eine Rollenverwaltung und oft eine Nachverfolgung, wer was getan hat – ein eigenständiges Vorhaben, das sich von der eigentlichen Fachlogik unterscheidet.
- Die Compliance. Ein Tool, das Daten Dritter berührt – Kunden, Mitarbeitende – zieht über die reine Hosting-Wahl hinaus das DSG (Datenschutzgesetz) nach sich: Verarbeitungsverzeichnis, Auftragsverarbeitungsvertrag, falls ein externer Baustein genutzt wird, Aufbewahrungsrichtlinie. Dieses Thema gehört in die Rahmung geklärt, nicht unterwegs entdeckt.
Keiner dieser drei Auslöser spricht gegen massgeschneiderte Lösungen. Sie verändern deren Budget und Sorgfaltsanforderungen, nicht deren Sinnhaftigkeit. Was sie hingegen widerlegen, ist die Vorstellung, ein solches Projekt lasse sich stets an ein paar Abenden erledigen: Ist diese Schwelle überschritten, verdient die Rahmung dieselbe Sorgfalt wie ein SaaS-Projekt vergleichbaren Umfangs – genau das lege ich zu Beginn jeder massgeschneiderten Lösung fest. Diese Anatomie ist nur ein Baustein unter anderen: Die übergreifende Roadmap wird dargelegt in Was muss ein Schweizer KMU 2026 im Umgang mit KI tun?
Wichtig in Kürze
— Eine massgeschneiderte Lösung lässt sich fast immer auf vier Bausteine zurückführen: schlanke Oberfläche, je nach Datensensibilität gewählte Engine, einfache Datenbank, optionaler Konversationsagent. — Das Hosting folgt der Wahl der Engine: lokaler Arbeitsplatz, Schweizer oder europäische Infrastruktur, oder Anbieter-Cloud unter vertraglichen Verpflichtungen. — Drei Auslöser lassen ein Projekt wachsen: Integrationen, mehrere Nutzer, Compliance – sie verändern das Budget, nicht die Sinnhaftigkeit der massgeschneiderten Lösung.
FAQ
Sollte man immer ein lokales KI-Modell einer API vorziehen? Nein. Lokal ist geboten, wenn keine Daten das Unternehmen verlassen dürfen; die API bleibt bei wenig sensiblen Daten oft schneller umzusetzen. Es handelt sich um eine fallbezogene Abwägung, kein absolutes Prinzip.
Kann ein KMU ohne internes technisches Know-how diese Art von Tool in Betracht ziehen? Ja, sofern eine kompetente Drittperson den Dialog mit dem Code-Assistenten führt und das Ergebnis überprüft. Das Liefergut – Code und Daten – gehört dann vollständig dem Unternehmen, was der zentrale Vorteil dieses Ansatzes bleibt.
Wie lange dauert ein Projekt dieser Art? Das hängt vollständig vom Umfang ab: wenige Abende für einen so eng begrenzten Bedarf wie FiscalDoc, mehrere Wochen, sobald Integrationen oder mehrere Nutzer ins Spiel kommen. Eine allgemeine Zahl wäre ohne vorherige Rahmung nicht ehrlich.
Ist eine so einfache Datenbank wie eine lokale SQLite-Datenbank für ein KMU wirklich zuverlässig? Für die Nutzung durch einen oder wenige Anwender und Volumen von einigen Tausend Einträgen: ja, durchaus. Sie stösst an ihre Grenzen, sobald mehrere Personen gleichzeitig schreiben oder das Volumen übersteigt, was eine einzelne Maschine komfortabel bewältigt – genau das Signal, das einen Massstabswechsel ankündigt.
Und in Ihrem Unternehmen? Die KI-Nutzungsdiagnose: sechzig Minuten, um Ihre tatsächlichen Abläufe zu erfassen, zu identifizieren, was eine massgeschneiderte Lösung verdient, was als SaaS bestehen bleibt und was gar keine KI braucht. Diagnose buchen
Jérôme Deshaie ist CEO und Gründer von MCVA Consulting SA, einer augmentierten Agentur mit Sitz im Wallis. Fünfzehn Jahre im Dienst grosser internationaler Marken, jetzt direkt im Einsatz für Schweizer KMU. Werdegang.