Le linee guida di Sandia sulla sicurezza dell'AI mettono in guardia le startup della Tri-Valley
Sandia National Laboratories ha riunito quattro ricercatori davanti alle startup della Tri-Valley con un avvertimento: la rapida adozione dell'AI sta creando rischi che le tradizionali revisioni del software possono non rilevare. Il panel del 29 luglio ha collocato i metodi di sicurezza AI di Sandia in un contesto aziendale, dove i team più piccoli spesso implementano modelli prima di istituire programmi formali di garanzia.
L'evento non ha presentato un nuovo prodotto, uno standard vincolante o una normativa. La sua importanza derivava dal modello operativo illustrato da Sandia. Le startup dovrebbero esaminare dati, modelli, integrazioni e decisioni umane come un unico sistema interconnesso, quindi testarlo rispetto a guasti e attacchi realistici.
Questa posizione crea un chiaro conflitto tra velocità di implementazione e prove di sicurezza. Le startup competono rilasciando funzionalità in anticipo, imparando dagli utenti e cambiando rapidamente direzione. Sandia affronta l'AI in ambienti ad alte conseguenze, dove un guasto inspiegato può compromettere un intero sistema.
Il panel ha inoltre messo in discussione una diffusa convinzione delle startup. Utilizzare un modello tramite un fornitore affidabile non trasferisce ogni rischio a quel fornitore. L'azienda che realizza l'applicazione finale mantiene infatti il controllo sugli accessi ai dati, sul livello di retrieval, sugli strumenti, sulle autorizzazioni, sull'esperienza utente e sulle procedure di risposta.
Questo rende la garanzia sull'AI una responsabilità di prodotto, non un esercizio finale di conformità. La domanda immediata per i fondatori è se i loro team possano produrre prove del comportamento del sistema prima che clienti, autorità di regolamentazione o aggressori le richiedano.
La sicurezza AI di Sandia passa dal laboratorio alle attività operative delle startup
L'evento ha tradotto le preoccupazioni di sicurezza nazionale in questioni operative che le giovani aziende affrontano già oggi.
Daybreak Labs ha ospitato il Lunch and Learn gratuito a Livermore, in California, dalle 11:30 alle 13:30. L'incubatore non profit sostiene startup delle scienze della vita e deep-tech nella regione della Tri-Valley.
Il panel ha visto la partecipazione di Amanda Dodd, Gayle Thayer, Philip Kegelmeyer e Jonathan Crussell di Sandia. Le loro esperienze comprendevano analisi della sicurezza nazionale, algoritmi sicuri, analisi dei dati avversariali, sicurezza del software e workflow di AI agentica.
Dodd, direttrice di Computation and Analysis for National Security di Sandia, ha inquadrato la discussione attorno alle vulnerabilità create dalla rapida adozione. Ha paragonato l'attuale espansione dell'AI alla diffusione di massa di Internet negli anni Novanta.
Il suo paragone era incentrato sull'incertezza, non sulla nostalgia. La connettività Internet ha creato servizi di valore, esponendo al contempo i sistemi ad attacchi e modalità di guasto che molte organizzazioni non avevano previsto. L'AI introduce ora un'incertezza simile all'interno di sistemi che generano contenuti, formulano raccomandazioni e talvolta intraprendono azioni.
Secondo il programma dell'evento, la discussione ha coperto velocità contro sicurezza, innovazione contro regolamentazione e rischi che coinvolgono team umani e AI. Ha inoltre esaminato la sovrapposizione tra priorità governative e del settore privato.
Il successivo resoconto del panel di Sandia ha descritto tre conseguenze aziendali delle minacce AI: perdita di proprietà intellettuale, interruzione operativa ed esposizione normativa. Questi esiti conferiscono alle debolezze tecniche un significato finanziario e strategico diretto.
Thayer, responsabile del dipartimento Secure Algorithms di Sandia, ha spiegato che l'attenzione alla sicurezza si sta spostando oltre l'hardware e il software convenzionale. I ricercatori esaminano sempre più gli algoritmi stessi e il comportamento che emerge dal loro utilizzo.
Questo cambiamento conta perché un'applicazione AI può operare come progettato e tuttavia produrre risultati non sicuri. Un modello potrebbe rivelare contesto sensibile, accettare un'istruzione dannosa o comportarsi in modo imprevedibile al di fuori delle condizioni di test originarie.
L'applicazione può anche fallire senza che nessuno la attacchi. Istruzioni ambigue, dati non familiari, criteri di valutazione deboli o un livello di autonomia inappropriato possono generare errori gravi. La scansione convenzionale delle vulnerabilità non individuerà ciascuno di questi problemi.
L'approccio di Sandia include il red teaming, ossia la ricerca attiva delle debolezze di un sistema prima che le trovi un avversario. I ricercatori effettuano inoltre benchmark di affidabilità, sicurezza e limiti prestazionali in condizioni definite.
Testare i limiti è diverso dal riportare un singolo punteggio di accuratezza favorevole. Una valutazione utile chiede dove il sistema smette di comportarsi in modo accettabile, quali input innescano tale cambiamento e se il monitoraggio sia in grado di rilevarlo.
Il panel ha quindi fatto più che elencare i rischi dell'AI. Ha collegato l'identificazione dei rischi a test ripetibili, mitigazione e progettazione sicura. Questa sequenza trasforma un avvertimento astratto in una disciplina ingegneristica.
Nulla nel resoconto pubblico indica che Sandia abbia certificato le startup partecipanti o valutato i loro prodotti. La sessione è stata uno scambio di approcci e preoccupazioni, non un audit.
Questa distinzione è importante. Un panel di due ore non può stabilire se un particolare sistema AI sia sicuro. Può però cambiare le domande che i fondatori si pongono prima di distribuirne uno.
La rapida adozione dell'AI lascia alle startup un divario di garanzia
Le startup subiscono pressioni perché i loro cicli di rilascio sono più brevi del tempo necessario a comprendere ogni comportamento del modello.
Una giovane azienda può aggiungere un modello ospitato a un prodotto senza addestrare quel modello. Può collegare documenti dei clienti, registri interni o strumenti esterni tramite interfacce di programmazione delle applicazioni in un breve ciclo di sviluppo.
L'applicazione risultante eredita diversi livelli di incertezza. Il suo comportamento dipende dal foundation model, dalle istruzioni di sistema, dai dati recuperati, dalle integrazioni software, dalle autorizzazioni e dall'input degli utenti.
Una modifica a qualsiasi livello può alterare il sistema. Un fornitore di modelli può aggiornare il comportamento, un indice di retrieval può ammettere nuovi documenti oppure un cliente può abilitare una nuova integrazione.
Questi cambiamenti creano quello che i team spesso chiamano un divario di garanzia. Il prodotto si sviluppa più rapidamente delle prove disponibili all'azienda su sicurezza, affidabilità e comportamento accettabile.
Il divario diventa più grave quando un sistema AI può agire. I workflow agentici sono applicazioni che consentono a un modello di pianificare passaggi e richiamare strumenti con un intervento umano limitato. Possono inviare messaggi, modificare record, eseguire codice o attivare processi aziendali.
Ogni autorizzazione aggiuntiva aumenta l'impatto di una risposta errata o manipolata. Una risposta debole in una finestra di chat è scomoda. La stessa risposta inviata a uno strumento di esecuzione può modificare dati o esporre informazioni.
La prompt injection illustra la differenza. Un aggressore inserisce istruzioni nell'input utente o in contenuti esterni, sperando che il modello le segua invece delle regole previste dallo sviluppatore.
L'attuale elenco dei rischi LLM gestito da OWASP identifica la prompt injection come una delle principali vulnerabilità applicative. Affronta inoltre la divulgazione di informazioni sensibili, le debolezze della supply chain, la gestione impropria degli output e l'eccessiva autonomia.
Questi rischi attraversano i confini organizzativi. Un fornitore di modelli protegge la propria piattaforma, mentre lo sviluppatore dell'applicazione controlla prompt, retrieval, strumenti e regole di accesso. Il cliente controlla poi il comportamento degli utenti, i dati collegati e la configurazione locale.
Nessun singolo partecipante vede il sistema completo. Questo rende facile disperdere la responsabilità fino al verificarsi di un incidente.
Il panel di Sandia ha ricollocato la responsabilità sull'organizzazione che effettua l'implementazione. Il governo può contribuire con ricerca, framework e valutazioni indipendenti. Tuttavia, le aziende restano responsabili dei rischi creati dai loro prodotti e dalle loro scelte operative.
Questa responsabilità non richiede a una startup di riprodurre un laboratorio nazionale. Richiede all'azienda di definire cosa significhi un comportamento sicuro per il proprio caso d'uso.
Un assistente per la ricerca clinica e un generatore di copy marketing non dovrebbero condividere criteri di accettazione identici. Il primo gestisce informazioni dalle conseguenze più elevate e richiede prove, controlli di accesso e revisione più rigorosi.
Le startup devono inoltre separare la qualità del modello dalla sicurezza del sistema. Un modello può avere buone prestazioni nelle attività di routine, ma fallire di fronte a input avversariali. Può rispondere accuratamente rivelando al tempo stesso informazioni che un utente non dovrebbe ricevere.
È possibile anche il contrario. Un'applicazione può prevenire gli attacchi più comuni e produrre comunque raccomandazioni inaffidabili. Sicurezza e utilità si sovrappongono, ma l'una non garantisce l'altra.
Per questo un singolo punteggio di benchmark offre una garanzia debole. I team hanno bisogno di test legati alle attività previste, agli usi impropri prevedibili, ai confini di accesso e alle condizioni di implementazione reali.
Hanno anche bisogno di registri. Una base di conoscenza ricercabile può conservare versioni dei modelli, risultati delle valutazioni, incidenti e rischi accettati tra i team di ingegneria e prodotto.
La documentazione non è burocrazia aggiunta dopo lo sviluppo. Consente a un team di individuare quando un comportamento è cambiato e se una mitigazione precedente funziona ancora.
La pressione è sia immediata sia di lungo termine. Gli acquirenti aziendali chiedono già ai fornitori informazioni sulla gestione dei dati, sui fornitori di modelli, sui controlli di accesso e sulla risposta agli incidenti. Le normative future potrebbero formalizzare ulteriormente tali prove.
Una startup incapace di rispondere a queste domande può perdere accordi prima ancora di subire una violazione tecnica. In questo senso, un'AI affidabile diventa parte della credibilità del prodotto.
Il compromesso centrale è tra velocità e prove
Il messaggio di Sandia non richiede un'innovazione più lenta, ma richiede prove più solide prima che all'AI venga attribuita maggiore autorità.
I fondatori di solito considerano la velocità un requisito di sopravvivenza. Rilasciare rapidamente produce feedback degli utenti, dimostra la domanda e aiuta una piccola azienda a competere con organizzazioni dai budget più grandi.
I team di sicurezza affrontano lo stesso rilascio da un'altra prospettiva. Vogliono modelli di minaccia, test, log, confini di accesso e un piano di risposta prima che un sistema raggiunga dati sensibili.
Entrambe le posizioni contengono preoccupazioni valide. Ritardare ogni funzionalità sperimentale finché non soddisfi standard ad alte conseguenze graverebbe su molte startup. Distribuire un sistema autonomo senza test significativi esporrebbe i clienti a rischi che non possono vedere.
La risposta pratica è una garanzia proporzionata. Un assistente di scrittura a basso impatto necessita di controlli diversi rispetto a un agente in grado di modificare record finanziari, di laboratorio o di produzione.
La garanzia proporzionata inizia con un contesto definito. Il team documenta chi utilizzerà il sistema, a quali dati può accedere, quali azioni può compiere e quali guasti sono inaccettabili.
L'azienda mappa quindi minacce credibili e normali modalità di guasto. Le minacce includono prompt dannosi, dati avvelenati, credenziali rubate, dipendenze compromesse e tentativi di estrarre contesto privato.
I guasti ordinari meritano pari attenzione. Un modello può fraintendere una richiesta, inventare una fonte, selezionare lo strumento sbagliato o continuare a operare dopo che le sue assunzioni sono diventate invalide.
Segue poi la misurazione. I team costruiscono set di valutazione a partire da attività realistiche, casi limite noti ed esempi avversariali. Registrano gli esiti attesi prima di eseguire i test.
Un test utile ha una condizione di superamento osservabile. “Il modello dovrebbe essere sicuro” non è misurabile. “L'assistente non deve restituire record al di fuori dello spazio di lavoro dell'utente autenticato” è abbastanza specifico da poter essere testato.
L’approccio red-team di Sandia aggiunge la prospettiva di un aggressore. I tester cercano percorsi inattesi attraverso l’intera applicazione, comprese istruzioni, dati connessi, interfacce e strumenti.
La più ampia comunità dei laboratori del Department of Energy ha descritto attività simili. Un rapporto sulla sicurezza dell’AI realizzato da più laboratori afferma che i benchmark statici non sono sufficienti per prevedere il comportamento al di fuori di condizioni familiari.
Il rapporto identifica anche limiti di risorse. Le valutazioni complete richiedono capacità di calcolo, lavoro di esperti e tempo. I nuovi modelli arrivano più rapidamente di quanto i valutatori possano esaminarli approfonditamente, uno per uno.
Questo vincolo è particolarmente rilevante per le startup. Le piccole aziende non possono testare ogni possibile input né riprodurre le valutazioni interne del fornitore.
Possono comunque testare l’applicazione che controllano. Una valutazione mirata dovrebbe coprire i dati dell’azienda, gli strumenti, i ruoli utente e i flussi di lavoro a maggiore impatto.
La mitigazione segue i test. Un team potrebbe limitare le autorizzazioni, isolare contenuti non attendibili, convalidare gli output, richiedere l’approvazione umana o restringere gli strumenti che il modello può chiamare.
Il controllo più efficace spesso riduce le conseguenze di un errore. Se un assistente si limita a preparare un’azione, una persona può esaminarla. Se l’assistente esegue direttamente quell’azione, l’azienda necessita di autorizzazioni e monitoraggio più rigorosi.
La revisione umana non è automaticamente efficace. I revisori possono diventare compiacenti quando la maggior parte degli output sembra corretta, soprattutto sotto pressione temporale.
I team dovrebbero quindi identificare le decisioni per cui la revisione conta di più. Dovrebbero inoltre fornire abbastanza contesto affinché una persona possa riconoscere un risultato dubbio.
Il monitoraggio chiude il ciclo. I log dovrebbero mostrare quali modello, istruzioni, fonti di dati e strumenti hanno contribuito a un output importante. Senza quel contesto, l’indagine sugli incidenti diventa un esercizio di congetture.
Nessuno di questi passaggi crea una garanzia permanente. Il comportamento dei modelli, il codice dell’applicazione, i dati e gli aggressori cambiano tutti. I test devono proseguire per l’intero ciclo di vita del sistema.
È qui che il conflitto tra velocità ed evidenza diventa gestibile. Una startup può muoversi rapidamente in un ambiente ristretto, per poi ampliare l’autorità man mano che le evidenze migliorano.
Può iniziare con utenti interni, dati sintetici e strumenti in sola lettura. Le fasi successive possono aggiungere dati dei clienti o azioni limitate dopo che il sistema ha raggiunto soglie esplicite.
Questo percorso considera la sicurezza parte dello sviluppo del prodotto. Evita la falsa alternativa tra bloccare ogni esperimento e rilasciare ogni funzionalità senza limiti.
I Framework Aiutano, ma Non Certificano un Prodotto
I framework esistenti organizzano il lavoro sui rischi dell’AI, ma non possono stabilire se l’applicazione di una specifica startup sia sufficientemente sicura.
L’AI Risk Management Framework del NIST offre alle organizzazioni quattro funzioni collegate: governare, mappare, misurare e gestire. La governance si applica a tutte le altre funzioni, anziché comparire soltanto alla fine.
Il framework è volontario e progettato per un uso ampio. Il suo framework sui rischi dell’AI aiuta le organizzazioni a integrare l’affidabilità nella progettazione, nello sviluppo, nella distribuzione, nell’uso e nella valutazione dell’AI.
Per una startup, “governare” significa assegnare l’autorità decisionale e documentare la tolleranza al rischio. Qualcuno deve decidere quali casi d’uso sono consentiti e quali evidenze giustificano il rilascio.
“Mappare” significa comprendere il contesto. I team identificano utenti, soggetti interessati, dati, dipendenze, benefici attesi e possibili danni.
“Misurare” comprende test e analisi. Include valutazione delle prestazioni, test di sicurezza, valutazione dell’incertezza e monitoraggio rispetto a criteri definiti.
“Gestire” trasforma i risultati in priorità e azioni. Un’azienda accetta, riduce, trasferisce o evita i rischi in base alla gravità e ai controlli disponibili.
Il NIST ha inoltre pubblicato un profilo sull’AI generativa nel luglio 2024. Il profilo adatta il framework più ampio ai rischi che i sistemi generativi introducono o intensificano.
Queste risorse offrono vocabolario e struttura. Non ispezionano un prodotto, non garantiscono la conformità e non certificano il comportamento di un modello.
La posizione di Sandia appare tecnicamente più impegnativa della mera adozione del linguaggio dei framework. I suoi ricercatori hanno sottolineato red teaming, benchmarking, progettazione sicura e comprensione dei limiti di prestazione.
Questa enfasi conta perché i documenti di governance possono disconnettersi dal software. Un registro dei rischi potrebbe indicare che la prompt injection è stata affrontata, mentre il sistema di retrieval distribuito continua a passare istruzioni non attendibili a un modello.
Le evidenze dovrebbero collegare ogni rischio identificato a un controllo e a un test. L’azienda dovrebbe anche sapere quali rischi restano dopo la mitigazione.
Una valutazione indipendente può rafforzare questo processo. Sandia ha descritto i centri di ricerca e sviluppo finanziati a livello federale come fonti di analisi tecnica imparziale.
Tuttavia, il rapporto pubblico del panel non ha annunciato un servizio generale di certificazione Sandia per le startup. Ha espresso interesse nell’individuare dove l’industria possa soddisfare le esigenze di assurance e dove i laboratori nazionali possano colmare le lacune.
Si tratta di un invito alla collaborazione, non della prova di un percorso già completato. Accesso, ambito, gestione della proprietà intellettuale e accordi di approvvigionamento determineranno se le singole startup potranno partecipare.
Sandia gestisce già programmi che collegano laboratori, università e aziende più piccole. Il suo programma RAIICE mira a fornire dataset aperti e pianificazione tecnica per attività di AI e machine learning legate all’energia resiliente.
RAIICE dimostra un modello di partnership, ma non va confuso con il panel sulla sicurezza di luglio. Il panel non ha annunciato che i partecipanti fossero entrati in quel programma.
Questa distinzione evidenzia l’aspetto più scettico del messaggio di Sandia. L’esperienza tecnica esiste, e i fondatori ne hanno chiaramente bisogno. Ciò che resta incerto è quanto ampiamente tale esperienza possa raggiungere i team commerciali.
I laboratori nazionali operano secondo missioni specifiche, regole contrattuali e vincoli di risorse. Le startup lavorano con tempistiche compresse e potrebbero aver bisogno di risposte entro pochi giorni.
Un modello di collaborazione deve colmare queste differenze di ritmo. Deve convertire i metodi di ricerca in test che piccoli team possano eseguire, ripetere e spiegare ai clienti.
La regolamentazione crea un’ulteriore incertezza. Secondo quanto riportato, i partecipanti al panel hanno favorito regole chiare che consentano all’industria di assumersi responsabilmente i rischi dell’AI, ma l’evento non ha prodotto alcuno standard legale proposto.
Le regole possono chiarire le aspettative, ma possono anche diventare obsolete man mano che modelli e applicazioni cambiano. Requisiti prescrittivi possono premiare il completamento di checklist senza migliorare il comportamento reale.
Le regole orientate ai risultati creano un problema diverso. Possono dire alle aziende quale risultato raggiungere senza fornire modalità economicamente accessibili per dimostrarlo.
Il miglior segnale nel breve termine sarà costituito da evidenze pratiche. Metodi di test pubblici, strumenti di valutazione riutilizzabili, dataset accessibili e collaborazioni documentate con startup mostrerebbero che la visione di partnership sta diventando operativa.
Fino ad allora, le aziende non dovrebbero affermare che l’adozione di un framework dimostri la sicurezza. Dovrebbero descrivere i controlli che usano, i test che hanno eseguito e i limiti che continuano a osservare.
Cosa Dovrebbero Osservare Ora Fondatori e Acquirenti
Il prossimo test sarà capire se il linguaggio di Sandia sul rischio produrrà pratiche ripetibili, partnership credibili e aspettative di mercato più chiare.
Il primo segnale è un percorso di collaborazione concreto per le piccole aziende. Sandia ha dichiarato di voler identificare dove l’industria possa soddisfare le esigenze di assurance e dove i laboratori nazionali possano colmare le lacune.
Un percorso utile definirebbe progetti idonei, competenze disponibili, requisiti di gestione dei dati, risultati attesi e tempistiche di coinvolgimento. Casi di studio pubblici renderebbero il modello più facile da valutare.
Se emergeranno questi dettagli, rafforzeranno l’affermazione centrale del panel. Mostrerebbero che i metodi dei laboratori nazionali possono andare oltre la discussione e sostenere lo sviluppo commerciale.
Se non apparirà alcun percorso, l’evento resterà un’attività di divulgazione utile ma offrirà un aiuto operativo limitato. Le startup dovranno comunque mettere insieme i propri programmi di test o assumere specialisti esterni.
Il secondo segnale è la validazione tecnica legata ad applicazioni reali. I fondatori dovrebbero cercare valutazioni pubblicate che coprano prompt injection, fuga di dati, manipolazione del modello, uso non sicuro degli strumenti e comportamento al di fuori delle normali condizioni di test.
Il lavoro più utile riporterà condizioni di fallimento e rischi residui, non soltanto punteggi favorevoli. Dovrebbe spiegare cosa è cambiato dopo i test e se la mitigazione ha resistito a un ulteriore ciclo di attacchi.
Tali evidenze rafforzerebbero l’argomentazione secondo cui un’AI affidabile crea un vantaggio competitivo. Gli acquirenti possono confrontare i fornitori con maggiore fiducia quando le aziende forniscono risultati ripetibili.
La mancanza di evidenze indebolirebbe questo argomento. Il solo linguaggio sulla sicurezza non distingue un prodotto da un altro, soprattutto quando ogni fornitore fa promesse simili.
Il terzo segnale è il passaggio da framework ampi verso aspettative più chiare da parte di clienti e autorità di regolamentazione. Il NIST sta aggiornando AI RMF 1.0 e sviluppando profili aggiuntivi per cybersecurity e infrastrutture critiche.
I fondatori dovrebbero monitorare se questionari aziendali, requisiti di approvvigionamento, revisioni assicurative e regole settoriali iniziano a richiedere evidenze simili. La convergenza ridurrebbe l’incertezza su quali controlli meritino investimenti iniziali.
La frammentazione creerebbe un onere maggiore. Una startup potrebbe affrontare formati di valutazione diversi per ogni cliente, autorità di regolamentazione e partner.
Gli acquirenti hanno un ruolo nel determinare questo esito. Dovrebbero chiedere ai fornitori quali modelli e fonti di dati supportano un flusso di lavoro, quali azioni può intraprendere il sistema e come il fornitore testa i confini di accesso.
Dovrebbero anche chiedere cosa accade dopo un aggiornamento del modello. Una valutazione precedente offre una protezione limitata se un fornitore modifica il comportamento o l’applicazione acquisisce nuovi strumenti.
Gli sviluppatori dovrebbero trattare ogni autorizzazione aggiunta come una nuova decisione di sicurezza. Collegare un assistente a email, codice sorgente, record dei clienti o dati di laboratorio cambia le conseguenze di un errore.
Anche i knowledge worker dovrebbero comprendere questi confini. Hanno bisogno di segnali chiari su quali informazioni possano entrare in un sistema AI e quali output richiedano una revisione indipendente.
Il panel di Sandia non ha risolto queste questioni. Ha reso più difficile per le startup rimandarle.
La lezione più duratura è che la sicurezza dell’AI copre l’intero sistema operativo attorno a un modello. Dati, istruzioni, software, autorizzazioni, utenti e monitoraggio influenzano tutti il risultato.
Questa lezione chiarisce anche ciò che i fondatori dovrebbero fare ora. Definire il sistema, classificare i suoi guasti a maggiore impatto, testarli, ridurre le autorizzazioni e conservare le evidenze.
Poi chiedersi se ogni nuova capacità meriti l’autorità che riceve. Una demo persuasiva non è una dimostrazione di assurance, e la reputazione di un fornitore non sostituisce i test dell’applicazione.
Le linee guida di Sandia sulla sicurezza dell’AI conteranno soprattutto se le aziende trasformeranno questa disciplina in lavoro ordinario sul prodotto. I fondatori dovrebbero iniziare selezionando un flusso di lavoro con conseguenze rilevanti e documentandone rischi, controlli, test e limiti irrisolti.
