Piano di governance. L'artefatto scritto che viene consegnato con ogni implementazione AI: un documento di policy che descrive cosa l'AI può e non può decidere, un audit log che mostra ogni azione e il suo esito, e un piano di rollback che riporta l'operatività al suo stato pre-ai.
La maggior parte delle società di consulenza AI consegna codice. Noi consegniamo codice più un piano di governance. Il piano di governance non è un add-on opzionale né un ripensamento dell'ultima settimana. è nel contratto dal primo giorno, ed esce con l'implementazione.
#Perché la governance è dentro lo scope, non fuori
Lo schema che continuava a emergere nei primi engagement era questo: un team passa settimane a costruire e consegnare un workflow AI. Va live. Poi qualcuno fa una domanda a cui il team non sa rispondere in modo pulito. Chi ha approvato questa decisione? Cosa succede se il modello produce una risposta sbagliata su larga scala? Come torniamo al processo precedente se serve?
Quelle domande non sono casi limite. Sono le prime domande che un risk officer, un team legale o un nuovo ops lead farà. Se le risposte non sono documentate — non nella config del modello, non in un readme, ma in un artefatto scritto leggibile — il workflow AI poggia su terreno molle.
Mettiamo la governance dentro lo scope perché consegnare senza è una consegna incompleta. Il workflow gira, ma l'organizzazione non è pronta a farlo proprio.
#Cosa contiene davvero il piano di governance
Tre documenti, scritti e testati insieme all'implementazione.
- policy doc — cosa l'AI è autorizzata a decidere, cosa deve escalare a un umano e cosa non deve mai fare. Scritto per il team operativo, non per gli ingegneri.
- spec dell'audit log — lo schema e le regole di retention per ogni azione AI. Chi ha agito, su quale input, con quale output, a che ora. è il documento che il tuo team di compliance prima o poi chiederà.
- piano di rollback — istruzioni passo passo per riportare il workflow alla versione manuale o precedente. Testato, non teorico. Una persona con nome è responsabile del piano.
Il policy doc ha bisogno di un avvocato?
Non per la prima versione. Il policy doc è un documento operativo, non legale. Descrive cosa fa l'AI e cosa resta in mano agli umani. Se la tua organizzazione dopo avrà bisogno di una policy formale sull'uso dell'AI per compliance o regolamentazione, il policy doc è la base di evidenze che rende più rapida la scrittura. Lo passiamo al tuo team in italiano semplice.
#La conversazione che di solito avviene a metà progetto
In molte implementazioni, uno stakeholder — spesso un CFO, un responsabile compliance o un direttore operations che non era nel brief iniziale — entra nel progetto a metà strada. Le domande che fa sono prevedibili: cosa fa questo modello quando sbaglia? Chi ne risponde? Qual è il peggior guasto e come ci riprendiamo?
Quando queste domande arrivano e il piano di governance esiste già, la riunione è breve. Quando arrivano e il team deve costruire le risposte a posteriori, il progetto rallenta, a volte si ferma e occasionalmente viene cancellato. Il piano di governance è il documento che evita che una riunione a metà progetto diventi un lungo ritardo.
We are
Consegniamo tre artefatti scritti — policy, spec dell'audit log, piano di rollback — come parte dell'ambito concordato. Il piano di governance è testato, scritto in linguaggio chiaro e di proprietà del tuo team fin dal primo giorno.
We aren't
Società di consulenza che aggiungono la governance come modulo extra dopo il go-live, o slide che descrivono 'principi di AI responsabile' senza nominare una sola procedura di rollback.
#Cosa comporta produrlo
Il piano di governance è lavoro in più rispetto a un engagement di implementazione standard. Un senior engineer e uno stratega lo scrivono in parallelo alla fase finale di test, quindi non ritarda la consegna. Fa parte dell'ambito concordato nella chiamata di discovery.
Gli engagement di governance autonomi — per organizzazioni che hanno già AI in funzione e hanno bisogno degli artefatti scritti — vengono definiti per iscritto nella chiamata di discovery. La forma è un audit dell'AI che hai in funzione più i tre documenti: il documento di policy, la spec dell'audit log e il piano di rollback — che consegniamo o meno il build. Se l'AI è già in produzione e manca il piano di governance, l'audit individua prima ciò che serve.
#Perché l'abbiamo reso non opzionale
La ragione più semplice: un workflow AI senza un piano di governance è un prodotto incompleto. Magari oggi gira. Causerà problemi nel momento in cui un membro del team cambia, un regolatore fa una domanda o gli output del modello cambiano in modo inatteso.
La seconda ragione: gli add-on opzionali sono quelli che vengono tagliati nelle negoziazioni di scope. La governance non è una feature. è la prova che l'implementazione è stata fatta come si deve.
Siamo nuovi. I termini su questa pagina sono quelli che onoreremo con il primo cliente che firma. Se stai facendo lo scope di un'implementazione AI e vuoi vedere come è fatto un piano di governance prima di impegnarti, prenota una discovery call da 30 min. Nella call passiamo un esempio anonimizzato.
Vendete piani di governance per AI che non avete costruito?
Sì. Gli engagement di governance autonomi vengono definiti per iscritto nella chiamata di discovery, prima che inizi qualsiasi lavoro. Il deliverable sono gli stessi tre documenti (documento di policy, spec dell'audit log, piano di rollback), scritti dopo un audit dell'AI che hai in funzione. Per organizzazioni che hanno rilasciato in fretta e hanno bisogno della base scritta prima che arrivi la conversazione sulla compliance.
