La governance dell’IA non può essere un ripensamento

Abhishek Ranjan è il CTO di Apna e Blue Machines, dove è profondamente coinvolto nella trasformazione sia della forza lavoro umana sia di quella basata sull'intelligenza artificiale.

Abbiamo parlato con lui della governance nei flussi di lavoro basati sull'intelligenza artificiale. Ecco cosa ci ha detto.

La tecnologia al fianco delle persone

Sono Abhishek Ranjan. Sono il CTO di Apna e Blue Machines. Due mondi molto connessi, ma diversi, hanno plasmato il mio percorso fino a questo momento di trasformazione basata sull'intelligenza artificiale.

In Apna sviluppiamo soluzioni per la forza lavoro umana. Apna è una delle aziende unicorno in più rapida crescita dell'India, con oltre 60 milioni di utenti sulla piattaforma. A questa scala, osserviamo da vicino la forza lavoro indiana. Vediamo milioni di persone alla ricerca di opportunità migliori, datori di lavoro che cercano di assumere più rapidamente, lingue diverse, livelli di competenza differenti e livelli variabili di accesso e sicurezza nell'uso delle tecnologie digitali.

In Blue Machines sviluppiamo soluzioni per la forza lavoro basata sull'intelligenza artificiale. Ci concentriamo sull'intelligenza artificiale vocale per le aziende, elaborando milioni di minuti ogni giorno. Non costruiamo soltanto bot che rispondono alle domande. Creiamo lavoratori basati sull'intelligenza artificiale in grado di parlare con i clienti, comprendere il contesto, raccogliere feedback, migliorare nel tempo ed eseguire flussi di lavoro aziendali reali.

Ho visto la tecnologia aiutare le persone a trovare lavoro, crescere e partecipare all'economia. E ora vedo l'intelligenza artificiale stessa diventare un nuovo tipo di forza lavoro in grado di operare al fianco delle persone.

Per me, quindi, questo momento non riguarda soltanto l'uso dell'intelligenza artificiale per aumentare la produttività o scrivere codice più velocemente. Riguarda il ripensamento del modo in cui operano le aziende e del modo in cui viene svolto il lavoro.

L'architettura di due aziende molto diverse

L'architettura di Apna è costruita come quella di una grande piattaforma di mercato. Disponiamo di sistemi per i consumatori, sistemi per i datori di lavoro, piattaforme dati, sistemi di intelligenza artificiale e di abbinamento, ricerca, comunicazione, livelli per la prevenzione delle frodi e la fiducia, oltre a funzionalità di selezione del personale e preparazione ai colloqui basate sull'intelligenza artificiale. Il modello di distribuzione è basato innanzitutto sul cloud, altamente scalabile e progettato per garantire un'elevata disponibilità, perché milioni di utenti e migliaia di aziende utilizzano la piattaforma.

L'organizzazione ingegneristica conta oltre 100 persone, che lavorano nei team di ingegneria del prodotto, backend, frontend, dispositivi mobili, dati, intelligenza artificiale, infrastruttura, sicurezza e piattaforma. Ci concentriamo non solo sulla creazione di funzionalità, ma anche sulla realizzazione di sistemi affidabili in grado di operare su scala enorme.

Blue Machines è un'organizzazione tecnologica di tipo diverso. Si concentra sull'intelligenza artificiale vocale per le aziende e sui flussi di lavoro basati su agenti. Stiamo creando lavoratori basati sull'intelligenza artificiale in grado di parlare, ragionare, intraprendere azioni, integrarsi con i sistemi aziendali e migliorare grazie al feedback. Oggi operiamo già su una scala significativa, elaborando ogni giorno milioni di minuti di interazioni vocali basate sull'intelligenza artificiale.

L'architettura di Blue Machines è più orientata al tempo reale e nativa per l'intelligenza artificiale. Comprende infrastruttura vocale, telefonia, conversione da voce a testo, ragionamento dei modelli linguistici di grandi dimensioni, sintesi vocale, orchestrazione dei flussi di lavoro, integrazioni, analisi, osservabilità e sistemi di valutazione. La complessità del prodotto è elevata, perché l'intelligenza artificiale vocale aziendale deve funzionare in produzione, nelle conversazioni reali, con bassa latenza, alta precisione, misure di conformità e risultati aziendali chiari.

