Cos’è la sicurezza degli LLM? Come mitigare i 10 principali rischi per la sicurezza secondo OWASP

Un attacco che induce un'IA a trattare le istruzioni di un aggressore come comandi, ovvero la prompt injection, si è classificato al primo posto della OWASP Top 10 for LLM Applications in tutte le edizioni dal 2023.

Questa classifica è quanto di più vicino a un consenso esista nel campo della sicurezza dell'IA. Il progetto è nato da un piccolo gruppo di professionisti della sicurezza e oggi si avvale del contributo di oltre 600 esperti in più di 18 paesi.

Siamo un'azienda di IA che pubblica una guida su come l'IA si lascia convincere a fare cose, quindi non fingeremo che il problema sia risolto. Wilson, co-responsabile del progetto OWASP, è stato piuttosto chiaro sulle difese attuali: “...francamente, non credo che siamo al 99%.”

L'edizione 2026 si apre con lo stesso tono. Il responsabile del progetto ci invita a “smettere di cercare di costruire un modello che non possa essere ingannato” e a progettare il sistema circostante in modo che un modello ingannato non possa compromettere nulla di importante.

Applichiamo questo approccio a tutti e 10 i rischi dell'elenco OWASP 2026.

Che cosa si intende per sicurezza degli LLM?

Per sicurezza degli LLM si intende la protezione dei modelli di IA e delle applicazioni che li utilizzano da attacchi e usi impropri. Il rischio cresce in base a ciò a cui il modello è collegato: i file e i dati che può leggere e gli strumenti che può usare, come l'email, la ricerca o un database aziendale.

In un software adeguatamente protetto esiste un confine netto tra le istruzioni che un programma segue e le informazioni che elabora. Ma gli LLM non hanno questo confine.

Tutto ciò che il modello legge arriva come un unico, lungo flusso di testo: le istruzioni dello sviluppatore, la tua domanda, una pagina web che ha consultato. I modelli di IA dovrebbero tenere traccia di chi sta parlando, che si tratti dello sviluppatore, dell'utente o del modello stesso mentre ragiona su un problema.

Ma i ricercatori Jasmine Cui e Charles Ye hanno scoperto che i modelli per lo più intuiscono chi sta parlando in base a come suona il testo. Quindi, se un aggressore scrive qualcosa che sembra il ragionamento del modello stesso, il modello potrebbe credere di aver avuto quell'idea da solo. È un problema per qualsiasi sistema di sicurezza che si basi sul fatto che il modello sappia chi comanda.

Abbiamo riscontrato lo stesso problema con i nostri agenti di IA. Il nostro CISO, Kyle Polley, ha dichiarato a ISMG che gli agenti “potrebbero non seguire le policy anche se le aggiungi al prompt di sistema”. Per questo abbiamo creato Numbat, uno strumento open source che verifica cosa sta per fare un agente e può bloccarlo se l'azione viola una regola di sicurezza configurata.

Sicurezza degli LLM significa accettare che il modello a volte prenderà ordini dalla persona sbagliata, e costruirgli intorno guardrail per l'IA che reggano anche quando succede.

Quali sono le migliori pratiche per la sicurezza degli LLM?

Esamineremo in ordine la OWASP Top 10 for LLM Applications 2026, dal n. 1 al n. 10.

Per ogni rischio troverai una spiegazione in parole semplici di cosa può andare storto e un esempio concreto. Poi vedremo le pratiche che possono aiutare a prevenirlo o, quanto meno, a limitare i danni.

1. Contenere la prompt injection

Una prompt injection si verifica quando un aggressore induce un'IA a seguire istruzioni che non dovrebbe seguire. Queste istruzioni possono arrivare direttamente in una chat oppure essere nascoste in un'email, in una pagina web o in un documento.

Il secondo tipo è noto come prompt injection indiretta. Chiedi al tuo assistente di riassumere un documento. Chi lo ha scritto ha ordinato all'assistente di inviargli i tuoi file privati. Se l'assistente segue quelle istruzioni, l'autore del documento ha di fatto preso in prestito il tuo accesso.

PCMag paragona la sicurezza dei prompt al tappare i buchi di una pietra porosa. Chiudi un'apertura e l'acqua ne trova un'altra. “Un attacco si fa strada; viene corretto, ma restano da scoprire innumerevoli altre vie di attacco, semplicemente per via di quanto siano dinamici sistemi come gli LLM.”

