Ogni piattaforma è il prodotto delle sue decisioni architetturali. Le feature si aggiungono e si tolgono. L'architettura resta. Le scelte che facciamo a livello di fondamenta determinano cosa sarà possibile — e cosa sarà impossibile — per anni.

Questo post documenta le decisioni architetturali fondamentali dello stack GRAL e il ragionamento dietro ciascuna. Non sono le uniche scelte possibili. Sono quelle che funzionano meglio nel contesto in cui operiamo: AI enterprise, dati sensibili, requisiti di produzione reali.

On-Premise First

La decisione architetturale più importante di GRAL è anche la meno alla moda: on-premise first.

La maggior parte delle piattaforme AI nasce nel cloud e poi cerca di adattarsi al mondo enterprise. GRAL ha fatto il percorso inverso. Le nostre piattaforme sono progettate per girare sull'infrastruttura del cliente — nei loro data center, sotto il loro controllo, dietro il loro firewall.

Perché? Perché i dati enterprise non lasciano l'azienda. Non per capriccio, ma per ragioni concrete: regolamentazioni settoriali, clausole contrattuali con i clienti, requisiti di sovranità dei dati, policy di sicurezza interna. Quando un'azienda manifatturiera ci dice che i dati di produzione non possono lasciare lo stabilimento, non è un vincolo da aggirare. È un requisito di progetto.

L'approccio on-premise first ha un costo ingegneristico significativo. Non possiamo assumere hardware omogeneo. Non possiamo fare affidamento su servizi managed. Dobbiamo gestire installazione, configurazione e aggiornamento in ambienti che variano enormemente da cliente a cliente. Ma il risultato è una piattaforma che si adatta all'infrastruttura esistente invece di pretendere che l'infrastruttura si adatti a lei.

Architettura Edge-Cloud Ibrida

On-premise non significa monolitico. Lo stack GRAL implementa un'architettura edge-cloud ibrida dove l'inferenza avviene all'edge e il training avviene in modo centralizzato.

All'edge: Nodi di inferenza leggeri che eseguono modelli quantizzati vicino alla fonte dati. Nella manifattura, questo significa hardware dedicato sulla linea di produzione. Nella logistica, significa nodi nei centri di smistamento. Latenza sotto i 15ms, nessuna dipendenza dalla rete per le decisioni critiche.

Nel core: L'istanza centralizzata di Cognity o Sentara che gestisce training, analytics, aggiornamento modelli e orchestrazione. Può risiedere nel data center del cliente o nel loro cloud privato.

Il collegamento: Una pipeline di sincronizzazione asincrona che muove dati di training dall'edge al core e modelli aggiornati dal core all'edge. Se la connessione si interrompe, i nodi edge continuano a funzionare con l'ultimo modello disponibile. Nessun single point of failure.

Questa architettura risolve un problema che il cloud puro non può risolvere: latenza deterministica. Quando un sistema di visione deve classificare un pezzo alla velocità della linea di produzione, non può aspettare un round-trip al cloud. L'inferenza deve avvenire localmente, con garanzie di latenza che solo l'esecuzione on-device può offrire.

Orchestrazione Custom

GRAL non usa Kubernetes per l'orchestrazione dei workload AI. Abbiamo costruito un orchestratore custom.

Questa è una decisione che richiede spiegazione, perché andare contro lo standard industriale non è una scelta che si fa a cuor leggero. Le ragioni sono tre.

Scheduling GPU-aware. Kubernetes tratta le GPU come risorse generiche. I nostri workload AI hanno bisogno di scheduling che comprenda la topologia GPU — quali modelli beneficiano della co-localizzazione, come partizionare la memoria GPU tra workload concorrenti, quando migrare un workload su un nodo diverso per bilanciare il carico termico.

Lifecycle management dei modelli. Il ciclo di vita di un modello AI non corrisponde al ciclo di vita di un container. Un modello ha versioni, metriche di qualità, finestre di validazione e procedure di rollback che sono specifiche del dominio. Il nostro orchestratore gestisce il modello come cittadino di prima classe, non come un artefatto dentro un container.

Vincoli real-time. Per i workload di inferenza edge, abbiamo bisogno di garanzie di scheduling che Kubernetes non può offrire. Priorità hard real-time, pinning dei core CPU, gestione deterministica della memoria. Il nostro orchestratore integra queste garanzie nativamente.

Il costo è la manutenzione di un componente infrastrutturale critico. Il beneficio è un livello di controllo e ottimizzazione che semplicemente non è possibile con soluzioni generiche.

Modello Dati Zero-Trust

In GRAL, ogni accesso ai dati è autenticato, autorizzato e auditato. Non ci sono eccezioni.

Il modello zero-trust si articola su tre livelli:

  • Autenticazione — Ogni componente del sistema ha un'identità crittografica. I nodi edge si autenticano con il core tramite certificati mutui. I servizi interni si autenticano tra loro. Nessuna comunicazione avviene su canali non autenticati.
  • Autorizzazione granulare — Le policy di accesso definiscono chi può leggere quali dati, a quale livello di granularità. Un modello di computer vision può accedere alle immagini della linea 3 ma non della linea 7. Un agente Sentara può leggere i dati del cliente ma non modificarli. Le policy sono dichiarative e versionate.
  • Audit completo — Ogni accesso ai dati genera un record immutabile. Chi ha acceduto a cosa, quando, perché, con quale risultato. Questo non è logging opzionale. È parte integrante della pipeline di accesso ai dati.

Per i clienti in settori regolamentati — finanza, sanità, difesa — questo modello non è un nice-to-have. È un prerequisito. Averlo costruito come fondamento architetturale significa che la compliance non è un'aggiunta tardiva, ma una proprietà del sistema.

Approccio all'Integrazione

Le piattaforme GRAL non vivono in isolamento. Si integrano con l'ecosistema enterprise esistente — ERP, MES, CRM, sistemi legacy, database proprietari. L'approccio all'integrazione è una decisione architetturale critica.

Adapter pattern. Ogni integrazione è implementata come un adapter che traduce tra il modello dati interno di GRAL e il sistema esterno. Gli adapter sono componenti indipendenti, versionati e testabili. Quando un sistema esterno cambia, solo l'adapter viene modificato.

Event-driven, non polling. Dove possibile, le integrazioni sono event-driven. I dati fluiscono quando cambiano, non quando qualcuno li chiede. Questo riduce la latenza e il carico su entrambi i sistemi.

Contratti API stabili. Le interfacce tra GRAL e i sistemi esterni sono definite da contratti espliciti e versionati. L'evoluzione interna della piattaforma non rompe le integrazioni esistenti. Questo è fondamentale per clienti che non possono permettersi downtime durante gli aggiornamenti.

Perché Queste Decisioni

Ogni decisione architetturale qui descritta nasce da un vincolo reale dell'AI enterprise. On-premise first perché i dati non si muovono. Edge-cloud ibrido perché la latenza conta. Orchestrazione custom perché le GPU non sono commodity. Zero-trust perché la compliance non è opzionale. Integration-first perché l'AI in isolamento non ha valore.

GRAL non ha scelto queste architetture perché erano le più eleganti. Le ha scelte perché sono quelle che funzionano quando il sistema deve girare in produzione, su scala, in ambienti enterprise reali.

La differenza tra un'architettura da whiteboard e un'architettura da produzione è tutta qui: le decisioni che sopravvivono al contatto con la realtà.