Gerald Kierce, CEO e Co-Fondatore di Trustible – Serie di Interviste

Gerald Kierce, CEO e Co-Fondatore di Trustible, è un leader tecnologico e politico concentrato sull’operativizzazione dell’AI responsabile. Guida la missione di Trustible per aiutare le organizzazioni a costruire fiducia, gestire il rischio e conformarsi alle normative emergenti sull’AI. In precedenza, ha ricoperto il ruolo di Vice Presidente e Direttore Generale delle Soluzioni AI di FiscalNote, dove ha sovrinteso ai prodotti AI aziendali e ha ricoperto ruoli senior nello sviluppo aziendale, prodotto, customer success e operazioni esecutive. La sua carriera si è sempre svolta all’intersezione tra tecnologia, regolamentazione e esecuzione aziendale scalabile.

Trustible fornisce una piattaforma di governance AI che aiuta le organizzazioni a inventariare i sistemi AI, valutare e mitigare il rischio e operativizzare la conformità attraverso flussi di lavoro strutturati e documentazione. Progettata per team legali, di conformità e AI, la piattaforma centralizza le attività di governance, allinea i casi d’uso AI con i quadri normativi e consente un deploy più rapido e trasparente di AI responsabile in tutta l’azienda.

Si è spostato dal marketing dei prodotti e dal lavoro di Chief of Staff alla guida delle soluzioni AI di FiscalNote prima di fondare Trustible. Cosa ha visto in quei ruoli che lo ha convinto che la governance AI necessitava di una piattaforma dedicata, e quale problema era determinato a risolvere per primo quando ha lanciato Trustible?

Ero abbastanza fortunato da avere molti ruoli durante i miei 8+ anni a FiscalNote, dove ho iniziato come dipendente di Seed/Series A e ho lasciato come dirigente senior dopo l’IPO.

Attraverso il marketing dei prodotti, il lavoro di Chief of Staff e infine la guida delle soluzioni AI di FiscalNote, continuavo a vedere lo stesso problema emergere da diverse angolazioni. La governance AI è fondamentalmente un problema sociotecnico, ma la maggior parte delle organizzazioni lo stava affrontando in modo frammentato. I team trattavano le prestazioni AI, la sicurezza, la privacy, l’etica e le revisioni legali come piste separate, spesso di proprietà di diverse funzioni con poco midollo operativo condiviso che le legava insieme. Queste cinque dimensioni assolutamente importanti devono essere affrontate in modo collaborativo. Ma dove le organizzazioni stavano lottando era tradurre quell’intento sociotecnico in qualcosa di duraturo una volta che l’AI si muoveva nella vera presa di decisioni.

Allo stesso tempo, l’ambiente normativo intorno all’AI stava chiaramente cambiando. L’Atto AI dell’UE e le norme correlate segnalavano uno spostamento verso la governance dell’AI come infrastruttura regolamentata piuttosto che tecnologia sperimentale. Ciò che divenne evidente era che molte aziende stavano cercando di mappare le aspettative politiche e normative sui sistemi AI dopo il deploy, invece di progettare la governance che poteva operativizzare continuamente l’intento normativo attraverso quelle dimensioni sociotecniche.

La mia esperienza a FiscalNote è stata importante perché stavamo applicando l’AI al paesaggio politico, legale e normativo stesso. Stavamo aiutando le organizzazioni a capire come le leggi evolvono, come vengono interpretate le esigenze e come le aspettative normative si traducono in obblighi operativi nel tempo. Quell’esperienza ha reso chiaro che una governance AI efficace richiede la stessa disciplina al contrario: applicare il pensiero politico e normativo direttamente a come vengono costruiti, distribuiti, monitorati e adattati i sistemi AI mentre le condizioni cambiano.

I clienti descrivevano costantemente gli stessi punti deboli. Non potevano rispondere con fiducia a cosa fossero i sistemi AI in produzione, quali fossero ad alto rischio secondo le normative emergenti, chi fosse responsabile quando i sistemi attraversavano i confini funzionali o come dimostrare la conformità continua mentre i modelli, i dati, i fornitori e le normative evolvevano simultaneamente.