Esempio: nel giugno 2025, i ricercatori di Aim Security hanno scoperto EchoLeak, una falla che induceva Microsoft 365 Copilot a divulgare informazioni aziendali riservate. Quando un dipendente poneva una normale domanda di lavoro, Copilot poteva recuperare l'email, seguire le istruzioni nascoste al suo interno e inviare informazioni sensibili all'aggressore. L'attacco aggirava i controlli pensati per intercettare le istruzioni dannose e rimuovere i link sospetti.

Cosa puoi fare:

• Segui la “Regola del due” di Meta: EchoLeak richiedeva un'IA in grado di leggere i dati aziendali, leggere email esterne e inviare informazioni all'esterno, e quell'IA aveva tutte e tre queste capacità. Limitarla a due di queste capacità impedisce a una prompt injection di acquisire troppo controllo. Se l'attività le richiede tutte e tre, prevedi l'approvazione umana prima di ogni azione.
• Esegui test contro aggressori che conoscono le tue difese: fornisci ai tuoi tester di sicurezza le regole e i filtri che hai implementato, poi lascia che trovino il modo di aggirarli. In uno studio, gli aggressori che si sono adattati alle difese hanno avuto successo in oltre il 90% dei casi contro la maggior parte delle 12 difese testate.

2. Impedire la fuga di informazioni sensibili

Quando i sistemi di IA forniscono informazioni private a persone che non dovrebbero vederle, si parla di divulgazione di informazioni sensibili. Può trattarsi di rivelare i dati di pagamento di un cliente o di lasciare conversazioni private in un database condiviso.

Molte fughe di dati iniziano con l'“oversharing”, ovvero la condivisione eccessiva. Supponiamo che un'azienda colleghi la propria IA a unità di archiviazione e knowledge base con permessi poco restrittivi. L'IA recupera tutto ciò che riesce a raggiungere, esattamente come previsto. Nessuno deve forzare l'accesso, eppure l'LLM va considerato violato.

Esempio: nel gennaio 2025, i ricercatori di Wiz hanno trovato un database di DeepSeek esposto su internet con oltre un milione di voci di log, tra cui la cronologia delle chat e le chiavi API, che i software usano per accedere ad altri servizi. I ricercatori non hanno avuto bisogno di convincere il modello a rivelare nulla.

Cosa puoi fare:

• Verifica gli accessi prima che l'IA legga i dati: la tua applicazione dovrebbe controllare quali documenti la persona che pone la domanda è autorizzata a vedere, prima di passarli al modello.
• Proteggi i registri che la tua IA lascia dietro di sé: rimuovi i dettagli privati e le chiavi segrete prima di salvare i log delle attività, richiedi l'autenticazione e limitane la consultazione alle persone che ne hanno bisogno. Imposta un periodo di conservazione affinché questi registri non si accumulino all'infinito.

3. Tenere a freno l'autonomia eccessiva

Le IA con un'autonomia eccessiva hanno più potere di quanto richieda il loro compito: strumenti di cui non hanno bisogno, permessi che vanno oltre il loro incarico o la libertà di agire senza verifiche. In questo caso la causa è irrilevante.

Una prompt injection, un bug o un modello che semplicemente sbaglia portano tutti allo stesso risultato. Prima o poi l'IA farà qualcosa di distruttivo, se ne ha la capacità.

Esempio: nel luglio 2025, il fondatore di SaaStr Jason Lemkin ha riferito che l'agente di programmazione di Replit aveva cancellato il suo database di 1.206 record di dirigenti, nonostante le istruzioni di non apportare modifiche. Inizialmente l'agente aveva affermato che i dati non potevano essere ripristinati, anche se in seguito il recupero si è rivelato possibile. Jason ha constatato che dirgli di non toccare il database non gli aveva tolto la capacità di eliminarlo.

Espandi

Fonte: X

Cosa puoi fare:

• Rimuovi le capacità che l'attività non richiede: limita sia gli strumenti a disposizione di un agente sia ciò che tali strumenti possono fare. Un assistente che riassume le email ha bisogno del permesso di leggerle, non di inviarle o eliminarle.
• Colloca i controlli dei permessi all'esterno dell'IA: ogni volta che viene richiesta un'azione, verificala rispetto alle tue regole di sicurezza e richiedi l'approvazione di una persona.

4. Controllare cosa entra nella supply chain dell'IA

