Il pilot funzionava. Quella non è mai stata la domanda. La demo è atterrata bene, l'accuratezza era difendibile, agli utenti piaceva, e poi ha passato cinque mesi in una coda e silenziosamente ha smesso di essere menzionato. Nessuno l'ha ucciso. È scaduto. Se l'hai visto succedere due volte, probabilmente hai concluso che l'organizzazione è rotta, e voglio proporre una spiegazione meno soddisfacente: il pilot era scoperto per rispondere a una domanda su cui nessuno era bloccato.

La demo risponde a "il modello può fare questo?" L'organizzazione non ne è mai stata incerta. Quello che non sa è chi è responsabile quando il modello sbaglia, dove vanno i dati, cosa succede al rinnovo, e chi firma. Quelle domande hanno dei proprietari, quei proprietari hanno delle code, e nessuno di loro ha visto arrivare il tuo pilot.

Il procurement non è il cattivo

La lettura ingegneristica è che il procurement è una tassa: persone avverse al rischio che rallentano un valore ovvio. Quella lettura è comoda e per lo più sbagliata, e tenerla costa cara, perché non puoi progettare attorno a un processo che hai deciso essere illegittimo.

Il procurement è la funzione che chiede se l'azienda può convivere con questa cosa per tre anni. Ogni domanda che fa codifica un incidente precedente, di solito uno che ti precede. Il vendor che è stato acquisito e ha triplicato il prezzo. Lo strumento con una violazione dati che nessuno riusciva a delimitare perché non esisteva un inventario di cosa conteneva. Il rinnovo che si è auto-eseguito per un prodotto usato da due persone. Questi non sono ipotesi per chi rivede il tuo modulo. Sono la ragione per cui il modulo esiste.

L'attrito è reale, e parte di esso è genuinamente spreco. Ma la risposta corretta a un gate lento è entrarci presto con buone risposte, non sperare che non ci sia.

I quattro gate che fermano davvero le cose

Security review

Il questionario non riguarda davvero la configurazione TLS del tuo vendor. Sta cercando di stabilire cosa può raggiungere lo strumento e cosa succede quando si comporta male. Gli strumenti AI ottengono punteggi bassi qui per una ragione strutturale: chiedono accesso in lettura ampio per essere utili. "Leggi ogni documento nel tenant così può rispondere a domande su di essi" è un requisito di prodotto legittimo e una richiesta di accesso genuinamente allarmante, ed entrambi i fatti sono veri contemporaneamente.

Il pilot che supera questo gate è quello che può dichiarare il proprio modello di permessi in una frase. Sola lettura per default, con accesso in scrittura come passaggio separato ed esplicitamente consentito, è una revisione fondamentalmente più facile di un unico scope che fa entrambe le cose, indipendentemente da quanto sia buono il log di audit. Se lo strumento non riesce a descrivere il proprio raggio d'esplosione, la security lo scoprirà, lentamente, per iscritto, in sei settimane.

Accordi sul trattamento dati

È qui che la maggior parte dei pilot AI muore davvero, e muore su una domanda: i nostri dati vengono usati per addestrare i vostri modelli?

Se la risposta richiede un paragrafo, la risposta è funzionalmente sì, e il legale la leggerà così. Il DPA deve avere i sub-processor nominati, la conservazione dichiarata in giorni, la cancellazione alla cessazione specificata, e la domanda sull'addestramento risolta in una singola clausola. Ogni riserva aggiunge un ciclo di revisione, e i cicli di revisione durano due settimane ciascuno perché chi legge ha altre quaranta cose da fare.

Il problema che si aggrava è che i vendor AI cambiano sub-processor più spesso di quanto la cadenza del DPA presupponga. Un cambio di fornitore di modello è un emendamento. Nessuno pianifica l'emendamento.

Il livello specifico per l'AI

Nuovo da circa un anno a questa parte, e applicato in modo incoerente: una revisione AI interna che chiede una classificazione del rischio, una descrizione della supervisione umana, e prove che conosci i tuoi obblighi. Dove esiste, è spesso il gate più veloce, perché è abbastanza nuovo che il proprietario ha tempo. Dove non esiste ancora, le sue domande vengono poste comunque, in modo estemporaneo, da chiunque se ne accorga, nel momento peggiore possibile. Con l'arrivo degli obblighi di trasparenza del 2 agosto, aspettati che questo gate si formalizzi in più posti, e aspettati che sia un miglioramento, perché un gate definito con una coda batte un'obiezione indefinita sollevata in un comitato direttivo.

