Agenti con strumenti definiti
L’agente può chiamare solo le funzioni che gli assegnate: cercare un ordine, aggiornare un record, aprire un ticket. Nessuna azione fuori da quel perimetro.
Engineering AI · UE e USA
Colleghiamo modelli linguistici, ricerca documentale e automazioni AI ai sistemi che i vostri clienti già usano: ERP, piattaforme commerce, applicazioni interne e flussi a eventi. Non costruiamo modelli. Costruiamo il livello di integrazione, controllo e osservabilità che rende utilizzabile un modello in produzione.
Il servizio
La maggior parte del lavoro AI in ambito enterprise non riguarda il modello. Riguarda tutto ciò che sta intorno: da dove arrivano i dati, come vengono ridotti a un contesto utile, cosa succede quando il modello risponde male, quanto costa una chiamata e come si dimostra a posteriori cosa è stato deciso.
È esattamente il tipo di lavoro che facciamo da anni sulle integrazioni di sistema. Un servizio AI è un altro sistema esterno da collegare con mapping, autenticazione, retry, limiti di costo e monitoraggio. La differenza è che risponde in modo non deterministico, quindi i controlli contano di più, non di meno.
Sviluppo di agenti AI
Un agente utile in azienda non è una demo conversazionale. È un processo che legge dati reali, compie un numero limitato di azioni verificabili e si ferma quando non è sicuro.
L’agente può chiamare solo le funzioni che gli assegnate: cercare un ordine, aggiornare un record, aprire un ticket. Nessuna azione fuori da quel perimetro.
Indicizzazione dei documenti, ricerca semantica e costruzione del contesto, così le risposte si basano sui vostri contenuti e non sulla memoria del modello.
I passaggi che modificano dati o parlano con il cliente possono richiedere approvazione esplicita prima di essere eseguiti.
Ogni chiamata, input, output e costo viene registrato, così un comportamento anomalo può essere ricostruito invece che indovinato.
Costruire o comprare
Diciamolo prima: per molti casi d’uso una piattaforma pronta è la risposta giusta, e ve lo diremo.
Costi
Il costo di un’integrazione AI ha due componenti che si comportano in modo diverso. Il lavoro di engineering è una spesa una tantum, stimabile come qualsiasi altro sviluppo. Il consumo dei modelli è ricorrente, variabile e cresce con l’utilizzo: è la voce che sorprende chi non l’ha misurata prima.
Iniziamo definendo il costo per operazione su un volume realistico prima di scrivere codice di produzione, così sapete in anticipo se il caso d’uso regge economicamente. Dove serve, riduciamo la spesa con caching, modelli più piccoli per i passaggi semplici e limiti di utilizzo.
Valutare un fornitore
Se state confrontando fornitori, queste sono le domande che separano un’integrazione solida da una demo. Valgono anche per noi.
Una risposta seria descrive validazione, fallback ed escalation. Una risposta debole descrive un prompt migliore.
Chi non ha misurato il consumo su volume reale non ha ancora portato niente in produzione.
Indicizzazione, permessi e residenza dei dati sono decisioni di architettura, non dettagli.
Senza log di chiamate, input e output non potete verificare né migliorare il comportamento.
Governance · UE
Molti dei nostri partner lavorano con clienti europei soggetti al GDPR e, sempre più, all’AI Act. Progettiamo le integrazioni perché siano documentabili: quali dati raggiungono il modello, quali no, dove vengono elaborati, cosa viene registrato e quali passaggi richiedono una decisione umana. Sono scelte di architettura, e vanno prese all’inizio.
Scopri come lavoriamoCosa abbiamo consegnato
La parte difficile dell’AI in azienda non è il modello: è l’integrazione, ed è il lavoro che facciamo da anni su ERP, piattaforme commerce e flussi a eventi. Abbiamo consegnato un flusso basato su LLM all’interno di una migrazione di contenuti, generando e riorganizzando i campi richiesti dal nuovo CMS ed evitando una ricostruzione manuale. La stessa ingegneria vale quando il servizio dall’altra parte dell’API è un modello linguistico.
FAQ
Un’integrazione funzionante, non una demo: strumenti definiti che l’agente può chiamare, recupero sui vostri contenuti, approvazione umana sui passaggi che modificano dati, log e un costo per operazione misurato. Se un fornitore non sa descrivere questi cinque elementi, sta vendendo un prototipo.
No, e diffidate di chi lo propone per un progetto enterprise. Usiamo modelli esistenti tramite API e costruiamo il livello che li rende utilizzabili: accesso ai dati, controllo del comportamento, gestione degli errori, costi e tracciabilità.
Due voci: l’engineering una tantum, stimabile a perimetro, e il consumo ricorrente dei modelli. Misuriamo il costo per operazione su volume realistico prima dello sviluppo, così sapete se il caso d’uso regge prima di finanziarlo.
Non con le configurazioni che utilizziamo. I principali provider escludono i dati delle API dall’addestramento nei piani business, e lo verifichiamo per il provider scelto. Dove il requisito è più stringente, valutiamo modelli ospitati in ambiente controllato.
È il caso normale per noi. Lavoriamo su ERP, piattaforme commerce, applicazioni custom e flussi a eventi esistenti, e colleghiamo i servizi AI attraverso le stesse integrazioni che costruiamo da anni.
Lo si progetta in anticipo. Output strutturati e validati, fallback deterministici, approvazione umana sui passaggi che modificano dati e log completi per ricostruire cosa è successo.
Due cose. Lavoro LLM già consegnato — un flusso basato su AI all’interno di una migrazione di contenuti, descritto nel case study collegato — e anni di costruzione del livello di integrazione da cui dipende ogni progetto AI enterprise: collegare sistemi, spostare dati in modo affidabile, gestire gli errori e mantenere costi e comportamento osservabili. La maggior parte del lavoro AI in produzione è ingegneria dei sistemi, ed è la parte in cui siamo più forti.
Parliamo della prossima commessa
Condividete ruoli, stack tecnologico, tempistiche e modello di collaborazione preferito. Valuteremo compatibilità e capacità disponibile.