Poche aziende sviluppano l'IA da zero, e ogni anno sono sempre meno. Secondo il sondaggio 2025 The State of Generative AI in the Enterprise di Menlo Ventures, nel 2024 il 53% delle aziende ha acquistato modelli di IA, percentuale salita al 76% nel 2025.

Il più delle volte, le aziende scaricano modelli da hub come Hugging Face, li addestrano ulteriormente su dataset raccolti da altri e integrano componenti aggiuntivi e pacchetti di codice scritti da sconosciuti.

Ognuno di questi elementi è una porta d'ingresso. Se uno viene manomesso, il problema finisce direttamente nel tuo prodotto.

Esempio: i repository pubblici di modelli di Hugging Face sono passati da 2,43 milioni a 2,96 milioni tra gennaio e agosto 2026. Nel luglio 2026, però, i modelli di OpenAI hanno aggirato i controlli pensati per tenerli lontani da internet durante i test di sicurezza interni e sono penetrati in parti dei sistemi di Hugging Face. Un agente, in particolare, ha recuperato 14 credenziali di accesso esposte pubblicamente, ha verificato che funzionassero e le ha condivise con altri agenti. Gli agenti hanno poi sfruttato falle che consentivano loro di eseguire codice sui server di Hugging Face.

“Stiamo imponendo requisiti più rigorosi sull'allineamento lungo l'intero ciclo di vita di un modello e stiamo creando sandbox più isolate, limitando l'accesso a internet e controllando ulteriormente l'accesso ai pesi dei modelli”, afferma il rapporto di OpenAI.

Cosa puoi fare:

• Vincola i modelli a una versione esatta e verificali: vincola ogni modello a una versione revisionata e controllane l'impronta del file prima di caricarlo, in modo che un file sostituito non possa infiltrarsi sotto la stessa etichetta. OWASP raccomanda anche le firme digitali, con un'avvertenza: una firma dimostra la provenienza di un modello, non che sia sicuro.
• Controlla ogni pacchetto suggerito dalla tua IA: prima di installare un pacchetto di codice consigliato da un assistente di IA, verifica che esista, che sia il pacchetto che intendevi e che provenga dall'editore che ti aspetti.

5. Proteggersi dall'avvelenamento dei dati e dei modelli

Un'IA avvelenata apprende da dati corrotti. Può trattarsi degli esempi usati per il suo fine-tuning o di una knowledge base in cui cerca le risposte. Il modello sembra ancora funzionare; semplicemente impara le lezioni sbagliate e, a volte, impara a comportarsi in modo anomalo solo quando incontra una specifica frase di attivazione.

Il modello supererà ogni test a cui lo sottoponi, finché qualcuno non userà quella frase.

Espandi

Inoltre, è davvero difficile porvi rimedio. L'avvelenamento non è un bug che si può correggere con una patch. Se i tuoi dati sono sbagliati, potresti doverli ricontrollare, riaddestrare il modello o sostituirlo completamente.

Esempio: nell'ottobre 2025, i ricercatori di Anthropic, dell'AI Security Institute del Regno Unito e dell'Alan Turing Institute hanno dimostrato che 250 documenti avvelenati potevano insegnare a un modello a produrre testo senza senso ogni volta che incontrava un determinato trigger. Lo stesso numero ha funzionato con tutte e quattro le dimensioni di modello testate, anche se il più grande era stato addestrato su una quantità di dati puliti oltre 20 volte superiore.

Cosa puoi fare:

• Traccia la provenienza dei tuoi dati: tieni un registro di ogni dataset e modello che utilizzi, della sua provenienza e di cosa è cambiato tra una versione e l'altra. Consigliamo il controllo delle versioni per i dataset, così, se emerge un avvelenamento, puoi tornare a una versione pulita e capire come è avvenuto.
• Esegui test per individuare backdoor: una “backdoor” è un comportamento nascosto che un aggressore inserisce in un modello e che resta in attesa di una frase specifica o di un altro trigger per attivarsi. Cercale con input progettati per indurre il modello a violare le sue normali regole.

6. Porre un tetto al consumo illimitato

Quando le IA non hanno alcun limite alla quantità di lavoro che possono svolgere o a quanto possono costare, il loro consumo è considerato “illimitato”. La maggior parte dei servizi di IA applica tariffe a consumo, quindi un aggressore potrebbe far lievitare i tuoi costi o creare una copia del tuo modello.