Quando abbiamo lanciato Trustible, il primo problema che abbiamo cercato di risolvere era trasformare la governance sociotecnica dalla teoria alla realtà operativa. Ci siamo concentrati sulla creazione di un sistema che collega il comportamento tecnico, il contesto di rischio dell’uso, la proprietà e le aspettative normative in un unico posto. Trustible è stato costruito per dare alle organizzazioni un sistema di registrazione vivente per l’AI, con visibilità continua e responsabilità, in modo che la governance potesse stare al passo con sia il cambiamento tecnologico che l’evoluzione normativa piuttosto che rimanere indietro.

Dalla prima linea, cosa ha imparato nell’ultimo anno sul perché i programmi di governance si bloccano una volta che l’AI si muove nelle vere decisioni, flussi di lavoro e esperienze rivolte al cliente?

Una volta che l’AI esce dall’esperimento e si muove nei flussi di lavoro reali, la governance tende a bloccarsi per ragioni molto pratiche piuttosto che filosofiche. La maggior parte delle organizzazioni semplicemente non sa come valutare il rischio AI in un modo che si colleghi a come i sistemi vengono effettivamente utilizzati. Possono valutare i modelli in astratto, ma lottano per valutare il rischio al livello dell’uso, dove il contesto, l’impatto e le decisioni a valle contano molto più dei metriche tecniche da sole.

Questo problema diventa ancora più pronunciato con l’AI generativa. Un singolo modello di base potrebbe essere utilizzato per il supporto clienti, la ricerca interna, il supporto alle decisioni o la generazione di contenuti, ognuno con profili di rischio molto diversi. Senza un metodo strutturato per valutare e confrontare questi usi, i team o esagerano con la cautela o procedono senza vera fiducia.

L’AI di terze parti complica ulteriormente le cose. Le organizzazioni si affidano pesantemente ai fornitori e alle capacità AI incorporate, ma mancano di metodi coerenti per valutare quei sistemi, capire i controlli upstream o determinare come il rischio del fornitore si traduca nel loro stesso esposizione operativa e normativa. Di conseguenza, le revisioni diventano soggettive e lente.

Queste sfide vengono amplificate dalle lacune di competenza e proprietà. Le responsabilità di governance sono spesso distribuite tra team legali, di conformità, sicurezza, dati e prodotti senza un quadro condiviso o un proprietario chiaramente responsabile una volta che i sistemi raggiungono la produzione. Combinato con strumenti inadeguati come fogli di calcolo, repository di documenti o piattaforme GRC legacy, i team di governance perdono la visibilità su cosa sta cambiando e perché è importante.

Al suo nucleo, la governance si blocca perché le organizzazioni stanno applicando vecchi playbook progettati per sistemi statici a sistemi AI dinamici. L’AI richiede una valutazione continua del rischio, una proprietà chiara legata ai risultati e strumenti che riflettono come i sistemi si comportano effettivamente in produzione piuttosto che come sono stati approvati sulla carta.

Infine, la proprietà è spesso irrisolta. In molte organizzazioni, non c’è un proprietario chiaramente responsabile per un sistema AI una volta che attraversa dall’esperimento alla produzione. Senza un proprietario aziendale nominato che sia responsabile dei risultati, la governance diventa consultiva e il progresso si rallenta.

Il filo comune è che le organizzazioni stanno applicando vecchi playbook di governance a una tecnologia fondamentalmente nuova. Quei playbook sono stati costruiti per sistemi statici e revisioni periodiche. L’AI richiede una valutazione continua del rischio, una proprietà più chiara e strumenti che collegano la governance direttamente a come i sistemi operano effettivamente in produzione.

Come definisce la governance AI di anno due, e cosa cambia quando un’organizzazione passa dall’adozione iniziale al monitoraggio continuo, alla gestione del drift e alla conformità continua?

La governance AI di anno due è il momento in cui l’AI smette di essere trattata come una serie di progetti e inizia a essere trattata come infrastruttura sottostante per la presa di decisioni. Ciò che intendo è che, nel primo anno, la governance AI è in gran parte un enablement. I team si concentrano sull’approvazione dei casi d’uso, sulla documentazione dei modelli e sull’istituzione di processi di revisione in modo che l’AI possa procedere in modo responsabile.

Man mano che i sistemi AI si espandono e diventano integrati nei processi aziendali core, l’attenzione si sposta. La domanda non è più se qualcosa debba essere distribuito, ma se possa essere operato in modo sicuro e affidabile nel tempo mentre i dati, gli utenti, i fornitori e le normative cambiano. La governance AI diventa continua piuttosto che episodica, scatenata da cambiamenti reali nel comportamento o nel contesto piuttosto che da revisioni basate sul calendario.

