Come gestire gli accessi di un workflow AI aziendale

Il workflow usa l'account di una persona uscita dal team tre mesi fa. Funziona ancora. Nessuno sa quali cartelle può leggere.

Il difetto non sta nel prompt. Sta nel confine degli accessi.

Per gestire gli accessi di un workflow AI devi sapere quale identità agisce, su quale risorsa, con quale azione, per quale scopo e fino a quando. Ogni permesso deve avere un owner e una prova di revoca.

Non basta vedere che il collegamento è verde nel pannello. Un token valido può essere troppo ampio, condiviso, senza scadenza o legato alla persona sbagliata.

L'accesso appartiene al task

Può usare il CRM non è una regola. Il CRM contiene oggetti e azioni diverse.

Un workflow che prepara una bozza commerciale potrebbe dover:

• leggere azienda e opportunità assegnate

• creare una bozza in una coda dedicata

• non vedere note riservate

• non inviare messaggi

• non cancellare record

Il NIST SP 800-53 descrive il least privilege come accesso limitato a ciò che serve per i task assegnati. La regola vale anche per i processi che agiscono per conto degli utenti.

Parti quindi dal task. Il tool viene dopo.

Censisci tutte le identità

Un workflow non ha una sola identità. Può coinvolgere:

Nell'inventario dei workflow AI registra gli identificatori, non i secret. La credenziale vive nel sistema adatto. L'inventario deve mostrare chi ne è owner, dove viene usata e quale procedura la ruota o la revoca.

Scomponi risorsa e azione

!Tre livelli di ruolo con percorsi di accesso separati per un workflow AI

*Ruoli e azioni vanno separati per limitare il perimetro operativo. — Visual originale MAIKER HUB*

Scrivi la matrice con verbi precisi.

Accesso completo non entra nella matrice. Va sostituito con azioni verificabili: leggere, creare, aggiornare, approvare, inviare, cancellare, amministrare.

Separa preparazione, approvazione ed esecuzione

Un workflow può preparare un'azione senza poterla eseguire. Un reviewer può approvare senza poter cambiare i log. Un amministratore può configurare gli accessi senza approvare il contenuto.

Il controllo AC-5 del NIST richiede di identificare i compiti che devono restare separati e di definire autorizzazioni coerenti. Nel tuo processo la separazione va scelta sul rischio reale.

La matrice di approvazione per workflow AI governa l'autorità sulla decisione. La matrice accessi governa il permesso tecnico. Una persona può avere autorità commerciale per approvare una proposta e non avere il diritto tecnico di modificare il registro delle esecuzioni.

Evita l'account personale come motore

L'account di una persona sembra comodo durante il pilota. Poi quella persona cambia ruolo, attiva la verifica a due fattori su un telefono privato o lascia l'azienda.

Per un workflow stabile usa un'identità dedicata quando l'architettura lo consente. Assegna:

• scopo unico

• owner operativo

• owner tecnico

• risorse e azioni ammesse

• metodo di rotazione

• scadenza o trigger di review

• percorso di disattivazione

Non condividere la stessa identità tra processi scollegati. Se uno dei due viene compromesso o dismesso, non devi spegnere anche l'altro per capire cosa è successo.

Disegna il ciclo di vita

Ogni accesso passa da stati leggibili.

requested
-> approved
-> provisioned
-> verified
-> active
-> review_due
-> revoked

La richiesta contiene task, risorsa, azione, durata e owner. L'approvazione non equivale a provisioning. Dopo la configurazione serve una verifica effettiva: l'azione ammessa deve riuscire, quella vietata deve fallire.

Il NIST include la disabilitazione di account scaduti o non più associati e la review dei privilegi con rimozione quando il bisogno non è confermato. La frequenza non è universale. Va legata a rischio, variazioni e contesto.

Usa scadenze ed eventi

Una review ogni sei mesi può essere adatta a un caso e lenta per un altro. Combina tempo ed eventi.

Trigger utili:

• cambio ruolo o team

• cambio owner del processo

• nuovo consumer

• nuova azione di scrittura

• incidente o uso anomalo

• passaggio da pilota a produzione

• fine contratto di un fornitore

• dismissione del workflow

Un accesso temporaneo deve scadere da solo o entrare in uno stato che impedisce l'uso. Ce lo ricordiamo non è un controllo.

Registra le decisioni, non i secret

La ricevuta di provisioning può contenere:

access_id: acc-2026-184
identity: svc-briefing
resource: approved-briefs
actions: [read]
approved_by_role: process-owner
provisioned_at: 2026-08-22T10:12:00+02:00
review_trigger: owner_change_or_30_days
verification:
  allowed_read: green
  denied_delete: green
secret_reference: vault://service/briefing

I valori sono fittizi. secret_reference indica dove vive la credenziale senza copiarla nel registro, nei prompt o nei log.

