Software esistente
Continua a gestire dati, regole e processi già in produzione senza essere riscritto per l'IA.
Case study · Integrazione IA su software esistente
Un API layer sicuro tra gestionale esistente e assistente IA
Come permettere a un assistente di Intelligenza Artificiale (IA / AI) di utilizzare dati e funzionalità di un gestionale già in produzione, senza riscriverlo e senza concedere all'IA accesso diretto e indiscriminato al database?
In un progetto reale ho affrontato questo problema costruendo un componente separato che espone soltanto ciò che l'assistente è autorizzato a utilizzare. Il gestionale continua a fare il proprio lavoro e non è stato impattato da questa implementazione; il nuovo layer API diventa il confine controllato tra software esistente e agent AI.
In questo senso il software diventa AI-ready: non perché viene legato a un singolo modello o prodotto, ma perché dati e funzionalità diventano utilizzabili in modo governato da assistenti e agenti di Intelligenza Artificiale diversi.
Architettura
Gestionale → API → IA
accesso controllato, policy e audit
Il problema
Collegare l'Intelligenza Artificiale ai dati aziendali senza aprire il database
Il progetto riguarda un software gestionale aziendale esistente che deve fornire informazioni a un assistente IA sviluppato separatamente. L'obiettivo non è sostituire il gestionale né trasferire la logica applicativa nell'assistente.
Il punto critico è stabilire quali dati e operazioni possono essere esposti, a chi e con quali regole. Un accesso diretto dell'AI al database renderebbe molto più difficile governare autorizzazioni, limiti, tracciamento e futura evoluzione dell'integrazione.
Principio architetturale
L'assistente non deve conoscere il database
L'assistente utilizza un contratto API esplicito. È il layer intermedio a decidere quali informazioni recuperare dal sistema esistente e quali operazioni rendere disponibili.
Il confine di integrazione resta sotto il controllo dell'applicazione, non del modello di IA.
La scelta
Un componente indipendente dal gestionale e dall'assistente utilizzato
Ho scelto di realizzare un API layer dedicato come progetto separato. Può essere sviluppato con ASP.NET Core, ma il gestionale originario non deve necessariamente essere .NET: il principio è applicabile anche a software realizzati con tecnologie differenti.
API layer governato
Espone soltanto dati e operazioni autorizzati, applicando controlli prima di raggiungere il gestionale.
Assistente / agent AI
Consuma API definite e può essere sostituito o affiancato da altri client senza accedere direttamente al database.
Software AI-ready
Un solo API layer, più assistenti possibili
Il layer non nasce per uno specifico chatbot o provider di Intelligenza Artificiale. Definisce un contratto stabile e governato verso il software aziendale, lasciando libera la scelta della soluzione IA che utilizzerà dati e funzionalità esposte.
Microsoft Copilot Studio
In un ecosistema Microsoft enterprise, le API possono essere rese disponibili agli agenti tramite connector, custom connector o strumenti REST, mantenendo nel layer applicativo autorizzazioni e regole di accesso al gestionale.
Assistenti e agent custom
Lo stesso contratto API può essere utilizzato da un assistente sviluppato su misura, da un agent AI o da altri client applicativi, senza replicare la logica di accesso direttamente sul database.
OiccAI come soluzione lightweight
Quando serve un'esperienza più leggera e personalizzata, OiccAI può essere adattato per utilizzare il layer API come sorgente strutturata, affiancandolo alla knowledge base controllata e mantenendo separata la logica del gestionale.
Scopri il progetto OiccAIIl vantaggio è evitare che l'investimento sull'integrazione dipenda da un singolo assistente: il software viene preparato all'IA una volta, mentre canali e soluzioni possono evolvere nel tempo.
Governance dell'accesso
Non basta esporre un endpoint: serve controllare cosa può fare l'assistente
Nel progetto sono già stati affrontati concretamente i principali aspetti necessari per trasformare l'API in un confine di sicurezza e governo dell'integrazione.
Autenticazione
API key gestite in modo sicuro per identificare chi sta utilizzando i servizi esposti.
Autorizzazioni e policy
Accesso differenziato alle informazioni e alle operazioni in base ai permessi concessi.
Consenso
Gestione esplicita del consenso nei flussi in cui è necessario prima di esporre determinate informazioni.
Rate limiting
Limiti applicativi per evitare utilizzi eccessivi o non previsti delle API.
Audit e logging
Tracciamento degli eventi rilevanti per ricostruire accessi, operazioni e anomalie.
Protezione dei dati
L'assistente riceve solo le informazioni necessarie al caso d'uso, invece di accedere indiscriminatamente al patrimonio dati.
Il caso operativo
Dall'accesso mobile a una base architetturale riutilizzabile
Nel caso concreto, quando i tecnici sul campo hanno bisogno di alcune informazioni sugli impianti, oggi devono telefonare in azienda e attendere che il personale interno le recuperi dal gestionale. Il nuovo sistema deve rendere quelle informazioni consultabili da smartphone tramite un assistente IA, ma il layer non è stato progettato come componente specifico di quel singolo canale.
La stessa base può essere utilizzata in futuro da altri assistenti, app o canali, perché il contratto verso il gestionale resta separato dall'interfaccia che lo utilizza.
Questo consente di modernizzare in modo incrementale un sistema esistente: nuove modalità di accesso vengono aggiunte intorno al gestionale senza trasformare ogni nuova esigenza in una modifica diretta del legacy.
Il mio ruolo
Responsabilità del layer API e delle scelte architetturali
Seguo autonomamente la progettazione e lo sviluppo del layer API e le relative scelte architetturali, coordinando il confine tra il gestionale esistente e il componente IA sviluppato separatamente.
Il valore dell'intervento non è soltanto realizzare endpoint, ma definire come esporre il sistema in modo controllato, riutilizzabile e compatibile con la sua evoluzione futura.
Valore operativo
Meno attività manuali, più autonomia per chi lavora sul campo
Il valore della soluzione non consiste soltanto nel rendere il gestionale accessibile a un assistente di Intelligenza Artificiale. L'obiettivo è semplificare un processo operativo che oggi coinvolge più persone per recuperare informazioni già presenti nel sistema aziendale.
Un tecnico sul campo può ottenere direttamente le informazioni di cui ha bisogno attraverso l'assistente IA, senza dover telefonare in azienda, attendere la disponibilità di un operatore e chiedergli di accedere al gestionale per effettuare la ricerca.
Questo significa ridurre sia il tempo perso dal tecnico sia le interruzioni del personale interno, che può evitare di dedicare parte della giornata a recuperare manualmente informazioni per altri utenti.
Ridurre questi passaggi manuali significa utilizzare meglio il tempo delle persone coinvolte e, di conseguenza, ridurre il costo operativo associato alla ricerca e alla condivisione delle informazioni.
Il vantaggio architetturale è che questo nuovo canale di accesso viene aggiunto senza sostituire il gestionale esistente: l'API layer rende disponibili in modo controllato dati e funzionalità già presenti, mantenendo separate l'applicazione aziendale e la soluzione IA utilizzata per interrogarla.
Approfondimenti tecnici
API enterprise e sicurezza dell'integrazione
Per gli aspetti più tecnici ho già approfondito il ruolo di un API layer nei sistemi aziendali e le misure di sicurezza applicabili alle API ASP.NET Core.
Abilitare l’IA sul software esistente
Vuoi collegare un gestionale o un software aziendale a un assistente IA?
Posso progettare lo strato API che rende il software AI-ready, esponendo in modo controllato dati e funzionalità e lasciandoti libero di utilizzare Microsoft Copilot Studio, un assistente custom, OiccAI o l'agent AI più adatto al progetto.