Il rischio diventa anche dinamico. Invece di assegnare una valutazione di rischio statica al lancio, le organizzazioni devono capire come il rischio evolve man mano che i modelli si spostano, gli ambiti si espandono o nuovi stakeholder interagiscono con il sistema. La conformità segue lo stesso spostamento. Le esigenze normative si spostano dall’essere mappate alle politiche all’essere applicate attraverso controlli live, segnali di monitoraggio e prove catturate continuamente.

Un altro aspetto chiave della governance AI di anno due è l’introduzione della gestione degli incidenti AI reali. Le organizzazioni devono sapere quali sistemi vengono monitorati, priorizzare in base al rischio intrinseco, integrare i dati giusti per far emergere segnali significativi e definire criteri di allarme e escalation chiari. Ciò consente ai team di intervenire presto, prima che i problemi si trasformino in incidenti.

Con sistemi frammentati e risorse limitate, quali sono le prime capacità di governance che ritiene le aziende debbano standardizzare in tutta l’organizzazione?

Quando le risorse sono limitate, le organizzazioni devono essere deliberate su dove iniziare, perché le prime scelte determinano la traiettoria per tutto ciò che segue. La prima priorità è ottenere una visibilità affidabile su dove l’AI esiste effettivamente nell’azienda. Molti team credono di avere solo un pugno di sistemi AI, solo per scoprire AI ombra, capacità di fornitori incorporate e casi d’uso scalati silenziosamente che non sono mai stati revisionati formalmente. Senza una visibilità vivente su cosa è in produzione, le discussioni sulla governance rimangono teoriche e disconnesse dalla realtà.

Una volta che esiste la visibilità attraverso il tuo inventario AI, si tratta di guidare la responsabilità nei casi d’uso AI. La governance si rompe rapidamente quando la responsabilità è distribuita tra comitati o funzioni. Le organizzazioni devono assegnare chiaramente chi è responsabile dei risultati quando un sistema AI prende o influenza le decisioni, non solo chi lo ha costruito o revisionato inizialmente. Questa chiarezza diventa particolarmente importante quando si verificano incidenti o quando i modelli evolvono oltre il loro scopo originale.

Dopo di che, i team devono avere un modo pratico per ragionare sul rischio. Ciò significa stabilire un approccio condiviso alla classificazione del rischio che funzioni attraverso sistemi interni, casi d’uso di AI generativa e fornitori di terze parti. Senza una lente di rischio comune, le organizzazioni o esagerano con la scrutinizzazione dei sistemi a basso impatto o sottopongono a monitoraggio quelli che contano di più.

Infine, la governance deve generare prove come sottoprodotto delle normali operazioni. Spesso parliamo di “Dire, Fare, Dimostrare” come modo per dimostrare affidabilità nella governance AI. Catturare approvazioni, modifiche e segnali di monitoraggio mentre i sistemi funzionano consente alle organizzazioni di rispondere a audit, incidenti, richieste dei clienti e domande normative con fiducia piuttosto che ricostruzione. Queste fondamenta non devono essere perfette all’inizio, ma devono essere coerenti e ripetibili se la governance deve scalare.

Perché ritiene che la governance AI debba essere trattata con la stessa serietà della sicurezza informatica o della GRC, e dove i leader sottovalutano di più il carico di lavoro operativo?

La governance AI comporta un rischio sistemico paragonabile alla sicurezza informatica e alla GRC, ma con una complessità aggiuntiva. Come i fallimenti della sicurezza informatica, i fallimenti dell’AI possono propagarsi rapidamente e invisibilmente attraverso un’organizzazione. Come la GRC, l’AI si interseca con obblighi legali, etici e operativi. A differenza di entrambi, i sistemi AI possono cambiare comportamento nel tempo senza azione umana esplicita.

Dove i leader tendono a sottovalutare il carico di lavoro è nelle continue esigenze operative. Il monitoraggio è continuo piuttosto che periodico. La coordinazione copre team di prodotto, dati, IT, legali, conformità e procurement. La gestione del cambiamento è costante perché i modelli, i fornitori, i casi d’uso e le normative evolvono simultaneamente.

Le organizzazioni che trattano la governance AI come un esercizio di conformità una tantum inevitabilmente lottano. Quelle che si avvicinano come infrastruttura operativa, molto come la sicurezza o l’ingegneria dell’affidabilità, sono molto meglio posizionate per scalare l’AI in modo sicuro e sostenibile.

