Collegare l'agente al prodotto esistente
Un punto di accesso al prodotto — API esistenti, adapter o un gateway quando serve — permette di offrire all'agente operazioni definite. Questo è il legame tra Web Bridge e AI Enablement: il software attuale rimane la fonte delle regole e dei dati, mentre la nuova funzione usa un'interfaccia controllata.
AWS descrive più modi di collegare strumenti agli agenti, dal collegamento diretto a un gateway centrale; la scelta dipende dal numero di strumenti e dal livello di controllo richiesto. Non è necessario introdurre un'infrastruttura complessa per il primo esperimento. In alcuni prodotti il punto di accesso è già disponibile; in altri va preparato e verificato.
Parti da un compito che puoi verificare
«Mettiamo l'AI nel gestionale» è troppo ampio per progettare e valutare un intervento. «Aiutiamo l'operatore a trovare le ultime richieste aperte di un cliente e preparare un riepilogo da controllare» delimita utente, dati, risultato e supervisione. Un'altra possibilità è suggerire una categoria a una pratica in ingresso, lasciando all'operatore la scelta finale.
Prima di iniziare, descrivi chi userà la funzione, quale attività impiega oggi tempo, quali dati sono necessari, che cosa sarebbe un risultato corretto e quale errore sarebbe inaccettabile. Il beneficio va misurato nel lavoro reale: tempo risparmiato, qualità del riepilogo, numero di correzioni, richieste evase. Se non hai un riferimento prima del pilota, sarà difficile capire se la funzione aiuta davvero.
Mappa letture, proposte e azioni
Un agente può leggere le pratiche che l'utente è autorizzato a vedere, proporre una bozza di report oppure eseguire un'azione come cambiare lo stato di una pratica. Ogni livello richiede controlli diversi. La lettura va filtrata per utente e cliente; una proposta deve mostrare le fonti e permettere la revisione; una modifica richiede permessi specifici, traccia dell'azione e, quando il rischio lo richiede, una conferma umana.
Questa distinzione impedisce che «l'agente può usare il gestionale» si traduca in un accesso generico a tutte le funzioni. Si può iniziare con letture e proposte, poi valutare azioni circoscritte. Non significa che la sola lettura sia sempre priva di rischio: anche recuperare il dato sbagliato o mostrarlo all'utente sbagliato può causare un problema serio.
AWS raccomanda permessi minimi, validazione degli input e output, tracciamento delle chiamate e limiti d'uso per le integrazioni degli agenti. Microsoft richiama l'autorizzazione per ogni azione e la supervisione umana per operazioni sensibili. Sono principi applicabili anche quando il gestionale è stato sviluppato molti anni fa.
- Leggere: quali pratiche può vedere questo utente e come viene registrato l'accesso?
- Proporre: quali fonti sostengono la bozza e chi la rivede?
- Eseguire: quale permesso autorizza l'azione e quando serve una conferma?
Fonti: AWS — sicurezza delle integrazioni con strumenti · Microsoft Learn — responsabilità negli agenti AI
Il punto d'accesso deve rispettare le regole del prodotto
Un agente non dovrebbe leggere o scrivere liberamente le tabelle del database solo perché è il percorso più rapido da prototipare. Il gestionale può applicare permessi, stati e controlli in altri punti del codice. Se la funzione AI aggira quelle regole, il pilota può apparire efficace finché non incontra un caso reale. Meglio esporre operazioni con un significato preciso: «trova le pratiche visibili a questo operatore», «prepara una bozza» o, più avanti, «proponi la chiusura della pratica».
Per ogni operazione definiamo input ammessi, output atteso, errori possibili, identità con cui viene eseguita e traccia dell'esecuzione. La distinzione tra identità dell'utente e identità del servizio è importante: un agente usato da più persone non dovrebbe ereditare permessi universali. Se il prodotto non offre API, si cerca un punto verificabile di integrazione nel codice, nei processi o nei dati. In alcuni casi il primo lavoro consiste proprio nel rendere accessibile una funzione esistente.
Un esempio illustrativo: il report operativo
Immaginiamo un gestionale per interventi tecnici. Ogni mattina il coordinatore prepara un riepilogo delle chiamate ancora aperte. Un assistente potrebbe leggere soltanto gli interventi del reparto autorizzato, raggrupparli per urgenza e produrre una bozza con i riferimenti alle pratiche. Il coordinatore controlla il testo prima di condividerlo. Il pilota confronta la bozza con report compilati manualmente e registra correzioni, omissioni e tempo impiegato.
È un esempio inventato, non un caso cliente MadeInCode. Il passo successivo potrebbe essere proporre un'assegnazione, ma non dovrebbe partire in automatico: prima occorre verificare come funzionano priorità, turni e conferme nel prodotto. Il valore dell'AI deriva dal compito che migliora, non dal numero di azioni autonome che le concediamo.
Testare il comportamento, non solo la risposta più bella
Un pilota credibile comprende casi normali, eccezioni e tentativi di usare dati fuori perimetro. La funzione deve gestire una pratica inesistente, dati incompleti, due clienti con nomi simili, un utente senza permesso e un documento che contiene istruzioni estranee al compito. Se genera un riepilogo, controlliamo quali informazioni ha usato e se ha inventato dettagli. Se chiama strumenti, verifichiamo che non esegua azioni non richieste.
Il QA Assessment aiuta a fissare casi di prova e criteri di accettazione. Una funzione AI non si valuta solo con test deterministici: serve anche un campione di casi reali, esaminato da persone che conoscono il lavoro. Prima della distribuzione vanno stabiliti soglie di qualità, gestione degli errori, costi per utilizzo, latenza tollerabile e chi mantiene la funzione quando cambiano dati o regole del gestionale.
Come decidere se ampliare il pilota
Il risultato utile non è «l'agente risponde». È sapere se l'utente completa meglio il proprio compito, con un rischio accettabile e un costo sostenibile. Se il problema è l'accesso ai dati, si migliora prima l'interfaccia verso il prodotto. Se il problema è l'ambiguità delle regole, si chiariscono con il team. Se le proposte sono valide ma richiedono sempre molte correzioni, il perimetro va ristretto o il flusso ridisegnato.
Con AI Enablement MadeInCode individua un caso d'uso nel prodotto esistente, prepara gli accessi necessari e valida una prima funzione. Quando il core non espone ciò che serve, il Web Bridge può creare il collegamento; il QA Assessment rende espliciti i comportamenti da verificare. Si parte dal lavoro delle persone e da ciò che il software sa già fare.