AI-OPS · Percorso 4: Costruire e gestire
LLMOps per ambienti connessi, separati e Air-Gap
Tre giorni dopo i quali un update del modello arriva in sicurezza anche quando nessun cavo porta verso l’esterno.
- Durata
- 3 giorni
- Gruppo
- da 4 a 12 persone
- Formato
- Inhouse · Nel lab
- Lingua
- Tedesco o inglese
- Preavviso
- da 4 settimane
- Prezzo
- 23.700 € forfettario, IVA esclusa
Erogazione a partire da quattro partecipanti effettivamente iscritti. La data viene confermata per iscritto dopo aver concordato contenuti, prerequisiti e disponibilità.
Per chi è questo track
Team di piattaforma ed esercizio responsabili di una piattaforma LLM in ambienti con connettività internet limitata o assente: pubbliche amministrazioni, infrastrutture critiche, difesa, industria manifatturiera con reti separate. Anche per team la cui piattaforma oggi è connessa, ma che hanno bisogno di uno scenario di separazione solido.
Per chi no
Non per team che non gestiscono né pianificano ancora una piattaforma. Loro costruiscono prima il fondamento nel Sovereign AI Platform Engineering (AI-PLATFORM).
Situazione di partenza
La Sua piattaforma AI deve girare in un ambiente in cui le solite ricette MLOps falliscono: nessun accesso a Hugging Face, nessuna container registry su internet, nessun backend di telemetria nel cloud. Modelli, container e firme devono entrare in modo controllato attraverso un varco, gli update non devono rompere nulla e un rollback deve funzionare senza supporto del produttore dall’esterno.
Questo esiste dopo il track
- Un flusso di artefatti documentato per modelli, container, prompt e configurazioni con versionamento e catena di firme
- Un processo di promotion dev-test-prod con gate definiti, incluso un gate di valutazione prima di ogni cambio di modello
- Un concetto di update offline: pacchetto di trasferimento, processo di varco, verifica delle firme e staging senza accesso a internet, provato una volta per intero nel Lab
- Un runbook di incident e rollback per regressione del modello, artefatti compromessi e guasto della piattaforma, testato in un’esercitazione
- Un concetto di monitoring che fa a meno di un backend cloud e rende comunque visibile la qualità del modello
Prerequisiti
Esperienza di esercizio con i container e comprensione di base di CI/CD. Ideale la partecipazione precedente ad AI-PLATFORM o un ambiente di inferenza esistente nella propria organizzazione.
Preparazione prima del track
Schizza in anticipo il Suo ambiente target su una pagina: zone di rete, passaggi consentiti, vie di update attuali e il guasto che di notte La preoccupa di più. Il primo giorno questi schizzi diventano i casi di studio del gruppo.
Contenuto della fornitura
- 3 giornate di formazione, tenute da Dino Bordonaro
- Ambiente Lab con una zona di rete volutamente isolata per ogni team, in cui le esercitazioni offline avvengono davvero
- Modelli per manifest del pacchetto di trasferimento, gate di promotion e runbook di rollback
- Certificati di partecipazione e documentazione formativa verificabile in sede di audit
- Follow-up di 60 minuti con il team 4 settimane dopo il corso
Agenda
Giorno 1
Tre modelli di esercizio, tre verità
Connesso, separato a tratti, separato in modo permanente: cosa cambia davvero per ogni modello in frequenza di update, monitoring e supportabilità. Inquadramento onesto di Azure Local Disconnected Operations: ad accesso limitato, con verifica di Eligibility, non un prodotto ordinabile liberamente.
Tutto è un artefatto
Modelli, container, prompt, configurazioni e dati di valutazione come artefatti versionati e firmati. Domanda concreta per ogni tipo di artefatto: dove nasce, chi lo firma, cosa prova la firma?
Gate di promotion che fermano qualcosa
Il percorso da dev a test a prod con gate armati sul serio: suite di valutazione, verifica delle firme, approvazione a quattro occhi. Discussione sul caso: quale gate avrebbe fermato l’ultimo cattivo cambio di modello della Sua organizzazione?
Esercizio: pipeline di promotion nel Lab
Ogni team ricostruisce la pipeline: un artefatto di modello attraversa dev e test, un modello peggiorato di proposito deve restare bloccato al gate di valutazione. Se non succede, il gate viene affinato.
Risultato della giornata: processo di promotion documentato
Ogni team ha un processo di promotion con gate definiti come documento e come pipeline funzionante, dimostrato da un modello passato e da uno fermato.
Giorno 2
Anatomia di un pacchetto di trasferimento
Cosa passa dal varco: pesi dei modelli, immagini container, firme, manifest, dati di valutazione. Costruzione di un manifest che rende verificabili completezza e integrità prima che qualcosa venga installato.
Il varco come processo, non come chiavetta USB
Ruoli, passi di verifica e protocollazione nel passaggio verso la zona separata. Quali verifiche girano fuori, quali dentro e chi porta l’approvazione? Confronto con gli schizzi di rete portati.
Esercizio: update offline in condizioni reali
La zona Lab di ogni team è staccata da internet. Un nuovo modello con il suo container viene costruito come pacchetto di trasferimento, fatto passare dal varco, verificato contro il manifest e attivato nello staging. Un pacchetto manipolato è in circolazione e deve fallire alla verifica delle firme.
Debriefing: dove si è inceppato
Analisi dell’esercitazione lungo i protocolli: quale verifica è mancata, quale era doppia, quanto è durato il passaggio? Le conclusioni confluiscono direttamente nel proprio concetto di update.
Risultato della giornata: update offline eseguito con protocollo
Ogni team ha eseguito per intero un update senza accesso a internet e ha respinto in modo dimostrabile il pacchetto manipolato. Il protocollo del varco documenta ogni passo.
Giorno 3
Monitoring senza backend cloud
Rendere visibili qualità del modello, drift e salute della piattaforma quando nessun dashboard SaaS è permesso. Costruzione della pipeline delle metriche nella zona separata, inclusa la domanda su quali analisi possano uscire periodicamente e quali mai.
Scenari di incident per piattaforme LLM
Regressione del modello dopo un update, sospetto di artefatto compromesso, guasto delle GPU, ondata di prompt injection: per ogni scenario fissare nel runbook via di riconoscimento, misura immediata e catena di comunicazione.
Esercizio: rollback sotto pressione di tempo
Il modello installato il giorno prima mostra nell’esercitazione una regressione massiccia. Ogni team torna secondo runbook all’ultimo stato buono, misura il tempo e dimostra via valutazione che lo stato precedente è ripristinato.
Il Suo piano dei 90 giorni per l’esercizio reale
Prioritizzazione nel team: quali tre lacune tra esercitazione Lab e ambiente proprio chiudere per prime, chi risponde della catena di firme in azienda, quando avviene il primo test del varco in proprio.
Risultato della giornata: runbook di incident e rollback testato
Ogni team ha un runbook che ha superato una vera esercitazione di rollback, con tempo di ripristino misurato e piano dei 90 giorni documentato per il proprio ambiente.
Esercitazioni e quota lab
Circa il 60 per cento del tempo sono esercitazioni: ogni team gestisce una zona Lab realmente isolata, costruisce pacchetti di trasferimento, respinge un pacchetto manipolato ed esegue un rollback completo con misurazione del tempo.
Piattaforme
Svolgimento sul nostro ambiente Lab con zone di rete separate, su richiesta inhouse con la Sua infrastruttura, purché accessi e approvazioni siano disponibili. Trattiamo Azure Local Disconnected Operations con onestà come offerta ad accesso limitato con verifica di Eligibility, tutte le funzioni di piattaforma valgono nella versione di volta in volta disponibile.
Prova di transfer
Tre prove documentate: la pipeline che ferma un modello cattivo, il protocollo del varco dell’update offline con il pacchetto manipolato respinto e l’esercitazione di rollback misurata. Tutte e tre vengono consegnate ai partecipanti come documentazione.
Artefatti che porta con sé
- Processo di promotion dev-test-prod come documento e modello di pipeline
- Manifest del pacchetto di trasferimento e protocollo del varco come modelli
- Runbook di incident e rollback, testato nell’esercitazione
- Concetto di monitoring per ambienti senza backend cloud
- Piano dei 90 giorni per il trasferimento nel proprio ambiente
Estensioni opzionali
- Azure Arc e Azure Local come Hybrid Control Plane (AI-ARC) per il quadro decisionale connesso contro separato
- Evaluation, Observability e Guardrails (AI-EVAL) per approfondire i gate di valutazione
- Primo test accompagnato del varco nel Suo ambiente come servizio separato
Delimitazione
Il corso fornisce processi, modelli e manovre provate, non una certificazione del Suo ambiente né l’implementazione del Suo varco. Costruzione ed esercizio nella Sua organizzazione sono prestazioni di progetto e vengono incaricate separatamente.
Domande frequenti
Dopo il corso il nostro ambiente è air-gapped e sicuro?
No, e attenzione a chiunque lo prometta. Il corso trasmette i processi e le prove con cui Lei rende gestibile un ambiente separato. Se e quanto rigorosa sia la Sua separazione lo decidono la Sua architettura di sicurezza e la Sua vigilanza, non un training.
Si può fare anche da remoto?
Il cuore del corso vive delle zone Lab isolate e dell’esercitazione fisica del varco, per questo lo offriamo solo in presenza: nel Lab o inhouse da Lei. Il follow-up dopo 4 settimane avviene da remoto.
Oggi siamo completamente connessi. Il corso conviene lo stesso?
Sì, se uno scenario di separazione può diventare realistico, per esempio per prescrizioni, clienti da infrastrutture critiche o obiettivi di certificazione. Il processo di promotion e la catena di firme del Giorno 1 migliorano subito anche gli ambienti connessi, il resto è la Sua assicurazione.