Vin Sharma, cofondatore e CEO di Vijil – Intervista

Vin Sharma è cofondatore e CEO di Vijil e vanta oltre 30 anni di esperienza nei settori della cybersicurezza, dell’open source, del cloud computing e delle infrastrutture per l’IA. Prima di fondare l’azienda, ha guidato attività di ingegneria del deep learning presso AWS per Amazon SageMaker e Amazon Bedrock, ha sviluppato infrastrutture per data center in Intel e ha ricoperto ruoli nei settori dei prodotti e dell’ingegneria in Hewlett-Packard. La sua carriera è iniziata con test automatizzati di red team per sistemi UNIX fidati: un’esperienza che oggi orienta il suo impegno nel rendere gli agenti di IA aziendali affidabili, protetti e sicuri.

Vijil fornisce infrastrutture di fiducia per gli agenti di IA aziendali, aiutando le organizzazioni a valutarne il comportamento, applicare controlli e migliorarne la resilienza durante l’intero ciclo di vita. Il suo approccio combina test, sicurezza e feedback continuo per allineare il comportamento degli agenti agli obiettivi e alle politiche che l’organizzazione ha definito. In questa intervista, Sharma spiega come definire e misurare la fiducia, perché i test sugli agenti differiscono dalle tradizionali verifiche di sicurezza del software e quale livello di supervisione serve alle aziende man mano che gli agenti acquisiscono autonomia.

Hai lavorato per oltre 30 anni in aziende come AWS, Intel e Hewlett-Packard prima di fondare Vijil. Che cosa ti ha convinto, in ultima analisi, che la fiducia e la sicurezza nell’IA fossero un problema irrisolto abbastanza importante da giustificare la fondazione di un’azienda?

Prima di entrare in una startup di sicurezza, 30 anni fa, frequentavo un corso di laurea specialistica e studiavo IA e apprendimento automatico. Da allora ho lavorato in team di prodotto che hanno integrato una sicurezza di livello militare nei sistemi operativi basati su Unix e Linux, realizzato server web sicuri per l’online banking, sviluppato ambienti di esecuzione fidati per il cloud computing e integrato la crittografia nelle piattaforme di analisi dei dati. Più di recente, sono tornato al punto di partenza, contribuendo a realizzare servizi di IA/apprendimento automatico pronti per le aziende in AWS. Questo percorso mi ha convinto che integrare la fiducia in un sistema intelligente è più difficile che costruire il sistema intelligente stesso. Sebbene il settore dell’IA sembri ampiamente impegnato ad aumentare le capacità degli agenti, ritengo che dovremmo investire altrettante risorse nell’integrare negli agenti meccanismi scalabili di supervisione e controllo. Senza metriche e meccanismi adeguati alle esigenze delle singole organizzazioni, l’iniziale ondata di adozione entusiastica si infrangerà sui banchi di sabbia del rischio e del ROI, perché le aziende non saranno in grado di dimostrare che i loro agenti agiscono nel loro interesse.

Vijil si basa sull’idea che molti agenti di IA non arrivino mai alla produzione perché le aziende non riescono a verificarne adeguatamente l’affidabilità, la sicurezza e l’assenza di rischi. Dove emergono le maggiori lacune di fiducia mentre le aziende passano dai prototipi di IA alle implementazioni in produzione?

Il principale ostacolo alla diffusione di un numero crescente di agenti dotati di sempre maggiore autonomia è la capacità delle organizzazioni di definire il comportamento previsto dei propri agenti e verificare che si comportino come desiderato. E non basta: devono poterlo fare alla scala e alla velocità con cui operano gli agenti. È logico, quindi, che serva un modo per consentire agli agenti di misurare e modificare il comportamento di altri agenti. Due delle lacune principali riguardano la comprensione di che cosa misurare (che cosa significa «fare bene» nel caso degli agenti) e di che cosa modificare (quali componenti del sistema dell’agente regolare per ottenere il comportamento voluto dal suo mandante: il modello e i relativi parametri, il prompt di sistema, le istruzioni dell’utente, l’ambiente operativo dell’agente o il grafo dei sistemi multi-agente).

