Nato da un problema reale.Costruito per i casi più difficili.
MiruIQ non è stato progettato in laboratorio. È nato da un'esigenza aziendale reale, dove i vincoli di sicurezza non erano negoziabili e la complessità documentale era la norma.
A una banca di credito svizzera serviva più del semplice OCR
All'interno di Acosom GmbH seguivamo una banca di credito per cui avevamo già realizzato la postazione di gestione delle richieste di credito e i portali clienti. Poi la conversazione si è spostata sul passo successivo.
Il cliente voleva automatizzare il confronto dei documenti che i suoi team gestivano ancora manualmente. In una tipica richiesta di prestito, i clienti caricano più documenti: buste paga, documenti d'identità, contratti di lavoro, dichiarazioni fiscali e altro. La banca doveva incrociare questi documenti: il nome è identico in tutti i caricamenti? Il datore di lavoro corrisponde? I calcoli su una busta paga sono matematicamente corretti, o rivelano falsificazioni evidenti?
Non era un semplice compito di estrazione. Richiedeva comprensione semantica tra più tipi di documento, con una logica di validazione ben oltre il semplice confronto di campi.
E poi c'erano i requisiti di sicurezza. Trattandosi di un istituto finanziario svizzero operante interamente on-premise, i vincoli erano assoluti: nessun documento poteva mai lasciare il suo ambiente. Nessuno stato poteva essere conservato lato fornitore: ogni informazione dei clienti era classificata come altamente confidenziale. Non erano linee guida. Erano confini rigidi.
Abbiamo documentato i requisiti e li abbiamo aggiunti al backlog. In quel momento non era nemmeno chiaro se avremmo costruito, comprato o cercato un partner. Una cosa era chiara: non sarebbe stato facile.
Quando il parsing di tabelle complesse ha incontrato una domanda reale
Un incontro fortuito ha unito due competenze complementari, e sbloccato le fondamenta tecniche di ciò che sarebbe diventato MiruIQ.
Più o meno nello stesso periodo è nato un contatto con qualcuno che stava studiando a fondo un problema molto specifico: come estrarre in modo affidabile tabelle complesse dai documenti usando grandi modelli linguistici. Non semplici tabelle a griglia, ma quelle dei veri documenti aziendali, dove una nota in alto avverte che gli zeri finali sono stati rimossi perché i valori non stavano su un A4, dove le colonne proseguono su più pagine e la formattazione è incoerente.
Aveva testato metodicamente ogni approccio disponibile: fine-tuning di LLM, retrieval-augmented generation, ingegneria dei prompt di sistema e varie strategie ibride. Per ciascun approccio aveva scritto suite di test complete su ogni grande modello linguistico disponibile all'epoca. Da questo processo rigoroso ed empirico, un approccio è emerso come eccezionalmente promettente.
Il passo critico successivo era farlo funzionare sotto i vincoli di sicurezza richiesti dalla banca. Questo significava modelli di IA locali, deployment di LLM locali su infrastruttura dedicata, il che ha richiesto investimenti in hardware ad alte prestazioni per eseguire modelli più grandi interamente on-premise, senza alcuna esposizione al cloud.
Con da un lato una profonda esperienza in architetture di streaming e sistemi distribuiti, e un cliente che ne aveva davvero bisogno, la decisione è stata semplice: costruire una proof of concept che rispettasse ogni requisito di sicurezza fin dal primo giorno.
La proof of concept è stata un successo
Ciò che è iniziato come un esperimento mirato è diventato la base di una piattaforma completamente nuova.
La POC ha consegnato esattamente ciò che serviva al cliente, che l'ha approvata. Da quel momento la missione era chiara: trasformare l'approccio validato in una piattaforma di livello produttivo utilizzabile da qualsiasi azienda.
È seguito un periodo di sviluppo intensivo. Nell'arco di circa 18 mesi l'architettura è stata ricostruita tre volte. Ogni iterazione ha avvicinato il design delle pipeline a ciò che serviva: job di streaming basati su Apache Flink in grado di isolare lo stato non solo per cliente, ma per singola esecuzione di pipeline. Questo livello di isolamento non era un vezzo: era la conseguenza diretta del modello di sicurezza.
Il risultato è MiruIQ com'è oggi: una piattaforma che abbiamo costruito per essere la soluzione di automazione documentale più flessibile e sicura che conosciamo. Non perché la sicurezza sia stata aggiunta a posteriori, ma perché era il vincolo fondativo che ha plasmato ogni scelta di design fin dalla primissima riga di codice.
Costruito diversamente, perché doveva esserlo
Ogni capacità di MiruIQ risale a un requisito reale, non a una roadmap di funzionalità.
Estrazione di tabelle complesse
Gestisce i casi limite che mandano in crisi gli altri strumenti: valori troncati, tabelle su più pagine, note a piè di pagina che ridefiniscono la semantica delle colonne e formattazioni incoerenti tra tipi di documento.
Estrazione semantica
Va oltre l'OCR basato sul layout per capire cosa significa davvero un documento. Estrae dati strutturati da documenti lunghi e complessi interpretando il contesto, non solo le coordinate.
Validazione tra documenti
Confronta automaticamente i campi tra più documenti caricati, incrociando nomi, datori di lavoro, date e calcoli per individuare incoerenze e potenziali frodi.
Sicurezza by design
Deployment interamente on-premise, nessuna conservazione di stato sull'infrastruttura del fornitore e isolamento a livello di pipeline. La sicurezza è l'architettura, non un'opzione da attivare.
Infrastruttura svizzera
Ospitato su infrastruttura locale, senza dipendenza dal cloud. I modelli di IA locali girano su hardware dedicato: i vostri documenti non lasciano mai il vostro ambiente.
Architettura a pipeline
Pipeline di streaming basate su Apache Flink con isolamento dello stato per esecuzione. Scalabile, verificabile e progettata fin dal primo giorno per i settori regolamentati.
Pronto a scoprire MiruIQ?
Che vi serva l'estrazione di tabelle complesse, la validazione tra documenti o un deployment interamente on-premise, saremo felici di mostrarvi cosa sa fare MiruIQ.