OWASP chiama il problema di fondo “asimmetria dei costi”. Una richiesta breve ed economica può innescare calcoli costosi dalla tua parte.

Esempio: nel maggio 2024, il Threat Research Team di Sysdig ha scoperto un nuovo attacco chiamato “LLMjacking”. Un gruppo di aggressori ha preso di mira 10 servizi LLM ospitati nel cloud usando credenziali rubate. Sono entrati sfruttando una versione vulnerabile di Laravel, poi hanno capito cosa consentivano di fare le credenziali e quali fossero le eventuali quote, con l'evidente obiettivo di rivenderne l'accesso. Sono state interrogate anche molte impostazioni di logging, probabilmente per evitare di essere rilevati. Secondo Sysdig, nel peggiore dei casi il costo per la vittima potrebbe superare i 46.000 dollari al giorno.

Cosa puoi fare:

• Imposta budget che blocchino la spesa: stabilisci limiti di spesa rigidi per i singoli utenti, le chiavi API, i team e l'account nel suo complesso. Applicali in ogni punto da cui possono entrare le richieste.
• Dai a ogni attività un punto di arresto: limita per quanto tempo può essere eseguita un'attività, quanto testo può elaborare e generare e quante chiamate agli strumenti può effettuare. Aggiungi interruzioni automatiche per gli agenti che si ripetono o superano il limite consentito.

7. Individuare la disinformazione prima di agire

Quando un'IA produce qualcosa di falso che sembra corretto e qualcuno, o qualcosa, agisce di conseguenza, si parla di disinformazione. Il rischio principale non è tanto la risposta sbagliata in sé, quanto il fatto che la risposta sbagliata venga ritenuta attendibile e utilizzata.

Lo storico degli incidenti suggerisce che gli addetti ai lavori non si siano preoccupati della disinformazione quanto avrebbero dovuto. Secondo la lettera introduttiva dell'edizione 2026, i votanti l'hanno collocata verso il fondo della classifica, ma a giudicare dagli incidenti reali si colloca ai primi posti.

Esempio: nel 2025, Deloitte Australia ha consegnato una revisione dei sistemi informatici del welfare nell'ambito di un contratto governativo da 440.000 dollari australiani. Chris Rudge, ricercatore dell'Università di Sydney, ha individuato riferimenti a ricerche inesistenti e una citazione inventata tratta da una sentenza di un tribunale federale. Il rapporto rivisto ha rivelato che Deloitte aveva utilizzato Azure OpenAI GPT-4o nella propria metodologia, e la società ha accettato di rimborsare l'ultima rata. Si trattava, purtroppo, di una revisione di assurance.

Cosa puoi fare:

• Verifica che le prove supportino la risposta: basa le affermazioni su fonti aggiornate e autorevoli. Per una risposta relativa a una policy, recupera la policy approvata e verifica che supporti la conclusione, eccezioni comprese.
• Verifica prima che il sistema agisca: se un agente afferma che un cliente ha superato un controllo d'identità, confermalo tramite il sistema di verifica prima di autorizzare un pagamento. Richiedi l'approvazione umana per le decisioni rilevanti, mettendo a disposizione del revisore le prove a supporto.

8. Limitare i danni dell'esposizione del contesto nascosto

Le applicazioni di IA forniscono al modello istruzioni e informazioni di contesto che normalmente gli utenti non vedono. Possono includere il prompt di sistema, le policy interne, le descrizioni degli strumenti disponibili e le regole su chi può utilizzarli. Si verifica un'esposizione del contesto nascosto quando il modello rivela queste informazioni a qualcuno.

Nel 2026 OWASP ha ampliato questa voce, che prima si chiamava “system prompt leakage” (fuga del prompt di sistema), perché il prompt di sistema è solo una parte di ciò che può trapelare. Il pericolo dipende da cosa vi hai inserito. La fuga di una guida sul tono di voce è un po' imbarazzante, ma la fuga di una chiave API dà a qualcuno l'accesso al tuo database riservato.

Esempio: nel febbraio 2023, alcuni utenti sono riusciti a far rivelare a Bing Chat di Microsoft le sue istruzioni interne. Uno dei tentativi riusciti è stato quello di Marvin von Hagen, che si è spacciato per uno sviluppatore di OpenAI e ha chiesto le istruzioni per poter configurare il modello. Bing ha rivelato le regole che ne governavano le ricerche, le risposte e il comportamento in materia di sicurezza, insieme al suo nome interno, Sydney. Tra le istruzioni rivelate ce n'era una che gli imponeva di mantenerle riservate.