In Blue Machines, un team centrale di quattro ingegneri ha costruito una piattaforma distribuita di orchestrazione vocale nel giro di poche settimane. Disponiamo inoltre di un team di ricerca altamente qualificato, impegnato in profondità nell'intelligenza artificiale vocale, nella valutazione degli agenti, nel ragionamento, nella latenza, nei sistemi multilingue e nel miglioramento degli agenti nel tempo. Questa profondità nella ricerca è importante, perché l'intelligenza artificiale vocale aziendale non può essere risolta semplicemente collegando tra loro i modelli. Richiede una solida ingegneria del prodotto, una solida ingegneria dei sistemi e una solida ricerca applicata sull'intelligenza artificiale.

Nel complesso, l'organizzazione tecnologica che guido si trova all'intersezione tra piattaforme su larga scala e sistemi nativi per l'intelligenza artificiale.

Come un'intelligenza artificiale ben governata migliora il ciclo di vita del software

Nell'ultimo anno, l'intelligenza artificiale ha cambiato il modo in cui sviluppiamo, testiamo e rilasciamo la tecnologia.

In precedenza, il nostro processo di rilascio era più tradizionale. Gli ingegneri sviluppavano le funzionalità, aprivano PR, partecipavano alle revisioni tra pari, eseguivano i casi di test e poi distribuivano il codice attraverso la consueta pipeline di distribuzione.

Quando la programmazione assistita dall'IA è diventata una parte sempre più importante dell'ingegneria del software, l'abbiamo adottata — e presto ci siamo resi conto che i soli miglioramenti della velocità non erano sufficienti. L'IA può aiutare gli ingegneri a scrivere codice più velocemente, ma se la governance non migliora può anche creare più bug nascosti, casi limite ignorati o astrazioni inadeguate.

Così abbiamo cambiato il modello operativo.

1. Abbiamo aggiunto un livello di revisione delle PR assistito dall'IA. Ogni PR veniva sottoposta a controlli per individuare logiche rischiose, casi limite mancanti, violazioni dei contratti delle API, problemi di sicurezza, rischi di migrazione e una copertura dei test insufficiente prima della revisione umana. Questo ha ridotto le omissioni più evidenti prima della revisione.
2. Abbiamo rafforzato i controlli della CI. Una modifica non poteva procedere semplicemente perché il codice sembrava corretto. Doveva superare i test unitari, i test di integrazione, il controllo dello stile del codice, i controlli di sicurezza, i test dei contratti delle API e le suite di regressione per l'area di prodotto interessata.
3. Abbiamo creato pacchetti di regressione più solidi per i flussi di lavoro critici. Ad esempio, aggiungendo casi di test per scenari reali degli utenti, casi limite, comportamento multilingue, gestione degli errori e risultati aziendali.
4. Abbiamo modificato la governance delle istruzioni. Ne parleremo tra poco.
5. Abbiamo reso obbligatori i rilasci graduali per le aree ad alto rischio. Invece di rilasciare a tutti, distribuiamo il prodotto a una piccola percentuale del traffico, monitoriamo errori, latenza, conversioni, abbandoni, qualità degli agenti e impatto sui clienti, quindi procediamo con la distribuzione completa o con il ripristino.
6. Abbiamo aggiunto una migliore osservabilità. Quando qualcosa si rompeva, volevamo sapere esattamente quale versione del codice, versione delle istruzioni, modello, flusso di lavoro o dipendenza ne fosse la causa.

L'impatto è stato molto evidente. La nostra velocità di rilascio è aumentata significativamente. I team che in precedenza distribuivano rilasci più grandi e raggruppati ora passano a rilasci più piccoli e frequenti. In alcune aree, la frequenza dei rilasci è aumentata di quasi 2x-3x perché i controlli sono più automatizzati e la fiducia è maggiore. Ed è così che un team di quattro persone ha costruito una piattaforma distribuita complessa nel giro di poche settimane.

