Come organizzare office hours AI in azienda

Le office hours AI sono un appuntamento ricorrente in cui le persone portano un caso di lavoro, non una domanda generica sul tool. Il team raccoglie il caso prima, lo assegna alla coda giusta e chiude la sessione con una decisione tracciata.

Il formato funziona quando ha confini. Senza intake e owner diventa una videochiamata in cui 9 persone guardano lo schermo di una sola.

Decidi cosa entra e cosa resta fuori

Scrivi il perimetro in 1 pagina. Deve dire chi può inviare un caso, quali tool sono ammessi, quali dati non vanno caricati e chi può approvare un cambiamento nel processo.

Dentro le office hours possono entrare:

• un prompt che produce risultati incoerenti,
• un passaggio manuale da studiare,
• un output da verificare,
• una domanda su fonti e controllo,
• un errore già osservato su un caso autorizzato.

Restano fuori incidenti di sicurezza, pareri legali, questioni HR, acquisti, accessi, credenziali e richieste di sviluppo già diventate progetto. Quelle vanno al canale competente.

Il NIST AI RMF Core indica che ruoli, responsabilità e linee di comunicazione per la gestione dei rischi AI vanno documentati. Le office hours non sono richieste dal NIST. Però senza ruoli chiari si rompe esattamente quel punto: nessuno sa chi può decidere.

Usa un intake da 7 campi

Il modulo deve essere corto. Chi lo compila deve però fare il primo lavoro di chiarezza.

Campo	Cosa chiedere
1. Compito	cosa stavi cercando di chiudere
2. Input	quali materiali autorizzati hai usato
3. Tool	modello e versione, se visibile
4. Output	cosa è uscito
5. Difetto	dove non regge
6. Impatto	cosa succede se l'errore passa
7. Richiesta	cosa vuoi decidere nella sessione

Non chiedere di allegare subito il documento vero. Prima basta una descrizione ripulita. L'owner decide in seguito se esiste un modo autorizzato per mostrare materiali.

Un ticket con scritto il prompt non funziona torna indietro. Manca il compito, manca il difetto e manca il rischio.

Dividi i casi in 4 code

La coda impedisce che una domanda piccola occupi lo spazio di un problema serio.

Coda	Segnale	Uscita possibile
Uso	la persona non sa applicare un workflow già approvato	esempio o guida
Qualità	l'output contiene errori, omissioni o fonti deboli	test e correzione
Governance	dati, diritti, responsabilità o tool non sono chiari	escalation
Progetto	il caso richiede collegamenti, automazioni o nuovo software	brief separato

La quarta coda non si risolve in diretta. Si apre un brief. Se provi a disegnare un agent AI negli ultimi 12 minuti della call, stai solo spostando il caos.

Prepara la sessione prima di aprire il link

L'host sceglie al massimo 3 casi per una sessione da 45 minuti. Gli altri ricevono una risposta asincrona, vengono spostati alla sessione successiva oppure escono dal perimetro.

Una struttura semplice:

Minuti	Attività	Owner
0-5	confini e risultato atteso	host
5-17	caso 1	owner del caso
17-29	caso 2	owner del caso
29-39	caso 3 o test comune	host
39-45	decisioni, owner e scadenze	note taker

I tempi sono un preset MAIKER HUB, non un benchmark. Se un caso coinvolge un rischio serio, la scelta corretta può essere fermarlo dopo 3 minuti e aprire l'escalation.

Lavora sul caso, non sulla schermata del tool

Ogni caso usa la stessa sequenza.

1. Ripeti il compito in 1 frase.
2. Mostra il difetto osservato.
3. Ricostruisci input, versione e controlli già fatti.
4. Prova 1 modifica alla volta.
5. Confronta prima e dopo sullo stesso input.
6. Decidi se adottare, testare ancora, fermare o escalare.

Il prompt più lungo non è una decisione. Se il nuovo output sembra migliore, chiedi quale criterio è migliorato e quale difetto resta.

Qui tocca essere freddi: un applauso in call non è un test.

Chiudi con un decision log

Ogni caso finisce in una riga. Nessun verbale da 4 pagine.

