L'hype è venuto prima. Poi l'architettura. Poi i fallimenti. Le imprese dell’UE sono le prossime in fila, e la maggior parte di loro ancora non lo sa.
Questa non è una speculazione. Il crollo della Knight Capital è di pubblico dominio. L’abbandono dell’NHS NPfIT è stato analizzato per anni nelle udienze parlamentari. Medibank. TSB. Hershey. Ognuno di loro ha studiato. Niente di tutto ciò impedisce alla compagnia successiva di entrare nella stessa stanza e fare la stessa chiamata.
Il problema non è l’ignoranza. È certezza. Ogni organizzazione ritiene che la propria situazione sia diversa.
Tre punti in cui un sistema si rompe
Quando un progetto AI fallisce, ne sentirai i sintomi. I dati erano confusi. Il modello ha sottoperformato. Il lancio è stato affrettato. Non è questo il fallimento. Ecco come appariva il fallimento all'uscita.
Il fallimento è stato strutturale. È stato integrato prima dell'esecuzione della prima riga di codice.
Ci sono tre posti in cui succede.
Il primo è il livello dei dati e della conoscenza. Questo è ciò che realmente sa un sistema; non quello che gli era stato detto che sapeva. SecondoGartnerDal 2018 al 2022, l’85% dei progetti di IA fornirà risultati errati a causa di errori nei dati, negli algoritmi o nei team responsabili della loro gestione. Questa cifra non riguarda le aziende negligenti. Si tratta di ingegneri a cui sono stati consegnati dati che gli era stato detto erano pronti per la produzione. Non lo era. Nessuno ha controllato. Il ciclo dell’hype aveva già fatto avanzare la stanza. Il modello ha funzionato. Ha prodotto risultati. Le uscite erano sbagliate. E per un po' nessuno se ne accorse.
Il secondo è lo strato di elaborazione, dove modelli linguistici di grandi dimensioni e algoritmi di inferenza trasformano i dati in decisioni. Questi sistemi non falliscono rumorosamente. Un sistema che ha allucinazioni non si ferma. Continua. Produce risposte che sembrano ragionevoli. Nel 2012,Gruppo Knight Capitalha perso $ 440 milioni in 45 minuti. Non perché un sistema sia andato in crash. Perché un sistema funzionava perfettamente, elaborando operazioni in tempo reale rispetto a una configurazione che avrebbe dovuto essere disattivata. Era fiducioso. È stato veloce. Era sbagliato. Nessuno nella stanza lo sapeva finché i soldi non erano finiti.
Il terzo è il livello di consegna, dove le decisioni di un sistema raggiungono le persone reali. Flussi di lavoro reali. Pazienti veri. Conseguenze reali.
ILProgramma nazionale del servizio sanitario nazionaleper l'IT ha speso circa 9,8 miliardi di sterline in un decennio. La tecnologia per lo più ha funzionato. Ciò che non ha funzionato è stato il presupposto che i flussi di lavoro clinici di dozzine di strutture del servizio sanitario nazionale, ciascuno con la propria realtà operativa, il proprio personale, i propri pazienti, potessero essere costretti in un unico sistema standardizzato senza un meccanismo che consentisse a quelle persone di dire: questo non si adatta al modo in cui lavoriamo. Non c'era alcun ciclo di feedback. Il sistema non poteva capire che stava deludendo le persone per cui era stato costruito, perché nessuno aveva costruito un modo per far viaggiare quel segnale. Gli infermieri hanno aggirato il problema. I medici si sono documentati due volte. I pazienti sono caduti nelle lacune. Alla fine il programma fu abbandonato. I 9,8 miliardi di sterline erano spariti.
Le organizzazioni del settore pubblico dell’UE che gestiscono oggi programmi di digitalizzazione sanitaria fanno lo stesso presupposto. Non lo stesso sistema. Lo stesso presupposto.
SecondoMcKinsey, il 70% delle trasformazioni su larga scala falliscono. Le ragioni addotte (obiettivi poco chiari, impegno debole, nessun investimento nelle capacità) sono tutte descrizioni di ciò che accade quando le organizzazioni decidono di lanciarsi prima di essere pronte a costruire. Questo è un problema di pubblicità. Non è un problema tecnologico.
La versione UE costa di più
Una società statunitense che riscontra un errore a livello di consegna entra in fase di riparazione. Un’azienda europea che subisce lo stesso fallimento ai sensi del GDPR, DORA o dell’EU AI Act avvia contemporaneamente una bonifica e un’indagine normativa.
L'ambiente di applicazione qui è diverso. La maggior parte dei casi di studio letti dalle persone sono stati scritti da organizzazioni che non hanno mai operato nell'ambito di esso.
Ciò è importante perché cambia il costo del secondo errore, non solo del primo. Sbagliare il livello dati nel primo anno è recuperabile. Scoprire che il livello di consegna registra i risultati non conformi da diciotto mesi, mentre il regolatore fa domande, è una situazione completamente diversa.
Calsoft si basa su tutti e tre i livelli come requisiti di progettazione, non come ripensamenti. Il livello di dati e conoscenza viene verificato per qualità, derivazione e accuratezza contestuale prima che venga eseguita qualsiasi altra cosa. Il livello di elaborazione è regolato dal rischio di allucinazioni e dalla responsabilità dell'output, non solo dalla velocità. Il livello di consegna è progettato con la verificabilità come caratteristica strutturale. Per le imprese dell’UE che operano secondo tempistiche di applicazione reali, questo non è un elemento di differenziazione. È l'architettura minima praticabile.
Una domanda prima della prossima approvazione
La cosa più utile che un CTO può fare con un fallimento documentato è non inoltrarlo al team. Fai una domanda alla prossima revisione dell’architettura: quale decisione, presa diversamente, avrebbe cambiato il risultato?
Quindi controlla se quella decisione è sul tavolo in questo momento.
Di solito lo è. La differenza è se qualcuno ha abbastanza autorità e abbastanza pazienza per rallentare le cose abbastanza a lungo da farcela.
Domande frequenti
Quali fallimenti tecnologici globali sono più rilevanti da studiare per le imprese dell’UE?
I fallimenti nell’implementazione del modello di intelligenza artificiale, nelle piattaforme dati su larga scala e nell’implementazione dei sistemi aziendali sono i più istruttivi. Coinvolgono le stesse infrastrutture che le imprese dell’UE stanno costruendo adesso. Falliscono secondo gli stessi schemi: lacune nella governance dei dati, deriva dell’elaborazione, ipotesi di consegna mai testate rispetto a condizioni operative reali, indipendentemente dal settore, dalla geografia o dalle dimensioni del budget.
In che modo la regolamentazione dell’UE cambia ciò che le imprese dovrebbero prendere dai casi di fallimento globale?
La maggior parte dei fallimenti documentati si è verificata nei mercati in cui un errore nella gestione dei dati implicava una riparazione tecnica. Ai sensi del GDPR, del DORA e dell’EU AI Act, lo stesso errore può significare un’azione normativa senza alcuna interruzione visibile. La lezione tecnica tratta da un caso di studio globale di solito viene trasferita. La conseguenza di sbattere contro lo stesso muro spesso non lo fa.
È sufficiente una cultura interna post-mortem?
No. Le autopsie documentano i fallimenti a cui la tua organizzazione è sopravvissuta. Non possono far emergere rischi nei sistemi che non hai ancora costruito. Ed escludono fallimenti abbastanza gravi da porre fine alle organizzazioni, perché quelle organizzazioni non stanno scrivendo le tue retrospettive. L’analisi dei fallimenti esterni copre la categoria di rischio che l’apprendimento interno non può raggiungere.
