Collegare l'IA al server: così un agente IA fa il deploy e gestisce il tuo server

Finora la maggior parte delle persone usa l'IA come un collega molto preparato al telefono: descrivi un problema del server, ricevi un comando da provare, lo copi nella console, riporti nella chat il messaggio di errore e ricominci da capo finché tutto funziona. Non appena colleghi l'IA al tuo server, questa deviazione non serve più. Un agente IA come Claude Code, OpenAI Codex CLI o Gemini CLI accede da solo al server via SSH, legge i log, controlla la configurazione, applica le modifiche, verifica il risultato e annota ciò che ha fatto. Tu stabilisci il compito e approvi i passaggi che non si possono annullare.

Questo articolo è un resoconto dal campo. In KernelHost un agente IA lavora da mesi, ogni giorno, sulla nostra infrastruttura: portale clienti, monitoraggio, sistemi di pagamento, documentazione. Mostriamo come è costruito il collegamento tra agente e server, quale procedura segue l'agente quando fa il deploy sui sistemi di produzione, quali regole impediscono che qualcosa vada storto o trapeli all'esterno e che cosa deve offrire un server perché tutto questo funzioni. Le basi su strumenti e architetture si trovano nell'articolo Server gestito da IA: collegare agenti in sicurezza, l'installazione sul server nella guida per Claude Code e Codex CLI.

Collegare l'IA al server: che cosa significa

Collegare un'IA al server significa dare a un agente IA un accesso proprio e controllato alla riga di comando del server, di solito tramite una chiave SSH. Da quel momento l'agente non si limita a proporre i comandi: li esegue da solo, legge l'output e ne ricava il passo successivo. Il modello linguistico continua a girare presso il fornitore (Anthropic, OpenAI o Google); sul tuo computer o sul server gira solo un leggero strumento a riga di comando che invia i comandi.

La parola decisiva è «controllato». Un agente con accesso al server non è un pilota automatico, ma un collaboratore molto veloce che chiede prima di ogni azione invasiva. Quanto può fare senza chiedere lo decidi tu: dal semplice accesso in sola lettura fino all'installazione autonoma degli aggiornamenti secondo una procedura fissa.

Chatbot o agente: la differenza in una tabella

Così mezz'ora di avanti e indietro si riduce spesso a pochi minuti, e la fonte di errore «comando ricopiato male» sparisce del tutto.

Che cosa fa un agente IA sul server: esempi dalla nostra attività

Gli esempi che seguono vengono dal nostro lavoro di tutti i giorni. Tralasciamo nomi, indirizzi e credenziali, ma le procedure sono reali.

Deployment con backup e rollback

Quando modifichiamo qualcosa nel portale clienti o in uno script del server, è l'agente a occuparsi del rilascio. Prima confronta il file sul server con l'ultima versione nota, per non sovrascrivere modifiche fatte da altri. Poi crea un backup datato fuori dalla directory web, scrive uno script di rollback, controlla la sintassi del nuovo file, lo installa con gli stessi proprietari e permessi di prima e infine testa la funzione interessata. Solo quando è tutto verde comunica che il lavoro è concluso. La procedura esatta è descritta più avanti, nella sezione sul deploy.

Diagnosi dei problemi: dal sintomo alla causa in pochi minuti

«Dal nostro ufficio il sito non è raggiungibile, da fuori invece sì.» Un tempo questo avrebbe significato una lunga ricerca. L'agente controlla le regole del firewall, cerca l'indirizzo dell'ufficio nei log del software di protezione, trova la regola che è scattata e spiega quale richiesta l'ha attivata. La decisione su cosa fare resta a noi, il lavoro da detective no. Con i tipici errori del web server come 502 Bad Gateway o un disco pieno lavora allo stesso modo: legge i log con journalctl e quelli dell'applicazione, formula un'ipotesi e la dimostra prima di cambiare qualcosa.

Monitoraggio che l'agente costruisce da solo

Buona parte del nostro monitoraggio è nata in collaborazione con l'agente: piccoli script di controllo che ogni pochi minuti, tramite un cron job, testano un servizio end-to-end e in caso di errore mandano un messaggio sul cellulare, per esempio tramite un bot Telegram. L'agente scrive lo script, lo prova provocando apposta un errore, configura il cron job e documenta come silenziare l'allarme. Come costruire in generale qualcosa del genere lo spiega l'articolo Configurare il monitoraggio del server.

Panoramiche e lavori di pulizia

