Come implementare una governance dei dati che regga nei flussi di lavoro di IA da agente a agente

Quando un agente di intelligenza artificiale trasmette dati a un altro agente, l’entità del controllo effettivo da parte di un essere umano dipende da come è stato strutturato il flusso di lavoro. Oggi la maggior parte delle aziende continua a coinvolgere una persona in qualche fase del processo; tuttavia, nel momento specifico in cui l’output di un agente diventa l’input di un altro, tale passaggio avviene solitamente senza che nessuno lo monitori in tempo reale.

Pertanto, in assenza di preavviso, se nei dati è presente un’incongruenza, si giunge a una decisione errata.

È come una staffetta. Si possono avere i migliori velocisti del mondo e un allenatore che osserva ogni passaggio. Ma se il passaggio stesso non è regolato da un sistema ben definito, nessuno può intervenire abbastanza rapidamente da impedire che il testimone cada a terra.

I flussi di lavoro di IA da agente a agente falliscono allo stesso modo: nel punto in cui i dati si spostano tra i sistemi, attraverso i domini, senza una governance coerente che li tenga insieme.

Tale governance deve provenire da qualche parte: o un essere umano controlla il passaggio, oppure il sistema è progettato per autocontrollarsi. Una governance che dipende dalla revisione umana ad ogni passaggio rappresenta un collo di bottiglia che rallenta il flusso di lavoro alla velocità delle persone che vi operano.

In questo blog scoprirai perché i flussi di lavoro da agente a agente falliscono a livello di dati e come deve essere strutturata un’infrastruttura dati governata per evitare che ciò accada.

Perché i flussi di lavoro da agente ad agente creano problemi relativi ai dati che i sistemi a agente singolo non presentano?

Un singolo agente di IA che opera all’interno di un unico sistema presenta un problema di dati circoscritto. Se i dati che legge sono incoerenti, l’errore rimane locale. Un operatore umano o un processo a valle può individuarlo.

I flussi di lavoro multi-agente riducono tale contenimento e, in configurazioni completamente autonome, lo eliminano del tutto.

Ogni agente agisce sull’output di quello precedente, attraverso sistemi e domini che non sono mai stati progettati per condividere un’unica versione della verità. Pertanto, un errore al primo passo non rimane confinato al primo passo.

Si consideri ciò che attraversa un tipico flusso di lavoro di e-commerce basato su agenti:

• Dati di prodotto (descrizioni, attributi, classificazioni)
• Posizioni di magazzino tra diversi magazzini e regioni

La governance può funzionare all’interno di ciascun dominio. Il problema emerge nel passaggio di consegne, quando un agente progettato per un dominio trasmette dati a un contesto per il quale non era stato originariamente strutturato.

Senza una governance che abbracci tutti questi domini, le incongruenze si propagano inosservate lungo la catena, aggravandosi ad ogni scambio.

In una staffetta, un testimone caduto non rallenta un solo corridore: pone fine alla gara per tutti i corridori che lo seguono.

Come si presenta un errore nei dati lungo una catena di agenti?

Prendiamo ad esempio un flusso di lavoro commerciale basato su agenti in cui un agente di raccomandazione dei prodotti fornisce dati a un agente di inventario, il quale a sua volta li trasmette a un agente fornitore.

Ciascuno sta facendo esattamente ciò per cui è stato configurato.

Ora introduciamo un'incongruenza:

I dati del prodotto nella fase uno contengono un errore di classificazione: uno SKU è stato associato alla categoria di prodotto sbagliata.

Ecco cosa succede:

1. L'agente di raccomandazione interviene in base a ciò
2. L'agente di inventario riceve tale output e assegna le scorte di conseguenza
3. L'agente fornitore effettua un ordine in base a tale allocazione

Quando l’errore diventa visibile, diverse decisioni autonome sono già state eseguite. Nessun singolo agente ha commesso un errore nella propria logica. Ciascuno si è semplicemente fidato dei dati ricevuti.

I guasti nei sistemi multi-agente sono molto diversi dai guasti nei sistemi a agente singolo:

• L’errore subisce un ritardo e non emerge nel punto di origine
• Il raggio d’azione del problema si espande ad ogni passaggio di consegne, poiché ogni agente a valle aggrava il problema anziché individuarlo
• Il flusso di lavoro sembra essere stato eseguito con successo poiché nessun agente segnala alcun errore
• Riqualificare gli agenti non risolve il problema, poiché la causa risiede nel livello dei dati sottostante

Senza un livello dati regolamentato che colleghi tali agenti, non esiste alcun meccanismo per tracciare su quale stato dei dati abbia agito ciascun agente, né dove si sia verificato l’errore nella catena.

Perché la governance dei dati fallisce proprio nei passaggi di consegne tra gli agenti?

La maggior parte dei sistemi di governance dei dati aziendali è stata costruita attorno a sistemi che attendono istruzioni.

1. Un utente esegue una query su un database
2. Un report estrae i dati da un data warehouse
3. Un'applicazione legge un record

