1. Parti dal lavoro che oggi crea attrito.
Chiedi a chi svolge il processo di descrivere una pratica dall’inizio alla fine. Annota cosa arriva, quali strumenti usa, dove ricopia informazioni e quali eccezioni richiedono aiuto. Osserva casi reali, inclusi quelli che non vanno bene.
Raccogli una misura iniziale: volume, minuti di lavoro, attese, correzioni e risultato finale. Non confondere il tempo trascorso tra due eventi con il tempo effettivamente lavorato. Un ordine fermo un giorno in attesa di conferma non equivale a un giorno di lavoro risparmiabile.
2. Confronta i candidati prima di scegliere.
Fai scorrere la tabella per confrontare tutte le colonne.
| Criterio | Un buon punto di partenza | Segnale per fermarsi o ridurre il perimetro |
|---|---|---|
| Frequenza e impegno | L’attività ricorre e il lavoro attuale è misurabile. | Il volume è occasionale o il tempo recuperabile è trascurabile. |
| Dati disponibili | Esistono esempi accessibili e utilizzabili per la prova. | I dati essenziali mancano o non sono autorizzati all’uso previsto. |
| Verificabilità | Una persona sa distinguere un risultato corretto da uno errato. | Il risultato sembra plausibile ma nessuno può validarlo. |
| Conseguenze degli errori | Si può lavorare su bozze e correggere prima dell’azione. | Un errore produce effetti difficili da rilevare o annullare. |
| Responsabile | Un referente ha tempo per prove, feedback ed eccezioni. | Il progetto non ha un proprietario operativo. |
Non è un punteggio scientifico. È una griglia decisionale proposta da Stolen Orbit: un limite grave su dati, controllo o responsabilità non va compensato con un alto volume.
3. Verifica se serve davvero l’intelligenza artificiale.
Se vuoi copiare campi strutturati o applicare regole note, confronta prima funzioni native e automazioni tradizionali. L’AI può essere utile quando serve interpretare testo libero, cercare contenuti pertinenti o preparare una bozza variabile.
Definisci il risultato senza legarlo a uno strumento: «preparare i campi di una bozza d’ordine e segnalare quelli incerti» è più utile di «installare un agente». Permette di confrontare approcci e capire dove la soluzione sta davvero aiutando.
4. Scrivi un brief che il team possa approvare.
Raccogli anche le decisioni da far verificare ai referenti competenti: dati personali o riservati, contratti con fornitori, conservazione delle informazioni e ambito di utilizzo. Un pilota tecnico non risolve automaticamente questi aspetti.
- Obiettivo e confini: cosa entra nel progetto e cosa resta fuori.
- Input, strumenti, permessi e regole per l’utilizzo dei dati.
- Risultato atteso ed esempi di risposta corretta, incompleta e inaccettabile.
- Responsabile del processo, revisore e referente per i problemi tecnici.
- Costi iniziali e ricorrenti, tempo interno e budget massimo della prova.
- Data della valutazione, metriche e condizioni per fermarsi.
5. Prova su un campione che possa smentire l’idea.
Seleziona casi ordinari, incompleti, ambigui e fuori perimetro. Se il progetto usa più lingue, formati o fonti, includili. Tieni separati gli esempi usati per configurare il sistema dai casi con cui valuti la versione finale.
Prima del test scrivi come valuterai ogni risultato: campi corretti, errori critici, tempo di revisione, necessità di rifare il lavoro e costo per pratica. Un campione piccolo aiuta a trovare problemi, ma non dimostra l’affidabilità su tutti i casi futuri.
Esempio di criterio da adattare: nessun invio senza approvazione nel pilota; ogni codice sconosciuto va in revisione; il tempo totale include correzioni e gestione delle eccezioni. Le soglie di qualità dipendono dalle conseguenze di un errore.
6. Decidi se avviare, correggere o fermarti.
Confronta il risultato con il metodo attuale, usando gli stessi tipi di pratica. Se la revisione annulla il tempo recuperato o i costi non sono sostenibili, riduci il perimetro o interrompi la prova. È una decisione utile, non un motivo per ampliare il progetto alla cieca.
Se i criteri sono rispettati, avvia gradualmente con un responsabile, una procedura manuale e un calendario di verifica. Insegna al team anche quando non usare il sistema. Registra versioni, eccezioni e cambiamenti che richiedono nuovi test.
Un modello su cui lavorare.
Brief per il primo progetto AI
Modello Markdown da compilare: processo, dati, responsabili e criteri per proseguire o fermarsi.
Scarica il modello MarkdownDomande pratiche
Come convincere il team a usare l’AI?
Coinvolgi le persone che fanno il lavoro nella scelta del problema e nella prova. Mostra input, risultato, limiti e modalità di correzione. Valuta l’utilità nel loro flusso quotidiano e assegna tempo per imparare, anziché misurare soltanto quante persone aprono uno strumento.
Meglio comprare un software o creare una soluzione su misura?
Confronta prima una funzione già disponibile con il requisito reale. Una soluzione dedicata ha senso quando integrazioni, controlli o passaggi essenziali non sono coperti. Nel confronto includi manutenzione, dipendenza dal fornitore e costi per uscire o cambiare soluzione.
Cosa portare a un primo confronto con Stolen Orbit?
Una descrizione del processo, gli strumenti usati, un volume indicativo e alcuni esempi privi di dati riservati non necessari. Se non conosci ancora tempi o costi, possiamo partire dalle domande da misurare prima di definire il progetto.
Riferimenti e metodo
Il framework NIST distingue responsabilità, contesto, misurazione e gestione continua del rischio. È un riferimento metodologico; questa guida è una proposta operativa di Stolen Orbit, non una certificazione.