Quali server sono ancora accesi anche se il relativo contratto è stato disdetto? Quali servizi aggiuntivi vengono pagati ma non si usano più? L'agente risponde a domande come queste interrogando database e interfacce in sola lettura e presentando il risultato in una tabella. Può fare pulizia solo dopo l'approvazione, e prima verifica che la macchina sia davvero inutilizzata, per esempio guardando il traffico degli ultimi giorni.

Documentazione che cresce da sola

Ogni modifica si chiude con una voce nel registro delle modifiche e, se serve, con un'aggiunta al manuale operativo. All'agente costa pochi secondi e a noi fa risparmiare ore in seguito, perché la domanda «Ma perché è fatto così?» ha una risposta scritta.

I vantaggi quando l'IA lavora direttamente sul server

• Velocità: l'agente legge in pochi secondi ciò che a una persona richiede minuti, e mette subito alla prova un'ipotesi invece di limitarsi a descriverla.
• Completezza: legge l'intera configurazione, compresi i file inclusi, e le righe di log attorno all'errore, non solo l'estratto che qualcuno ha ritenuto rilevante.
• Procedura sempre uguale: backup, controllo della sintassi e verifica finale avvengono ogni volta, anche il venerdì sera e anche alla ventesima piccola modifica.
• Documentazione senza lavoro extra: ogni modifica è descritta, con il motivo, la posizione del backup e la procedura di rollback.
• Automazione senza studiare lo scripting: script di controllo, cron job e report nascono da una descrizione in linguaggio naturale e vengono testati prima dell'uso.
• Si impara strada facendo: l'agente spiega che cosa fa e perché. Chi segue il suo lavoro conosce il proprio server molto meglio già dopo qualche settimana.

Tre architetture e quella che usiamo noi

Esistono tre modi collaudati per collegare un agente a un server. Si differenziano per dove gira lo strumento e per dove si trovano le credenziali.

La nostra scelta: agente sulla postazione di lavoro, server via SSH

Noi lavoriamo con la prima variante. L'agente gira sul computer di lavoro, ogni server ha una voce nella configurazione SSH e l'agente si collega con una chiave propria. Il motivo principale: gestiamo molti sistemi, e proprio in questo modo un unico agente può seguire una causa attraverso più server nella stessa sessione, per esempio dal web server al database fino al firewall. Inoltre l'accesso al fornitore IA e le chiavi si trovano in un posto che proteggiamo comunque. Chi ha un solo server e vuole report automatici di notte si trova bene con la seconda variante. Vantaggi e svantaggi sono approfonditi nell'articolo sul server gestito da IA.

Guida: collegare un agente IA al server via SSH

I sette passi che seguono funzionano allo stesso modo con Claude Code, Codex CLI e Gemini CLI. Gli esempi usano l'indirizzo riservato alla documentazione 203.0.113.10 e il nome utente deploy: sostituiscili entrambi con i tuoi valori. Il requisito è un server con accesso tramite chiave SSH, come descritto nell'articolo Proteggere SSH con l'accesso tramite chiave.

Passo 1: generare una chiave SSH riservata all'agente

L'agente non riceve mai la tua chiave personale, ma una propria. Così puoi revocargli l'accesso in qualsiasi momento senza perdere il tuo, e nei log si riconosce quale accesso è arrivato dall'agente.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 genera chiavi corte, è veloce ed è considerato sicuro. Il commento ki-agent comparirà poi nel file authorized_keys del server e rende la chiave riconoscibile a colpo d'occhio.

Passo 2: registrare la chiave pubblica sul server

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Se vuoi limitare ancora di più l'accesso, aggiungi delle opzioni davanti alla chiave nel file ~/.ssh/authorized_keys sul server. from= consente l'accesso solo da un indirizzo preciso, mentre no-agent-forwarding e no-port-forwarding impediscono che la connessione venga usata come trampolino verso altri sistemi:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Se poi il server risponde con Permission denied (publickey), ti aiuta l'articolo Risolvere l'errore SSH Permission denied (publickey).

Passo 3: creare un alias host nella configurazione SSH

Con un alias l'agente deve conoscere solo un nome breve e usa sempre la chiave giusta:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Da quel momento basta ssh web-prod "systemctl status nginx". IdentitiesOnly yes impedisce a SSH di provare in sequenza tutte le altre chiavi del tuo portachiavi. Per ogni altro server crei un blocco a parte; per i sistemi di test e di produzione conviene usare nomi diversi come web-test e web-prod, così un eventuale scambio salta all'occhio già dal nome.

Passo 4: installare l'agente ed effettuare l'accesso

