Per anni il cloud ha rappresentato soprattutto un cambiamento nel modo di acquisire e utilizzare capacità IT. Elaborazione, storage e applicazioni sono stati progressivamente spostati da infrastrutture dimensionate e gestite internamente verso risorse disponibili on demand. Oggi il punto non è più però soltanto dove eseguire un workload, dal momento che sta cambiando il carico di lavoro stesso.
Se l’intelligenza artificiale generativa ha introdotto nuovi requisiti in termini di potenza elaborativa e accesso ai dati, i sistemi agentici portano con loro anche la capacità di scegliere, entro un perimetro definito, quali strumenti utilizzare e in quale sequenza. L’esecuzione non segue quindi necessariamente un flusso interamente stabilito in fase di sviluppo, una parte viene determinata durante il processo, sulla base del contesto e dei risultati ottenuti nei passaggi precedenti.
Per esempio, se consideriamo un sistema utilizzato per gestire una richiesta di assistenza, un agente riceve il testo del cliente e ne identifica il contenuto attraverso un modello linguistico per poi interrogare il CRM per ricostruire lo storico, accedere alla knowledge base, verificare attraverso un’API lo stato di un ordine e, se necessario, aprire un ticket o avviare un workflow in un sistema di service management.
La discontinuità non sta quindi tanto nelle singole tecnologie coinvolte, e già presenti nelle architetture aziendali, ma nel modo in cui vengono utilizzate. Il sistema agentico non segue necessariamente una sequenza prestabilita, per selezionare invece strumenti e servizi diversi in funzione della richiesta e delle informazioni raccolte durante l’esecuzione.
Per il cloud questo significa affrontare workload meno lineari e più difficili da dimensionare. Pertanto non si tratta soltanto di fornire più potenza di calcolo per eseguire un modello, ma anche digestire contemporaneamente modelli, dati, applicazioni, API e servizi che possono essere attivati dinamicamente in funzione del compito da svolgere.
Il ruolo del cloud si sposta quindi dall’esecuzione di un’applicazione alla gestione dell’ambiente nel quale l’agente può prendere decisioni e attivare risorse. Non determina quali decisioni prendere, ma definisce in larga misura le condizioni tecniche entro cui queste decisioni possono tradursi in azioni, quindi quali dati sono accessibili, quali strumenti sono disponibili, quali servizi possono essere attivati e con quali autorizzazioni
Il suo valore non sta più soltanto nella disponibilità della capacità elaborativa, ma nella possibilità di far interagire in modo controllato componenti diversi, rendendo disponibili all’agente i dati e gli strumenti necessari e mantenendo sotto controllo ciò che può utilizzare e attivare.
Dall’applicazione al sistema di agenti
Questo è un cambiamento che riguarda anche il concetto stesso di servizio applicativo. Finora un’organizzazione poteva ragionare in termini di applicazioni, infrastrutture e servizi cloud relativamente distinti, con l’AI agentica questi confini diventano meno netti visto che un servizio può incorporare uno o più agenti, utilizzare modelli differenti, accedere a repository aziendali, interrogare database e attivare servizi esterni. Gli agenti possono inoltre interagire tra loro, delegando attività e componendo flussi di lavoro più articolati.
Di conseguenza, progettare un servizio applicativo non significa più soltanto definire quali funzionalità debba offrire e su quali infrastrutture debba essere eseguito. Significa anche stabilire quali componenti possono prendere decisioni, quali strumenti possono utilizzare e entro quali limiti possono agire
Questo porta anche a una scelta progettuale importante: non tutte le parti di un processo devono essere affidate a un agente. Le attività che richiedono un comportamento deterministico possono continuare a essere gestite da logiche applicative tradizionali, mentre l’agente può intervenire dove serve interpretare informazioni, scegliere tra strumenti o gestire eccezioni. L’architettura diventa quindi ibrida per definizione, combinando componenti deterministiche e componenti probabilistiche.
Il cloud diventa quindi una parte dell’architettura operativa del sistema agentico, non decide al posto dell’agente, ma determina in larga misura quali risorse l’agente può vedere, quali strumenti può utilizzare e quali azioni può effettivamente eseguire.
Non serve un nuovo cloud, ma un nuovo modo di pensarlo
Tutto ciò non richiede necessariamente un nuovo modello di cloud, le architetture pubbliche, private, ibride e multi-cloud continueranno a rispondere a esigenze diverse di prestazioni, localizzazione dei dati, compliance e controllo. A cambiare è piuttosto ciò che ci si aspetta dall’ambiente cloud quando al suo interno vengono eseguiti sistemi agentici.
La capacità elaborativa resta una componente essenziale, ma non è più il solo elemento da dimensionare. Un’architettura agentica deve poter mettere in relazione modelli, dati e applicazioni con gli strumenti che l’agente può utilizzare durante l’esecuzione. Deve inoltre consentire di applicare policy agli accessi, tracciare le interazioni e stabilire quali azioni possono essere eseguite autonomamente e quali richiedono un controllo.
Questo modifica anche il criterio con cui valutare un’architettura cloud. Decidere dove eseguire l’applicazione agentica rimane importante per aspetti come prestazioni, costi, sovranità del dato e requisiti normativi, ma non è più sufficiente. Occorre valutare anche l’intero ambiente nel quale gli agenti opereranno definendo quali dati può raggiungere, quali strumenti può utilizzare, quali sistemi può modificare e come vengono controllate le sue azioni.
Il cloud non è più soltanto l’infrastruttura su cui eseguire software e modelli, ma l’ambiente nel quale gli agenti accedono a dati e servizi, utilizzano strumenti e svolgono le attività loro assegnate, entro limiti definiti. In questa direzione il valore dell’infrastruttura non dipenderà più soltanto dalla capacità di sostenere il carico computazionale, ma anche dalla capacità di fornire a un sistema agentico le risorse necessarie per completare un’attività, mantenendo definiti i confini entro cui può operare.
Per chi progetta servizi cloud, questo significa necessariamente spostare parte dell’attenzione dall’infrastruttura al comportamento del workload.
di Sergio Ajani, Service & Solution Design Director di Innovaway
