Consulenza AI e .NET per sistemi che devono reggere la produzione

Il problema

Un prototipo AI che funziona in una demo e uno che regge in produzione sono due cose diverse. Il primo ha bisogno di un modello che risponda bene alla maggior parte dei casi; il secondo ha bisogno di sapere cosa succede quando il modello sbaglia, quando il provider è lento o irraggiungibile, e di un confine chiaro tra cosa decide il codice in modo deterministico e cosa viene lasciato all'interpretazione dell'AI. È la parte che spesso manca nei progetti che arrivano da un proof of concept.

Cosa consegno

• Revisione o progettazione dell'architettura per applicazioni AI su .NET: Clean Architecture, DDD, CQRS, ABP.io dove ha senso.
• Confine esplicito tra lavoro deterministico (API, job schedulati, parsing) tenuto nel backend, e lavoro interpretativo lasciato all'AI (classificazione, matching semantico, question answering) - con l'origine di ogni decisione tracciata.
• Integrazione di servizi AI (Azure Cognitive Services, Azure OpenAI, Anthropic Claude, Assembly.AI) dietro un layer di astrazione multi-provider, così un fornitore si sostituisce senza riscrivere il dominio.
• Resilienza pensata per la produzione: retry policy, circuit breaker, multi-tenancy con RBAC granulare, monitoring con Application Insights.

Il principio

Il principio che uso è semplice da dire e più difficile da applicare con disciplina: non far decidere al modello quello che il codice può decidere in modo affidabile. L'AI entra dove il lavoro è davvero interpretativo - capire il contenuto di un'email, abbinare una transazione bancaria, classificare un documento - e ogni sua decisione persistita registra la propria origine, con conferma umana obbligatoria sui passaggi che contano. Il resto - instradamento, validazione, scheduling, integrazioni - resta codice deterministico, testabile e prevedibile. È questo confine, non la scelta del modello, a fare la differenza tra un sistema che regge la produzione e uno che si rompe alla prima settimana.

Il caso reale

Con SPRocket e SprocketLive, in FEDRO Software, sono passato da zero a produzione in 3 mesi: una piattaforma per l'analisi AI e l'assistenza live nei call center, costruita da zero su ABP.io. Oggi gestisce 4.000+ ore di audio al mese, è multi-tenant, lavora al 99.9% di uptime e processa 500+ file audio in parallelo. Stack: .NET 9, ABP.io (Clean Architecture, DDD, CQRS), Angular, Elasticsearch, Hangfire, Azure Cognitive Services, Azure OpenAI, Anthropic Claude, Assembly.AI, Docker.

Per il consorzio C.I.S.A. sto applicando lo stesso principio sul lato documentale: un backend C# su ABP Framework che resta l'unica fonte di verità, un server MCP di dominio che espone all'AI solo tool controllati e mai SQL diretto, e ogni decisione che registra la propria origine - AI o operatore. È la fase 1 del progetto: studio di fattibilità e piano operativo, non ancora un sistema in produzione.

Prima di specializzarmi in AI ho lavorato come sviluppatore frontend per Expedia Group tramite ALTEN, su una codebase React servita a 1.000.000+ utenti - la stessa attenzione alla produzione, applicata al frontend.

Chi sono

Sono Solution Architect & Technical Lead in FEDRO Software, dove lavoro da 7+ anni su sistemi .NET enterprise. Questo tipo di progetto lo seguo in proprio, come libero professionista con partita IVA, parallelamente al ruolo in FEDRO.