Prova anche ciò che deve fallire

Un test positivo dimostra che il workflow legge la cartella. Non dimostra che non possa cancellarla.

Prepara test negativi per ogni confine importante:

1. lettura fuori perimetro

2. scrittura su record non assegnato

3. invio senza approvazione

4. uso dopo la scadenza

5. azione amministrativa da account operativo

6. accesso con owner rimosso

7. retry dopo revoca

La Zero Trust Architecture del NIST mette al centro la protezione delle risorse e decisioni di accesso least-privilege per singola richiesta. Per un workflow significa evitare che una sessione iniziale diventi fiducia illimitata su tutto ciò che arriva dopo.

Collega accesso e contesto di esecuzione

La stessa identità può essere ammessa in una finestra e bloccata in un'altra. Può leggere record assegnati e non l'intero archivio. Può creare una bozza solo se il task ha un ID valido.

Condizioni possibili:

• ambiente

• orario

• tipo di record

• owner del record

• stato del workflow

• approvazione presente

• livello di rischio

• rete o dispositivo, se pertinente

Non aggiungere condizioni decorative. Ogni condizione deve avere una fonte e un test.

Prepara la revoca prima dell'attivazione

!Chiave temporanea disattivata accanto a una sequenza verificabile di eventi di accesso

*La revoca e la traccia di audit si progettano prima dell'attivazione. — Visual originale MAIKER HUB*

La revoca non è cancella token scritto in una nota. Devi sapere quali sessioni, code, cache e job continuano a esistere.

Un runbook minimo risponde a queste domande:

• chi può fermare il workflow?

• quale identità viene disabilitata?

• quali trigger vengono sospesi?

• quali azioni sono già partite?

• come si riconciliano risultati parziali?

• quale prova conferma che l'accesso è chiuso?

Se l'accesso viene revocato dopo una scrittura parziale, non lanciare un retry cieco. Prima ricostruisci lo stato remoto.

Monitora eventi utili

Conserva almeno identità, risorsa, azione, esito, timestamp, run e policy valutata. Non mettere nei log payload completi o dati personali senza necessità.

Segnali da osservare:

• uso fuori finestra

• tentativi vietati

• crescita dei privilegi

• account inattivi ancora abilitati

• azioni senza run riconoscibile

• revoche fallite

• account condivisi

• secret scaduti o ruotati senza verifica

Il registro degli incidenti AI prende in carico gli eventi che richiedono contenimento, analisi e decisione. Non tutto ciò che viene negato è un incidente. Molti dinieghi mostrano che il confine sta facendo il suo lavoro.

Un esempio fittizio

Un workflow prepara risposte a richieste di assistenza. Legge ticket assegnati, recupera articoli approvati e scrive una bozza. Non invia.

L'identità svc-support-draft ha tre diritti: leggere ticket con stato assigned, leggere la knowledge base pubblicata e creare una bozza legata allo stesso ticket.

Il reviewer può approvare o respingere la bozza. Solo il sistema di assistenza invia, dopo l'approvazione. L'account del workflow non ha quel permesso.

Quando il knowledge owner cambia team, scatta una review. La sua approvazione viene rimossa, ma l'account di servizio continua a preparare bozze. Due identità. Due cicli di vita.

Misura ciò che resta aperto

Misure pratiche:

• accessi senza owner

• identità condivise

• permessi senza task associato

• review scadute

• revoche non verificate

• tentativi vietati per categoria

• giorni tra cambio ruolo e rimozione

• workflow senza test negativo

Il conteggio più utile non è quanti account hai. È quanti accessi non sai ancora giustificare.

Gli errori che allargano il perimetro

Il primo è copiare i permessi dell'utente che ha costruito il pilota.

Il secondo è assegnare admin per evitare problemi di configurazione. Il problema sparisce dal setup e riappare nel rischio.

Il terzo è usare un account condiviso. Perdi attribuzione e revoca selettiva.

Il quarto è mettere token nei prompt, nei file di esempio o nei log.

Il quinto è rivedere gli accessi senza provare la rimozione. Il foglio dice revoked, la sessione continua a funzionare.

Think, Build, Enable applicato agli accessi

Think: mappa task, identità, risorse, azioni e conseguenze. Decidi cosa deve restare separato.

Build: configura permessi minimi, ricevute, scadenze, test positivi e negativi. Prepara la revoca.

Enable: assegna owner e review. Mostra gli accessi senza giustificazione e le revoche non provate.

Porta la matrice alla consulenza roadmap e governance AI di MAIKER HUB. Si parte da un workflow solo, quello che oggi ha più accessi di quanti ne sappiate spiegare.

Fonti e riferimenti

• NIST AI Risk Management Framework

• NIST AI 600-1: Generative AI Profile

• Commissione europea: quadro normativo sull'intelligenza artificiale