Campo	Esempio fittizio
Caso	classificare richieste interne
Decisione	test controllato
Evidenza	18 esempi ripuliti
Owner	responsabile operations
Scadenza	19 agosto
Stop	1 richiesta critica classificata male
Prossimo passo	confronto manuale

L'esempio non descrive un'attività MAIKER HUB. Serve a mostrare la struttura.

Risolto è uno stato troppo largo. Usa 4 esiti: guida, test, escalation, progetto. Sono facili da contare e impediscono di dichiarare chiuso un caso ancora aperto.

Trasforma le risposte in memoria riusabile

Non pubblicare automaticamente la trascrizione. Contiene rumore e può contenere dati che non devono circolare.

L'host estrae soltanto ciò che è stato verificato:

• domanda ripulita,
• contesto minimo,
• risposta approvata,
• esempio sicuro,
• limite,
• owner della revisione,
• data di scadenza.

Se la stessa domanda arriva 3 volte, prepara una guida. Se la guida cambia ogni settimana, non è ancora una regola: resta una nota di test.

Il NIST AI RMF Core include formazione coerente con i ruoli, testing, identificazione degli incidenti e integrazione del feedback. Qui quei principi diventano un flusso locale. Non danno una certificazione e non sostituiscono le funzioni competenti.

Assegna 4 ruoli

Una persona può coprire più ruoli in un team piccolo. I ruoli però devono restare distinti.

Ruolo	Responsabilità
Host	tiene perimetro e tempo
Owner del caso	descrive il lavoro e approva il contesto
Reviewer	controlla qualità, fonti e rischio
Note taker	registra decisione e prossima azione

L'AI può sintetizzare appunti già ripuliti. Non decide il gate. Non assegna l'owner e non trasforma una proposta in procedura approvata.

Un esempio ipotetico

Una persona usa un LLM per riordinare richieste interne. Il modello mette una richiesta urgente nella coda ordinaria. Nel modulo vengono registrati compito, 12 esempi fittizi, difetto e impatto.

Durante le office hours il team scopre che la priorità era implicita in 2 abbreviazioni. Prima modifica il glossario. Poi ripete il test sugli stessi 12 esempi. La richiesta urgente ora passa, ma 1 caso resta ambiguo.

Esito: test. Non guida. L'owner aggiunge 6 esempi e fissa lo stop a 1 errore critico. La decisione resta tracciata.

I numeri sono didattici. Non sono risultati interni né una promessa di performance.

Misura il servizio senza premiare il volume

Conta:

• casi ricevuti per coda,
• casi accettati e respinti,
• tempo fino alla prima risposta,
• esiti guida, test, escalation, progetto,
• domande ripetute,
• guide riusate,
• difetti critici trovati prima dell'uso,
• casi riaperti entro 30 giorni.

Non premiare il numero di ticket chiusi. Un servizio che chiude tutto in 24 ore può aver trasformato domande difficili in risposte fragili.

DigComp 3.0 offre learning outcome e livelli per descrivere la competenza. Puoi usarli per capire se una domanda richiede conoscenza, pratica o autonomia maggiore. Non usarli per etichettare una persona dopo 1 ticket.

Gli errori che trasformano il supporto in teatro

• accettare casi senza intake,
• aprire documenti reali in diretta,
• usare la sessione per presentare tool nuovi,
• correggere 4 variabili insieme,
• lasciare decisioni senza owner,
• pubblicare trascrizioni grezze,
• chiamare bug un errore di processo,
• chiamare formazione una richiesta di sviluppo,
• misurare soltanto presenze e ticket chiusi.

Le office hours non devono intrattenere. Devono chiudere una decisione piccola o riconoscere che serve un percorso diverso.

La prima sessione

Apri un modulo da 7 campi. Chiedi 3 casi già chiusi o riproducibili con dati sicuri. Selezionane 2. Fissa l'esito che vuoi ottenere prima della call.

La formazione AI per il team costruisce la base. Il workshop AI aziendale porta il metodo sui processi. La mappatura delle competenze AI aiuta a capire chi ha bisogno di supporto e su quale compito.

Se il punto è definire ruoli, confini e governance, serve un lavoro separato. La consulenza su roadmap e governance AI è il passaggio coerente.