Insight ON Who's running your AI once the delivery team has gone home?

By  Insight UK / 10 Aug 2026  / Argomenti: Modern workplace

InsightAI: Chi gestisce
la tua AI?

Cosa significa davvero "End-to-End"

Team sicuro di sé che pianifica al laptop
 
 

Progettate per il lancio, non per durare: perché le partnership limitate alla fase di delivery falliscono con l'AI

C'è un momento che molti responsabili tecnologici riconosceranno: l'incarico di delivery si conclude, il nuovo sistema entra in produzione e il partner passa al progetto successivo. Da quel momento in poi, l'organizzazione è responsabile di qualcosa che non ha progettato pienamente per il funzionamento a lungo termine: framework di governance che si sarebbero comunque dovuti definire più avanti, team che lavorano ogni giorno con il sistema ma non hanno avuto alcun ruolo nella sua costruzione e documentazione che descrive come è stato realizzato, anziché come mantenerlo in funzione.

Queste partnership limitate alla fase di delivery sono ancora comuni nei progetti tecnologici. Per alcuni tipi di software, il vuoto che lasciano può essere gestibile. Per l'AI, tende a non esserlo: un sistema di AI in produzione comporta una serie aggiuntiva di requisiti continuativi, che non sempre si manifestano quando le cose iniziano ad andare storte.

Il divario di delivery

Lo spazio tra un sistema entrato in produzione e una capacità di AI che funziona in modo affidabile e nel rispetto delle regole. Le organizzazioni che lo colmano tendono a condividere un approccio comune: collaborano con partner che pensavano già al dodicesimo mese fin dal primo giorno.

Fase 1: lancio del sistema

Rendere operativo il sistema di AI è solo il primo passo. Il successo di un proof of concept raramente garantisce le prestazioni nel mondo reale.

 

Perché il 2026 rende urgente colmare il divario

Dal 2 agosto 2026, gli obblighi dell'EU AI Act relativi ai sistemi ad alto rischio diventano pienamente applicabili per le aziende che operano nell'UE: valutazioni di conformità, processi documentati, monitoraggio continuo e chiara responsabilità per le decisioni automatizzate. "Lanciato" non è più il traguardo finale e, per le organizzazioni le cui partnership sull'AI erano costruite attorno a un punto di consegna, questo rappresenta un divario reale da colmare. Un accordo provvisorio ha inoltre definito una tempistica più ampia di scadenze successive a questa. Consulta le date principali qui sotto.

Roadmap normativa sull'AI

Esplora le scadenze di conformità principali e le tappe di applicazione della transizione.

2 ago 2026

Obblighi ad alto rischio applicabili

I meccanismi di applicazione entrano in vigore per i sistemi di AI ad alto rischio. Le organizzazioni devono garantire che i framework di gestione del rischio, le policy di data governance e la documentazione tecnica soddisfino gli standard normativi.

EU AI Act: obblighi per i sistemi ad alto rischio

Gli obblighi per i sistemi ad alto rischio sono pienamente applicabili per le aziende che operano nell'UE. Le organizzazioni devono predisporre valutazioni di conformità, processi documentati, monitoraggio continuo e una chiara responsabilità per le decisioni automatizzate.

Pilastro 1: valutazioni di conformità

Test obbligatori pre-immissione sul mercato, valutazioni del rischio e certificazione normativa per verificare la sicurezza del sistema e la conformità agli standard prima della messa in produzione.

 

Requisiti di governance principali

01
Registrazione nel database dell'UE

L'accordo provvisorio ripristina l'obbligo per i fornitori di registrare i sistemi di AI nel database dell'UE per i sistemi ad alto rischio, qualora ritengano che i propri sistemi siano esentati dalla classificazione come ad alto rischio.

02
Criterio di stretta necessità

Ripristina il criterio della stretta necessità per il trattamento di categorie particolari di dati personali allo scopo di garantire il rilevamento e la correzione dei bias.

03
Vigilanza e competenze dell'Ufficio per l'AI

Chiarisce le competenze dell'Ufficio per l'AI nella vigilanza sui sistemi di AI basati su modelli di AI per finalità generali, quando il modello e il sistema sono sviluppati dallo stesso fornitore, elencando le eccezioni in cui restano competenti le autorità nazionali: tra queste, le forze dell'ordine, la gestione delle frontiere, le autorità giudiziarie e gli istituti finanziari.

 

Strategia, ingegneria, operatività: perché i partner AI devono coprirle tutte

