Chi l’ha approvato? Costruire un audit trail per le modifiche dell’IA nel tuo ERP e nel tuo negozio

La domanda che prima o poi arriva

Tre settimane dopo, qualcuno si accorge che i prezzi di 60 articoli sono scesi del 10%. Oppure che un codice sconto valeva per tutto il negozio invece che per una sola collezione. Oppure che a un ospite è stato addebitato un prodotto del minibar che dice di non aver mai preso.

La prima domanda è sempre la stessa: chi l’ha fatto, e perché?

Se una persona lavora direttamente nel sistema, il registro delle modifiche forse riporta un nome utente. Con gli strumenti di IA la risposta è spesso peggiore: “è stata l’IA”, con un token che appartiene all’amministratore delegato, attivata dalla chat personale di qualcuno che nessun altro può vedere.

Cosa contiene un audit trail utile per l’IA

Per ogni modifica preparata dall’IA, un’azienda ha bisogno di cinque informazioni:

1. La richiesta: chi l’ha chiesta, e con quali parole?
2. La proposta: esattamente quali record e quali valori sarebbero cambiati?
3. La decisione: chi l’ha approvata o rifiutata, e quando? Se è stata rifiutata, perché?
4. Il risultato: cosa è successo davvero nel sistema, voce per voce?
5. Il contesto: quale conversazione, quale progetto e quale motivo aziendale l’hanno generata?

Molti connettori per l’IA ne registrano solo una parte.

Come Steward registra le modifiche

Ogni modifica che Steward prepara in modalità Chiedi approvazione, o che una regola di approvazione richiede di verificare, diventa una proposta nella conversazione. Le modifiche eseguite in modalità Automatica non sono proposte verificate: nessuno decide su di esse prima che vengano eseguite.

• La richiesta è il messaggio in chat, di una persona con nome e cognome, in un progetto condiviso.
• La proposta elenca ogni voce con il nome del campo, il valore attuale e quello proposto. Include anche la richiesta esatta che verrà inviata. Vedi verificare e approvare le modifiche.
• Una spiegazione indipendente. Per weclapp, un modello di IA separato descrive l’effetto aziendale della richiesta senza vedere la conversazione di lavoro. Chi approva ottiene così un secondo parere.
• La decisione viene registrata con la persona che ha deciso ed eventuali messaggi di rifiuto. Possono decidere solo le persone con l’autorizzazione Approvazione e il ruolo di Collaboratore o Responsabile del progetto.
• I risultati compaiono voce per voce, inclusi i fallimenti parziali. Gli esiti incerti vengono contrassegnati come incerti, mai come riusciti.

Tutto questo resta nella cronologia condivisa del progetto, dove i colleghi con accesso possono ritrovarlo in seguito.

Separazione dei compiti, integrata

Ai revisori piace un principio semplice: chi prepara una modifica non dovrebbe essere l’unico ad approvarla. In Steward, questo principio è un’impostazione di accesso:

Ruolo	Autorizzazioni in Steward sulla connessione
Impiegato o assistente	Collaboratore
Responsabile	Lettura e Approvazione: può approvare modifiche
Partner IT	Configurazione: gestisce la connessione, nessun dato aziendale

Assegna queste autorizzazioni a persone o team nelle autorizzazioni delle connessioni. Un’approvazione vale per l’esatto blocco preparato. Non amplia mai le autorizzazioni di nessuno e non approva modifiche successive.

Modifiche che vanno sempre verificate

Alcune modifiche non dovrebbero mai partire senza una persona, qualunque sia la modalità della chat. Steward ha impostazioni predefinite rigorose:

• Shopify: rimborsi, incasso dei pagamenti, annullamenti, evasione, pubblicazione, eliminazione e notifiche ai clienti.
• ASA HOTEL: addebiti in camera, documenti di addebito, creazione di prenotazioni, prenotazioni spa e messaggi in camera.

Per qualsiasi connessione, le regole di approvazione ti permettono di aggiungerne di tue, come “verifica sempre la creazione degli ordini di vendita” per weclapp.

I risultati incerti vengono registrati, non nascosti

Se una modifica può essere arrivata o meno al sistema, per esempio dopo un timeout, Steward la registra come incerta e non riprova. Per ASA HOTEL, una persona controlla il sistema e registra l’esito verificato con un riferimento come prova. Il risultato originale resta invariato, e la verifica umana viene aggiunta accanto.

Letture e report ricorrenti

Non ogni voce è una modifica. Le attività pianificate mostrano a nome di chi vengono eseguite, quali connessioni usano, in quale modalità di autorizzazione girano e il risultato di ogni esecuzione. Un report giornaliero in Sola lettura è di per sé la prova che il processo non può modificare i dati.

Cosa non sostituisce

Il registro di Steward copre le modifiche preparate tramite Steward. Il tuo ERP, il tuo negozio e il tuo gestionale alberghiero hanno i propri log, e le modifiche fatte direttamente in quei sistemi compaiono lì, non in Steward. I tuoi obblighi contabili restano gli stessi.

Inizia ora

Ruoli nel progetto. I Visualizzatori seguono i risultati, i Collaboratori usano le connessioni configurate e preparano modifiche, i Responsabili approvano. I membri invitati non necessitano di un accesso separato alla connessione.