I3K RAG Enterprise vs Onyx: un confronto open-source onesto

Se nel 2026 state valutando una piattaforma open-source di Retrieval-Augmented Generation, i due nomi che ricorrono più spesso sono Onyx e I3K RAG Enterprise. Ce ne sono altri — Verba, Quivr, Haystack come libreria — ma Onyx e I3K RAG Enterprise sono i due progetti che puntano esplicitamente al deployment enterprise out of the box.

Noi sviluppiamo I3K RAG Enterprise. Abbiamo anche fatto girare Onyx sul serio su dati di produzione, sia per conto di clienti sia come parte del nostro lavoro di valutazione. Questo articolo è un tentativo di darvi il confronto che avremmo voluto ricevere noi quando stavamo valutando, comprese le parti in cui Onyx vince genuinamente.

Se notate qualcosa di sbagliato, segnalatecelo e lo correggeremo.

Da dove vengono i due progetti

I due progetti partono da presupposti diversi, e questo plasma i compromessi.

Onyx (precedentemente Danswer) è una piattaforma RAG open-source di origine statunitense che ha guadagnato trazione intorno al 2023 come "ChatGPT per la tua azienda". Ha un forte focus sui connector — Slack, Confluence, Google Drive, Notion — e sul portare rapidamente un assistente funzionante davanti agli utenti.

I3K RAG Enterprise è sviluppato da I3K Technologies a Milano. È nato come strumento interno sovereignty-first per clienti regolamentati UE, ed è stato rilasciato in open-source una volta che l'architettura si è stabilizzata. Il focus è sull'esecuzione interamente all'interno del perimetro del cliente, sugli strumenti di compliance e sulla qualità del retrieval multilingue come preoccupazione di prima classe.

I due progetti scelgono licenze open-source deliberatamente diverse. Onyx è MIT. I3K RAG Enterprise è AGPL-3.0 — una licenza copyleft che protegge il progetto dall'essere ripacchettizzato come prodotto SaaS chiuso da terze parti, lasciandovi però completamente liberi di self-hostare, modificare e usare il software commercialmente all'interno della vostra organizzazione. È una differenza reale e sostanziale, e ci torneremo sopra.

Architettura: connector-first vs sovereignty-first

La differenza architetturale più netta tra i due è cosa ciascun progetto considera il proprio centro di gravità.

Onyx è connector-first

Il punto di forza di Onyx è la sua libreria di connector. Out of the box è in grado di fare ingestion da una lunga lista di sorgenti SaaS, gestire l'autenticazione e la sincronizzazione incrementale. Se la vostra conoscenza vive in Notion, Confluence e Slack, Onyx ci starà parlando entro un pomeriggio. Il layer di retrieval è una pipeline relativamente convenzionale appoggiata (a seconda della configurazione) su Vespa o su Postgres con pgvector.

I3K RAG Enterprise è sovereignty-first

Abbiamo progettato la piattaforma intorno a un vincolo non negoziabile: nulla lascia il perimetro del cliente. Lo stack riflette questa scelta end-to-end:

• Un solo binario Rust — niente Docker, niente Compose, niente Java. Avvia da sé database vettoriale e motore di inferenza.
• Qdrant come vector store, con filtering RBAC integrato nella query in modo che i confini dei ruoli vengano fatti rispettare già in fase di retrieval.
• eullm come motore di inferenza locale, avviato e tenuto aggiornato dal binario, che riconosce la GPU all'avvio.
• BAAI/bge-m3 come modello di embedding — 1024 dimensioni, multilingue nativo su oltre 100 lingue, calcolato nel processo tramite Candle.
• Orchestrator di retrieval interno I3K (Python, nessun agent framework di terzi) (ingest → embed → retrieve → generate).
• pdfium + Tesseract OCR per le pagine scansionate, applicato in automatico quando una pagina restituisce troppo poco testo.
• JWT auth + RBAC con tre ruoli predefiniti.
• GPU quando c'è: una GPU NVIDIA viene rilevata e usata in automatico; altrimenti gira su CPU.
• Backup coerenti: un archivio giornaliero con database applicativo e snapshot vettoriale presi insieme, ripristinabile sull'installazione in esecuzione.
• Setup one-command, tipicamente in circa un'ora su hardware standard.