Proprietà del budget

L'assassino più silenzioso. Un pilot gira sul budget discrezionale di qualcuno o su un tier gratuito. La produzione ha bisogno di una voce di bilancio, un centro di costo, e un proprietario che la difenderà nel prossimo ciclo. Se lo sponsor del pilot è un ingegnere entusiasta anziché il titolare di un budget, non c'è percorso dal pilot alla produzione indipendentemente dai risultati, e questo di solito è visibile dal primo giorno a chiunque guardi.

Perché il pilot stesso pone la trappola

I pilot sono progettati per essere facili da avviare, e le cose che li rendono facili da avviare sono le cose che li rendono impossibili da finire. Dati sintetici o sanificati, così la domanda sul DPA non si pone mai. Un tenant sandbox, così il modello di accesso non viene mai revisionato. Un tier gratuito, così non serve un titolare di budget. Un team entusiasta, così non viene posta nessuna domanda sulla responsabilità.

Ognuna di quelle scelte rinvia un gate anziché superarlo. Poi il pilot ha successo e tutti e quattro arrivano insieme, nel momento in cui tutti credono che la parte difficile sia finita e il lavoro rimanente sia burocrazia. L'organizzazione non si è mossa di un millimetro verso la produzione, e ora è anche delusa.

Delimita i pilot ai gate

La soluzione non è più governance nel pilot. È scegliere un pilot il cui successo risponde alle domande che bloccano il deployment.

  • Usa dati reali su un tenant reale, sullo scope più piccolo possibile. Un dipartimento, dati di produzione, modello di permessi reale. Un pilot su dati reali con tre utenti supera più gate di un pilot su dati sintetici con trecento, perché produce risposte anziché promesse.
  • Fai leggere il DPA alla settimana uno, non alla settimana dodici. Mandalo al legale prima della demo. Se la clausola sull'addestramento è un problema, hai imparato l'esito al prezzo di un'email anziché di un trimestre.
  • Nomina il titolare del budget prima di iniziare. Se nessuno possiederà la voce di bilancio, esegui il pilot come ricerca e dillo ad alta voce. È una cosa legittima da fare. Ciò che non è legittimo è chiamarlo percorso verso la produzione.
  • Scrivi le risposte di security prima che arrivi il questionario. Modello di permessi, flusso dati, sub-processor, conservazione, cancellazione. Una pagina. La maggior parte del ritardo di sei settimane sono andate e ritorni, e gli andate e ritorni sono latenza, non lavoro.
  • Esegui i gate in parallelo con lo sviluppo. Sono vincolati dalla coda, non dallo sforzo. Il legale che legge un DPA non richiede che il tuo codice esista.

Questo rende i pilot più lenti da avviare e drammaticamente più probabili da finire, e quello scambio è ovvio solo dopo averne perso uno. Il controargomento è reale: caricare di gate il lavoro esplorativo uccide l'esplorazione, e alcuni pilot meritano di essere esperimenti economici che muoiono in fretta. Va bene. Sii solo onesto su quale tipo stai eseguendo, perché il fallimento che sto descrivendo non è un cattivo esperimento. È un buon esperimento che tutti hanno scambiato per un piano di deployment.

Il punto chiave

I pilot AI raramente muoiono per l'accuratezza. Muoiono perché la demo ha risposto a una domanda su cui nessuno era bloccato, mentre la security review, il DPA, il livello AI, e la proprietà del budget sono rimasti intoccati fino alla fine e poi sono arrivati tutti insieme. Il procurement non è ostruzione; è l'organizzazione che chiede se può convivere con questo per tre anni, e quelle domande arrivano comunque, che tu le abbia pianificate o no. Delimita il pilot in modo che avere successo significhi superare un gate. I team che spediscono non sono quelli con i modelli migliori. Sono quelli che hanno fatto partire l'orologio delle dodici settimane alla settimana uno.

Leggi questo dopo

La versione infrastrutturale di questa storia, sul perché le migrazioni di piattaforma si bloccano nelle stesse code, è nelle field notes su ercan.cloud. L'hub è su ercanermis.com.