> Strumenti senza inventario
L'organizzazione paga e utilizza servizi AI, ma non esiste un elenco aggiornato di cosa viene usato, da chi e per quale attività.
AI Act e governance tecnica
L'AI Act non si affronta comprando un attestato e non si risolve con una policy copiata. Prima bisogna sapere quali sistemi di intelligenza artificiale entrano davvero nei processi, quali dati toccano, chi controlla i risultati e cosa succede quando sbagliano.
Io lavoro su questa parte: inventario, formazione operativa, audit tecnico e modifiche ai sistemi perché restino verificabili, governabili e comprensibili.
In molte aziende l'AI è entrata un'applicazione alla volta. Un dipendente usa ChatGPT, un altro Copilot, il gestionale aggiunge una funzione automatica, il sito riceve un chatbot e nessuno tiene più insieme il quadro.
Il risultato non è necessariamente un sistema vietato o ad alto rischio. Molto più spesso è un insieme di strumenti di cui non sono chiare finalità, dati, responsabilità e limiti.
L'organizzazione paga e utilizza servizi AI, ma non esiste un elenco aggiornato di cosa viene usato, da chi e per quale attività.
Le persone sanno che alcuni dati sono riservati, ma non hanno indicazioni abbastanza concrete per decidere cosa possa essere inserito in un sistema esterno.
Un testo, una classificazione o una sintesi vengono utilizzati perché sembrano plausibili, senza una regola su quando controllarli e chi ne risponde.
Il sistema esegue operazioni reali, ma non è chiaro come fermarlo, ricostruire una decisione o passare il caso a una persona.
Il primo intervento non è un progetto di mesi. È una ricognizione delimitata che serve a capire cosa esiste davvero e quali problemi meritano un intervento.
Identifico gli strumenti e le funzioni AI utilizzati dall'organizzazione, compresi quelli incorporati in software già in uso.
Ricostruisco chi fornisce il sistema, chi lo utilizza, per quale scopo e quali persone o processi ne subiscono gli effetti.
Verifico quali informazioni entrano nel sistema, dove vengono elaborate, quali fornitori intervengono e quali condizioni operative devono essere chiarite.
Cerco supervisione umana, log, soglie di confidenza, gestione degli errori, procedure di escalation, autorizzazioni e possibilità di fermare il sistema.
Distinguo ciò che è già ragionevole, ciò che richiede una correzione tecnica, ciò che richiede una regola interna e ciò che deve essere esaminato da un consulente legale competente.
Non tutte le organizzazioni hanno bisogno dello stesso lavoro. Un'azienda che usa strumenti generalisti e un produttore che inserisce AI in una macchina non hanno lo stesso problema.
Una valutazione tecnica iniziale degli utilizzi AI presenti in azienda.
Il risultato è un documento che contiene inventario, finalità, ruoli, dati coinvolti, controlli esistenti, criticità, priorità e azioni successive.
Non è una certificazione e non sostituisce un parere legale. Serve a trasformare una situazione indistinta in un elenco di decisioni concrete.
L'articolo 4 dell'AI Act richiede a provider e deployer di adottare misure per sostenere l'AI literacy delle persone che utilizzano sistemi AI per loro conto.
Non significa comprare un corso uguale per tutti. Significa spiegare alle persone, sugli strumenti che usano davvero, cosa il sistema può fare, dove sbaglia, quali dati non devono essere inseriti, quando è necessario verificare il risultato e a chi segnalare un problema.
Preparo il percorso sui processi reali dell'organizzazione e lascio materiali, regole operative e una traccia documentabile dell'attività svolta.
Per le organizzazioni che usano già diversi strumenti AI preparo una base di governo semplice, mantenibile e proporzionata.
Non un manuale di cento pagine destinato a non essere letto, ma documenti e procedure che possano essere usati quando qualcuno deve scegliere uno strumento, autorizzare un utilizzo o gestire un errore.
Quando il sistema esiste già, analizzo come è costruito e cosa succede davvero durante l'esecuzione.
Guardo architettura, flussi dei dati, fornitori, prompt, fonti, log, soglie di confidenza, controlli degli output, autorizzazioni, fallback, costi, sicurezza e comportamento in caso di errore.
Il risultato è una relazione tecnica indipendente: cosa regge, cosa è fragile, cosa manca, cosa può essere corretto e in quale ordine.
Quando serve intervenire sul software, progetto i controlli dentro il sistema invece di aggiungerli alla fine come documentazione.
Possono essere punti di approvazione, audit log, attribuzione delle fonti, versionamento dei prompt, soglie di confidenza, code di revisione, autorizzazioni, limiti operativi, fallback, arresto di emergenza e procedure di escalation.
Quando l'AI tocca una macchina, un impianto o un processo fisico, il problema non è soltanto il modello.
Bisogna considerare sensori, firmware, protocolli, tempi di risposta, condizioni di rete, comportamento degradato, comandi manuali e conseguenze di un risultato sbagliato.
Vengo dai sistemi SCADA, dal firmware e dall'automazione industriale. Posso analizzare la parte tecnica insieme agli specialisti legali, di sicurezza macchina e di valutazione della conformità necessari al progetto.
Per chi utilizza ChatGPT, Copilot o funzioni AI incorporate nei software aziendali e vuole stabilire regole pratiche prima che ogni ufficio ne inventi di proprie.
Per chi sviluppa o integra funzioni AI e ha bisogno di un audit indipendente, di controlli tecnici o di una competenza specialistica da affiancare al proprio team.
Per chi sta introducendo computer vision, manutenzione predittiva, assistenti tecnici o altre funzioni AI vicine alle macchine e ai processi produttivi.
Per chi segue la parte legale, privacy o organizzativa e cerca un interlocutore capace di leggere codice, architettura, log, pipeline e comportamento reale del sistema.
Per chi deve formare gruppi di imprese o professionisti con esempi applicabili al loro lavoro, senza trasformare l'incontro in una lezione per programmatori.
Non rilascio certificazioni AI Act e non sostituisco un avvocato, un DPO o un organismo di valutazione della conformità.
Posso però fornire a questi professionisti la parte che spesso manca: inventario tecnico, architettura, flussi dei dati, comportamento del sistema, controlli esistenti, log, evidenze e interventi software.
Quando una questione richiede un parere legale specifico, la separo dal problema tecnico invece di fingere che siano la stessa cosa.
Sviluppo software dal 1995. Prima dei modelli linguistici ho lavorato su firmware, sistemi industriali, supervisione, applicazioni collegate a impianti reali e backend che dovevano continuare a funzionare anche quando qualcosa andava storto.
Oggi costruisco sistemi RAG, agenti, document intelligence e architetture AI in produzione. Ho anche svolto audit e perizie tecniche su progetti software contestati.
La combinazione serve proprio qui: capire cosa dichiara un sistema, cosa fa davvero e quali controlli sono tecnicamente possibili.
Resis Growth OS raccoglie segnali da fonti consentite, conserva le evidenze, collega ogni informazione all'organizzazione corretta, segnala i casi incerti e lascia a me la decisione finale.
Ogni conclusione deve poter essere ricostruita: fonte, dati utilizzati, regole applicate, zone d'ombra e percorso seguito.
Non è una dimostrazione aggiunta al sito per parlare di governance. È il sistema con cui sto organizzando il lavoro commerciale di Resis, e i difetti li pago io per primo.
Guarda Resis Growth OSPuò riguardarlo. Un'organizzazione che utilizza un sistema AI nei propri processi può assumere il ruolo di deployer, ma gli obblighi concreti dipendono da sistema, finalità, persone coinvolte e livello di rischio.
Usare un assistente per riscrivere una mail non equivale automaticamente a utilizzare un sistema high-risk. Serve evitare sia la minimizzazione sia la classificazione indiscriminata di ogni uso come critico.
Per l'AI literacy non esiste un unico corso obbligatorio né uno specifico certificato imposto dal regolamento.
Le misure devono essere proporzionate agli strumenti usati, alle persone coinvolte e ai rischi. L'organizzazione può conservare una registrazione interna della formazione e delle altre iniziative adottate.
Dimostra che una persona ha partecipato a un'attività. Non dimostra, da solo, che l'organizzazione abbia compreso i propri utilizzi dell'AI, stabilito regole adeguate e applicato controlli coerenti.
L'attestato può far parte delle evidenze, ma non sostituisce il lavoro organizzativo e tecnico.
No. Mi occupo della parte tecnica e operativa: sistemi, dati, architettura, log, controlli, procedure e modifiche software.
Quando serve un'interpretazione legale specifica, lavoro a supporto del professionista incaricato o indico chiaramente che quella decisione deve essere presa altrove.
Sì. L'audit nasce proprio per produrre un giudizio indipendente su ciò che esiste: architettura, codice disponibile, documentazione, configurazioni, fornitori, log, controlli e comportamento osservabile.
No. L'impostazione è basata sul rischio. La maggior parte degli utilizzi ordinari non diventa automaticamente vietata o ad alto rischio.
L'obiettivo pratico è capire dove l'AI viene usata, quali conseguenze può avere e quali controlli sono proporzionati.
Da un inventario. Prima di scrivere policy o comprare corsi bisogna sapere quali strumenti vengono realmente usati, per quali attività, con quali dati e sotto la responsabilità di chi.
Scrivimi quali strumenti usate, chi li usa e quale dubbio vi ha portato fin qui.
Ti dico se serve formazione, un inventario, un audit tecnico, una modifica al sistema o un professionista diverso da me.