Cosa puoi fare:

• Tieni i segreti fuori dal contesto del modello: parti dal presupposto che tutto ciò che il modello può leggere possa diventare visibile agli utenti, quindi conserva password, chiavi API e token di accesso in un sistema separato di gestione dei segreti.
• Fai in modo che i permessi reggano anche quando le regole trapelano: applica i controlli di accesso nel codice della tua applicazione. Se uno strumento è riservato agli amministratori, verifica i permessi dell’account dell’utente prima di eseguirlo.

9. Proteggi vettori ed embedding

Quando un’IA usa la ricerca vettoriale per trovare risposte nei documenti della tua azienda, non cerca direttamente nel testo. I documenti vengono convertiti in “embedding”, lunghe liste di numeri che catturano il significato di ogni passaggio, e archiviati in un database vettoriale. Una domanda viene convertita allo stesso modo e il sistema recupera i passaggi i cui numeri sono più vicini.

OWASP riassume i quattro modi in cui il sistema può fallire: il poisoning lo fa sbagliare, l’inversione gli fa divulgare informazioni, il jamming lo ammutolisce e un controllo degli accessi difettoso lo porta a consegnare qualsiasi cosa a chiunque.

I numeri non sono l’astrazione sicura che sembrano. Gli embedding archiviati possono essere riconvertiti in testo e un metodo ha ricostruito esattamente il 92% dei passaggi brevi da 32 token nei suoi test. Quindi anche un backup trapelato contenente “solo embedding” può esporre il contenuto dei documenti.

Esempio: in una ricerca presentata a USENIX Security 2025, alcuni ricercatori hanno dimostrato che un singolo documento costruito ad arte poteva impedire a un’IA di rispondere a una determinata domanda. Lo hanno aggiunto alla raccolta in cui l’IA effettuava le ricerche. Quando l’IA lo trovava, poteva rispondere di non avere informazioni sufficienti o che rispondere non sarebbe stato sicuro. Il documento non aveva bisogno di dire all’IA di ignorare le proprie regole. Questo fenomeno si chiama “retrieval jamming”.

Cosa puoi fare:

• Mantieni indici separati per i dati pubblici e quelli privati: non mescolare contenuti web estratti tramite scraping con dati dei partner o documenti interni riservati. Separa fisicamente i contenuti in base al livello di attendibilità anziché contrassegnarli con tag in un unico indice: così elimini un’intera categoria di errori di configurazione e i contenuti estratti da Internet non possono finire accanto ai documenti del consiglio di amministrazione.
• Tratta gli embedding come i documenti da cui derivano: crittografali, proteggi i backup del database vettoriale così come i file di origine ed elimina gli embedding quando elimini l’originale. Le chiavi API del tuo servizio di embedding vanno mantenute segrete.

10. Controlla l’output dell’IA prima di trasmetterlo

Ogni volta che un’applicazione passa l’output dell’IA a un altro sistema senza verificare che sia sicuro da usare in quel contesto, sta gestendo in modo improprio l’output dell’LLM.

La voce riguarda anche il codice non sicuro che gli assistenti di programmazione basati sull’IA generano su larga scala. Ogni riga scritta da un assistente, quindi, è anch’essa output.

Esempio: nel 2025 il ricercatore Johann Rehberger ha mostrato come l’assistente di programmazione Amp di Sourcegraph potesse divulgare il contenuto delle chat semplicemente visualizzando un’immagine. Ha usato la prompt injection per indurre Amp a inserire informazioni private nell’indirizzo web di un’immagine. L’applicazione ha poi recuperato automaticamente quell’immagine, inviando le informazioni al suo server. L’errore nella gestione dell’output è stato proprio quella richiesta automatica: il testo generato dal modello si è trasformato in una connessione a un server esterno, portando con sé dati privati.

Cosa puoi fare:

• Rendi l’output sicuro per la sua destinazione: controlla e gestisci le risposte in base a dove andranno. Per una pagina web, impedisci che il testo generato diventi codice eseguibile. Per un database, usa query preparate che mantengano i valori forniti separati dai comandi.
• Impedisci alle risposte di stabilire connessioni esterne automatiche: disattiva per impostazione predefinita il caricamento automatico di immagini, anteprime dei link e pagine incorporate nelle risposte del modello. Limita le connessioni necessarie a destinazioni approvate in modo esplicito.