Anche il numero di problemi in produzione è diminuito perché ogni rilascio è più piccolo, meglio testato e più facile da annullare. Abbiamo registrato una riduzione significativa dei bug in produzione, soprattutto dove la regressione automatizzata e i rilasci graduali sono ormai obbligatori. Oggi i difetti sono quasi il 40% inferiori rispetto al valore di riferimento iniziale.

La sola IA offre velocità. L'IA con la governance offre velocità e qualità.

Perché le istruzioni devono essere trattate come codice

Condivide Abhishek

Per i sistemi di IA, abbiamo iniziato a trattare le istruzioni come codice… Questo è stato un miglioramento importante. Sappiamo quali istruzioni erano attive, cosa è cambiato, cosa è migliorato e se i risultati per i clienti sono migliorati.

Per i sistemi di IA, abbiamo iniziato a trattare le istruzioni come codice.

Ora sottoponiamo le istruzioni a versionamento, revisione e test, le promuoviamo tra gli ambienti e le distribuiamo gradualmente. Le istruzioni non vengono più trattate come piccoli aggiornamenti di configurazione. Sono sottoposte a conversazioni di test, casi limite, verifiche multilingue, controlli della latenza, controlli di conformità e verifiche dei risultati aziendali.

Possiamo rilasciare prima nuove istruzioni o un nuovo flusso di lavoro dell'agente a una piccola percentuale del traffico, osservarne i risultati e promuoverli se le metriche mostrano un miglioramento.

Questo è stato un miglioramento importante. In precedenza era difficile capire se una modifica alle istruzioni avesse migliorato l'agente o ne avesse semplicemente cambiato il comportamento. Ora possiamo confrontare le versioni in modo più obiettivo. Sappiamo quali istruzioni erano attive, cosa è cambiato, cosa è migliorato e se i risultati per i clienti sono migliorati.

Il cambiamento più significativo è che l'intero sistema tecnologico è diventato più automatizzato, più misurabile e sottoposto a una governance migliore.

Un flusso di lavoro di rilascio per l'ingegneria agentica

Utilizziamo un flusso di lavoro di rilascio per l'ingegneria agentica, con il coinvolgimento delle persone nei punti chiave.

Questo flusso di lavoro non è adatto a ogni rilascio. Per modifiche molto complesse alla piattaforma, cambiamenti profondi all'architettura o sistemi sensibili, utilizziamo ancora un processo più tradizionale guidato dalle persone. Tuttavia, per alcune aree di prodotto, soprattutto per i flussi di lavoro che evolvono più rapidamente, è diventato il modo predefinito di sviluppare.

Ecco il flusso di lavoro:

1. Il processo inizia quando arriva un requisito di prodotto o un problema di ingegneria. Un agente di pianificazione basato sull'IA legge il requisito, lo suddivide in attività, identifica le dipendenze, segnala le aree rischiose e suggerisce un piano di implementazione. L'ingegnere esamina il piano, corregge le ipotesi e decide l'approccio finale.
2. Successivamente, un agente di programmazione genera il codice, ristruttura i moduli, scrive il codice standard e crea test unitari e di integrazione. Un agente di revisione controlla la PR alla ricerca di logiche rischiose, casi limite mancanti, problemi di sicurezza, violazioni dei contratti API e lacune nei test.
3. Poi, un agente di test crea scenari di regressione e convalida i casi limite. Per i flussi di lavoro basati sull'IA, esegue anche valutazioni dei prompt, test delle conversazioni, verifiche multilingue, controlli della latenza e verifiche dei risultati aziendali.
4. L'agente di rilascio raccomanda quindi se la modifica è sicura per una distribuzione canary sulla base dei risultati dei test, dell'area di impatto, degli errori passati e della preparazione all'osservabilità. Tuttavia, le persone approvano ancora le promozioni critiche, soprattutto se la modifica influisce sui ricavi, sull'esperienza del cliente, sulla sicurezza o sull'infrastruttura principale.
5. Una volta rilasciata, l'agente di monitoraggio controlla errori, latenza, conversioni, abbandoni, qualità dell'agente e impatto sui clienti. Se qualcosa sembra non funzionare, raccomanda il rollback, apre un incidente, riepiloga i log e crea una prima bozza dell'RCA.

