Builder.ai: la startup dell’intelligenza artificiale che forse AI non era

Dalla nascita di Engineer.ai alla valutazione miliardaria

Builder.ai nasce nel Regno Unito nel 2016 per iniziativa di Sachin Dev Duggal.
L’azienda si chiamava inizialmente Engineer.ai e proponeva un modello alternativo allo sviluppo tradizionale del software: anziché progettare ogni applicazione da zero, il processo avrebbe utilizzato componenti riutilizzabili, automazione e una rete di professionisti incaricati delle personalizzazioni.

Nel 2018 venne lanciata Builder Studio, la piattaforma destinata a guidare i clienti nella progettazione delle applicazioni.
Nel maggio 2019 l’impresa annunciò il passaggio dal marchio Engineer.ai a Builder.ai, una denominazione più immediatamente associabile all’idea di “costruire” prodotti digitali. La società descriveva già allora il proprio metodo come una combinazione di intelligenza artificiale, automazione e intervento umano.

La proposta aveva un evidente potenziale commerciale.
La creazione di un’app richiede normalmente programmatori, designer, responsabili di progetto, analisi preliminari e una fase prolungata di test. Builder.ai presentava invece un percorso guidato nel quale il cliente poteva scegliere funzionalità già disponibili e ottenere una previsione dei costi e dei tempi.

Nel 2023 la società annunciò un finanziamento superiore a 250 milioni di dollari guidato dalla Qatar Investment Authority.
L’operazione portò il capitale complessivamente raccolto oltre i 450 milioni. Tra i sostenitori e partner della società figuravano anche Microsoft, Insight Partners, Jungle Ventures e altri investitori internazionali.
In quel periodo la valutazione di Builder.ai arrivò a circa 1,5 miliardi di dollari.

La crescita finanziaria non dipendeva soltanto dall’interesse generale verso l’AI.
Builder.ai intercettava un problema concreto: migliaia di aziende desideravano digitalizzare attività e servizi, ma non disponevano di un reparto informatico in grado di progettare applicazioni personalizzate.

Come avrebbe dovuto funzionare Builder.ai

Il modello tecnologico di Builder.ai si fondava sull’idea che molte applicazioni condividano strutture ricorrenti.
Registrazione degli utenti, pagamenti, notifiche, cataloghi, carrelli, prenotazioni e pannelli di controllo possono essere riutilizzati in progetti differenti, adattandoli alle esigenze del cliente.

La società dichiarava di possedere una libreria con più di 600 funzionalità.
Questi componenti venivano descritti come mattoncini simili ai Lego, da assemblare per ridurre il tempo necessario alla programmazione. L’intervento umano restava previsto per progettazione, sviluppo delle funzioni personalizzate, verifica e gestione del progetto.

Builder.ai, dunque, non dichiarava che ogni app venisse realizzata interamente da una macchina. La stessa comunicazione aziendale parlava di una linea di assemblaggio assistita dall’intelligenza artificiale e completata da designer e sviluppatori.

Questa distinzione è importante.
L’utilizzo di professionisti umani non dimostra da solo che la tecnologia fosse inesistente o che il servizio fosse ingannevole. Il problema riguarda piuttosto l’effettiva estensione dell’automazione e il modo in cui veniva percepita dal mercato.

Chi era Natasha

Il volto della piattaforma era Natasha, l’assistente virtuale che avrebbe dovuto dialogare con il cliente, comprenderne l’idea e suggerire le funzionalità necessarie.

Secondo il percorso descritto sul sito di Builder.ai, Natasha raccoglieva le esigenze dell’utente, organizzava le caratteristiche dell’applicazione e calcolava prezzo e tempi sulla base dei progetti precedentemente realizzati.
Dopo questa fase, un esperto dedicato seguiva la realizzazione e coordinava il contributo dei professionisti.

Natasha non va però immaginata come un sistema capace di progettare e programmare autonomamente un prodotto complesso dall’inizio alla fine. Nella configurazione originaria svolgeva soprattutto funzioni di raccolta dei requisiti, raccomandazione, stima e organizzazione del processo.
Negli anni successivi Builder.ai le attribuì ambizioni più ampie, annunciando capacità come la trasformazione della voce in specifiche e codice. Alcune di queste funzioni erano presentate come sviluppi futuri o progressivi, più che come prestazioni già disponibili in ogni progetto.