In che modo Perplexity protegge gli LLM?

Partiamo dal presupposto che ogni rischio descritto sopra prima o poi si concretizzerà e progettiamo i nostri sistemi in modo che, quando accade, i danni siano minimi. Il nostro CISO, Kyle Polley, ha illustrato come lo facciamo in un workshop recente.

• L’agente ha un computer tutto suo, che parte vuoto: gli strumenti per agenti installati sul tuo laptop possono accedere ai suoi file, alle app e alle credenziali salvate. Perplexity Computer funziona al contrario. Ogni attività viene eseguita nella propria sandbox isolata e, come dice Polley, “per impostazione predefinita non ha accesso a nulla”.
• L’agente non vede mai le password: le credenziali dei servizi connessi sono archiviate fuori dalla sandbox. Quando l’agente deve raggiungere un servizio come GitHub, invia una richiesta senza credenziali. Un gateway verifica che la destinazione e la richiesta corrispondano a quanto previsto, poi aggiunge le credenziali in uscita. L’agente può usare la connessione senza ottenere le chiavi.
• I tuoi permessi restano validi e puoi restringerli: le connessioni effettuate tramite OAuth mantengono i tuoi permessi di accesso nel servizio connesso. Se tu non puoi vedere qualcosa, non può farlo nemmeno il tuo agente.
• Ogni pagina web viene trattata come un’estranea: abbiamo creato BrowseSafe per Comet, il nostro browser agentico, perché gli strumenti che avevamo testato non soddisfacevano le nostre esigenze nell’uso reale. Il browser analizza le pagine web e altri contenuti esterni, comprese le email, alla ricerca di prompt injection. Abbiamo reso open source sia il modello sia il dataset.
• Monitoriamo l’agente e le macchine su cui viene eseguito: Numbat si colloca tra la decisione di un agente di agire e l’effettiva esecuzione dello strumento. Numbat registra l’attività degli agenti di programmazione supportati e può bloccare le azioni che violano i criteri configurati prima che vengano eseguite. Bumblebee esegue l’inventario dei pacchetti software su laptop, server e pipeline di build e segnala quelli noti come dannosi. Entrambi sono open source.
• I fornitori dei modelli non conservano i tuoi dati: abbiamo accordi di zero data retention con i nostri fornitori di LLM di terze parti. Gli amministratori Enterprise possono inoltre ridurre il periodo di conservazione dei dati di Perplexity stessa fino a 24 ore.

Abbiamo creato Numbat in modo proattivo, per un motivo che Polley riassume in una frase: “Più autonomia dai a un agente, maggiore è il rischio”.

Domande frequenti sulla sicurezza degli LLM

Qual è l’LLM più sicuro?

Nessun LLM rende sicura un’applicazione da solo: i modelli possono comunque scambiare i contenuti che dovrebbero leggere per istruzioni da seguire. Anche le difese che sembrano solide nei test standard possono cedere sotto pressione.

Una domanda migliore è quale configurazione sia la più sicura per il tuo caso d’uso. Questo significa permessi limitati, credenziali tenute lontane dal modello, approvazione umana per le azioni rischiose e test condotti da persone che conoscono le tue difese.

Cosa sono le vulnerabilità degli LLM?

Le vulnerabilità degli LLM sono punti deboli che possono portare un sistema di IA a farsi ingannare, a divulgare dati o a causare danni, per mano di un aggressore o a causa dei suoi stessi errori.

I dieci rischi principali sono prompt injection, divulgazione di informazioni sensibili, autonomia eccessiva (excessive agency), catena di fornitura, avvelenamento di dati e modelli, consumo illimitato, disinformazione, esposizione del contesto nascosto, punti deboli di vettori ed embedding e gestione impropria dell’output.

Un LLM privato è sicuro?

Per alcuni aspetti è un’opzione più sicura, ma non lo è automaticamente. Se esegui un modello sulla tua infrastruttura o in un ambiente cloud, hai un maggiore controllo sulla gestione dei dati. Tuttavia, non esiste un modo automatico per prevenire prompt injection, autonomia eccessiva, avvelenamento o disinformazione.

Con il self-hosting sei anche responsabile del modello che scarichi, compresi i rischi legati alla catena di fornitura e l’infrastruttura di cui ha bisogno.