In che modo Vijil definisce e misura la «fiducia» in un agente di IA e quali indicatori o parametri di riferimento sono più importanti per stabilire se un agente è pronto a operare all’interno di un’azienda?

Definiamo la fiducia come il beneficio atteso dalla delega a un agente autonomo, scontato in base al rischio che tradisca le nostre intenzioni. Ciò significa che ci si può fidare di un agente se si comporta correttamente in condizioni normali, rumorose e ostili e, quando commette un errore, riduce al minimo il raggio d’impatto. Possiamo quindi misurare la fiducia secondo tre pilastri: affidabilità, sicurezza e incolumità. Gli agenti sono affidabili quando operano come previsto in condizioni diverse; sono sicuri quando operano come previsto in condizioni ostili; e sono innocui quando riescono a ridurre al minimo i rischi aziendali, legali e tecnici.

Gli agenti di IA possono comportarsi in modo imprevedibile perché combinano modelli, strumenti, fonti di dati, memoria e sistemi esterni. In che cosa differiscono i test sugli agenti dai tradizionali test di sicurezza delle applicazioni o dalla valutazione convenzionale dei modelli?

Il software tradizionale si guasta in modi ormai ben noti: in termini generali, non riesce a gestire input malformati, presenta punti deboli nella logica e nella progettazione del sistema, bug nell’implementazione, vulnerabilità agli attacchi non individuate ed effetti collaterali imprevisti degli output. È quindi possibile prevedere con una certa precisione i test necessari per individuare questi problemi. Gli agenti ampliano enormemente la superficie dei possibili guasti, al punto che essa sfugge del tutto alla valutazione dei modelli, ai test unitari, ai test d’integrazione, ai test di sicurezza delle applicazioni, ai test di penetrazione e alle verifiche di conformità. Per testare la nuova superficie di rischio degli agenti servono metriche e meccanismi che ne valutino il comportamento rispetto agli obiettivi definiti dal mandante, alle caratteristiche degli utenti e alle politiche dell’organizzazione, del settore e della regione in cui operano.

Il tuo percorso comprende la guida di progetti di ingegneria del deep learning per Amazon SageMaker e Amazon Bedrock. Quali insegnamenti tratti dalla realizzazione di infrastrutture di IA in AWS hanno influenzato maggiormente il tuo approccio alla sicurezza e all’affidabilità degli agenti in Vijil?

L’insegnamento più formativo è stato che individuare tempestivamente, durante il ciclo di sviluppo, i problemi di affidabilità, sicurezza e conformità dei servizi era molto più efficace ed efficiente che scoprirli alla vigilia del lancio, come si faceva tradizionalmente, o, peggio ancora, dopo la messa in produzione del servizio, quando ci si ritrovava a rispondere alle telefonate per un servizio non funzionante.

Vijil non si limita a testare gli agenti prima della distribuzione, ma li protegge e li migliora costantemente anche in produzione. Quali tipi di rischi diventano visibili solo quando un agente inizia a interagire con utenti reali, dati e sistemi aziendali?

Il mondo reale ha una capacità infinita di sorprenderci. E un agente colto di sorpresa è incline a commettere errori. Se un agente sbaglia a generare un meme, a nessuno importa. Un agente progettato per assistere o sostituire un consulente finanziario, un assistente legale, un avvocato, un infermiere, un medico, un paziente o un professionista di qualsiasi settore in cui sia necessario dimostrare una condotta fiduciaria non può funzionare se i margini di tolleranza non sono definiti con precisione, monitorati attentamente e il comportamento dell’agente ripristinato rapidamente.

Man mano che le aziende adottano agenti sempre più autonomi, capaci di agire anziché limitarsi a generare risposte, come deve evolvere il modello di sicurezza? Concetti tradizionali come autorizzazioni, identità e controllo degli accessi sono sufficienti?