Man mano che gli Stati americani spingono avanti con le regole sull’AI mentre la politica federale rimane controversa, come consiglierebbe di progettare la governance in modo che rimanga resiliente attraverso l’incertezza normativa?

L’ambiente normativo per l’AI è incerto e in evoluzione. I programmi di governance più resilienti sono costruiti intorno alle esigenze piuttosto che alle singole normative. Invece di reagire a ogni nuova legge con processi su misura, le organizzazioni dovrebbero concentrarsi sulle aspettative comuni che appaiono attraverso le giurisdizioni, come l’inventario, la trasparenza, la responsabilità, la valutazione del rischio, la supervisione umana e la documentazione.

Quando i sistemi di governance sono modulari, nuove esigenze normative possono essere mappate sui controlli esistenti piuttosto che costringere i team a reinventare il loro approccio ogni volta che il paesaggio si sposta. Ciò riduce l’attrito e aiuta la governance a stare al passo con il cambiamento politico.

L’obiettivo non è ottimizzare la conformità con le regole di oggi, ma adattarla man mano che le aspettative evolvono.

Guardando verso il 2026, quali capacità di governance AI si aspetta diventeranno imprescindibili man mano che le organizzazioni scalano l’AI attraverso più unità aziendali?

Man mano che l’AI si sposta da piloti isolati a sistemi che plasmano decisioni reali, le aspettative di governance stanno cambiando altrettanto rapidamente. Entro il 2026, le organizzazioni non saranno più in grado di affidarsi ai playbook che hanno funzionato nel 2024 e 2025, quando la supervisione dell’AI era spesso manuale, episodica e centrata sulle singole revisioni. Il monitoraggio continuo diventerà un requisito fondamentale, perché la documentazione statica e le valutazioni punto-nel-tempo non soddisferanno i regolatori, i consigli di amministrazione, i dipendenti o i clienti in un ambiente AI dinamico.

Man mano che l’AI si integra in più team e flussi di lavoro, le organizzazioni avranno anche bisogno di una governance coerente attraverso catene di approvvigionamento AI sempre più complesse. I modelli interni, i fornitori di terze parti, le funzionalità AI incorporate e i componenti autonomi dovranno tutti essere governati attraverso la stessa lente, piuttosto che trattare l’AI del fornitore come un punto cieco o supporre che la responsabilità finisca all’acquisto.

Le prove pronte per l’audit dovranno essere disponibili su richiesta man mano che l’applicazione normativa si stringe e le aspettative pubbliche per la trasparenza aumentano. Ciò significa catturare l’attività di governance mentre i sistemi AI vengono progettati, distribuiti e monitorati, piuttosto che ricostruire le decisioni dopo un incidente o una richiesta di audit.

Infine, la governance dovrà essere integrata in tutto il ciclo di vita dell’AI. La supervisione non sarà una revisione legale al deploy, ma una capacità operativa integrata nei flussi di lavoro SDLC, MLOps e di procurement per i fornitori di terze parti. Le organizzazioni che costruiscono queste capacità saranno meglio posizionate per adattarsi all’incertezza normativa, rispondere agli incidenti e scalare l’AI più velocemente e in modo più sicuro man mano che le aspettative continuano a evolversi.

Se stesse consigliando un’azienda che ha già l’AI in produzione ma nessun programma di governance formale, cosa sarebbe un realistico primo 90 giorni?

I primi 30 giorni dovrebbero concentrarsi sull’acquisizione della visibilità di base. Ciò significa identificare quali sistemi AI sono in produzione, capire dove influenzano le decisioni reali e assegnare una proprietà chiara.

La fase successiva consiste nell’istituzione di controlli di base. Le organizzazioni dovrebbero definire come classificano il rischio, introdurre punti di controllo per sistemi ad alto rischio e iniziare a monitorare le aree che più contano.

Nell’ultima fase, la governance deve passare dall’installazione all’operazione. Il monitoraggio dovrebbe essere integrato nei flussi di lavoro esistenti, i percorsi di escalation dovrebbero essere chiaramente definiti e le prove dovrebbero iniziare ad accumularsi naturalmente man mano che i sistemi funzionano.

L’obiettivo nei primi 90 giorni non è la perfezione. È la momentum. Un programma di governance che funziona imperfettamente nella pratica è molto più prezioso di uno che esiste solo sulla carta.”

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Trustible.