Quando NO self-host: 7 scenari dove cloud EU vince su on-prem AI 2026

Prima di comprare un server: sette domande che possono farti scegliere il cloud

Tenere un modello AI in casa è una scelta sensata in molti casi, e la serie ha mostrato come farla. Ma non è una scelta universale, e un articolo che sostiene una tesi deve anche dire quando non vale. Questo articolo prende sette situazioni in cui un servizio gestito, europeo e a consumo può essere la scelta migliore per una PMI, e per ciascuna dà il test che puoi fare con i tuoi numeri. Non troverai prezzi di fornitori né casi aziendali con cifre: i listini cambiano, e un caso inventato non dimostra niente. Troverai programmi, eseguiti, che ti fanno calcolare il tuo caso.

Il risultato più utile da anticipare riguarda il costo: un server proprio costa un importo fisso, quindi il costo per ogni token dipende da quanto lo fai lavorare, e il tempo di chi lo gestisce pesa quanto la macchina. Con ipotesi dichiarate e variabili, il primo programma lo mostra. Il resto dell'articolo è l'applicazione di questa idea ai sette casi, più il quadro normativo europeo che serve quando il fornitore non è europeo. Per i costi del caso in casa, dall'altra parte, vedi l'analisi dei costi di 12 mesi e il dimensionamento in Ollama da 1 a 50 utenti.

Il costo per token dipende da quanto lavora il server

Un server costa lo stesso se risponde a mille richieste o a nessuna. Un'API a consumo costa solo quello che usi. Il confronto onesto fra i due è quindi il costo per milione di token in funzione dell'utilizzo, cioè della frazione di tempo in cui la macchina lavora davvero, con in più il costo del lavoro di chi la tiene in piedi. Il programma calcola la tabella con valori di prova: 200 euro al mese per la macchina, 50 euro l'ora per chi la gestisce, 25 token al secondo (la velocità va misurata sulla tua macchina) e prezzi dell'API da 1 a 50 euro per milione di token. Nessuno di questi numeri è il prezzo di un fornitore: sono ipotesi da sostituire con il tuo listino e le tue misure.

"""Costo per milione di token di un server proprio contro un'API a consumo, in funzione dell'utilizzo e del tempo di gestione."""
SECONDI_MESE = 30 * 24 * 3600

# TUTTI VALORI DI PROVA, non prezzi di nessun fornitore: sostituiscili con il tuo listino e le tue misure
SERVER_EURO_MESE = 200.0       # costo mensile della macchina
TARIFFA_ORARIA = 50.0          # costo di un'ora di lavoro di chi gestisce il servizio
TOKEN_AL_SECONDO = 25.0        # velocità MISURATA (vedi articolo sul dimensionamento)
API_EURO_PER_MILIONE = 1.0     # prezzo a consumo per milione di token (ingresso e uscita mediati)


def costo_proprio(utilizzo, ore_gestione_mese):
    """Euro per milione di token generati, se il server lavora per la frazione 'utilizzo' del tempo."""
    token_mese = TOKEN_AL_SECONDO * SECONDI_MESE * utilizzo
    return (SERVER_EURO_MESE + ore_gestione_mese * TARIFFA_ORARIA) / (token_mese / 1e6)


print(f"capacità a utilizzo 100%: {TOKEN_AL_SECONDO * SECONDI_MESE / 1e6:.1f} milioni di token al mese")
print("euro per milione di token del server proprio (API di riferimento: 1.00)")
print("utilizzo   0 h gestione   8 h gestione   20 h gestione")
for u in (0.05, 0.20, 0.50, 0.80):
    print(f"{u:7.0%}   {costo_proprio(u, 0):12.2f}   {costo_proprio(u, 8):12.2f}   {costo_proprio(u, 20):13.2f}")