Il piano tecnologico: vera AI, automazione o servizio assistito?

La domanda più immediata posta dal caso è se Builder.ai utilizzasse davvero l’intelligenza artificiale.

La risposta non può essere ridotta alla contrapposizione tra “AI autentica” e “centinaia di sviluppatori nascosti”.
Builder.ai dichiarava apertamente di utilizzare specialisti umani e descriveva il proprio modello come una combinazione tra automazione e rete di esperti. Anche il materiale aziendale del 2023 parlava di una piattaforma human-assisted, nella quale alcune funzioni venivano automatizzate e altre restavano affidate a designer e sviluppatori.

Dopo il collasso si è diffusa la ricostruzione secondo cui circa 700 programmatori in India avrebbero svolto manualmente attività attribuite all’assistente virtuale.
Questa formula ha avuto grande fortuna mediatica, ma rischia di semplificare eccessivamente la questione.
La presenza di un ampio gruppo di sviluppatori era compatibile con la natura ibrida dichiarata dalla piattaforma; ciò che dovrebbe essere verificato è quali compiti fossero effettivamente automatizzati, quali ancora sperimentali e quanto chiaramente questa distribuzione venisse comunicata a clienti e investitori.

Il nodo tecnologico è quindi più sottile: Builder.ai disponeva certamente di un processo industrializzato e di componenti software riutilizzabili, ma il valore attribuito all’azienda dipendeva anche dalla convinzione che l’intelligenza artificiale potesse progressivamente comprimere costi, tempi e lavoro manuale.

Un’azienda che organizza bene il lavoro di centinaia di programmatori può essere un’impresa software valida. Non necessariamente, però, merita la stessa valutazione di una piattaforma tecnologica capace di automatizzare una parte sostanziale dello sviluppo.

Builder.ai e il rischio di AI washing

Con AI washing si indica la tendenza a presentare come guidato dall’intelligenza artificiale un prodotto nel quale l’AI ha un ruolo limitato, secondario o non chiaramente dimostrato.

Il concetto non implica automaticamente una frode.
Può comprendere condotte molto diverse: dall’uso generico dell’etichetta AI fino alla rappresentazione ingannevole delle capacità di un sistema. Tra questi estremi esistono numerose situazioni nelle quali la tecnologia è presente, ma viene enfatizzata oltre il suo peso reale.

Builder.ai è diventata un caso emblematico perché la parola AI non era marginale nella propria identità. Era incorporata nel nome, nella valutazione, nella raccolta di capitali e nella promessa di rendere lo sviluppo più rapido ed economico.
La questione non è stabilire se una singola funzione utilizzasse un algoritmo. Occorre chiedersi se l’immagine complessiva offerta al mercato riflettesse in modo sufficientemente fedele la maturità e l’incidenza della tecnologia.

Il piano economico: perché tanti investitori hanno creduto nel progetto?

Il sostegno di Microsoft, della Qatar Investment Authority e di importanti fondi viene spesso citato come prova del fatto che Builder.ai avesse superato controlli rigorosi.

In realtà, un investimento non equivale a una certificazione definitiva della tecnologia o dei conti.
La due diligence riduce l’incertezza, ma non può eliminarla. Gli investitori si basano su documenti, previsioni, metriche commerciali, verifiche legali e informazioni fornite dall’azienda. Se alcuni dati sono incompleti, eccessivamente ottimistici o contabilizzati in modo controverso, anche operatori sofisticati possono formulare valutazioni errate.

Builder.ai si trovava inoltre nel punto d’incontro tra due mercati molto attraenti: l’intelligenza artificiale e lo sviluppo software per imprese prive di competenze tecniche. La possibilità di creare applicazioni più velocemente e con costi prevedibili rendeva il modello teoricamente scalabile.

A questo si aggiungeva una dinamica tipica del venture capital.
Quando un settore cresce rapidamente, non investire può apparire rischioso quanto investire male. La presenza di finanziatori prestigiosi tende inoltre a produrre un effetto di convalida reciproca: ogni nuovo nome rafforza l’impressione che gli altri abbiano già compiuto verifiche sufficienti.