Il divario di delivery si presenta con tanta regolarità perché la maggior parte delle partnership sull'AI è dimensionata attorno a una sola fase di un percorso composto da tre fasi. Questi ambiti parziali portano a tre distinte modalità di fallimento nel successo a lungo termine dei progetti di AI.

Dove si inceppano i progetti AI

Fase 1: Gap strategico

La società di consulenza produce una tabella di marcia coerente, un business case ben argomentato e una visione davvero interessante di ciò che il prodotto potrebbe fare. Poi, però, la realtà ingegneristica diventa un problema altrui. Le domande che determinano se un sistema AI funzioni davvero in produzione (come si comporta il modello sui dati reali rispetto a set di test puliti, quali siano i costi di inferenza su scala, come si colleghi ai sistemi su cui l'azienda lavora già) richiedono la presenza fin dall'inizio di qualcuno che le comprenda. I divari tra strategia e realtà ingegneristica possono causare problemi in qualsiasi progetto tecnologico, ma nell'AI spesso emergono più tardi e costano di più da risolvere.

L'integrazione dei sistemi legacy è l'ambito in cui le partnership di delivery lasciano più spesso questioni irrisolte. Le connessioni più complesse, ovvero quelle tra le moderne funzionalità di AI e i sistemi più datati che gestiscono altre funzioni, tendono a essere risolte solo quel tanto che basta per il lancio, rinviando il lavoro più profondo. Una volta concluso l'incarico, spetta all'organizzazione gestire quel lavoro rimandato.

0%
dei leader IT afferma che l'impossibilità di migrare le applicazioni aziendali legacy li stia frenando: il trilemma della sovranità digitale

Avere una competenza end-to-end significa affidarsi a un unico partner per tutte queste fasi: una strategia basata sulla realtà ingegneristica, un'ingegnerizzazione progettata per funzionare fin dal primo giorno e una strategia operativa definita fin dall'inizio per mantenere i sistemi attivi, conformi e in continuo miglioramento nel tempo. Ma, aspetto fondamentale, significa avere un partner che ti aiuta a identificare i casi d'uso che creano un valore aziendale reale, e non solo quelli tecnicamente fattibili.

 

Sviluppare competenze AI durature presso un ente di formazione leader mondiale

Siamo stati contattati da un ente di formazione leader a livello mondiale attivo in quasi 200 Paesi, che fornisce contenuti digitali, valutazioni e soluzioni per l'apprendimento basate sulla tecnologia su scala globale. La divisione ingegneristica dell'organizzazione ha posto una domanda a cui la maggior parte delle realtà non pensa con sufficiente anticipo: non solo se l'AI avrebbe funzionato, ma se i propri team sarebbero stati in grado di gestirla in sicurezza, governarla correttamente e continuare a migliorarla in autonomia.

Un'indagine iniziale condotta tra gli ingegneri ha rivelato un aspetto che i dati generali sull'adozione dell'AI tendono a nascondere. La maggior parte del team utilizzava già regolarmente strumenti di AI, quindi i numeri sembravano positivi, ma un uso regolare non significa necessariamente un uso efficace o sicuro, una dinamica riscontrabile in molte organizzazioni.

Analizzando più a fondo il modo in cui questi strumenti venivano effettivamente utilizzati, è emerso che la valutazione strutturata dei risultati dell'AI era incostante e che le tecniche più avanzate, capaci di generare i vantaggi più significativi, erano sottoutilizzate.

Ancora più significativo è stato ciò che frenava le persone: le preoccupazioni legate a sicurezza e conformità rappresentavano l'ostacolo più citato dagli ingegneri in ogni ruolo e funzione. Chi era incerto su quali dati fosse sicuro condividere con l'AI evitava del tutto determinati strumenti oppure agiva in modo autonomo, senza un quadro di riferimento coerente a guidarlo. Il problema non era la negligenza, ma l'assenza di standard, di indicazioni sugli strumenti e di sicurezza nei propri mezzi. Implementare ulteriore tecnologia non avrebbe risolto la situazione.

Il programma si è proposto di costruire ciò che mancava ai team: l'infrastruttura per un uso sicuro ed efficace dell'AI. Questo è avvenuto attraverso una combinazione di:

  • Workshop basati su attività reali di ingegneria e QA
  • Coaching integrato direttamente nei codebase e nelle suite di test reali
  • Strumenti di governance (guide all'uso, framework decisionali, librerie di prompt e playbook delle migliori pratiche) progettati esplicitamente per durare nel tempo oltre la fine del programma

Invece di lasciare che tali standard sfumassero al termine della collaborazione, è stata creata una rete interna di champion, in cui i professionisti più esperti hanno assunto la responsabilità diretta dei nuovi standard e un ruolo guida nella fase di coaching.

I risultati sono andati ben oltre gli obiettivi prefissati all'inizio:

6 su 7
degli sviluppatori afferma che gli strumenti di AI fanno risparmiare tempo concreto nel lavoro svolto
39%
di riduzione del lead time fino al primo commit di codice, rispetto a un obiettivo del 15–20%
2–8 ore
risparmiate per ciascun test automatizzato creato
10–30 min
risparmiati per ciascuna segnalazione di bug
90%
del personale senior sa indicare controlli specifici di governance dell'AI

Il dato sulla governance è quello che conta di più nel contesto della scadenza del 2 agosto. Entro la fine del programma, il personale senior indicava controlli specifici: configurazioni di licenza enterprise confermate, snippet anonimizzati per il codice sensibile e trasparenza sulle PR come prassi standard. Un team ha intercettato uno strumento con permessi di scrittura mentre sovrascriveva il contenuto di un ticket prima che diventasse un incidente reale, quel tipo di consapevolezza pratica del rischio che non deriva da un documento di policy e richiede mesi per essere costruita.

“Leggi ogni riga. L'AI genera codice dall'aspetto plausibile che può testare qualcosa di completamente errato. Se non riesci a far fallire il test con un input errato, non sta testando nulla.”
QA Engineer
 

Dall'adozione all'autonomia

La prova più evidente del reale trasferimento di questa competenza è ciò che è accaduto dopo la fine del programma. Il team di QA, il gruppo che all'inizio si era valutato in modo più prudente, ha poi sviluppato due agenti orientati a risolvere problemi specifici del proprio processo di delivery. Nessuno dei due è stato realizzato da Insight AI: sono stati creati dagli ingegneri del team stesso, sfruttando competenze che ora appartengono a quell'organizzazione.

Accessibility compliance work, per page
Up to 38 hrs ~30 min
Design review time, per component
Up to 3 hrs < 10 min
Annuncio CTA Insight AI

Vuoi sviluppare questo tipo di competenze di AI nei tuoi team?

I nostri specialisti possono mostrarti l'approccio di questo programma: come il trasferimento di competenze, la governance e l'applicazione nel mondo reale siano stati strutturati per durare nel tempo oltre la fase di delivery.

Parla con i nostri specialisti
 

Progettare pensando al risultato finale

Questo programma dimostra cosa significhi sviluppare competenze durature a livello organizzativo, fornendo alle persone che gestiscono un sistema AI gli strumenti per utilizzarlo in sicurezza e governarlo al meglio. La stessa questione si pone a livello ingegneristico: se il sistema stesso sia stato progettato per essere gestito, adattato e governato nel tempo, oppure realizzato semplicemente per il lancio.

Abbiamo messo in pratica noi stessi questi principi quando abbiamo creato AURA, una piattaforma di conoscenza basata sull'AI progettata per risolvere un problema interno reale: trasformare i progetti completati in case study rivolti ai clienti era un processo lento e manuale, che spesso faceva sì che i contenuti non fossero pronti al momento di un'opportunità commerciale. Con AURA, i nostri team di vendita hanno accesso a elementi di prova pertinenti durante la gestione di una trattativa e possono creare narrazioni in più lingue per mostrare ai clienti le nostre competenze, portando a un vantaggio commerciale diretto. Ma la sua realizzazione ci ha anche offerto l'opportunità di applicare ai nostri sistemi gli stessi principi ingegneristici che applicheremmo a un progetto per un cliente.

Architettura principale e governance di AURA

Seleziona un pilastro sottostante per esplorare le fondamenta della struttura

Il principio

Le scelte che determinano se ci si possa fidare di un sistema nel tempo sono raramente visibili durante una demo. Emergono mesi dopo, quando i dati gestiti dal sistema diventano più sensibili, quando l'uso cresce su scala o quando il quadro normativo si fa più rigido. Pertanto, anziché considerare la governance e la conformità come elementi da aggiungere a sistema già attivo, le abbiamo integrate fin dall'inizio.

Fondamenta integrate
  • I dati sono anonimizzati per impostazione predefinita e l'accesso è regolato in base al ruolo
  • Le modifiche all'infrastruttura sono verificabili e riproducibili, anziché applicate manualmente e difficili da tracciare
  • Il monitoraggio operativo è integrato nativamente, non aggiunto in seguito
Responsabilità su scala

Nessuna di queste scelte modifica ciò che il sistema fa dal primo giorno, ma determina se AURA possa essere gestito in modo responsabile su scala, adattato al variare dei requisiti e governato in condizioni sempre più impegnative, inclusi gli obblighi previsti dall'EU AI Act che ora hanno carattere continuo e non occasionale.

Piattaforma in evoluzione

AURA è ancora in funzione, ha continuato a evolversi ed è governato dalle stesse fondamenta che abbiamo definito all'inizio. La piattaforma si è ora sviluppata per creare narrazioni più ampie a carattere tematico o di settore a partire da gruppi di case study pertinenti, un risultato che non sarebbe stato possibile ottenere su un sistema non progettato fin dall'inizio per crescere.

 

Cosa si richiede davvero da agosto 2026

Gli obblighi a elevato rischio previsti dall'EU AI Act non possono essere soddisfatti con un'approvazione una tantum. Richiedono una conformità continua: documentazione costante, monitoraggio, supervisione umana delle decisioni automatizzate e chiare strutture di responsabilità che possano essere dimostrate e non solo descritte. Per le organizzazioni le cui partnership di AI si concludono al momento della delivery, soddisfare questo standard rappresenta una sfida operativa per la quale non saranno preparate.

Ciò che il programma per lo sviluppo delle competenze AI dell'ente di formazione illustra è l'aspetto pratico della prontezza normativa: il personale senior in grado di indicare controlli specifici e di applicarli nel contesto, il team che ha intercettato un rischio di governance prima che diventasse un incidente in produzione, gli standard, i materiali di governance e la rete di champion che continuano a regolare l'uso dell'AI nell'organizzazione mentre la tecnologia prosegue la sua evoluzione.

Questo tipo di fondamenta operative rappresenta sempre più anche un vantaggio commerciale. Mentre la maggior parte delle organizzazioni trova difficile la complessità normativa, quelle che la gestiscono con efficacia acquisiscono un vantaggio competitivo:

55%

delle organizzazioni indica la complessità normativa (GDPR, DORA, l'AI Act) come una delle maggiori sfide strategiche

60%

dei clienti richiede ormai una prova di conformità nei processi di acquisto

43%

delle organizzazioni ha utilizzato le credenziali di sovranità per acquisire o mantenere clienti: il trilemma della sovranità digitale

Le organizzazioni in grado di dimostrare una conformità continua, e non solo di mostrare un'approvazione finale alla delivery, saranno quelle che manterranno un vantaggio con il continuo crescere degli obblighi.

 

L'intero percorso

Il programma per lo sviluppo delle competenze AI dell'ente di formazione e il nostro progetto AURA mostrano entrambi cosa significa costruire per il lungo termine nella pratica, arrivando al medesimo risultato da prospettive diverse. Il programma per le competenze AI ha sviluppato capacità interne (gli standard, la governance e la sicurezza necessaria per continuare a migliorarsi) in modo che, al termine della collaborazione con Insight AI, l'organizzazione potesse proseguire in autonomia. AURA è stato progettato per durare fin dall'inizio, con le decisioni che determinano l'operatività a lungo termine prese durante lo sviluppo anziché rinviate a un secondo momento. Entrambi gli approcci si riducono a una sola domanda: chi sta pensando oltre la delivery prima ancora che la delivery abbia inizio?

Annuncio CTA Insight AI - Architettura AURA

Vuoi scoprire come questi principi di governance e ingegneria si traducono in un sistema attivo?

Possiamo mostrarti come AURA sia stato progettato per un'operatività a lungo termine, inclusi conformità fin dalla progettazione, monitoraggio e scelte di architettura scalabile.

Richiedi una presentazione di AURA

Per la maggior parte delle organizzazioni, questa domanda trova risposta molto prima che il sistema vada online. Dipende dal fatto che il partner che lo ha realizzato abbia pensato alla gestione operativa fin dall'inizio: se la strategia ha tenuto conto della realtà ingegneristica, se l'ingegnerizzazione è stata progettata per ciò che deve essere gestito e se la responsabilità continua faceva parte dell'incarico anziché essere una discussione rinviata a un secondo momento.

Questa continuità di responsabilità, tra strategia, ingegnerizzazione e il lavoro costante per mantenere un sistema in funzione, è ciò che significa davvero end-to-end.