print()
print("utilizzo minimo perché il server proprio costi meno dell'API, per prezzo dell'API (euro per milione di token)")
print("prezzo API   0 h gestione   8 h gestione   20 h gestione")
for prezzo in (1.0, 5.0, 20.0, 50.0):
    righe = []
    for ore in (0, 8, 20):
        u_min = (SERVER_EURO_MESE + ore * TARIFFA_ORARIA) / (TOKEN_AL_SECONDO * SECONDI_MESE / 1e6 * prezzo)
        righe.append("mai (>100%)" if u_min > 1 else f"{u_min:.0%}")
    print(f"{prezzo:10.2f}   {righe[0]:>12s}   {righe[1]:>12s}   {righe[2]:>13s}")

# Output:
# capacità a utilizzo 100%: 64.8 milioni di token al mese
# euro per milione di token del server proprio (API di riferimento: 1.00)
# utilizzo   0 h gestione   8 h gestione   20 h gestione
#      5%          61.73         185.19          370.37
#     20%          15.43          46.30           92.59
#     50%           6.17          18.52           37.04
#     80%           3.86          11.57           23.15
#
# utilizzo minimo perché il server proprio costi meno dell'API, per prezzo dell'API (euro per milione di token)
# prezzo API   0 h gestione   8 h gestione   20 h gestione
#       1.00    mai (>100%)    mai (>100%)     mai (>100%)
#       5.00            62%    mai (>100%)     mai (>100%)
#      20.00            15%            46%             93%
#      50.00             6%            19%             37%

Le due tabelle si leggono insieme. La prima mostra che con quelle ipotesi il server proprio costa da 61,73 euro per milione di token a utilizzo del 5% fino a 3,86 euro a utilizzo dell'80%, e che 8 ore di gestione al mese portano il costo a utilizzo basso oltre i 180 euro per milione. La seconda risponde alla domanda inversa: da quale utilizzo il proprio server batte l'API. Con un'API da 1 euro per milione, mai; a 5 euro serve il 62% di utilizzo e nessuna ora di gestione; a 20 euro servono il 15% senza gestione, il 46% con 8 ore e il 93% con 20. Il punto è la struttura, non le cifre: il pareggio cade quasi sempre a utilizzi alti, e il tempo di gestione lo sposta più della macchina. Per questo i sette casi che seguono hanno in comune la stessa causa: un utilizzo che non sarà mai alto, o un costo di gestione che non puoi assorbire.

Scenario 1: il carico arriva a picchi

Se le richieste si concentrano in poche ore, devi dimensionare il server per il picco e pagarlo anche quando è fermo. Il test è il fattore di picco, il rapporto fra l'ora più carica e la media oraria. Il programma lo calcola su una giornata costruita di un assistente interno, con un picco alle 11, e poi chiede che cosa succede se compri meno capacità del picco.

"""Fattore di picco: quanto costa dimensionare per il momento peggiore invece che per la media."""
# Richieste per ora in una giornata di un assistente interno, SERIE COSTRUITA: ufficio di giorno e un picco alle 11
orarie = [0, 0, 0, 0, 0, 0, 2, 10, 40, 80, 120, 300, 90, 50, 70, 100, 60, 30, 10, 4, 2, 0, 0, 0]
media = sum(orarie) / len(orarie)
picco = max(orarie)
print(f"richieste al giorno: {sum(orarie)}, media oraria {media:.1f}, picco orario {picco}")
print(f"fattore di picco: {picco / media:.1f}")
print(f"utilizzo medio se dimensioni per il picco: {media / picco:.0%}")

# Con la capacità pari al 60% del picco, quante richieste eccedono nell'ora peggiore?
capacita = 0.6 * picco
eccesso = sum(max(0, r - capacita) for r in orarie)
print(f"capacità al 60% del picco ({capacita:.0f} richieste/ora): eccedono {eccesso:.0f} richieste su {sum(orarie)} ({eccesso / sum(orarie):.1%})")

# Output:
# richieste al giorno: 968, media oraria 40.3, picco orario 300
# fattore di picco: 7.4
# utilizzo medio se dimensioni per il picco: 13%
# capacità al 60% del picco (180 richieste/ora): eccedono 120 richieste su 968 (12.4%)