Dai ricavi previsti ai ricavi effettivi

Il punto di rottura è arrivato con la revisione dei dati finanziari.
Secondo Bloomberg, durante la ricerca di un finanziamento di emergenza Builder.ai avrebbe presentato ai creditori una previsione di circa 220 milioni di dollari di ricavi per il 2024.
Le vendite effettive sarebbero poi risultate vicine a 50 milioni.
Il Financial Times ha riferito anche di una significativa revisione dei ricavi attribuiti al 2023, ridotti da circa 180 a 45 milioni di dollari nei conti provvisori.

Le ricostruzioni hanno inoltre sollevato interrogativi sulle vendite effettuate attraverso intermediari e sulle operazioni con VerSe Innovation, società indiana attiva nei media digitali.
Si è parlato di possibili transazioni circolari o di ricavi registrati senza una corrispondente capacità di incasso. VerSe ha respinto le accuse di rapporti commerciali fittizi.

Nel gennaio 2026 è emersa anche una ricostruzione differente.
Un audit forense, commissionato da alcuni investitori iniziali, avrebbe concluso che le operazioni tra Builder.ai e VerSe corrispondevano ad attività commerciali reali e che la crisi sarebbe stata aggravata dalla tardiva comunicazione di una rilevante passività. Il rapporto, reso noto dalla stampa indiana, contesta quindi almeno in parte l’ipotesi delle fatturazioni interamente fittizie.

Questa divergenza è essenziale per evitare conclusioni premature. Le anomalie nei ricavi, le difficoltà di riscossione, le vendite tramite intermediari e la possibile circolarità delle operazioni sono aspetti distinti. La loro qualificazione definitiva richiede documenti completi e accertamenti formali, non soltanto sintesi giornalistiche.

La crisi di liquidità e il fallimento

Nel 2024 Builder.ai aveva ottenuto un finanziamento da 50 milioni di dollari da un gruppo di creditori guidato da Viola Credit.
Nel maggio 2025 Viola avrebbe prelevato circa 37 milioni dai conti della società, lasciandole una liquidità insufficiente a proseguire normalmente le attività.

La società annunciò quindi l’avvio di procedure di insolvenza.
Il 2 giugno 2025 una società del gruppo presentò in Delaware una richiesta di liquidazione secondo il Chapter 7, procedura diversa dal Chapter 11 utilizzato per tentare una riorganizzazione aziendale.

Il collasso non può essere spiegato da una sola causa. La combinazione tra riduzione dei ricavi, debito, contestazioni contabili, carenza di liquidità e perdita di fiducia dei creditori rese estremamente difficile mantenere in funzione una struttura internazionale con costi elevati.

Il piano giuridico: il fallimento non dimostra automaticamente una frode

Definire Builder.ai una truffa può essere efficace sul piano comunicativo ma non è una conclusione che derivi automaticamente dal fallimento.
Un’impresa può diventare insolvente per errori strategici, crescita eccessivamente rapida, costi non sostenibili, stime irrealistiche o crisi di liquidità. Nessuno di questi elementi, isolatamente, dimostra l’esistenza di una frode.

Il piano cambia se vengono consapevolmente forniti a investitori o a creditori dati falsi, se vengono registrati ricavi inesistenti oppure se le caratteristiche del prodotto vengono rappresentate in modo materialmente ingannevole.
In tali circostanze possono emergere responsabilità civili, societarie e, nei casi più gravi, penali.

Prima del fallimento, l’ufficio del procuratore federale del Southern District of New York aveva richiesto a Builder.ai documenti finanziari, politiche contabili ed elenchi di clienti.
Nell’ottobre 2025 Bloomberg ha riferito che le autorità avevano notificato all’ex direttore finanziario una richiesta di comunicazioni riguardanti revisori e rendicontazione, nell’ambito di accertamenti relativi a possibili ipotesi di wire fraud, securities fraud e conspiracy. L’esistenza di un’indagine, tuttavia, non equivale a un rinvio a giudizio o a una condanna.

Per questo è opportuno distinguere almeno quattro livelli:

• il fallimento economico del progetto;
• eventuali violazioni contrattuali nei confronti di clienti e fornitori;
• possibili irregolarità nella rappresentazione finanziaria;
• l’eventuale responsabilità personale di amministratori e dirigenti.