Questo flusso di lavoro è agentico, ma non autonomo alla cieca. Gli agenti IA pianificano, programmano, revisionano, testano, rilasciano, monitorano e riepilogano. Le persone approvano, mettono in discussione, stabiliscono le priorità e mantengono la responsabilità della decisione finale.

Dove Claude Code e Cursor eccellono

I miei strumenti preferiti sono Claude Code e Cursor, a seconda del flusso di lavoro.

Cursor eccelle quando gli ingegneri desiderano un'IA profondamente integrata nel loro IDE per la programmazione quotidiana, la ristrutturazione del codice, la comprensione della base di codice e un'implementazione più rapida.

Claude Code si dimostra estremamente utile per attività più agentiche: comprendere basi di codice più ampie, apportare modifiche a più file, generare test, correggere problemi e iterare come un partner di ingegneria.

Perché l'IA offre leva mentre le persone forniscono giudizio

Ora facciamo ampio affidamento sull'IA per tutto ciò che migliora velocità, copertura o coerenza, ma non per le attività che richiedono giudizio, responsabilità o compromessi a lungo termine.

Ad esempio, l'IA ora ci aiuta nella revisione del codice, nella generazione di casi di test, nella copertura della regressione, nella documentazione, nel debug, nell'analisi dei log e persino nel triage degli incidenti. Può identificare rapidamente percorsi di codice rischiosi, casi limite mancanti, possibili problemi di sicurezza o schemi negli errori di produzione. Nei sistemi di IA, ci aiuta anche a confrontare le versioni dei prompt, valutare le conversazioni e capire dove un agente sta fallendo.

Ma le decisioni finali restano alle persone. Ecco alcuni esempi:

• Le scelte architetturali devono restare umane perché comportano compromessi relativi a scalabilità, costi, affidabilità, capacità del team e direzione del prodotto a lungo termine.
• L'RCA completa può essere supportata dall'IA, ma le persone devono ancora collegare i punti, convalidare l'ipotesi e decidere la correzione.
• La definizione delle priorità del backlog resta affidata alle persone perché richiede il contesto del cliente, la strategia aziendale e il giudizio su ciò che conta davvero.
• Le revisioni della sicurezza utilizzano l'IA, ma è necessario il giudizio di esperti. L'IA può segnalare problemi, ma può anche generare falsi positivi o non rilevare rischi legati al contesto aziendale. Le persone mantengono la responsabilità perché il rischio e la responsabilità sono troppo elevati.

Esempi reali di errori dell'IA nel giudizio tecnico

Ecco un paio di esempi dell'importanza del giudizio umano.

Il primo riguardava picchi di latenza a livello di millisecondi nella nostra pipeline vocale. L'IA ha commentato correttamente il problema e ha identificato che la latenza in un percorso avrebbe potuto diventare un problema. Ma il codice suggerito era errato. Sembrava pulito, ma sotto carico avrebbe creato un collo di bottiglia diverso. Un ingegnere umano è intervenuto, ha compreso il comportamento in fase di esecuzione e ha risolto correttamente il problema.

Un altro esempio si è verificato durante il triage in produzione. Più sistemi a valle stavano fallendo e l'IA continuava ad analizzarli singolarmente, suggerendo ottimizzazioni. Ma sapevamo già che il vero problema era una dipendenza a monte che aveva fallito per prima. L'IA confondeva i fallimenti visibili con la causa principale.

È qui che l'IA ha ancora difficoltà. Può leggere i log, riassumere le tracce, suggerire correzioni e velocizzare la diagnosi dei problemi. Ma nei sistemi distribuiti complessi può non cogliere la causalità, le tempistiche e il contesto a livello di sistema.

Perché i team stanno diventando più snelli e con competenze più ampie

L'IA ha cambiato il profilo delle assunzioni più di quanto abbia cambiato l'organigramma.

In precedenza assumevamo persone per competenze funzionali più ristrette: sviluppo lato server, sviluppo lato client, QA, DevOps, dati e così via. Queste competenze sono ancora importanti, ma ora do valore agli ingegneri capaci di operare su tutti i livelli tecnologici, usare l'IA in modo approfondito e passare dal problema alla produzione con molto meno supporto.