I dati rimangono inattivi abbastanza a lungo da poter essere controllati.

Gli agenti sono sempre più spesso progettati per agire, trasmettere i risultati e innescare la fase successiva. E spesso ciò avviene all’interno della stessa esecuzione del flusso di lavoro, senza alcun punto di controllo intermedio.

La governance concepita per un utilizzo statico crolla quando i dati iniziano a muoversi autonomamente tra i sistemi.

Gli agenti attingono da sistemi di origine non governati

La maggior parte delle aziende dispone di più sistemi di origine, ciascuno con i propri standard di dati, definizioni e cicli di aggiornamento. Un record di prodotto gestito in un sistema non mantiene tale governance quando un altro agente lo utilizza altrove.

Il passaggio da un dominio all’altro elimina il contesto condiviso

I dati che risultano accurati all’interno di un dominio perdono integrità quando un agente in un dominio diverso li interpreta senza disporre di definizioni condivise. Il significato di «attivo» per una scheda prodotto non è lo stesso che ha per una relazione con un fornitore.

Non esiste una traccia di audit nel punto di passaggio di consegne

Quando qualcosa va storto, spesso non vi è alcuna traccia dello stato dei dati su cui ciascun agente ha agito nel momento in cui ha preso una decisione.

Senza tale visibilità, risalire all’origine di un errore lungo una catena multi-agente è quasi impossibile. È possibile vedere il risultato, ma non quale passaggio di consegne lo abbia causato – né quale fosse lo stato dei dati nel momento in cui hanno attraversato quel confine.

Di cosa ha bisogno il vostro livello dati per supportare l’IA da agente a agente?

La risposta non è «più dati». La maggior parte delle aziende ne dispone già in quantità sufficiente. Il problema è che i dati non sono governati nei punti in cui gli agenti si scambiano le informazioni. Ciò di cui c’è bisogno sono i seguenti quattro elementi.

1. Un unico record regolamentato trasversale a tutti i domini

Ogni agente della catena deve utilizzare lo stesso record regolamentato. I dati relativi a prodotti, fornitori, clienti, partner e sedi devono essere collegati e coerenti. Non possono essere gestiti come silos separati che casualmente condividono un’infrastruttura.

2. Una governance che accompagna i dati

Una governance applicata al momento dell’acquisizione e abbandonata al primo passaggio di mano non è una governance per gli attori. Le regole, le definizioni e gli standard associati a un record di dati devono seguirlo mentre si sposta tra gli attori e attraverso i domini.

3. Verificabilità in ogni fase

Quando una catena di agenti produce un risultato inaspettato, è necessario identificare esattamente su quale stato dei dati abbia agito ciascun agente e in quale momento. In assenza di tali informazioni, la traccia di audit termina nel log del flusso di lavoro, non nel livello dei dati in cui ha avuto origine l’errore.

La tracciabilità influisce anche sul modo in cui si progetta la governance fin dall’inizio. Se ogni stato dei dati deve essere tracciabile a posteriori, la struttura che lo supporta deve essere integrata sin dall’inizio.

4. Una struttura pensata per le catene

La governance dei dati tradizionale era progettata attorno a singole applicazioni che utilizzavano i dati su richiesta.

Nei flussi di lavoro multi-agente, è necessario un livello progettato per supportare un consumo sequenziale e autonomo oltre i confini dei domini, dove, a meno che il livello di governance non lo intercetti prima:

• la revisione umana ad ogni passaggio di consegne non è garantita (e nelle configurazioni autonome non è affatto presente)
• Nessun sistema segnala un'incongruenza a meno che il livello di governance non la rilevi per primo

In che modo Stibo Systems rende affidabili i flussi di lavoro da agente ad agente?

STEP, la piattaforma di intelligence affidabile di Stibo Systems, è una piattaforma leader nella gestione dei dati master (MDM). Grazie ad essa, è possibile gestire i dati relativi a prodotti, clienti, partner, fornitori e sedi come un insieme interconnesso, anziché come domini separati con standard distinti.

Per l’intelligenza artificiale multi-agente, ciò significa:

• Un unico record gestito ad ogni passaggio di consegne
• Le regole di governance seguono i dati
• Le relazioni tra domini vengono mantenute lungo tutta la catena
• Convalida continua dei dati in tutti i domini
• Ogni stato dei dati è tracciabile a posteriori
• Il passaggio tra domini è supportato in modo nativo, senza perdita di coerenza

Man mano che l’IA da agente a agente passa dalla fase pilota a quella di produzione, il livello dati sottostante diventa il fattore determinante.

In una staffetta, la squadra più veloce perde se la zona di cambio non è gestita. Lo stesso vale in questo caso: gli agenti possono essere ben configurati e progettati appositamente, ma senza un livello dati gestito che li colleghi, è proprio nel passaggio di consegne che le prestazioni crollano.

Stibo Systems organizza la vostra azienda per garantire un'intelligenza da agente a agente affidabile.