Il lato ingestion è deliberatamente più semplice di quello di Onyx. Supportiamo il file system, lo storage oggetti S3-compatibile e i formati documentali standard via Tika — ma non stiamo cercando di pareggiare Onyx connector per connector. Se vi serve oggi un connector Slack, Onyx vi ci porta più rapidamente.

Per le organizzazioni che vogliono inferenza EU-sovereign senza gestire le GPU in casa, raccomandiamo EuLLM come opzione gestita.

Confronto funzionale

Capacità	I3K RAG Enterprise	Onyx
Licenza open-source	AGPL-3.0	MIT
Self-hostable	Sì	Sì
Deployment air-gapped / 100% locale	Default	Possibile, meno documentato
Vector store	Qdrant (filtering RBAC integrato)	Vespa o Postgres + pgvector
LLM serving	eullm, avviato dal binario	Configurabile
Modello embedding (default)	BAAI/bge-m3 — oltre 100 lingue native	Default English-first
OCR / documenti scansionati	pdfium + Tesseract integrati	Non integrati
GPU	NVIDIA rilevata in automatico, altrimenti CPU	Focus NVIDIA
Backup integrato	Archivio giornaliero coerente + restore	Non integrato
Libreria di connector	Ingestion file / S3 / via Tika	Estesa (Slack, Notion, GDrive…)
Setup	Un comando, ~1 ora	Multi-step
Team di sviluppo residente in UE	Sì (Milano)	No
Strumenti GDPR / EU AI Act	First-class	Fai-da-te
Auth e RBAC	JWT + 3 ruoli integrati	Integrato; SSO in Enterprise

Le righe in cui Onyx vince sono reali: la libreria di connector, la UI conversazionale e la dimensione della community sono tutti vantaggi genuini oggi.

Le righe in cui vince I3K RAG Enterprise contano soprattutto se sovranità del dato, qualità multilingue, topologia di deployment e completezza operativa (backup, OCR, multi-GPU) sono requisiti non negoziabili.

Deployment

Entrambi i progetti supportano Docker Compose per la valutazione e Kubernetes per la produzione.

Onyx distribuisce un chart Helm e ha una buona documentazione per i tipici deployment SaaS-on-Kubernetes. L'installazione air-gapped è possibile ma dà la sensazione di nuotare controcorrente: molti default presumono accesso di rete in uscita (pull di immagini da registry pubblici, telemetry, download di modelli).

I3K RAG Enterprise è progettato per il deployment completamente locale, 100% offline, come caso di default. Il modello è servito localmente da eullm, gli embedding girano nello stesso processo via bge-m3, e non ci sono chiamate verso l'esterno in funzionamento normale. Non c'è nessun installer da eseguire: si scompatta l'archivio e si lancia il binario, che al primo avvio scarica e verifica via sha256 i propri componenti e da lì in poi non ha più bisogno di rete.

Se state facendo deployment all'interno di una rete aziendale con restrizioni proxy, o in un ambiente regolamentato dove il traffico in uscita è negato per policy, la nostra esperienza è che I3K RAG Enterprise vi darà meno sorprese.

Licenze — e perché AGPL conta

Entrambi i progetti sono utilizzabili sotto la loro licenza open-source senza alcun contratto commerciale. Le licenze in sé sono diverse in un modo che vale la pena capire.

Onyx: MIT per il core. MIT è massimamente permissiva — chiunque può prendere il codice e mettere in commercio un prodotto closed-source costruito sopra, senza alcun obbligo di restituire le modifiche.

I3K RAG Enterprise: AGPL-3.0 per l'intera piattaforma. AGPL è una licenza copyleft forte: potete self-hostare, modificare e usare la piattaforma commercialmente all'interno della vostra organizzazione senza restrizioni. Quello che AGPL impedisce è che un terzo prenda il codice, lo impacchetti in un SaaS hosted e tenga le proprie modifiche private. È una scelta deliberata da parte nostra — protegge il progetto e la community dal pattern di estrazione open-source-verso-closed-source più comune.