I migliori ingegneri oggi non si limitano a scrivere codice. Progettano flussi di lavoro, usano l'IA per l'implementazione, generano test, revisionano i risultati, eseguono la diagnosi dei problemi più rapidamente e prestano attenzione alla qualità del rilascio.

Per questo il livello richiesto nelle assunzioni si è spostato verso ingegneri con forte senso di responsabilità e grande capacità di giudizio. Persone capaci di porre le domande giuste, verificare i risultati dell'IA, comprendere a fondo i sistemi e procedere in autonomia fino al rilascio.

Questo ha inoltre ridotto la necessità di grandi team in alcune aree. Un team più piccolo, ma capace di sfruttare efficacemente l'IA, oggi può svolgere attività che in precedenza richiedevano molte più persone.

Perché l'IA rende più difficile formare ingegneri alle prime armi

Condivide Abhishek

Non penso che vietare l’IA o costringere le persone a programmare come se fosse il 2010 sia la risposta. Sarebbe sbagliato. Ma non penso nemmeno che abbiamo risolto del tutto il problema di come sviluppare un solido giudizio ingegneristico quando l’IA svolge gran parte del lavoro preliminare. Per ora, la mia risposta migliore è rendere visibile la comprensione.

Come formiamo gli ingegneri alle prime armi nell'era dell'IA? Non ho ancora una risposta perfetta.

Quando abbiamo iniziato, gli IDE ci aiutavano. Poi ci ha aiutato Google. In seguito ci ha aiutato Stack Overflow. Ma in tutte queste fasi dovevi comunque affrontare il problema. Dovevi comprendere la risposta, adattarla, eseguire la diagnosi dei problemi e capire perché funzionasse.

Con l'IA e la programmazione intuitiva possiamo saltare questa fase di difficoltà. Un ingegnere alle prime armi può generare codice funzionante senza comprendere davvero il sistema, i compromessi o le modalità di errore. Questo mi preoccupa.

Non penso che vietare l'IA o costringere le persone a programmare come se fosse il 2010 sia la risposta. Sarebbe sbagliato. Ma non penso nemmeno che abbiamo risolto del tutto il problema di come sviluppare un solido giudizio ingegneristico quando l'IA svolge gran parte del lavoro preliminare.

Per ora, la mia risposta migliore è rendere visibile la comprensione. Gli ingegneri dovrebbero essere in grado di spiegare perché il codice funziona, dove può fallire, quali test sono importanti, cosa accade su larga scala e come eseguirebbero la diagnosi dei problemi in produzione.

Come gestire l'utilizzo dei token

Anche il costo è stato una difficoltà legata all'IA.

All'inizio l'utilizzo dei token sembra irrilevante, ma quando l'IA entra nella programmazione, nelle revisioni, nei test, nella diagnosi dei problemi e nei flussi di lavoro basati su agenti, il costo può crescere molto rapidamente.

Per questo ora dobbiamo misurare il ROI per flusso di lavoro e utilizzare un'orchestrazione più intelligente. Non ogni attività richiede il modello più costoso.

Il futuro consiste nell'utilizzare il modello giusto per l'attività giusta.

Perché i CTO devono muoversi rapidamente, con i giusti controlli

Ecco il mio consiglio: costruite rapidamente. Sperimentate rapidamente. Integrate l'IA nei flussi di lavoro reali di ingegneria, prodotto, assistenza, vendite, operazioni e nelle attività interne. Non fate finta che non funzioni. Funziona, a volte sorprendentemente bene.

Ma non diventate credenti ciechi. L'IA è potente, ma non è magia. Servono controllo, governance, test, osservabilità e responsabilità chiaramente definite. Altrimenti creerete soltanto caos più rapidamente.

La mentalità giusta non è né «l'IA sostituirà tutto» né «l'IA è sopravvalutata». La mentalità giusta è «come posso usare tutto questo per rendere la mia organizzazione 10 volte più capace?»

Segui gli aggiornamenti

Segui Abhishek Ranjan su LinkedIn. E dai un'occhiata alla sua newsletter Hacktivate.

Altre interviste con esperti in arrivo su The CTO Club!