Claude Code, Codex CLI e Gemini CLI girano su Linux, macOS e Windows e si autenticano con un account del fornitore o con una chiave API. L'installazione e l'accesso senza browser sono descritti nella guida passo dopo passo. Per la variante con la postazione di lavoro installa lo strumento sul tuo computer, non sul server.

Passo 5: stabilire le regole che l'agente deve rispettare

All'avvio tutti e tre gli strumenti leggono un file di regole nella directory di lavoro: Claude Code legge CLAUDE.md, Codex CLI AGENTS.md e Gemini CLI GEMINI.md. Lì scrivi come si lavora sui tuoi server. Un punto di partenza collaudato:

# Regole per lavorare sui server

- Prima di ogni modifica creare un backup datato, fuori dalla directory web.
- Prima del rilascio verificare la sintassi (nginx -t, php -l, apachectl configtest).
- Dopo il rilascio verificare servizio, log e funzionalità e riportare il risultato.
- Mai mostrare password, chiavi API e token, mai copiarli in un file.
- Cancellazioni, modifiche al database e tutto ciò che è irreversibile solo dopo approvazione esplicita.
- Non modificare direttamente i file gestiti dal pannello di controllo.
- Rimuovere i file di test al termine del test.

Le regole crescono con il tempo. Ogni volta che l'agente fa qualcosa in modo diverso da come vuoi tu, la correzione va scritta in questo file come nuova regola. Dopo qualche settimana lavora come lavoreresti tu.

Passo 6: configurare approvazioni e allowlist

Per impostazione predefinita gli strumenti chiedono conferma prima di ogni comando che modifica qualcosa. All'inizio è giusto così. I comandi di sola lettura che ti ritrovi a confermare di continuo puoi autorizzarli in modo permanente. In Claude Code si fa nel file .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Tutto ciò che non è in questo elenco richiede ancora la tua approvazione. Le opzioni che disattivano tutte le richieste di conferma vanno usate al massimo su una macchina di test usa e getta.

Passo 7: il primo compito, solo in lettura

Inizia con compiti che non possono cambiare nulla e osserva come procede l'agente:

Controlla su web-prod gli errori di nginx delle ultime 24 ore e indica le tre
cause più frequenti, ciascuna con una prova tratta dal log. Non modificare nulla.

Solo quando le analisi sono corrette passi a piccole modifiche, per esempio una nuova rotazione dei log o un servizio systemd, e solo dopo ai deployment sul sistema di produzione.

Come fa il deploy l'agente: la nostra procedura per ogni modifica al sistema di produzione

Un agente IA può fare il deploy su un sistema di produzione solo seguendo una procedura fissa, che comprende un backup, un rollback già preparato e un controllo prima e dopo il rilascio. Da noi questa procedura si presenta così:

1. Verificare lo stato attuale. Il file sul server viene confrontato con l'ultima versione nota. Se nel frattempo qualcun altro l'ha modificato, l'agente si ferma e chiede, invece di sovrascrivere la modifica altrui.
2. Creare un backup. I file interessati finiscono, con la data, in una cartella di backup fuori dalla directory web. Un backup dentro la directory web potrebbe essere scaricabile pubblicamente.
3. Preparare il rollback. Un piccolo script che ripristina la versione precedente con un solo comando viene scritto prima della modifica, non in piena emergenza.
4. Controllare la sintassi. Il nuovo file viene controllato prima del rilascio, con php -l per PHP e con nginx -t per nginx. Così un errore di sintassi non arriva nemmeno al sistema di produzione.
5. Installare con i permessi giusti. Proprietario, gruppo e permessi del file vengono ripresi dalla versione precedente. Dopo gli errori di sintassi, i permessi sbagliati sono la causa più frequente di interruzioni dopo un aggiornamento.
6. Testare senza effetti collaterali. Si testa in sola lettura, con dati di prova inventati o in un ambiente isolato, mai con ordini reali o dati reali dei clienti.
7. Verificare in produzione. Dopo il rilascio si controllano lo stato HTTP, il log degli errori e la funzione modificata.
8. Documentare. Si aggiornano il registro delle modifiche e il manuale operativo, indicando dove si trova il backup e il comando per il rollback.

Come sequenza di comandi, con segnaposto al posto dei percorsi reali, appare più o meno così:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Perché il rollback nasce prima della modifica

Quando qualcosa va storto, nessuno è nelle condizioni migliori per pensare a un rollback pulito. Se lo script è già pronto, annullare la modifica è questione di secondi, e l'agente può farlo anche da solo se il controllo dopo il rilascio fallisce. È questa la differenza più grande tra un agente che cambia qualcosa «al volo» e uno a cui si affida un sistema di produzione.

