// TOM'S HARDWARE ITALIA — HARDWARE & GADGET
I team Kubernetes frenano l'automazione mentre cresce l'AI
Una nuova indagine condotta su 321 professionisti Kubernetes in contesti enterprise mostra un divario netto tra fiducia nell'automazione e disponibilità a delegarle decisioni sulle risorse. L'82% dichiara fiducia elevata o completa nei controlli automatizzati di delivery, ma il 71% richiede ancora una revisione umana prima di applicare raccomandazioni di ottimizzazione. Il dato che pesa di più è un altro: solo il 27% consente modifiche automatiche a CPU e memoria, anche quando sono presenti guardrail.
Il punto è tecnico, non culturale. Distribuire codice viene percepito come un'azione additiva: si porta valore in produzione, il percorso di rollback è noto e un errore tende a emergere rapidamente. Il rightsizing, invece, viene visto come un intervento sottrattivo, perché riduce margini di sicurezza su servizi già in esecuzione e cambia il rapporto tra workload, scheduler e risorse disponibili.
Quando si modificano le request di CPU o memoria, Kubernetes può schedulare, prioritizzare e allocare diversamente i workload. L'effetto non è sempre visibile lungo una normale pipeline CI/CD e può emergere solo più avanti, magari durante un picco di traffico. In quel momento ricostruire la causa diventa complesso, perché nel frattempo possono essere cambiate release, configurazioni e pattern d'uso.
Questa prudenza esisteva già prima dell'arrivo dell'AI inference su larga scala, ma i carichi di intelligenza artificiale rendono il problema più costoso. Le workload accelerate da GPU hanno un costo orario molto più alto rispetto alla CPU, mentre il loro comportamento può essere più bursty e meno prevedibile per team abituati a servizi tradizionali. L'over-provisioning, in questo scenario, smette di essere una piccola inefficienza e diventa una voce economica difficile da ignorare.
Il nodo si collega anche al dibattito più ampio sull'illusione dell'automazione nei processi aziendali: delegare una decisione non basta se chi gestisce l'infrastruttura non può capire perché quella decisione è stata presa. Nel sondaggio, il 48% dei practitioner indica la visibilità sulle scelte del sistema come fattore principale per aumentare la fiducia, il 25% chiede guardrail comprovati e il 23% vuole rollback istantaneo.
La scala peggiora il quadro. L'ottimizzazione delle risorse non è una singola leva come l'horizontal scaling: può coinvolgere request e limit di CPU e memoria, quindi almeno quattro dimensioni per workload, moltiplicate per centinaia o migliaia di servizi per cluster. I dati indicano che l'ottimizzazione manuale inizia a rompersi attorno a 250 modifiche al giorno, una soglia che i carichi IA possono superare rapidamente.
La risposta più credibile non sembra essere l'autonomia totale imposta dall'alto, ma una adaptive autonomy progressiva. I team più maturi partono da modalità read-only, namespace di sviluppo e limiti definiti, poi ampliano il raggio d'azione man mano che confrontano raccomandazioni e risultati. In produzione, la fiducia non nasce dalla promessa di automazione completa: nasce dalla capacità di spiegare, contenere e annullare ogni intervento.