Con 968 richieste al giorno la media è di 40,3 all'ora e il picco di 300: fattore 7,4. Dimensionando per il picco, il server lavora in media il 13% del tempo, e con quel valore di utilizzo la tabella precedente dice che il costo per token è alto. Dimensionando al 60% del picco, il 12,4% delle richieste eccede la capacità: se l'eccesso può attendere (coda) o andare altrove, la macchina più piccola va bene; se no, il carico a picchi è un buon motivo per un servizio a consumo, o per il modello ibrido dell'ultima sezione. Chiediti prima se il picco è davvero imprevedibile o solo concentrato in un orario noto: nel secondo caso una coda ben dimensionata, come quella dell'articolo sul dimensionamento, può bastare.

Scenario 2: il modello che ti serve non entra nella tua macchina

I modelli grandi chiedono memoria in proporzione ai parametri. Il programma la calcola dai campi pubblicati nelle config.json di due modelli, uno da circa 7 miliardi e uno da circa 72 (esempi, non raccomandazioni): per ciascuno i pesi a 16, 8 e 4 bit e la cache per token. La nota in coda all'uscita dice che il calcolo ignora i bias di Qwen2.5, e che quattro bit sono un minimo teorico.

"""Quanta memoria chiede un modello, dai parametri pubblici della sua config.json (consultate il 2026-11-13)."""
GIB = 1024 ** 3

MODELLI = {
    # Mistral-7B-Instruct-v0.3 (mistralai) e Qwen2.5-72B-Instruct (Qwen), campi di config.json
    "7B  (Mistral-7B-Instruct-v0.3)": dict(h=4096, i=14336, L=32, a=32, kv=8, v=32768),
    "72B (Qwen2.5-72B-Instruct)": dict(h=8192, i=29568, L=80, a=64, kv=8, v=152064),
}


