AI per le aziende, con il rigore di un auditor.

Non dallo strumento, ma da due o tre processi in cui oggi si perde tempo in modo misurabile: ricerca di informazioni nei documenti, attività ripetitive, risposte ai clienti. In parallelo verifico come l'AI viene già usata in azienda, spesso più di quanto il management immagini. Da lì un pilota circoscritto con obiettivi fissati in anticipo: si scala solo se i numeri arrivano.

Dipende dal caso d'uso, ed è la prima cosa che verifico. Propongo soluzioni (come assistenti RAG o analisi predittiva) solo quando il business case mostra un ritorno sull'investimento plausibile entro 6-12 mesi. Se i dati disponibili non bastano a dimostrarlo, si parte da un pilota circoscritto con obiettivi misurabili fissati in anticipo: se i numeri non arrivano, ci si ferma lì, prima di aver investito su larga scala.

Lo è se avviene senza regole, perché documenti riservati finiscono in servizi che nessuno ha valutato: è esattamente ciò che è emerso in una delle due diligence descritte nei casi studio. Vietare raramente funziona; funziona dare strumenti approvati con garanzie contrattuali adeguate, regole chiare su quali dati si possono usare e un minimo di formazione. Così l'uso spontaneo diventa un vantaggio invece che un rischio.

No: per ogni progetto AI valuto prima quali dati possono lasciare il perimetro aziendale e con quali garanzie contrattuali (es. opt-out dal training, hosting in region UE). Dove serve massima riservatezza, oriento verso modelli self-hosted o API enterprise con clausole di non utilizzo dei dati per l'addestramento: la stessa attenzione che applico a sicurezza e governance vale anche per l'AI.

Dipende da come usate l'AI. Alcuni obblighi valgono già per tutte le aziende che la utilizzano, come i divieti su determinate pratiche e la formazione del personale sull'uso consapevole dell'AI; quelli più impegnativi riguardano i sistemi classificati ad alto rischio, come la selezione del personale o la valutazione del credito. Il primo passo è un inventario di dove l'AI è già in uso e con quale livello di rischio: lo stesso approccio da auditor che applico a sicurezza e governance.

Per compiti circoscritti sì, a condizione di trattarli come un nuovo collaboratore con accessi privilegiati: permessi minimi, tracciabilità di ogni azione, approvazione umana dove un errore costa caro. Conviene partire da attività in cui il risultato è facile da verificare e alzare l'autonomia solo dopo aver misurato l'affidabilità. È la stessa logica con cui nei miei progetti ho introdotto la revisione umana obbligatoria sul codice generato dall'AI.

Molto: quando generare software costa poco, il limite diventa la fantasia, e il fornitore smette di essere un semplice outsourcer a cui affidare specifiche chiuse per diventare un partner di co-sviluppo. Questo va governato: chi revisiona e approva il codice generato, chi decide cosa va in produzione, di chi sono il codice e la conoscenza che nasce dal progetto (documentazione, prompt, basi documentali). Aiuto a ridefinire contratti, ruoli e processi di rilascio prima che sia il fornitore a farlo al posto vostro.

Oltre allo sviluppo ci sono costi che crescono con l'uso: chiamate ai modelli, infrastruttura cloud, licenze per utente, aggiornamento della base documentale. Li stimo nel business case prima di partire e li monitoro dopo il rilascio con le stesse pratiche FinOps che uso per il cloud (budget, alert, scelta del modello adatto a ogni compito), così il costo per risposta resta sotto controllo anche quando l'adozione cresce.

Sì, e vanno gestiti come gli altri: documenti riservati esposti da un assistente con permessi troppo ampi, istruzioni malevole nascoste nei contenuti che il modello legge (prompt injection), phishing e truffe molto più credibili grazie a voci e testi generati. Li includo nell'analisi dei rischi insieme ai requisiti NIS2 e ISO 27001 già in essere, invece di trattarli come un capitolo a parte.

Assumere un CISO, un Cloud Architect e un AI Specialist costerebbe oltre 200k/anno in stipendi fissi. Con WIRD parli direttamente con me — auditor certificato ISACA CISA, con esperienza operativa su AWS, governance e AI — un solo interlocutore che presidia tutte queste competenze, con una rete di specialisti attivabile sui progetti che richiedono capacità aggiuntive, pagando solo il tempo realmente necessario.

Firmo un NDA prima di qualsiasi condivisione di dati o accesso ai sistemi, e applico lo stesso principio least-privilege che raccomando ai miei clienti: accedo solo a ciò che serve al progetto, per la durata del progetto. Nessuna informazione relativa a un cliente viene condivisa con terzi, nemmeno in forma anonima, senza autorizzazione esplicita.

Dipende dall'obiettivo: un audit o una certificazione (es. ISO 27001) è tipicamente a progetto, con milestone e deliverable definiti; un ruolo di CTO/CISO frazionale è un retainer con un numero di giornate al mese concordato e rivedibile. In entrambi i casi parli direttamente con chi esegue il lavoro, non con un account manager — ed è proprio il primo confronto a definire insieme il modello più adatto.