Se siete un'azienda che self-hosta la piattaforma, AGPL non vi impone alcun onere pratico che MIT non vi imporrebbe. Se intendete rivendere I3K RAG Enterprise come servizio hosted, parlateci di una licenza commerciale.

Multilingue e OCR — dove si vedono le scelte di stack

Due scelte di stack meritano di essere evidenziate perché tendono a essere invisibili finché non ci si scontra.

bge-m3 per gli embedding: bge-m3 è multilingue nativo su oltre 100 lingue, e la qualità su corpus non-inglesi è significativamente migliore rispetto ai default English-first. Se il vostro corpus è in italiano, francese, tedesco, spagnolo, o un mix di lingue UE, lo sentirete dalla prima query.

Tika + Tesseract per l'ingestion: una quota importante dei documenti enterprise reali — soprattutto in sanità, legale e pubblica amministrazione — sono PDF scansionati. Senza OCR, quei documenti sono di fatto invisibili al retrieval. Spediamo Tika e Tesseract nello stack di default proprio perché questo caso funzioni out of the box.

Quando dovreste scegliere Onyx

Pensiamo onestamente che Onyx sia la scelta migliore se:

• La maggior parte della vostra conoscenza vive in strumenti SaaS (Slack, Confluence, Notion, Google Drive) e avete bisogno di connector out of the box.
• Siete un'organizzazione solo o prevalentemente in inglese e la qualità multilingue non è un vincolo.
• Apprezzate la UI conversazionale e il maggiore momentum della community attorno a Onyx.
• Volete il percorso più rapido da zero a un assistente interno funzionante in uno stack inglese e US-centric.

Quando dovreste scegliere I3K RAG Enterprise

Pensiamo che I3K RAG Enterprise sia la scelta migliore se:

• Operate in un settore regolamentato UE — legale, sanità, finanza, pubblica amministrazione — e la data residency è un requisito vincolante.
• Avete bisogno di una storia reale per l'EU AI Act, non solo per il GDPR.
• Il vostro corpus è multilingue o non è dominato dall'inglese.
• Avete bisogno di fare deployment completamente locale / air-gapped, senza chiamate in uscita.
• Vi serve l'OCR per i documenti scansionati come capacità di prima classe.
• Volete un backup che si ripristini come insieme coerente — database applicativo e snapshot vettoriale presi insieme — come parte della piattaforma, non come script da scrivere dopo.
• La licenza AGPL-3.0 è allineata con come pensate all'open source — e apprezzate la protezione che offre contro il SaaS-wrapping da parte di terzi.

Quando nessuno dei due è la risposta giusta

Disclosure onesta: ci sono situazioni in cui nessuno dei due progetti è quello che vi serve.

Se siete una startup con venti documenti e un prototipo di chatbot, una tabella Postgres più pgvector più uno script breve vi porterà più avanti di entrambe le piattaforme. Se siete un hyperscaler con ASIC custom e un team di ricerca, quasi certamente avete già uno stack interno.

Scegliete una piattaforma quando le preoccupazioni operative — scoping multi-tenant, RBAC, backup, topologia di deployment, ciclo di vita di modelli e indici — iniziano a sembrare più lavoro del retrieval stesso.

Come scegliere, concretamente

Eseguite entrambi sui vostri dati per due settimane. Lo intendiamo letteralmente — non una demo, non un benchmark del vendor, il vostro corpus e le vostre query di valutazione.

Misurate quattro cose: qualità del retrieval sulle vostre query, latency end-to-end alla vostra concorrenza, costo operativo (incluso il tempo delle persone) e gap di compliance (cosa manca che dovreste costruire voi stessi). Poi scegliete quello che vince sulle dimensioni che vi interessano davvero.

Pensiamo che la risposta sia I3K RAG Enterprise più spesso che non per i carichi di lavoro regolamentati UE, per i corpus multilingue, e per i team che vogliono tutto — inferenza, retrieval, OCR, backup — in esecuzione dentro il proprio perimetro. Questa è la scommessa dietro il progetto. Ma la valutazione dovrebbe essere vostra, non nostra.

---