def parametri(c):
    h, i, L = c["h"], c["i"], c["L"]
    kv_dim = c["kv"] * (h // c["a"])
    strato = h * h + 2 * h * kv_dim + h * h + 3 * h * i + 2 * h   # attenzione + MLP + norme (senza bias)
    return L * strato + 2 * c["v"] * h + h


print("modello                           parametri   pesi 16 bit  pesi 8 bit  pesi 4 bit   KV per token")
for nome, c in MODELLI.items():
    p = parametri(c)
    kv = 2 * c["L"] * c["kv"] * (c["h"] // c["a"]) * 2
    print(f"{nome:32s} {p / 1e9:7.2f} G   {p * 2 / GIB:8.1f} GiB  {p / GIB:7.1f} GiB  {p / 2 / GIB:7.1f} GiB  {kv / 1024:6.0f} KiB")
print("Nota: Qwen2.5 usa bias nei livelli di attenzione, che il calcolo ignora (differenza trascurabile); 4 bit = minimo teorico.")

# Output:
# modello                           parametri   pesi 16 bit  pesi 8 bit  pesi 4 bit   KV per token
# 7B  (Mistral-7B-Instruct-v0.3)      7.25 G       13.5 GiB      6.8 GiB      3.4 GiB     128 KiB
# 72B (Qwen2.5-72B-Instruct)         72.71 G      135.4 GiB     67.7 GiB     33.9 GiB     320 KiB
# Nota: Qwen2.5 usa bias nei livelli di attenzione, che il calcolo ignora (differenza trascurabile); 4 bit = minimo teorico.

Il numero che decide è la colonna a 4 bit del modello grande: 33,9 GiB, minimo teorico, solo per i pesi, prima della cache (320 KiB per token, quindi 1,25 GiB per un contesto da 4096) e del resto del sistema. A 16 bit servono 135 GiB. Se la tua macchina ha meno memoria di quella del modello più la cache, il confronto non è più fra costi: il modello non gira, o gira in modo così degradato da non servire. Se invece il modello ti serve solo per poche richieste difficili, un'API a consumo per quelle sole richieste, con il modello piccolo in casa per il resto, è un'architettura da considerare. Ricorda che la qualità di un modello quantizzato va misurata con il tuo golden dataset, come nell'articolo sulla valutazione, non presunta.

Scenario 3: nessuno può occuparsi del servizio

Questo è il caso che la tabella dei costi mette in numeri: le ore di gestione al mese sono una voce del costo, e se nessuno ha quelle ore, la voce non è zero, è un rischio. Il servizio si ferma di notte, il disco si riempie, un aggiornamento cambia il comportamento. Il test è semplice e non richiede un programma: elenca le attività dell'articolo sul disaster recovery (archiviazione, verifica dei backup, prova di ripristino), il monitoraggio del dimensionamento e gli aggiornamenti di sicurezza, e chiediti a chi stanno assegnate e dentro quale orario. Se la risposta è «a nessuno in particolare», un servizio gestito sposta quel lavoro a chi lo fa di mestiere, e tu paghi per questo. Resta tuo il lavoro di verificare il contratto, che è il tema del prossimo scenario.

Scenario 4: servono garanzie contrattuali o certificazioni che non puoi darti da solo

Alcune attività richiedono di dimostrare a clienti o a un'autorità che il servizio è gestito secondo requisiti precisi. HIPAA, citato spesso in questo contesto, è una legge statunitense sulla sanità e non è il quadro di una PMI europea: per te contano il GDPR e le norme di settore. Dal GDPR viene un principio che vale in entrambe le direzioni: quando affidi un trattamento a un fornitore, l'articolo 28, paragrafo 1, dice che il titolare ricorre unicamente a responsabili che presentino garanzie sufficienti per misure tecniche e organizzative adeguate, e il paragrafo 2 che il responsabile non ricorre a un altro responsabile senza autorizzazione scritta. Per i soggetti nell'ambito della direttiva NIS2, l'articolo 21 paragrafo 2 elenca fra le misure anche la sicurezza della catena di approvvigionamento e dei rapporti con i fornitori.

Il corollario è che il cloud non toglie responsabilità, la sposta in un contratto da leggere: dove stanno i dati, chi sono i sub-responsabili, che cosa succede in caso di incidente, che cosa puoi dimostrare a un cliente. Lo schema europeo di certificazione del cloud (EUCS) è un riferimento che avrei voluto verificare: la pagina ufficiale dell'agenzia competente non era raggiungibile durante la stesura, quindi non lo uso come criterio e non dichiaro il suo stato. Per un requisito certificativo concreto, chiedi al fornitore l'attestazione e leggi che cosa copre.

Quando il fornitore non è europeo

Se il servizio è offerto da un'impresa extra-UE o sposta dati fuori dall'Unione, entra in gioco il capo V del GDPR. L'articolo 44 dice che qualunque trasferimento verso un paese terzo ha luogo soltanto se il titolare e il responsabile rispettano le condizioni del capo; l'articolo 45 ammette il trasferimento se la Commissione ha deciso che il paese terzo garantisce un livello di protezione adeguato. Per gli Stati Uniti, la Commissione ha adottato il 10 luglio 2023 la decisione di adeguatezza sul quadro UE-USA per la protezione dei dati (Data Privacy Framework), decisione di esecuzione (UE) 2023/1795: la pagina ufficiale della Commissione spiega che i dati personali possono fluire verso le imprese statunitensi che aderiscono al quadro.

Questo quadro è stato contestato in giudizio. Il Tribunale dell'Unione europea, con sentenza del 3 settembre 2025 nella causa T-553/23 (Latombe contro Commissione), ha respinto il ricorso. Contro questa sentenza è stata proposta impugnazione dinanzi alla Corte di giustizia il 31 ottobre 2025 (causa C-703/25 P, avviso nella Gazzetta ufficiale C/2025/6610 del 22 dicembre 2025). Nelle fonti che ho consultato il 2026-11-13 non ho trovato l'esito dell'impugnazione: verifica lo stato prima di basare un contratto su questa decisione. La conseguenza pratica per una PMI è che affidarsi a un fornitore statunitense significa dipendere da una decisione ancora sub iudice, mentre un fornitore e un trattamento interamente nell'Unione non pongono il problema dei trasferimenti. Non è una consulenza legale, e non è una raccomandazione di fornitori.

Scenario 5: gli utenti sono lontani

Se gli utenti stanno in più continenti, la distanza fisica pone un limite alla latenza che nessuna ottimizzazione supera. Il programma calcola, con la formula della distanza sulla sfera e assumendo che il segnale viaggi in fibra a circa due terzi della velocità della luce nel vuoto, il minimo teorico dell'andata e ritorno da Francoforte. È un limite inferiore: il valore reale è sempre maggiore, per l'instradamento non rettilineo e per l'elaborazione nei router.

"""Limite fisico della latenza: andata e ritorno in fibra lungo la circonferenza massima, senza router né elaborazione."""
from math import asin, cos, radians, sin, sqrt

R_TERRA_KM = 6371.0
KM_S_FIBRA = 200_000.0     # circa due terzi della velocità della luce nel vuoto: ordine di grandezza per la fibra

CITTA = {"Francoforte": (50.11, 8.68), "Milano": (45.46, 9.19), "New York": (40.71, -74.01),
         "San Paolo": (-23.55, -46.63), "Singapore": (1.35, 103.82), "Sydney": (-33.87, 151.21)}


def distanza_km(a, b):
    (la1, lo1), (la2, lo2) = (tuple(map(radians, a)), tuple(map(radians, b)))
    h = sin((la2 - la1) / 2) ** 2 + cos(la1) * cos(la2) * sin((lo2 - lo1) / 2) ** 2
    return 2 * R_TERRA_KM * asin(sqrt(h))


origine = CITTA["Francoforte"]
print("da Francoforte: distanza e minimo teorico dell'andata e ritorno (il valore reale è sempre maggiore)")
for nome, pos in CITTA.items():
    d = distanza_km(origine, pos)
    print(f"{nome:12s} {d:8.0f} km   {2 * d / KM_S_FIBRA * 1000:6.1f} ms")

# Output:
# da Francoforte: distanza e minimo teorico dell'andata e ritorno (il valore reale è sempre maggiore)
# Francoforte         0 km      0.0 ms
# Milano            518 km      5.2 ms
# New York         6203 km     62.0 ms
# San Paolo        9829 km     98.3 ms
# Singapore       10258 km    102.6 ms
# Sydney          16483 km    164.8 ms

Da Francoforte a New York il minimo è 62 millisecondi, a Singapore 103, a Sydney 165. Per una chat in streaming, dove il primo token arriva dopo l'elaborazione del modello e dopo il viaggio di rete, 165 ms in più sono una frazione piccola dei secondi che una risposta richiede su un processore senza GPU: la distanza conta davvero solo se l'esperienza dipende da molte richieste brevi in sequenza. Se invece la tua app fa dieci chiamate una dopo l'altra per una pagina, il conto da Sydney diventa 1,6 secondi di sola fisica. Prima di replicare l'infrastruttura in più regioni, misura quante chiamate in sequenza fa la tua applicazione.

Scenario 6: usi il sistema solo per una parte dell'anno

Il caso della stagionalità è lo scenario 1 in grande: un utilizzo medio annuale basso, perché per mesi il server è fermo. Dalla tabella del pareggio si ricava il criterio: calcola il tuo utilizzo medio sull'anno, non nel mese di punta, e usalo nella tabella. Un servizio acceso solo per il periodo che serve, o un'API a consumo, pesa per le ore usate; un server fisso pesa per dodici mesi. Verifica però le condizioni contrattuali di un'eventuale macchina a ore (impegno minimo, disponibilità garantita), perché una capacità che non è disponibile nel momento di punta non ti serve. Su questo punto non ho cifre: il listino lo leggi tu, alla data in cui decidi.

Scenario 7: stai verificando un'idea

Per un prototipo che durerà poche settimane, il tempo che spendi a installare e mettere in sicurezza un server è un costo fisso che non si recupera se l'idea viene scartata. Un servizio a consumo ti permette di rispondere alla domanda «serve a qualcuno?» prima di decidere dove ospitare il sistema. Due precauzioni: usa dati non personali, perché un prototipo spesso salta il capitolo contratti, e scrivi fin dall'inizio l'accesso al modello dietro un'interfaccia tua, in modo che passare a un modello in casa sia un cambio di configurazione e non una riscrittura. Se il prototipo ha successo, il programma del pareggio dice quando conviene spostarlo.

Il modello ibrido: regole, non ottimismo

Fra i due estremi c'è l'architettura che tiene un modello in casa per il carico ordinario e per i dati personali, e manda al servizio esterno solo ciò che il locale non può servire. Va scritta come regole, non come intenzione. Il programma implementa quelle del caso costruito: se il contesto supera quello del modello locale la richiesta va al remoto (se la policy lo consente); se il locale ha capacità la richiesta resta in casa; se è saturo e il testo contiene dati personali riconoscibili resta in casa e aspetta; se è saturo e il testo non contiene dati riconosciuti va al remoto. Mostra poi la sostituzione di email e codici fiscali con segnaposto stabili, che si può usare quando la policy ammette l'invio di un testo ripulito.

"""Instradamento a regole fra modello locale e servizio remoto: i dati personali non partono, il carico in eccesso sì."""
import re

EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
CODICE_FISCALE = re.compile(r"\b[A-Z]{6}\d{2}[A-Z]\d{2}[A-Z]\d{3}[A-Z]\b")
CODA_MASSIMA_LOCALE = 3          # richieste in attesa oltre le quali il locale è considerato saturo
TOKEN_MASSIMI_LOCALE = 4000      # contesto massimo del modello locale (esempio)


def contiene_dati_personali(testo):
    return bool(EMAIL.search(testo) or CODICE_FISCALE.search(testo))


def pseudonimizza(testo):
    """Sostituisce email e codici fiscali con segnaposto stabili: il remoto riceve il testo, non le identità."""
    mappa, contatore = {}, 0

    def sostituisci(m):
        nonlocal contatore
        if m.group(0) not in mappa:
            contatore += 1
            mappa[m.group(0)] = f"[PERSONA_{contatore}]"
        return mappa[m.group(0)]

    pulito = CODICE_FISCALE.sub(sostituisci, EMAIL.sub(sostituisci, testo))
    return pulito, mappa


def instrada(richiesta, coda_locale, remoto_consentito=True):
    testo, token = richiesta["testo"], richiesta["token"]
    if token > TOKEN_MASSIMI_LOCALE:
        return ("remoto", "contesto più lungo di quello del modello locale") if remoto_consentito else ("rifiuta", "troppo lungo e remoto non consentito")
    if coda_locale <= CODA_MASSIMA_LOCALE:
        return "locale", "capacità disponibile"
    if contiene_dati_personali(testo):
        # Dati personali: restano locali anche a costo di attendere (oppure si pseudonimizza, se la policy lo permette)
        return "locale", "locale saturo ma il testo contiene dati personali: si attende"
    return ("remoto", "locale saturo, nessun dato personale riconosciuto") if remoto_consentito else ("locale", "remoto non consentito")


casi = [
    ("A", "Riassumi la procedura di rimborso spese", 300, 0),
    ("B", "Riassumi la procedura di rimborso spese", 300, 7),
    ("C", "Scrivi a mario.rossi@esempio.it per il rimborso", 300, 7),
    ("D", "Analizza questo contratto lungo di 30 pagine", 9000, 0),
    ("E", "Analizza questo contratto lungo di 30 pagine", 9000, 0),
]
for nome, testo, token, coda in casi:
    ok = nome != "E"                      # nel caso E la policy vieta il remoto
    print(nome, instrada({"testo": testo, "token": token}, coda, ok))

print()
esempio = "Cliente RSSMRA80A01H501U, scrivere a mario.rossi@esempio.it e a anna.verdi@esempio.it, poi richiamare mario.rossi@esempio.it"
print(pseudonimizza(esempio))

# Output:
# A ('locale', 'capacità disponibile')
# B ('remoto', 'locale saturo, nessun dato personale riconosciuto')
# C ('locale', 'locale saturo ma il testo contiene dati personali: si attende')
# D ('remoto', 'contesto più lungo di quello del modello locale')
# E ('rifiuta', 'troppo lungo e remoto non consentito')
#
# ('Cliente [PERSONA_3], scrivere a [PERSONA_1] e a [PERSONA_2], poi richiamare [PERSONA_1]', {'mario.rossi@esempio.it': '[PERSONA_1]', 'anna.verdi@esempio.it': '[PERSONA_2]', 'RSSMRA80A01H501U': '[PERSONA_3]'})

Nell'uscita il caso A resta locale, il B (saturo, nessun dato personale) va al remoto, il C (saturo, con un indirizzo email) resta locale e attende, il D va al remoto per la lunghezza del contesto, e il E, con la stessa lunghezza ma remoto vietato, viene rifiutato con un messaggio chiaro invece di tentare comunque. Nella pseudonimizzazione, ogni identità ha lo stesso segnaposto nelle sue ripetizioni, e la mappa che permette di ripristinare i nomi resta in casa. Il limite da non dimenticare: un'espressione regolare riconosce email e codici fiscali, non un nome in un testo libero né un caso clinico descritto a parole. La decisione di mandare fuori un testo non va affidata a un riconoscitore di formati senza una revisione, e va registrata con l'impronta e senza il contenuto, come nell'articolo sull'audit log.

Il lock-in si può ridurre, e c'è una norma

Chi teme di restare prigioniero di un servizio ha uno strumento nuovo: il regolamento sui dati (UE) 2023/2854, che si applica dal 12 settembre 2025, disciplina il passaggio fra fornitori di servizi di trattamento dei dati. L'articolo 29 prevede che dal 12 gennaio 2027 i fornitori non impongano al cliente tariffe di passaggio, e che dall'11 gennaio 2024 fino a quella data possano imporre tariffe ridotte non superiori ai costi direttamente connessi al passaggio. Non ho verificato come questa disciplina si applichi a un servizio di inferenza di modelli rispetto a un servizio di calcolo generico: leggi la definizione di «servizio di trattamento dei dati» nel regolamento e il tuo contratto prima di contarci. Resta valido il consiglio pratico dello scenario 7: tieni l'accesso al modello dietro un'interfaccia tua.

Domande frequenti

Conviene il cloud se il mio utilizzo è basso?

Di norma sì, perché il costo fisso di un server si ripartisce su pochi token. Il programma del pareggio lo mostra con ipotesi dichiarate: a utilizzo del 5% il server proprio costa decine di volte il prezzo di un'API da 1 euro per milione di token. Sostituisci le ipotesi con i tuoi dati.

Il cloud europeo risolve il problema dei trasferimenti di dati?

Per il trasferimento verso paesi terzi del capo V del GDPR, un trattamento che resta nell'Unione non pone la questione dell'articolo 44. Restano gli altri obblighi, a cominciare dal contratto con il responsabile dell'articolo 28 e dalla scelta dei sub-responsabili.

La decisione di adeguatezza UE-USA è ancora valida?

Risulta adottata con la decisione di esecuzione (UE) 2023/1795 e il ricorso Latombe è stato respinto dal Tribunale il 3 settembre 2025. Contro la sentenza pende impugnazione (C-703/25 P): non ho trovato un esito alla data di consultazione, quindi verifica lo stato aggiornato.

Posso usare un servizio remoto solo per i picchi?

Sì, con regole esplicite su che cosa può uscire e che cosa no. I dati personali riconoscibili restano in casa, e la decisione di inviare un testo all'esterno va registrata e verificata a campione.

Che cosa sai fare adesso

Sai calcolare, con le tue misure, da quale utilizzo un server proprio conviene rispetto a un'API a consumo, e quanto pesa il tempo di chi lo gestisce. Sai riconoscere i sette casi in cui conviene il servizio gestito: picchi, modelli troppo grandi, assenza di chi lo gestisca, requisiti contrattuali, utenti lontani, stagionalità, prototipi. Sai che il cloud sposta responsabilità in un contratto da leggere, dove i trasferimenti verso paesi terzi seguono il capo V del GDPR e la decisione UE-USA ha ancora un'impugnazione pendente. Sai scrivere come regole l'instradamento fra locale e remoto. L'ultimo articolo della serie raccoglie il percorso: il riepilogo e che cosa portarti via.

Nella stessa serie trovi anche il server Ollama su un VPS europeo, la scelta fra modello piccolo e grande e la privacy e il GDPR con un modello in casa.