Eldric è la piattaforma di infrastruttura AI multi-tenant dietro le offerte di Private AI di ISP, MSP, telco e cloud regionali. I Vostri clienti vogliono l'AI; non vogliono inviare i propri dati a OpenAI, Anthropic, Azure o AWS. Con Eldric gestite la piattaforma sul Vostro hardware, nei Vostri datacenter — ogni cliente è un tenant completamente isolato, con il Vostro brand, fatturato da Voi.
La relazione con il cliente resta Vostra. I ricavi ricorrenti restano Vostri. I dati restano nella giurisdizione a cui appartengono. L'unica cosa che non dovete costruire è la piattaforma AI stessa.
Nei consigli di amministrazione, ai Vostri clienti enterprise viene chiesto quale sia la loro strategia di AI. Rispondono in uno di tre modi. Due di queste risposte Vi lasciano fuori dal gioco — o guardando il cliente spedire i carichi di lavoro a un hyperscaler, o vederlo sparire in un progetto interno di diciotto mesi che forse non finirà mai. La terza risposta Vi mette al centro della relazione e Vi apre una linea di ricavi ricorrenti che un anno fa non esisteva.
Un'offerta Private AI funziona solo se il provider può vendere con sicurezza a clienti enterprise che tengono all'isolamento, al brand, alla fatturazione e a dove i dati vivono davvero. Eldric porta queste quattro proprietà come primitive della piattaforma, non come voci di un capitolato di servizi professionali. Il provider costruisce il movimento di vendita; Eldric è ciò che vende.
Ogni artefatto persistente porta un identificativo di tenant. La piattaforma rifiuta per impostazione predefinita ogni accesso cross-tenant; esiste una via di fuga superadmin per le chiamate cluster-internal legittime. Accesso basato sui ruoli per tenant, quote e capability token — lo stesso RBAC che il provider usa per i propri admin.
Ogni tenant ha il proprio portale sul proprio sottodominio, con la propria palette di colori, il proprio logo, la propria tipografia e i propri testi. La chat shell, le superfici admin e l'interfaccia rivolta al cliente sono tematizzate per ogni tenant. Gli utenti del cliente non hanno bisogno di sapere quale infrastruttura ci sia sotto.
La piattaforma emette eventi di utilizzo per tenant — richieste, token, chiamate di retrieval, minuti di addestramento, ingombro di storage — via OTLP-HTTP verso qualunque stack di observability o billing il provider già operi. I connettori chiavi in mano per le piattaforme di billing più comuni arrivano come plugin in roadmap; il segnale grezzo è disponibile oggi.
Vincolate un tenant a una regione. La piattaforma rifiuta di replicare i dati di quel tenant al di fuori delle regioni in cui è autorizzato a vivere — una regola che il cluster impone, non l'operatore. La federazione fra le sedi del provider è completa nel codice; la dashboard visibile al cliente per il pinning regionale arriva con prossime patch 5.0.x.
Se il Vostro cliente sta confrontando la Vostra offerta di Private AI con quanto potrebbe ottenere da un cloud pubblico, la risposta deve essere: le stesse capacità, nella sua lingua, sulla Vostra giurisdizione, fatturate nella sua valuta. Eldric copre la coda lunga di ciò che le imprese chiedono davvero — non solo la chat, ma gli strumenti agentici e di dominio che distinguono un'offerta seria da una demo.
Ogni capacità è regolata dal livello di licenza — il provider sceglie quali capacità esporre a quale tenant, con quale quota e a quale prezzo. Un tenant di piccola impresa potrebbe vedere solo chat e RAG; un tenant enterprise potrebbe ricevere l'intero catalogo di dominio più il fine-tuning. È il provider che decide il menu.
La maggior parte dei service provider opera su più sedi — Paesi diversi, regioni regolatorie diverse, contratti di colocation diversi. Eldric federa fra queste sedi senza forzare un unico cluster gigante che si estende sulla WAN. Ogni regione mantiene il proprio cluster Eldric autonomo per i percorsi caldi; un livello di federazione mantiene coerenti directory, policy di tenant e provisioning delle risorse su tutta la piattaforma. I clienti vedono un solo prodotto. I provider vedono una sola dashboard. Ogni regione conserva i byte che devono restare lì.
Il provider vede una sola piattaforma. Il cliente vede il proprio brand. Il regolatore vede dati che non hanno mai attraversato un confine che non potevano attraversare.
Eldric viene rilasciato con cinque livelli di licenza. Come service provider, licenziate Eldric al livello Enterprise o Custom e rivendete il pacchetto di capacità ai Vostri clienti come Vostre SKU, al Vostro prezzo retail. Eldric non firma contratti con i Vostri clienti; il provider mantiene la relazione end-to-end. La mappa qui sotto è il menu di pacchetti di capacità da cui potete costruire le Vostre SKU.
| Livello | Ambito | Cosa include il pacchetto |
|---|---|---|
| Free | 1 controller · 2 worker | Il pacchetto di prova. Un modo per far provare la piattaforma a un cliente potenziale prima dell'impegno. Con il brand del provider; valgono le stesse regole di isolamento. |
| Standard | 3 worker · RAG + agenti | Cliente di piccola impresa. Chat, RAG su documenti privati, agenti di base, modelli custom. L'offerta Private AI di tutti i giorni. |
| Professional | 10 worker · multi-sede · metriche | Impresa mid-market. Aggiunge dashboard, metriche, hardening di sicurezza, RAG distribuito, generazione di dati di addestramento. La SKU di rilascio "vero". |
| Enterprise | 50 worker · HA · orchestrazione | Cliente large enterprise. Aggiunge alta disponibilità, federazione, orchestrazione completa, decisioni guidate dall'AI, supporto prioritario. Superficie completa. |
| Custom | illimitato · tutto | La licenza del provider stesso. Controller, router e worker illimitati su tutte le Vostre regioni. È su questa che gestite la piattaforma. |
Le licenze sono firmate offline con Ed25519. La piattaforma le valida localmente; nessun phone-home, nessun feed di consumo per token che esce dai Vostri locali. Il provider opera tutto dentro il proprio perimetro — la licenza è qualcosa che ci pagate una volta l'anno, non una dipendenza runtime su qualcosa che controlliamo noi.
I service provider non possono buttare via il proprio stack operativo esistente per aggiungere un prodotto nuovo. Eldric è costruito per integrarsi — attraverso un plugin host che esegue estensioni lato server e lato client — con quello che già avete: il sistema di network management, il parco di BMC, il provider di identità, la piattaforma di billing, la coda di ticketing. Il plugin host è in produzione; l'ecosistema di connettori cresce a ogni release.
Plugin SNMP e syslog per integrare il monitoring con l'NMS in cui il team operativo vive già — alimentando lo stato della piattaforma Eldric nella stessa dashboard che guarda per tutto il resto.
Il plugin host può eseguire integrazioni in stile Redfish contro il parco bare-metal — utile per triage degli incidenti guidato dall'AI, manutenzione predittiva e consapevolezza di potenza e calore sull'intero cluster.
Configurazione del provider di identità per ogni tenant. Gli utenti del cliente si autenticano contro la directory esistente del cliente; il provider non diventa per sbaglio un broker di identità.
Telemetria per tenant via OTLP-HTTP che alimenta la piattaforma di billing che già gestite. I connettori chiavi in mano per le piattaforme più comuni (Zuora, Chargebee, cicli di fatturazione custom) arrivano come plugin in roadmap; il segnale grezzo è disponibile oggi.
Hook di provisioning e dismissione dei tenant. Quando un cliente firma un contratto nel CRM del provider, viene creato un tenant Eldric; quando se ne va, viene archiviato. Il portale del provider non deve imparare un nuovo vocabolario.
Il team di supporto del provider riceve log, audit trail e cronologia d'uso per tenant — esposti attraverso qualunque sistema di ticketing già operi. Il percorso di escalation resta familiare.
Sei passi separano il giorno in cui un provider decide di lanciare un'offerta Private AI dal giorno in cui il primo cliente paga la prima fattura. Il lato piattaforma — i passi da uno a tre — è la parte di cui Eldric è responsabile, e dove lavoriamo a fianco del provider. Il lato cliente — i passi da quattro a sei — è ciò che la piattaforma è stata costruita per rendere routine, non un'integrazione su misura ogni volta.
Singolo rack o multi-sede, sull'hardware che il provider già gestisce. dnf install eldric-aios sui nodi del cluster; file di licenza attivato; controller online.
Licenza Custom emessa da Eldric copre l'intero parco del provider. I livelli di capacità sono configurati come SKU clienti del provider.
Tema di default, connettore di billing, handoff verso il portale cliente, hook del provider di identità, workflow di supporto. Fatto una volta; vale per ogni tenant futuro.
Il cliente arriva sul portale del provider, sceglie una SKU, firma il contratto. Il portale chiama Eldric; viene provisionato un nuovo tenant con il brand e i limiti del cliente.
Gli utenti del cliente arrivano sul portale con il brand del provider, sul sottodominio del cliente. Chat, RAG, agenti, fine-tune — tutto ciò che la SKU include. La parola "Eldric" non appare mai a meno che il provider non lo voglia.
Gli eventi di utilizzo fluiscono attraverso il connettore di billing nel ciclo di fatturazione esistente del provider. Il cliente paga il provider sul normale calendario di fatturazione del provider. La linea di ricavi ricorrenti è aperta.
Non ogni service provider dovrebbe vendere Private AI; non ogni base clienti la vuole. Preferiamo avere la conversazione onesta in partenza che chiudere un contratto che non funziona per nessuno dei due. Ecco il taglio.
La maggior parte delle conversazioni con i service provider inizia con una call di trenta minuti: la Vostra base clienti, l'infrastruttura esistente, la timeline, il panorama competitivo. Vi diremo se Eldric è lo strumento giusto per quello che volete fare — e, se lo è, com'è il percorso da oggi al primo tenant pagante.
Siamo una piccola azienda austriaca. La persona con cui parlate è quella che conosce il codice. La conversazione è in italiano, tedesco o inglese; la licenza si firma a Vienna; la piattaforma gira dove mettete l'hardware.