No. Quando gli agenti diventano soggetti attivi all’interno di un’organizzazione, è necessario assegnare loro identità univoche e verificabili; occorre attribuire loro ruoli che vincolino sia il comportamento sia i componenti funzionali (strumenti con autorizzazioni di accesso alle risorse) mediante politiche obbligatorie di controllo degli accessi; bisogna monitorare costantemente eventuali deviazioni dallo scopo previsto e indirizzarli affinché mantengano la propria resilienza sotto attacco.

Vijil è passata da un round Seed da 6 milioni di dollari a un round Series A da 17 milioni, costruendo al contempo un team fondatore di circa 20 persone e raggiungendo il primo milione di dollari di ricavi ricorrenti annuali. Quali sono state le decisioni più importanti che vi hanno permesso di passare da un primo concetto tecnico all’adozione commerciale?

Fin dall’inizio abbiamo scelto di realizzare un livello di fiducia integrabile con la piattaforma scelta dal cliente, prevedendo però che le aziende avrebbero cercato sempre più personalizzazione, controlli più granulari e costi inferiori per i sistemi multi-agente basati su modelli aperti. La strategia a lungo termine di costruire un livello di piattaforma anziché un prodotto singolo ci offre vantaggi competitivi, ma crea anche condizioni difficili: trovare aziende pronte ad adottare una governance degli agenti su larga scala non è semplice come vendere un servizio di migrazione lift-and-shift.

Hai iniziato la tua carriera nel 1995 sviluppando test automatizzati di red team per sistemi UNIX affidabili. A quasi tre decenni di distanza, come sono cambiati i principi del red teaming quando il sistema sottoposto a test è un agente di IA capace di ragionare, adattarsi e usare strumenti esterni?

Storicamente, il red teaming consisteva nel mettere alla prova le difese di un’organizzazione contro un attacco coordinato. I principi generali restano validi. Dobbiamo ancora coordinare attacchi in condizioni controllate per individuare i punti deboli dell’organizzazione sottoposta a test. Tuttavia, le esercitazioni di red team del periodo intermedio, basate su scenari predefiniti per testare i sistemi software, non sono più adeguate: gli agenti di IA non sono software deterministici, ma sono progettati per adattarsi all’ambiente, perciò lo stesso attacco non può essere ripetuto in modo prevedibile. Sostengo che gli agenti vadano trattati come le aziende. Di conseguenza, il red teaming degli agenti deve necessariamente adattarsi al loro scopo, verificare eventuali deviazioni dalle intenzioni degli utenti e valutare la loro volontà e capacità di eludere le politiche dell’ambiente in cui operano.

Guardando al futuro, pensi che test indipendenti e standard misurabili di affidabilità per gli agenti di IA diventeranno un requisito preliminare alla loro adozione aziendale? E cosa deve accadere nel settore perché questo livello di garanzia diventi una prassi standard?

Oggi chi sviluppa gli agenti ne valuta le capacità, i red team ne verificano la resistenza alle prompt injection e ai jailbreak, mentre i team GRC hanno appena iniziato a controllarne la conformità alle normative. Sono pochissime le organizzazioni che adottano un regime di verifica del comportamento, attivo in modo continuo e in background per tutto il ciclo di vita dell’agente, mentre cambiano modelli, strumenti, risorse, flussi di lavoro e ambiente operativo. Ancora più importante, Vijil offre alle aziende un vantaggio distintivo: ricostruisce il comportamento effettivo dell’agente in produzione risalendo alle specifiche, in un ciclo di feedback che lo migliora costantemente. Gli agenti che resistono agli attacchi sono quelli che si adattano per mantenere la propria resilienza.

Grazie per la bella intervista. I lettori che desiderano saperne di più su come testare, proteggere e migliorare costantemente gli agenti di IA aziendali possono visitare Vijil.