Aus einem echten Problem entstanden.Gebaut für die härtesten Fälle.
MiruIQ wurde nicht im Labor entworfen. Es entstand aus einem realen Enterprise-Bedarf, mit nicht verhandelbaren Sicherheitsanforderungen und komplexen Dokumenten als Normalfall.
Eine Schweizer Kreditbank brauchte mehr als OCR
Innerhalb der Acosom GmbH betreuten wir eine Kreditbank, für die wir bereits den Kreditantrags-Arbeitsplatz und die Kundenportale gebaut hatten. Dann drehte sich das Gespräch um den nächsten Schritt.
Der Kunde wollte den Dokumentenabgleich automatisieren, den seine Teams noch manuell durchführten. Bei einem typischen Kreditantrag laden Kundinnen und Kunden mehrere Dokumente hoch: Lohnabrechnungen, Ausweise, Arbeitsverträge, Steuererklärungen und mehr. Die Bank musste diese Dokumente gegeneinander prüfen: Ist der Name in allen Uploads identisch? Stimmt der Arbeitgeber überein? Sind die Berechnungen auf einer Lohnabrechnung mathematisch korrekt, oder deuten sie auf offensichtliche Fälschungen hin?
Das war keine einfache Extraktionsaufgabe. Es brauchte semantisches Verständnis über mehrere Dokumenttypen hinweg, mit Validierungslogik weit jenseits eines simplen Feldabgleichs.
Und dann waren da die Sicherheitsanforderungen. Als Schweizer Finanzinstitut mit vollständigem On-Premise-Betrieb waren die Vorgaben absolut: Kein Dokument durfte jemals die eigene Umgebung verlassen. Auf Anbieterseite durfte kein Zustand gespeichert werden; jede Kundeninformation war als streng vertraulich klassifiziert. Das waren keine Richtlinien. Das waren harte Grenzen.
Wir dokumentierten die Anforderungen und nahmen sie ins Backlog auf. Zu diesem Zeitpunkt war nicht einmal klar, ob wir bauen, kaufen oder partnern würden. Klar war nur: Einfach würde es nicht.
Als komplexes Tabellen-Parsing auf echten Bedarf traf
Eine zufällige Begegnung verband zwei komplementäre Kompetenzen und legte das technische Fundament für das, was MiruIQ werden sollte.
Etwa zur gleichen Zeit entstand der Kontakt zu jemandem, der intensiv an einem sehr spezifischen Problem geforscht hatte: wie sich komplexe Tabellen mit grossen Sprachmodellen zuverlässig aus Dokumenten auslesen lassen. Keine einfachen Raster-Tabellen, sondern die Art, die in echten Unternehmensdokumenten vorkommt: wo eine Fussnote oben vermerkt, dass Endnullen entfernt wurden, weil die Werte nicht auf A4 passten, wo Spalten über Seiten laufen und die Formatierung inkonsistent ist.
Er hatte methodisch jeden verfügbaren Ansatz getestet: Fine-Tuning von LLMs, Retrieval-Augmented Generation, System-Prompt-Engineering und diverse Hybrid-Strategien. Für jeden Ansatz hatte er umfassende Testsuiten über alle damals verfügbaren grossen Sprachmodelle geschrieben. Aus diesem rigorosen, empirischen Prozess ging ein Ansatz als aussergewöhnlich vielversprechend hervor.
Der entscheidende nächste Schritt war, das Ganze unter den Sicherheitsauflagen der Bank zum Laufen zu bringen. Das bedeutete lokale KI-Modelle, lokale LLM-Deployments auf dedizierter Infrastruktur, und damit Investitionen in Hochleistungs-Hardware, um grössere Modelle vollständig On-Premise zu betreiben, ohne jegliche Cloud-Exposition.
Mit tiefer Expertise in Streaming-Architekturen und verteilten Systemen auf der einen Seite und einem Kunden, der genau das wirklich brauchte, war die Entscheidung einfach: einen Proof of Concept bauen, der vom ersten Tag an jede Sicherheitsanforderung erfüllt.
Der Proof of Concept war ein Erfolg
Was als fokussiertes Experiment begann, wurde zum Fundament einer völlig neuen Plattform.
Der POC lieferte genau das, was der Kunde brauchte, und wurde abgenommen. Von da an war die Mission klar: den validierten Ansatz zu einer produktionsreifen Plattform ausbauen, die jedes Unternehmen einsetzen kann.
Es folgte eine intensive Entwicklungsphase. Über rund 18 Monate wurde die Architektur dreimal neu gebaut. Jede Iteration brachte das Pipeline-Design näher an das, was gebraucht wurde: Apache-Flink-basierte Streaming-Jobs, die Zustand nicht nur pro Kunde, sondern pro einzelner Pipeline-Ausführung isolieren. Dieses Mass an Isolation war kein Nice-to-have; es war die direkte Konsequenz des Sicherheitsmodells.
Das Ergebnis ist MiruIQ, wie es heute existiert: eine Plattform, die wir als die flexibelste und sicherste Lösung für Dokumentenautomatisierung gebaut haben, die wir kennen. Nicht weil Sicherheit nachträglich angeschraubt wurde, sondern weil sie die Gründungsbedingung war, die jede Designentscheidung von der allerersten Codezeile an geprägt hat.
Anders gebaut, weil es so sein musste
Jede Fähigkeit in MiruIQ geht auf eine reale Anforderung zurück, nicht auf eine Feature-Roadmap.
Komplexe Tabellenextraktion
Meistert die Grenzfälle, an denen andere Tools scheitern: abgeschnittene Werte, mehrseitige Tabellen, Fussnoten, die Spaltensemantik umdefinieren, und inkonsistente Formatierung über Dokumenttypen hinweg.
Semantische Extraktion
Geht über layoutbasierte OCR hinaus und versteht, was ein Dokument tatsächlich bedeutet. Extrahiert strukturierte Daten aus langen, komplexen Dokumenten durch Kontextinterpretation statt blosser Koordinaten.
Dokumentübergreifende Validierung
Vergleicht Felder automatisch über mehrere hochgeladene Dokumente hinweg; gleicht Namen, Arbeitgeber, Daten und Berechnungen ab, um Inkonsistenzen und möglichen Betrug zu erkennen.
Security by Design
Vollständige On-Premise-Deployments, keine Zustandsspeicherung auf Anbieter-Infrastruktur und Isolation auf Pipeline-Ebene. Sicherheit ist die Architektur, kein Feature-Schalter.
Schweizer Infrastruktur
Betrieb auf lokaler Infrastruktur ohne Cloud-Abhängigkeit. Lokale KI-Modelle laufen auf dedizierter Hardware; Ihre Dokumente verlassen niemals Ihre Umgebung.
Pipeline-Architektur
Apache-Flink-basierte Streaming-Pipelines mit Zustandsisolation pro Ausführung. Skalierbar, auditierbar und vom ersten Tag an für regulierte Branchen konzipiert.
Bereit für MiruIQ?
Ob komplexe Tabellenextraktion, dokumentübergreifende Validierung oder ein vollständig lokales On-Premise-Deployment: Wir zeigen Ihnen gerne, was MiruIQ kann.