Il riflesso di chi vuole introdurre l’intelligenza artificiale in un sistema legacy è quasi sempre lo stesso: rifare tutto. È una reazione comprensibile ma, nella maggior parte dei casi, sbagliata. Un’applicazione che funziona da quindici anni non è solo codice vecchio: è un deposito di regole di business, casi limite e vincoli normativi che nessuno ha mai documentato per intero. Sostituirla significa obbligare un team a riscoprire tutto mentre il vecchio sistema continua a gestire l’operatività.

Qui sta il punto che separa i progetti che restano in piedi da quelli che falliscono: l’AI va trattata come un’estensione, non come una nuova fondazione. Le imprese che ci riescono non aggiungono modelli al core, ma costruiscono un perimetro attorno al core.

Nel concreto, esistono almeno quattro schemi di integrazione che evitano di toccare i moduli critici. Il primo è il middleware: l’AI non interroga mai direttamente il database di produzione, ma passa da un livello che espone operazioni definite e ristrette. Questo limita i danni da richieste malformate e da attacchi di prompt injection. Il secondo è la retrieval-augmented generation, che indicizza documenti e record in un database vettoriale separato: gli utenti conversano con anni di informazioni, e il sistema legacy continua a conservare i dati come ha sempre fatto. Il terzo è l’integrazione event-driven, dove i servizi AI ascoltano gli eventi o le modifiche catturate dal change data capture e reagiscono in tempo quasi reale, per esempio segnalando una transazione sospetta. Il quarto è il pattern Strangler Fig, descritto da Martin Fowler: le funzionalità potenziate dall’AI passano da una facciata, mentre tutto il resto gira ancora sul vecchio sistema; il passaggio può avvenire pezzo per pezzo, senza un cutover rischioso.

La tesi di fondo, per chi gestisce ambienti on-premise o ibridi, è che il problema non è il modello, ma il governo degli accessi. Quando l’AI sta sopra un legacy, il perimetro di sicurezza non coincide più con l’applicazione: coincide con le API, con i database vettoriali e con i flussi di eventi. Chi controlla questi punti controlla cosa il modello può leggere, scrivere e dimenticare. Questo spiega perché i progetti di successo partono in sola lettura: ricerca, sintesi, reporting. L’accesso in scrittura arriva dopo, con approvazione umana per le azioni sensibili.

Le implicazioni vanno oltre il singolo progetto. Per i fornitori di software, la crescita dell’AI a strati riduce la pressione a vendere sostituzioni complete e sposta il valore verso piattaforme di integrazione, pipeline di indicizzazione e tooling di observability. Per i team interni, premia chi conosce i dati e i flussi, non chi sa solo orchestrare un fine-tuning. E per chi valuta deployment on-premise, il messaggio è strutturale: una parte rilevante dell’AI aziendale può restare dentro i confini dell’infrastruttura esistente, grazie a RAG e middleware, senza migrare tutto su cloud. AI-RADAR dedica un’analisi su /llm-onpremise ai trade-off tra costo, controllo e sovranità dei dati per chi valuta deployment on-premise.

Non è però un percorso a costo zero. Le API dei modelli commerciali si pagano in genere per token, e i costi operativi di monitoraggio, valutazione e riaddestramento continuano dopo il lancio. Trattare lo strato AI come un progetto una tantum è l’errore che porta al degrado silenzioso quando i dati e le condizioni cambiano. L’approccio prudente è partire da un caso d’uso stretto e lasciare che i risultati reali decidano quanto estendere lo strato intelligente.