{"id":2747,"date":"2026-09-18T14:51:55","date_gmt":"2026-09-18T13:51:55","guid":{"rendered":"https:\/\/www.kanban.systems\/blog\/?p=2747"},"modified":"2026-09-18T14:51:59","modified_gmt":"2026-09-18T13:51:59","slug":"perche-collegare-lai-ai-vostri-dati-di-flusso-non-basta-le-decisioni-che-qualcuno-deve-prendere","status":"publish","type":"post","link":"https:\/\/www.kanban.systems\/blog\/2026\/09\/18\/perche-collegare-lai-ai-vostri-dati-di-flusso-non-basta-le-decisioni-che-qualcuno-deve-prendere\/","title":{"rendered":"Perch\u00e9 collegare l\u2019AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere"},"content":{"rendered":"\n

Sono appena rientrato dal Kanban Leadership Retreat<\/a>, la tre giorni annuale organizzata per la propria comunit\u00e0 da Kanban University. Tra i temi che hanno occupato pi\u00f9 spazio quest\u2019anno c\u2019era l\u2019AI: dove sta gi\u00e0 cambiando il modo di lavorare di manager e knowledge worker e come il metodo Kanban possa aiutare le organizzazioni a orientarsi in un contesto tecnologico che si muove molto in fretta.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La risposta che sembra corretta finch\u00e9 non fate due volte la stessa domanda<\/h2>\n\n\n\n

Prendo spunto da una sessione proposta da Sonya Siderova, fondatrice di Nave, dedicata a flow metrics, analytics e AI agent. La domanda di partenza era semplice da porre ma non di facile risposta: che cosa succede quando si toglie la persona, lo human in the loop<\/em>, dal ciclo di gestione del flusso di lavoro e si lascia decidere all\u2019AI? Gli argomenti condivisi dal gruppo di lavoro sono stati sei: costo pi\u00f9 elevato, difficolt\u00e0 ad adattarsi a condizioni che cambiano, perdita di competenza di management, perdita di capacit\u00e0 di fare le domande giuste, perdita di capacit\u00e0 di guidare il cambiamento, perdita di gestione delle pratiche operative. Nel confronto tra un agente AI da solo e un agente affiancato da una persona, l\u2019agente da solo non basta su nessuno di questi sei punti, nemmeno se lavora interfacciandosi con un motore di flow analytics gi\u00e0 maturo.<\/p>\n\n\n\n

Peggio ancora se l\u2019agente accede direttamente ai dati grezzi di flusso e li elabora in autonomia. Il riscontro, dai test effettuati, \u00e8 che si ottiene una risposta plausibile ma non affidabile. Il valore che l\u2019AI aggiunge sta altrove: accedere attraverso il protocollo MCP ai dati prodotti in modo affidabile dal motore di flow analytics e costruirci sopra una narrazione, arrivando a generare raccomandazioni.<\/p>\n\n\n\n

Successivamente a quella sessione, Siderova ha ripreso e sviluppato il ragionamento in un articolo che trovate su LinkedIn: https:\/\/www.linkedin.com\/pulse\/your-ai-can-talk-delivery-data-you-trust-answer-sonya-siderova-rfdfe<\/a><\/p>\n\n\n\n

L\u2019esempio che descrive \u00e8 preciso. Qualcuno collega un LLM ai dati grezzi di flusso e chiede quanto dura normalmente un lavoro, cosa sta rallentando un team, quando saranno finiti quaranta work item. In pochi minuti arriva una risposta, e sembra che il problema sia risolto. Tre mesi dopo qualcuno rif\u00e0 la stessa domanda. Nel frattempo il team ha cambiato workflow, due stati sono stati rinominati, i difetti seguono un percorso diverso. L\u2019AI restituisce un numero diverso, e a quel punto nessuno sa pi\u00f9 dire quale risposta fosse corretta.<\/p>\n\n\n\n

Il prototipo non \u00e8 la parte difficile<\/h2>\n\n\n\n

Siderova anticipa l\u2019obiezione pi\u00f9 ovvia, quella di chi ha collegato i propri dati grezzi di flusso a un LLM, ha sviluppato una demo e pensa di aver gi\u00e0 risolto tutto: collegare l\u2019API di strumenti quali Jira o Azure DevOps a un modello di AI non \u00e8 al giorno d\u2019oggi particolarmente difficile. La parte difficile comincia dopo la demo.<\/p>\n\n\n\n

Prendete il cycle time. Dove parte il timer, alla creazione del ticket, all\u2019ingresso in backlog o all\u2019inizio effettivo del lavoro? Cosa succede se il work item torna indietro? Se salta uno stato? Se viene riaperto? Il tempo di attesa conta o no? Sono decisioni di misurazione, non domande che si rivolgono all\u2019AI. Qualcuno deve prenderle, e poi assicurarsi che continuino a valere quando il workflow cambia il mese successivo, e quello dopo ancora. L\u2019integrazione \u00e8 un progetto, con un inizio e una fine. Il modello di misurazione \u00e8 un prodotto: ha bisogno di un owner, di test, di manutenzione continua.<\/p>\n\n\n\n

Da qui le sei domande che Siderova invita a porsi su ogni sistema, prima di fidarsi di un suo qualsiasi numero, che si tratti di uno strumento interno, di un foglio di calcolo o di una piattaforma commerciale: dove parte il cycle time, dove finisce, cosa succede quando il lavoro torna indietro, cosa succede quando un work item salta direttamente a \u201cFatto\u201d, cosa succede quando un lavoro completato viene riaperto, il tempo di attesa viene conteggiato? E ne aggiunge una settima, decisiva quando quei numeri servono a prendere un impegno su una data di consegna: si sta guardando una media, o un percentile che permette davvero di valutare il rischio? Se il sistema non permette di rispondere con chiarezza a queste domande, quei numeri non possono essere usati per un impegno su una data di consegna. Un numero plausibile e un numero affidabile sono due cose diverse.<\/p>\n\n\n\n

Interfaccia, non motore di calcolo<\/h2>\n\n\n\n

Interrogare ogni volta i dati grezzi e lasciare che sia l\u2019LLM a interpretarli da zero \u00e8 il modo pi\u00f9 veloce per avere una risposta, ed \u00e8 per\u00f2 anche quello che produce il problema descritto sopra, una risposta diversa ogni volta che qualcosa a monte cambia, senza che nessuno se ne accorga finch\u00e9 i numeri smettono di tornare. Interrogare un motore di flow analytics che applica sempre le stesse definizioni perch\u00e9 configurato opportunamente, con l\u2019AI solo come interfaccia, fornisce invece risposte affidabili: la stessa domanda, posta oggi o tra sei mesi, produce una risposta diversa solo se sono cambiati i dati di flusso sottostanti, non perch\u00e9 \u00e8 cambiata l\u2019interpretazione di quei dati.<\/p>\n\n\n\n

Non \u00e8 un problema di modello di AI pi\u00f9 o meno capace, \u00e8 che le definizioni di misura non sono pattern che un LLM possa indovinare guardando i dati, sono decisioni che qualcuno deve avere gi\u00e0 preso a monte.<\/p>\n\n\n\n

Non \u00e8 un problema di AI<\/h2>\n\n\n\n

Qui il discorso torna alla sostanza della gestione del flusso di lavoro. Dove parte il timer, come si trattano gli stati, cosa succede se c\u2019\u00e8 una rilavorazione: non sono un problema di ownership tecnica dello strumento. Sono esattamente ci\u00f2 che rende maturo un sistema Kanban: policy esplicite, confini del workflow dichiarati, non lasciati all\u2019intuito di chi in quel momento guarda la board. Un\u2019organizzazione che non ha mai reso esplicite queste regole non scopre un problema di AI quando i numeri smettono di tornare. Scopre un problema di sistema che aveva sempre avuto, e che l\u2019AI si limita a rendere visibile pi\u00f9 in fretta, perch\u00e9 moltiplica il numero di domande poste a un sistema che non era pronto a rispondere con coerenza.<\/p>\n\n\n\n

Ed \u00e8 per questo motivo che trattare lo\u00a0human in the loop<\/em> come un tema separato dalla qualit\u00e0 della misurazione \u00e8 fuorviante. Sono lo stesso tema visto da due lati diversi. La persona che possiede le definizioni di misurazione deve anche restare la persona che le mantiene quando il workflow cambia. Non \u00e8 un ruolo che l\u2019AI rende superfluo. Diventa anzi pi\u00f9 necessario proprio perch\u00e9 l\u2019AI abbassa il costo di fare domande al sistema.<\/p>\n\n\n\n

Il punto di leva resta lo stesso di sempre<\/h2>\n\n\n\n

Visualizzare il flusso. Limitare il lavoro in corso. Rendere esplicite le policy, comprese quelle di misurazione che di solito nessuno scrive perch\u00e9 sembrano ovvie finch\u00e9 il numero torna. Solo dentro un sistema costruito cos\u00ec ha senso collegare un\u2019AI e farsi rispondere sui propri dati di flusso di lavoro. Solo cos\u00ec quello che si ottiene \u00e8 una risposta, oltre che plausibile, di cui ci si possa fidare.<\/p>\n\n\n\n

Ho pubblicato originariamente questo articolo per il portale Kanban Help<\/a>, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help<\/a> – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Sono appena rientrato dal Kanban Leadership Retreat, la tre giorni annuale organizzata per la propria comunit\u00e0 da Kanban University. Tra i temi che hanno occupato pi\u00f9 spazio quest\u2019anno c\u2019era l\u2019AI: dove sta gi\u00e0 cambiando il modo di lavorare di manager e knowledge worker e come il metodo Kanban possa aiutare le organizzazioni a orientarsi in … Continua a leggere Perch\u00e9 collegare l\u2019AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[618,130,467,7],"tags":[373,622,619,523,211,621,99,620],"class_list":["post-2747","post","type-post","status-publish","format-standard","hentry","category-ai-intelligenza-artificiale","category-kanban","category-lean","category-riflessioni","tag-ai","tag-analytics","tag-cycle-time","tag-flow-metrics","tag-flusso-di-lavoro","tag-human-in-the-loop","tag-kanban","tag-llm"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t