Oggi con l'IA è facile ottenere qualcosa che sembra funzionare: una demo, un prototipo, un primo risultato sorprendente. Il difficile viene dopo, quando bisogna farlo funzionare con i dati veri, i casi imprevisti e il lavoro di ogni giorno. Lì molti progetti si fermano.

Il motivo è semplice: l'IA è eccezionale nel compito circoscritto, ma il valore, e il rischio, stanno nell'insieme.

Noi lavoriamo proprio sull'insieme. Uniamo una comprensione scientifica di come funzionano i modelli a una solida esperienza di ingegneria.

Partiamo dai vostri processi, non dalla tecnologia. Progettiamo l'intero intervento, dimostriamo la fattibilità con criteri decisi prima e confrontati con i risultati che ottenete oggi, poi introduciamo l'IA gradualmente e la monitoriamo nel tempo.

Costruiamo architetture che non dipendono dal modello del momento, e il codice, i dati e la documentazione restano vostri.

Un esempio: chiediamo a un agente di aggiungere una funzionalità che non si integra bene con il sistema esistente. L'agente troverà un modo per farla funzionare, magari con un caso speciale o una scorciatoia. Il compito è completato. Un buon ingegnere invece si fermerebbe e direbbe: «Se questa funzionalità non entra nel progetto, forse va ripensato il progetto».

Chi progetta un sistema ne ha una visione d'insieme, e ogni scelta va nella sua direzione. Questa visione si può scrivere, e va scritta. Ciò che non si delega è la responsabilità degli scopi, e quindi di cambiare la visione quando la realtà la smentisce.

Per questo il ruolo dell'ingegnere si sposta: scrive meno codice e progetta di più. Definisce la struttura e scompone il lavoro in compiti ben delimitati. A ciascun agente dà il contesto di cui ha bisogno: le informazioni del compito, i vincoli del progetto che non vanno violati e un modo per segnalare quando qualcosa non torna.

È così che si è sempre organizzato bene il lavoro di un team. Il metodo resta; cambia dove sta il peso.

La distanza tra demo e produzione non si colma aggiungendo codice, ma con la progettazione. Senza una solida architettura, la demo non saprà adattarsi ai casi reali e non sarà possibile mantenerla nel tempo. Ogni nuovo caso diventerà un'eccezione da gestire a parte, finché il sistema non sarà più sostenibile.

È lo stesso schema dell'agente che chiude il compito con una scorciatoia: il risultato immediato c'è, la visione d'insieme manca. Non si può prevedere ogni caso che un sistema dovrà affrontare. Si può però decidere fin dall'inizio quali parti resteranno stabili e dove il sistema dovrà poter cambiare.

C'è poi una differenza reale rispetto al software tradizionale: i componenti basati su IA non sono deterministici. Lo stesso input può dare risultati diversi, e un errore può avere un aspetto del tutto plausibile. Per questo un sistema con IA non si collauda una volta sola. Va verificato con continuità, cercando attivamente gli errori che nessuno segnalerebbe.

Linguaggi di programmazione un tempo popolari e tecnologie un tempo diffusissime sono diventati obsoleti. Le architetture che avevano separato i compiti dalle tecnologie hanno potuto sostituirle e sono sopravvissute. La tecnologia è uno strumento: serve a implementare i componenti di un'architettura, non a definirla.

Nell'IA di oggi lo stesso schema si ripete, ma ancora più accelerato. Nuove tecnologie e nuovi modelli linguistici emergono di continuo e sembrano spazzare via il «passato», un passato che spesso ha pochi mesi. Basti pensare al prompt engineering: presentato come la competenza del futuro, nel giro di un anno ha cambiato natura. I modelli più recenti capiscono le istruzioni senza formule particolari, e oggi conta dare loro il contesto giusto. La competenza non è scomparsa, si è trasformata.

Conoscere a fondo la tecnologia serve proprio a distinguere ciò che resta vero quando lo strumento cambia. Un esempio: agli inizi molti affidavano agli agenti IA anche i calcoli matematici, che un modello di linguaggio non sa eseguire in modo affidabile. Il nostro principio è: deterministico dove si può, probabilistico dove serve. Calcoli, regole e controlli li affidiamo al codice; all'IA lasciamo l'interpretazione e il linguaggio.

Per questo non progettiamo attorno a un modello o a uno strumento. Progettiamo architetture in cui ogni componente ha un compito chiaro, e la tecnologia che lo realizza può essere sostituita quando ne arriva una migliore. Il valore sta nel progetto, non nello strumento del momento.

Se ci occupiamo di IA non è per rincorrerla. È perché oggi è proprio nell'IA che l'architettura viene trascurata più spesso.

Lo stesso vale per la conoscenza aziendale. Un'azienda che negli anni ha organizzato e censito le informazioni che produceva ha in mano una risorsa preziosa: documenti, decisioni, procedure, il perché delle scelte fatte.

Un'azienda che non l'ha fatto oggi incontra difficoltà. La sua conoscenza vive solo nella testa delle persone, oppure è dispersa tra email, chat e cartelle condivise. Gli agenti IA che introduce danno risposte generiche, perché non conoscono la realtà specifica dell'azienda. Oppure colmano i vuoti con ipotesi plausibili ma sbagliate, che è il caso peggiore perché l'errore non si vede. Il risultato delude, e spesso si conclude che «l'IA non funziona», quando il problema è a monte.

Per noi la conoscenza che si può scrivere non deve restare solo nella testa delle persone. Adottare l'IA è l'occasione per rimettere ordine: censire la conoscenza, renderla accessibile e mantenerla aggiornata. È un investimento che ripaga due volte, perché ciò che rende l'informazione utilizzabile da un agente la rende utilizzabile anche dalle persone.

Dentro un processo, gli agenti IA sono come persone specializzate: ognuno ha il suo compito. E come una persona, un agente lavora meglio quando riceve tutte e sole le informazioni necessarie al suo compito. Le informazioni superflue non aiutano, confondono.

Censire tutta la conoscenza non significa darla tutta a tutti. Significa che è accessibile, e che a ciascuno, agente o persona, arriva quella che gli serve.

Il contesto minimo comprende sempre due cose: i vincoli che non vanno violati e un modo per segnalare quando il compito non torna. Uno specialista bravo non forza un risultato: avvisa chi coordina. Un agente deve poter fare lo stesso.

Nemmeno questa è un'idea nuova. È il principio con cui da decenni si progettano buoni sistemi software: ogni componente conosce solo ciò che gli serve.

Un'adozione che rispetta il modo di lavorare delle persone viene accolta più facilmente e dà risultati prima. Il codice, i dati e la documentazione restano del Cliente: l'adozione dell'IA lascia l'azienda più forte, non più dipendente.