piano di governance. l'artefatto scritto che esce insieme a ogni implementazione ai: un policy doc 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'operazione allo stato pre-ai entro una giornata lavorativa.
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. richiedono una settimana per scriverli e testarli, non un trimestre.
- 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, con una finestra target di una giornata lavorativa.
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 tende ad arrivare nella terza settimana
in circa metà delle implementazioni, uno stakeholder — spesso un cfo, un responsabile compliance o un direttore ops che non era nel brief iniziale — entra nel progetto nella terza settimana. le domande che fa sono prevedibili: cosa fa questo modello quando sbaglia? chi è responsabile? qual è il caso peggiore e come ci si recupera?
quando arrivano queste domande e il piano di governance esiste già, l'incontro dura 20 minuti. quando arrivano queste domande 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 impedisce all'incontro della terza settimana di diventare un ritardo dell'ottava.
we are
consegniamo tre artefatti scritti — policy, spec dell'audit log, piano di rollback — come parte dello scope a fee fissa. il piano di governance è testato, scritto in italiano semplice e di proprietà del tuo team dal primo giorno.
we aren't
società di consulenza che aggiungono la governance come modulo a retainer dopo il go-live, o slide che descrivono 'principi di ai responsabile' senza nominare una sola procedura di rollback.
#quanto costa produrre la governance
il piano di governance aggiunge circa una settimana di lavoro a un engagement di implementazione standard. un ingegnere senior e uno stratega lo co-redigono in parallelo con la fase di test finale. non sposta la data di consegna. è dentro la fee fissa.
gli engagement di sola governance — per organizzazioni che hanno già ai in produzione e hanno bisogno degli artefatti scritti — hanno scope e prezzo a sé; i dettagli nella discovery call. la forma è un audit di 2 settimane più i tre documenti: il policy doc, la spec dell'audit log e il piano di rollback — che si consegni il build o no. se l'ai è già in produzione e il piano di governance manca, l'audit fa emergere cosa serve per primo.
#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 voi?
sì. gli engagement di sola governance hanno scope per iscritto prima che parta qualsiasi lavoro — prezzo nella discovery call. il deliverable sono gli stessi tre documenti (policy doc, spec dell'audit log, piano di rollback), scritti dopo un audit di 2 settimane sull'ai che hai in produzione. per organizzazioni che hanno consegnato velocemente e hanno bisogno delle fondamenta scritte prima che arrivi la conversazione di compliance.