Le responsabilità dovranno essere accertate con riferimento ai singoli soggetti, alle decisioni adottate e alle informazioni effettivamente conosciute in ogni momento.

Le promesse commerciali possono diventare giuridicamente rilevanti?

Le espressioni pubblicitarie sono spesso approssimative.
Dire che un servizio rende la creazione di software semplice come ordinare una pizza è chiaramente uno slogan e non una garanzia tecnica letterale.

Diverso è il caso di affermazioni misurabili: percentuali di risparmio, livelli di automazione, tempi garantiti, ricavi, numero di clienti o prestazioni concretamente disponibili.
Quanto più una dichiarazione è precisa e determinante per la decisione di acquistare o investire, tanto maggiore è la probabilità che venga valutata sotto il profilo della correttezza commerciale o della rappresentazione finanziaria.

Nel caso Builder.ai, il problema giuridico non consiste quindi nell’uso di un linguaggio entusiastico in sé, ma nell’eventuale distanza tra dichiarazioni verificabili, capacità operative e dati contabili.

Come si costruisce una fiducia miliardaria

Builder.ai offre un caso interessante anche dal punto di vista criminologico, purché l’analisi non venga trasformata in una lezione morale.
Non è necessario immaginare centinaia di persone ingenue persuase da una semplice presentazione commerciale.

La fiducia aziendale si costruisce attraverso molti segnali che, presi singolarmente, appaiono razionali:

• investitori riconosciuti;
• partnership con grandi aziende;
• sedi in più Paesi;
• crescita del personale;
• premi e riconoscimenti;
• linguaggio tecnico;
• risultati finanziari;
• testimonianze di clienti;
• presenza costante in eventi e mezzi di informazione.

Ogni elemento rinforza gli altri.
Microsoft non dimostrava che ogni componente tecnologica funzionasse come dichiarato, ma la presenza di Microsoft rendeva più credibili le affermazioni dell’azienda. La Qatar Investment Authority non garantiva la correttezza di ogni dato contabile, ma il suo investimento diminuiva la percezione del rischio per altri osservatori.

Si crea così una struttura di fiducia distribuita. Nessuno possiede necessariamente tutte le informazioni e ciascuno presume che qualcun altro abbia svolto controlli più approfonditi.

Il ruolo del fondatore e la narrazione del visionario

Sachin Dev Duggal si presentava come fondatore e “Chief Wizard” di Builder.ai.
La scelta di un titolo non convenzionale contribuiva a costruire l’immagine di un imprenditore creativo, distante dai modelli aziendali tradizionali.

Duggal aveva alle spalle precedenti esperienze nel settore tecnologico e una forte presenza pubblica.
Builder.ai gli attribuiva una biografia da imprenditore precoce e visionario, capace di anticipare trasformazioni tecnologiche.
Il ruolo del fondatore nelle startup non è soltanto amministrativo. È spesso parte del prodotto. La capacità di raccontare il futuro aiuta a ottenere capitali, assumere personale e convincere i clienti.

Questo non significa che il carisma sia un indicatore di frode. Diventa però un fattore di rischio quando la credibilità personale sostituisce la verifica delle prestazioni, oppure quando contestare le previsioni del fondatore viene percepito come mancanza di visione.

Builder.ai è la nuova Theranos?

Il paragone con Theranos è comprensibile, ma va utilizzato con cautela.
Entrambe le società hanno costruito una valutazione elevata intorno alla promessa di semplificare un processo complesso attraverso una tecnologia proprietaria. In entrambi i casi la reputazione di investitori e partner ha contribuito a rafforzare la fiducia del mercato.

Le differenze sono però rilevanti.
Theranos operava nella diagnostica medica, dove risultati inesatti potevano incidere direttamente sulla salute dei pazienti.
Builder.ai vendeva servizi per la creazione di software e disponeva comunque di una struttura operativa capace di realizzare applicazioni attraverso personale e componenti riutilizzabili.

Nel caso Theranos, Elizabeth Holmes è stata processata e condannata per frode agli investitori. Per Builder.ai sono emerse indagini, accuse e ricostruzioni contrastanti, ma non è corretto presentare come già dimostrata una responsabilità penale equivalente.