Test che non possono rompere nulla

Molte funzioni non si possono testare senza che succeda qualcosa: un ordine, un pagamento, un'email. Qui aiutano tre tecniche. Primo, le esecuzioni di prova (dry run) offerte dallo strumento stesso. Secondo, identificativi inventati che di sicuro non esistono da nessuna parte. Terzo, un ambiente isolato: un processo che gira in un proprio network namespace senza rete (unshare -n) non può raggiungere un'interfaccia esterna né comprare qualcosa per errore, ma continua a vedere il database locale attraverso il socket Unix. Dopo il test tutti i file di prova vengono rimossi.

Le azioni che costano denaro richiedono un lock

Quando una procedura ordina, fattura o cancella qualcosa, non deve mai girare due volte in contemporanea, nemmeno se qualcuno fa doppio clic o l'agente ripete un comando. La soluzione più semplice su Linux è flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "già in esecuzione"

Nelle applicazioni con database svolge la stessa funzione un lock con nome (GET_LOCK in MySQL e MariaDB), nelle API una Idempotency-Key: ne parliamo più avanti, nella sezione sulla KernelHost API.

Sicurezza: accesso per l'agente senza che nulla trapeli

La preoccupazione che sentiamo più spesso è: «E i miei dati?» La risposta onesta: tutto ciò che l'agente legge viene inviato al modello linguistico del fornitore per essere elaborato. Per questo, con le regole che seguono, sei tu a decidere che cosa gli è consentito vedere.

I segreti non vanno nella chat

Password, chiavi API e token non si scrivono mai in un compito e l'agente non li mostra mai. Gli script li leggono da file con permessi 600, che l'agente non ha bisogno di visualizzare per usare lo script. Se nonostante tutto una chiave finisce nella chat, la si revoca subito presso il fornitore e se ne genera una nuova. Nemmeno i frammenti vanno nella chat: i primi caratteri di una chiave non aiutano nessuno nella diagnosi, ma accorciano il lavoro di un attaccante.

Chiavi proprie, permessi propri, revocabili in qualsiasi momento

Ogni agente riceve una propria chiave SSH, e ogni chiave si riconosce in authorized_keys dal suo commento. Per revocare l'accesso basta cancellare quella riga. Dove basta, l'agente lavora con un proprio utente e una regola sudo che consente solo i comandi necessari. Le API ricevono chiavi proprie con i permessi minimi indispensabili, in sola lettura per le semplici analisi.

Approvazioni: ciò che non succede mai senza una persona

Da noi, senza consenso esplicito, l'agente non può cancellare, scrivere nei database, allentare regole del firewall o di protezione, fermare macchine né ordinare nulla. Gli strumenti aiutano in questo: Claude Code mette in pausa le azioni invasive e si può inoltre configurare in modo che un filtro di sicurezza riconosca i comandi rischiosi e li blocchi fino all'approvazione. Dalla nostra esperienza quotidiana: questo filtro ha fermato più di una volta un'azione tecnicamente corretta, ma appunto irreversibile. È stata eseguita solo dopo che una persona l'aveva approvata esplicitamente. È esattamente così che deve essere.

Tracciabilità: log, elenco delle modifiche, backup

Ogni sessione lascia tracce leggibili da una persona: i backup datati, lo script di rollback, la voce nel registro delle modifiche e gli accessi nel log di sistema. Chi inoltre gestisce /etc in Git con etckeeper vede ogni modifica alla configurazione come diff. Ciò che non è tracciabile non si può nemmeno annullare. La base resta una strategia di backup che funzioni, perché un agente non sostituisce un backup.

Quale server è adatto a un agente IA?

Un server per la gestione assistita dall'IA ha bisogno di accesso root completo, login con chiave SSH, connessioni in uscita senza restrizioni, una protezione DDoS permanente e, idealmente, un'API con cui ordinare e controllare i server in modo automatico. Non gli serve una GPU, perché il modello linguistico gira presso il fornitore.

Perché KernelHost per i server gestiti da IA

In linea di principio un agente IA può lavorare con qualsiasi server su cui ottiene una shell. Nella pratica, però, è l'ambiente a decidere quanto lavoro puoi davvero affidargli. Su un server root KVM o un server dedicato KernelHost non ci sono account limitati, né ostacoli per le connessioni HTTPS verso i fornitori IA, né vincoli contrattuali che rendano costoso sperimentare. La protezione DDoS permanente è attiva su ogni server senza costi aggiuntivi, e per i carichi di calcolo intensivi c'è la linea VDS Professionale con core dedicati. La fatturazione è PrePaid: nessun contratto, nessuna durata minima, nessun costo di attivazione. Se vuoi provare prima, inizia con il test server gratuito.

