Aikido, società belga di sicurezza, ha presentato un modello open-weight pensato per analizzare codice e segnali di rischio vicino all'infrastruttura del cliente. L'obiettivo è evitare che materiale sensibile debba passare per un servizio esterno per ottenere una prima valutazione. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Perché è importante
- Aikido ha presentato un modello AI open-weight per analisi di cybersecurity eseguibile in infrastrutture controllate.
- La scelta intercetta la richiesta di non inviare codice e dati sensibili a provider esterni, cresciuta mentre gli attaccanti usano strumenti AI.
- Un modello locale riduce un percorso di esposizione, ma non garantisce accuratezza, aggiornamento o assenza di falsi positivi.
Perché l'AI locale torna al centro
La domanda cresce perché i team vogliono usare l'AI nel ciclo di sviluppo, mentre gli attaccanti sfruttano modelli e automazioni per cercare vulnerabilità. Tenere il modello nel proprio perimetro può ridurre il numero di trasferimenti, non il bisogno di governo. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Open-weight indica che i pesi sono disponibili secondo una licenza, non che dati, codice di addestramento e risultati siano automaticamente trasparenti. Prima dell'adozione vanno letti licenza, hardware e modalità di aggiornamento. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Locale non significa infallibile
Un modello che non invia il repository a un provider esterno affronta comunque rischi tecnici: può non riconoscere una vulnerabilità, generare un falso allarme o suggerire una correzione non compatibile con il sistema. La privacy migliora soltanto se anche log, telemetria e backup seguono la stessa policy. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
La qualità va misurata su casi noti. Prepara un campione di vulnerabilità confermate, errori comuni e codice innocuo, quindi confronta finding, gravità e tempo di revisione con gli strumenti già in uso. Un punteggio medio nasconde i casi critici mancati. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Il perimetro locale aggiunge anche lavoro operativo: aggiornare il modello, proteggere GPU e endpoint, controllare chi può leggere gli output e prevedere un ritorno a regole deterministiche quando il servizio è indisponibile. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Cosa puoi farci concretamente
- Classificare il codice e decidere quali repository possono essere analizzati fuori dal perimetro aziendale.
- Confrontare il modello locale con regole, scanner e revisione umana su casi già verificati.
- Registrare versione, prompt, evidenze e decisione per ogni finding prima di aprire un ticket.
Come provarlo senza spostare il rischio
La prima prova dovrebbe usare un repository copia, dati sintetici e una finestra di osservazione breve. Ogni output deve avere il riferimento al file, la regola o il segnale che lo sostiene e una decisione umana separata. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Confronta tre percorsi: scanner tradizionale, modello locale e revisione manuale. Misura precisione sui casi importanti, falsi positivi, tempo di triage e numero di correzioni respinte. Il confronto rende visibile se l'AI accelera il lavoro o soltanto produce più testo. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Stabilisci prima una soglia di blocco. Se il modello propone una modifica ad alto impatto senza evidenza, il flusso deve fermarsi e chiedere approvazione. L'automazione utile è quella che sa anche non procedere. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Il verdetto: il controllo vale più dalla distanza
La proposta Aikido intercetta un bisogno reale: usare modelli AI senza trasformare codice proprietario in un nuovo flusso di dati verso terzi. È un vantaggio architetturale, non una certificazione di sicurezza. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Per adottare un modello locale servono benchmark ripetibili, gestione degli aggiornamenti, identità tecniche e una responsabilità chiara per il finding finale. La domanda non è solo dove gira il modello, ma chi può contestare il suo output. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Un pilota ben delimitato può rispondere in due settimane: quali vulnerabilità trova, quali manca, quanto tempo risparmia e quali dati lascia. Senza queste quattro misure, locale resta un aggettivo rassicurante. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare. La prova va ripetuta su casi reali, con una persona responsabile e un risultato che si possa controllare.
Va misurata anche la manutenzione. Un modello distribuito dentro l'azienda deve ricevere aggiornamenti, correzioni e regole per evitare che una versione vecchia continui a segnalare rischi già risolti o ignori una tecnica nuova. Il team deve sapere chi firma il rilascio, chi controlla i permessi e chi sospende l'analisi se il sistema produce output anomali. Questa disciplina rende l'AI locale un componente governato, non un server isolato che tutti considerano automaticamente sicuro.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
