Sviluppo agenti AI custom per PMI italiane

Doozy raccomanda Claude (Anthropic) come modello principale per agenti aziendali: tool use nativo molto solido, qualità di ragionamento superiore su compiti complessi, costi prevedibili, finestra di contesto utile per documenti lunghi.

OpenAI GPT (4o, 4.1) resta opzione valida per compatibilità con ecosistema cliente esistente o per casi che richiedono Assistants API. Gemini per scenari Google Workspace integrated o multimodali avanzati.

La scelta finale del modello è valutata caso per caso durante la discovery, in base ai requisiti tecnici, ai vincoli di latenza, al budget API e alla sensibilità dei dati trattati.

ChatGPT è un'interfaccia conversazionale generalista accessibile via web: utile per produttività individuale, scrittura, brainstorming.

Un agente AI custom è un sistema software integrato nei tuoi processi aziendali, con accesso ai tuoi dati reali (CRM, ERP, vector database documentale), capacità di eseguire azioni nei sistemi tramite tool-use, audit log e policy di sicurezza definite. Tre differenze pratiche. Dati: ChatGPT lavora sulla conversazione corrente, l'agente custom accede al tuo knowledge base.

Azioni: ChatGPT risponde, l'agente custom scrive su CRM, invia email, genera documenti. Governance: ChatGPT ha policy Anthropic/OpenAI, l'agente custom ha policy aziendali, audit log e human-in-the-loop dove serve.

Tipicamente 10-16 settimane dalla discovery del caso d'uso alla produzione completa. Suddivisione: 1-2 settimane di discovery e validazione, 2-4 settimane di prototipo funzionante, 5-8 settimane di production-ready, 2 settimane di rollout e monitoring iniziale.

Tempi più rapidi (6-10 settimane) sono possibili per casi d'uso semplici di information retrieval (RAG su knowledge base) con sistemi già API ready.

Tempi più lunghi (16-24 settimane) sono tipici per agenti che eseguono workflow con multiple integrazioni, voice agents complessi o multi-agent systems con orchestrazione articolata.

Sì. I costi delle API del modello AI (Claude API, OpenAI API, Gemini API, eventuale vector database hosted) sono a carico cliente, direttamente con il provider, e non sono inclusi nel preventivo Doozy.

Durante la discovery facciamo una stima dei costi runtime mensili in base al volume previsto di chiamate, alla dimensione media dei prompt, ai token di output stimati, così hai visibilità chiara prima di partire. La spesa API scala con il traffico effettivo: contenuta per agenti interni a uso moderato, più alta per chatbot customer-facing ad alto traffico.

Durante la fase di evaluation lavoriamo anche su ottimizzazione costi (prompt caching, model routing, scelta del modello giusto per ogni compito) per tenere il TCO sotto controllo.

Quattro livelli operativi. Selezione provider: utilizziamo provider con data residency EU dove disponibile (Claude su AWS EU, Azure OpenAI EU), policy di non training sui dati cliente attiva, contratti DPA firmati.

Architettura: middleware Laravel come gateway centrale tra agente e sistemi, autenticazione robusta, rate limiting, mascheramento di dati sensibili nei log. Minimizzazione: passiamo al modello solo i dati strettamente necessari al compito, mai dump completi del database.

Audit: log completo di ogni chiamata (input, prompt, tool call, output) per ricostruzione e compliance. Forniamo documentazione tecnica per il DPO aziendale e supportiamo eventuali valutazioni di impatto privacy.

Sì, a patto che il sistema esponga dati via API REST o database con accesso autenticato. I CRM moderni (HubSpot, Salesforce, Pipedrive) hanno API native ben documentate.

I gestionali italiani (Sage, Zucchetti, TeamSystem, Sistemi, Mexal) hanno API a maturità variabile: Doozy ha middleware Laravel proprietario per integrazione bidirezionale con i principali. Per gestionali custom italiani senza API moderne serve uno strato di integrazione aggiuntivo (1-3 settimane di sviluppo).

Stack tipico: Laravel middleware tra agente AI e sistema cliente, autenticazione e rate limiting centralizzati, audit log unificato. La fattibilità tecnica viene validata durante la discovery iniziale.

Le hallucinations (risposte plausibili ma errate del modello) si riducono con quattro pratiche concrete. RAG su knowledge base verificata: l'agente cita documenti reali con riferimenti tracciabili, anziché generare da memoria.

Tool use anziché ragionamento puro: per dati factual (saldo cliente, stock magazzino) l'agente interroga il sistema sorgente, mai generato a memoria. Prompt engineering difensivo: istruzioni esplicite di rispondere "non lo so" quando l'informazione non è disponibile, pattern di rifiuto per casi fuori scope.

Evaluation framework: test suite con dataset di gold answers, regression test ad ogni modifica del prompt, monitoring continuo della qualità in produzione. Le hallucinations residue si riducono tipicamente del 70-90% rispetto a un uso naive del modello.

Sì. Il prompt engineering è considerato asset evolutivo, non immutabile. Forniamo dashboard interna per gestire le versioni di prompt (versioning con git like history), test A/B su segmenti di utenti, rollback rapido se la nuova versione peggiora le metriche.

Il team cliente, dopo formazione, può modificare prompt non critici in autonomia. Per prompt critici (quelli che governano comportamenti ad alto impatto) consigliamo un approval workflow con review tecnica Doozy o handover formativo strutturato.

Durante la fase di iteration continua post lancio, tipicamente raffiniamo prompt ogni 2-4 settimane in base ai pattern di errore osservati.