La KernelHost API: il tuo agente ordina e controlla i server da solo

La leva più grande si trova un livello sopra il singolo server. Tramite la KernelHost API un agente può consultare prodotti e prezzi, ordinare server, leggere lo stato dei propri servizi, avviare, fermare e riavviare server, nonché inviare disdette e revocarle. Così «Configurami un server di test» diventa un unico compito: l'agente ordina la macchina, attende l'attivazione, si collega via SSH, installa l'applicazione e comunica l'indirizzo.

Per l'uso da parte degli agenti l'API è stata costruita volutamente in modo prudente. Le chiavi API ricevono solo i permessi di cui hanno bisogno: una chiave per le analisi non può ordinare proprio nulla. Una Idempotency-Key garantisce che un ordine ripetuto dall'agente dopo un errore di timeout non venga eseguito due volte. Le richieste sono limitate per chiave, per account e per indirizzo, così nemmeno un agente finito in un ciclo infinito può scatenare una valanga. E ogni recupero di credenziali genera una notifica via email, così sai quando un agente ha letto delle credenziali.

Quanto costa un server gestito da IA?

Le voci di costo sono due. La prima è il server stesso: se l'agente lavora via SSH, il server non richiede dotazioni particolari e basta qualsiasi server root su cui la tua applicazione gira già. Se l'agente gira direttamente sul server, lo strumento in sé occupa solo poche centinaia di megabyte di RAM, e un server root con 2 vCPU e 4 GB di RAM basta, se non ci gira molto altro. La seconda è il modello linguistico: o un abbonamento del fornitore che include l'uso dello strumento a riga di comando, o una chiave API con fatturazione a consumo. Con un uso quotidiano intensivo l'abbonamento di solito conviene di più; per i compiti automatizzati senza una persona davanti la chiave API è la strada pulita, perché si può limitare con un budget mensile. I prezzi aggiornati dei server li trovi nella pagina Noleggio server root.

Errori frequenti e come evitarli

• L'agente lavora con la chiave personale dell'amministratore. In quel caso il suo accesso non si può revocare separatamente né distinguere nei log. Soluzione: una chiave propria con un commento proprio.
• Tutte le richieste di conferma sono disattivate. Il primo giorno fa risparmiare qualche clic, prima o poi costa un server. Soluzione: allowlist per i comandi di sola lettura, approvazione per tutto ciò che interviene sul sistema.
• Nessun backup prima della modifica. Soluzione: backup e script di rollback come regola fissa in CLAUDE.md o AGENTS.md.
• Backup nella directory web. Un file come config.php.bak nella webroot può essere scaricabile pubblicamente, password del database compresa. Soluzione: una cartella di backup fuori dalla directory web con permessi 700.
• Segreti nel prompt. Soluzione: credenziali solo in file con permessi 600 letti dagli script e, in caso di svista, rigenerarle subito.
• Doppia esecuzione. Un doppio clic o una richiesta ripetuta ordina due volte. Soluzione: un lock con flock o una Idempotency-Key.
• File gestiti dal pannello di controllo modificati direttamente. Il pannello li sovrascrive al prossimo aggiornamento, oppure smette di funzionare per colpa loro. Soluzione: escludere questi file nelle regole e fare le modifiche tramite il pannello o la sua interfaccia.
• Output accettati senza verifica. Un agente che non capisce un output tira a indovinare. Soluzione: chiedere prove («mostrami la riga del log») e far verificare i risultati in produzione.

In sintesi

• Collegare un'IA al server significa dare a un agente come Claude Code, Codex CLI o Gemini CLI una chiave SSH propria e regole chiare.
• L'agente legge i log, applica le modifiche, verifica il risultato e lo documenta; i passaggi invasivi avvengono solo con approvazione.
• Ogni deployment segue una procedura fissa: verificare lo stato attuale, fare il backup, preparare il rollback, controllare la sintassi, installare, testare, verificare in produzione, documentare.
• I segreti non vanno mai nella chat, e le azioni che costano denaro richiedono un lock contro la doppia esecuzione.
• Il server ha bisogno di accesso root, chiavi SSH, connessioni in uscita libere e protezione DDoS, ma non di una GPU.
• I server KernelHost soddisfano tutti i requisiti di serie, PrePaid e senza vincoli contrattuali, e con la KernelHost API l'agente può perfino ordinare e controllare i server da solo.