Il confronto è quindi utile per comprendere il ruolo della narrazione e della due diligence, non per sovrapporre automaticamente i due casi.

Che cosa insegna davvero il caso Builder.ai alle imprese

La vicenda non dimostra che il no-code sia inefficace o che ogni servizio assistito dall’intelligenza artificiale nasconda attività manuali.
La combinazione tra software, moduli riutilizzabili e specialisti umani è comune e può generare risultati validi. In molti casi l’AI non sostituisce l’intero processo, ma riduce il tempo necessario per analisi, progettazione, generazione del codice, test o gestione del progetto.

Il punto è un altro: chi acquista una soluzione AI dovrebbe conoscere abbastanza chiaramente il ruolo della tecnologia nel servizio.

Prima di affidare un progetto a una piattaforma, un’impresa dovrebbe verificare:

• quali fasi sono realmente automatizzate;
• quali attività vengono affidate a sviluppatori esterni;
• chi possiede il codice realizzato;
• come vengono protetti dati e proprietà intellettuale;
• quali prestazioni sono garantite contrattualmente;
• come vengono gestiti manutenzione e aggiornamenti;
• cosa accade se il fornitore diventa insolvente;
• se è possibile trasferire il progetto a un altro operatore.

Queste verifiche non richiedono di conoscere nel dettaglio ogni algoritmo. Richiedono soprattutto di trasformare affermazioni generiche come “AI-powered” in domande operative.

Le domande ancora aperte su Builder.ai

A distanza di oltre un anno dal collasso, diversi aspetti non risultano definitivamente chiariti.
Occorre ancora comprendere quale fosse la reale entità dei ricavi validamente maturati, quale quota delle vendite contestate potesse essere riscossa e in che misura le informazioni finanziarie fossero state condivise con consiglio di amministrazione, revisori e investitori.

Resta inoltre da stabilire se le differenze nelle valutazioni economiche derivassero da previsioni non realizzate, criteri contabili inadeguati, rapporti commerciali anomali o condotte consapevolmente ingannevoli.
Le ricostruzioni pubbliche non sono concordi e alcune conclusioni dell’audit forense emerso nel 2026 contrastano con le prime accuse relative ai rapporti con VerSe.

Anche sul piano tecnologico manca una misurazione indipendente e completa di quanto Builder.ai fosse riuscita ad automatizzare nelle diverse fasi della propria attività.
Le dichiarazioni aziendali, le critiche degli ex dipendenti e le versioni fornite successivamente dal fondatore descrivono prospettive differenti.
La prudenza, in questo caso, non serve a rendere la storia meno interessante. Serve a distinguere ciò che è documentato da ciò che è ancora oggetto di indagine o interpretazione.

Builder.ai e la fiducia nel mercato dell’intelligenza artificiale

Builder.ai probabilmente non sarà ricordata soltanto come una startup che non è riuscita a sostenere la propria crescita.

Il caso mostra quanto il valore di un’impresa tecnologica dipenda dalla relazione tra quattro elementi: prodotto, narrazione, numeri e verifiche. Finché procedono nella stessa direzione, possono alimentare una crescita molto rapida. Quando iniziano a divergere, la fiducia può dissolversi in pochi giorni.

La presenza di lavoro umano non rende falsa una piattaforma AI. Un finanziamento ottenuto da investitori prestigiosi non rende infallibile il modello.
Una previsione economica errata non prova automaticamente una frode. Allo stesso tempo, l’etichetta intelligenza artificiale non può sostituire indefinitamente la dimostrazione delle capacità tecniche e dei risultati finanziari.

La domanda più utile lasciata dal caso Builder.ai non è quindi se Natasha fosse “vera” o “finta”. È capire quanta parte del valore miliardario della società dipendesse da una tecnologia già operativa e quanta dalla previsione di ciò che quella tecnologia sarebbe diventata.

Negli anni in cui ogni impresa dichiara di essere “AI-powered”, la vera domanda non sarà più se un prodotto utilizzi l’intelligenza artificiale.

Sarà capire quale parte del lavoro venga realmente svolta dall’AI, quale dagli esseri umani e quanto questa distinzione venga comunicata con trasparenza.