BandiPA: come abbiamo costruito la piattaforma AI che porta l'automazione nei Comuni italiani

Ogni Comune italiano — dal piccolo borgo di trecento abitanti al capoluogo di provincia — vive un paradosso operativo quotidiano. I fondi pubblici per finanziare opere, servizi e digitalizzazione esistono, sono sempre più consistenti, e in molti casi sono pensati esattamente per la dimensione di quel Comune. Eppure, una percentuale enorme di queste risorse resta non utilizzata. Non per disinteresse — per impossibilità materiale di intercettarle in tempo.

Il funzionario che si occupa di programmazione in un Comune di media dimensione monitora — manualmente — decine di portali diversi: incentivi.gov.it, il portale EU Funding, i siti delle Regioni, le pagine dei Ministeri competenti, i bollettini ufficiali. Ogni portale ha un'interfaccia diversa, una logica di ricerca diversa, un calendario di pubblicazione diverso. Il tempo necessario per fare questa attività in modo serio è incompatibile con le altre responsabilità di chi la deve svolgere.

Il risultato è prevedibile: bandi scoperti il giorno della scadenza, opportunità intercettate per caso, errori di valutazione sull'eleggibilità che bruciano settimane di lavoro su candidature destinate al rigetto. Una macchina amministrativa che sa di poter fare di più ma non ha gli strumenti per farlo.

Da questa osservazione diretta — fatta sul campo, parlando con segretari comunali, responsabili di settore e dipendenti dell'area programmazione — nasce BandiPA: una piattaforma che porta nei Comuni italiani lo stesso livello di automazione che le grandi aziende usano da anni per intercettare opportunità di mercato. Solo che qui il "mercato" sono i finanziamenti pubblici, e il "cliente" è la Pubblica Amministrazione.

Il punto di partenza progettuale di BandiPA non è tecnologico. È strategico, e si riassume in una frase precisa: l'automazione intelligente non può restare appannaggio del settore privato. La PA gestisce volumi documentali, procedurali e decisionali enormi — proprio il contesto in cui l'AI applicata in modo serio produce il valore più alto.

Abbiamo costruito BandiPA come un prodotto dedicato esclusivamente alla PA. Non un software gestionale generalista riadattato. Non un tool aziendale con il "modulo PA" aggiunto sopra. Un sistema progettato fin dalla prima riga di codice considerando le specificità degli enti pubblici: cicli decisionali, obblighi di trasparenza, vincoli di sicurezza dei dati, eterogeneità dimensionale tra micro-Comuni e città capoluogo.

Questa scelta di posizionamento ha implicazioni tecniche profonde. La piattaforma deve funzionare bene per un Comune di duecento abitanti senza ufficio IT dedicato, e contemporaneamente reggere i flussi di un'Unione di Comuni o di una Provincia con decine di operatori connessi. Architettura, UX, sicurezza, performance: ogni decisione tiene conto di entrambi gli estremi.

Il prodotto nasce dalla partnership tra Potenza AI — il nostro studio focalizzato su software engineering e intelligenza artificiale per le imprese — e NextBe S.r.l., partner con esperienza diretta nel settore pubblico. La collaborazione mette insieme competenza ingegneristica AI e conoscenza del dominio amministrativo: due ingredienti raramente presenti nello stesso team, e fondamentali per costruire un prodotto credibile in un settore tradizionalmente diffidente verso l'innovazione esterna.

Il primo problema da risolvere è apparentemente banale: portare i bandi dentro la piattaforma. In realtà è la parte più complessa dell'intero sistema.

Ogni fonte accreditata espone i bandi in modo diverso. Alcuni portali offrono feed strutturati. Altri pubblicano PDF caricati a mano. Altri ancora aggiornano pagine HTML con strutture incoerenti tra loro. I formati cambiano nel tempo senza preavviso. I metadati essenziali — scadenza, importo, tipologia di beneficiario — sono spesso annegati dentro il corpo del documento, scritti in linguaggio amministrativo con formulazioni che variano da regolamento a regolamento.

Abbiamo costruito un livello di ingestion modulare in cui ogni fonte ha un proprio adattatore dedicato — software piccolo, focalizzato, sostituibile — che si occupa di estrarre il bando grezzo. Sopra questo strato vive un secondo livello, comune a tutte le fonti, che normalizza il bando in una rappresentazione strutturata: dati identificativi, requisiti di ammissibilità, importi, scadenze, oggetto, area geografica, tipologia di intervento.

Il passaggio dalla forma grezza alla forma strutturata è dove l'AI inizia a fare la differenza. Un parser tradizionale basato su regole esplicite si rompe alla prima variazione di formato. Un agente AI guidato da prompt strutturati e validato da controlli deterministici resiste all'eterogeneità dei testi e migliora nel tempo. La pipeline di ingestion è progettata per fallire in modo controllato: se l'estrazione non raggiunge la confidenza richiesta su un campo critico, il bando viene segnalato per revisione invece di essere pubblicato con dati incerti.

L'aggiornamento avviene H24 con job notturni programmati. Ogni mattina i Comuni connessi trovano il catalogo aggiornato, con i nuovi bandi del giorno precedente già normalizzati, indicizzati e pronti all'analisi.

La scelta dello stack è una di quelle decisioni che pesano per anni — e abbiamo dedicato tempo a farla bene. Le esigenze del prodotto orientano la scelta in modo abbastanza netto: serve un framework backend solido per la logica di business e i flussi amministrativi, un'esperienza utente moderna senza la complessità di un'app SPA tradizionale, un database relazionale che gestisca anche ricerca vettoriale.

La risposta è uno stack mirato: Laravel per il backend, React via Inertia.js per il frontend, PostgreSQL con estensione pgvector per la persistenza.

Laravel gestisce tutto il dominio applicativo: autenticazione e autorizzazioni granulari per ente, gestione del catalogo bandi, sistema di notifiche, profili degli enti, code di lavoro per l'ingestion e l'analisi AI, audit trail di ogni azione amministrativa. La maturità dell'ecosistema Laravel — Eloquent per l'ORM, le code, la gestione dei job, il sistema di policy per i permessi — riduce drasticamente il codice infrastrutturale che dovremmo scrivere a mano. Per un prodotto che deve essere robusto fin dal primo cliente in produzione, questa solidità non è negoziabile.

Inertia.js + React è la scelta meno scontata. Una SPA tradizionale (React puro che parla con un'API REST o GraphQL) avrebbe imposto la duplicazione della logica di routing, autenticazione e gestione degli errori tra frontend e backend. Inertia rimuove quella duplicazione: il backend Laravel resta autorevole sul flusso applicativo, il frontend React si occupa solo della resa dell'interfaccia. Risultato concreto: meno codice, meno bug, sviluppo più rapido, e un'esperienza utente comunque al livello delle migliori SPA — navigazione fluida senza ricaricamenti, animazioni curate, reattività immediata.

PostgreSQL con pgvector è il cuore della persistenza. Postgres da solo è già lo standard per applicazioni serie che richiedono integrità transazionale, vincoli relazionali rigorosi e capacità di evolvere lo schema senza migrazioni traumatiche. L'estensione pgvector aggiunge la possibilità di archiviare e interrogare embedding vettoriali — la rappresentazione numerica del significato di un testo prodotta dai modelli AI — direttamente accanto ai dati relazionali, senza dover gestire un database vettoriale separato. Il bando, il suo testo, i suoi embedding e tutti i suoi metadati vivono nello stesso database, atomicamente coerenti, interrogabili con una sola query.

Tutto gira in container Docker orchestrati su un server Hetzner in datacenter europeo. La scelta di Hetzner non è casuale: garantisce hosting interamente in Europa, condizione di partenza non negoziabile per un prodotto che tratta dati di Pubbliche Amministrazioni italiane.

Una delle decisioni architetturali più importanti riguarda l'uso dell'intelligenza artificiale. La soluzione più semplice — un singolo modello che fa tutto — è anche la meno efficiente. Modelli diversi hanno punti di forza diversi, costi diversi e velocità diverse. Forzare un solo modello su tutti i task significa pagare prestazioni inferiori a costi superiori.

BandiPA usa tre famiglie di modelli — Claude, GPT-4o e Gemini — ognuna assegnata al ruolo in cui rende meglio. Non per moda multi-vendor: per progettazione.

Estrazione strutturata dai testi grezzi. Quando un PDF di bando arriva nella pipeline, il primo lavoro è trasformare un documento di trenta pagine in una struttura dati pulita: titolo, ente erogatore, importo, scadenza, beneficiari ammessi, area geografica, oggetto. Per questo task usiamo il modello che combina meglio precisione su dati strutturati e costo per token — il vantaggio di avere tre fornitori è poter ribilanciare in qualsiasi momento se il rapporto qualità/prezzo cambia.

Ragionamento di eleggibilità. Quando un Comune apre la scheda di un bando, l'agente AI deve confrontare i requisiti del bando con il profilo dell'ente e produrre un giudizio motivato: "compatibile / parzialmente compatibile / non compatibile", con spiegazione puntuale del perché. Per questo passaggio serve un modello forte sul ragionamento giuridico-amministrativo, capace di leggere clausole formali e ricavarne implicazioni concrete. La scelta varia per profilo del bando — alcuni testi rispondono meglio a modelli specifici.

Sintesi e riformulazione in linguaggio naturale. Un funzionario che apre BandiPA non vuole leggere il testo originale del bando — vuole capire in trenta secondi se è interessante, perché, e quali documenti dovrà preparare. Per questa fase finale usiamo il modello che produce italiano più scorrevole e rigoroso, con il tono giusto per un contesto amministrativo: preciso senza essere burocratico, sintetico senza perdere informazioni rilevanti.

Il routing tra modelli è gestito da un orchestratore interno che conosce i punti di forza di ciascuno e instrada ogni task al provider più adatto. Se domani esce un modello migliore di uno di quelli attuali, lo si aggiunge al routing senza riscrivere il resto del sistema. Questa modularità è la stessa filosofia che applichiamo anche nei nostri progetti di agenti AI per l'automazione aziendale e nello sviluppo di agenti AI su misura per aziende italiane: ogni componente fa una cosa, la fa bene, e può essere sostituito senza traumi.

Una delle funzionalità che cambia in modo netto il rapporto tra il funzionario e il catalogo è la ricerca semantica. Le ricerche tradizionali per parola chiave funzionano male sui bandi pubblici per un motivo strutturale: il linguaggio amministrativo è denso di termini tecnici che non corrispondono a come una persona pensa al proprio bisogno.

Un Comune che vuole "asfaltare le strade del centro storico" non troverà il bando giusto cercando "asfaltatura" — quel bando si chiamerà "interventi di manutenzione straordinaria delle infrastrutture viarie comunali in aree urbane di valore storico". Un funzionario che cerca finanziamenti per "comprare i computer per gli uffici" deve scoprire da solo che il bando rilevante parla di "ammodernamento della dotazione hardware nelle pubbliche amministrazioni locali in ottica PNRR Missione 1".

BandiPA risolve questa frizione con la ricerca semantica basata su embedding. Quando un bando entra nel sistema, oltre ai metadati strutturati viene generato e archiviato il suo embedding vettoriale — una rappresentazione numerica che cattura il significato del testo, non solo le parole. La stessa cosa avviene quando un utente fa una query: "vorrei finanziare nuovi mezzi per la raccolta differenziata" produce un embedding che viene confrontato con tutti gli embedding dei bandi in catalogo.

Il risultato è un elenco di bandi ordinati per pertinenza concettuale, non per corrispondenza di stringhe. Il funzionario non deve più indovinare quali parole usa il legislatore — descrive il bisogno nel modo in cui lo penserebbe parlando con un collega, e il sistema fa il lavoro di traduzione semantica.

L'archiviazione e la ricerca degli embedding avvengono dentro PostgreSQL grazie a pgvector, con indici HNSW per garantire query in millisecondi anche su cataloghi di decine di migliaia di documenti. La stessa transazione che mostra il bando con i suoi metadati restituisce anche il punteggio di pertinenza semantica — niente chiamate a servizi esterni, niente sincronizzazione tra database diversi, niente latenza superflua.

L'approccio è lo stesso che usiamo in tutti i nostri progetti di sviluppo RAG aziendale: convertire la conoscenza in embedding vettoriali, archiviarla in modo sicuro e renderla interrogabile in linguaggio naturale. Quello che cambia tra un caso d'uso e l'altro non è la tecnica — è il dominio specifico su cui viene applicata.

Trovare un bando potenzialmente interessante è solo metà del lavoro. La domanda successiva — che assorbe la maggior parte del tempo nel processo tradizionale — è: siamo davvero ammissibili?

Per rispondere bene servono ore: leggere il testo integrale, isolare i requisiti formali, confrontarli con la situazione amministrativa dell'ente, controllare cumulabilità con altri finanziamenti già attivi, verificare scadenze e tempi tecnici di partecipazione. Un funzionario esperto fa questo lavoro in modo solido — ma non può farlo per tutti i bandi pubblicati ogni settimana.

BandiPA porta questo lavoro a circa trenta secondi per bando, senza sostituire il giudizio umano: lo accelera. Quando un Comune apre la scheda di un bando, parte un'analisi di eleggibilità che usa il profilo dell'ente — popolazione, area geografica, dotazione organica, stato delle infrastrutture, priorità strategiche dichiarate — come riferimento di confronto.

L'output è un report strutturato che dichiara: la compatibilità complessiva (compatibile / parzialmente compatibile / non compatibile), i punti di forza dell'ente rispetto al bando, le criticità potenziali su requisiti specifici, e una checklist preliminare dei documenti che andranno predisposti. Tutto questo in linguaggio chiaro, leggibile in trenta secondi, con i riferimenti puntuali agli articoli del bando da cui ogni valutazione è ricavata.

Il funzionario riceve così uno strumento di triage rapidissimo. I bandi chiaramente non compatibili vengono scartati senza investirci tempo. I bandi compatibili passano a una valutazione umana approfondita — ma con un punto di partenza già strutturato. I bandi parzialmente compatibili diventano oggetto di analisi mirata sui punti critici evidenziati dal sistema, invece di richiedere una lettura integrale partendo da zero.

Una candidatura tecnicamente perfetta ma presentata fuori termine vale zero. Per quanto banale, è uno dei modi più frequenti in cui le opportunità di finanziamento si perdono — non per incapacità tecnica, ma per scollamento tra il momento in cui un bando viene scoperto e il momento della scadenza.

BandiPA include un sistema di notifiche automatiche che lavora su due assi paralleli. Sul primo asse, quando un nuovo bando rilevante per l'ente entra nel catalogo, l'utente responsabile riceve una notifica immediata — non un alert generico, ma un messaggio che include già la sintesi del bando e l'esito preliminare dell'analisi di eleggibilità.

Sul secondo asse, ogni bando salvato dall'ente attiva una sequenza di promemoria sulle scadenze: a 30 giorni, 15 giorni, 7 giorni e 1 giorno dal termine. Questi promemoria sono pensati per integrarsi con il modo in cui un Comune lavora — non sono spam, ma momenti di check-in calibrati sulle fasi di una candidatura tipica: 30 giorni per decidere se candidarsi, 15 per produrre la documentazione, 7 per la revisione finale, 1 come ultimo controllo prima dell'invio.

L'effetto cumulativo è un cambio di postura: il Comune passa da una modalità reattiva — scopre i bandi quando è quasi tardi, corre per produrre la documentazione — a una modalità programmatica, in cui le opportunità vengono valutate con il tempo necessario e la decisione di candidarsi viene presa con consapevolezza.

Un prodotto destinato alla Pubblica Amministrazione non può permettersi compromessi sulla sicurezza dei dati. Le scelte fatte su questo fronte sono parte integrante del progetto, non un livello aggiunto a posteriori.

Tutti i dati di BandiPA risiedono su infrastrutture Hetzner in datacenter europei. Nessun trasferimento extra-UE, nessuna dipendenza da provider americani per la persistenza. La scelta è motivata sia dalla normativa GDPR sia dalla sensibilità politica del settore: un Comune italiano che usa una piattaforma per la propria attività di programmazione finanziaria deve sapere con certezza dove vivono i suoi dati.

Le interazioni con i modelli AI sono gestite con attenzione specifica al perimetro dei dati condivisi. I bandi pubblici sono — per definizione — pubblici, e il loro processing non pone problemi di confidenzialità. I profili degli enti contengono dati amministrativi e operativi che vengono passati ai modelli solo nei termini strettamente necessari all'analisi di eleggibilità, senza identificatori personali superflui e con politiche esplicite di non utilizzo per addestramento dei modelli.

Il sistema di permessi è granulare: ogni utente vede e opera solo sui dati di sua competenza, con audit trail completo di chi ha fatto cosa e quando. Un'eventuale ispezione o controllo interno trova il dato a portata di query, senza dover ricostruire nulla a posteriori. Questo livello di tracciabilità è lo stesso che applichiamo nei nostri progetti di sviluppo software su misura per contesti regolati.

BandiPA non è un prodotto costruito da una sola realtà. Nasce dalla collaborazione strutturata tra Potenza AI — il nostro studio di software engineering e intelligenza artificiale — e NextBe S.r.l., partner che porta la conoscenza di dominio sul settore pubblico.

La divisione di responsabilità riflette le competenze specifiche di ciascuno. Potenza AI gestisce l'intera architettura tecnica: stack applicativo, integrazione dei modelli AI, pipeline di ingestion, sicurezza, infrastruttura, evoluzione del prodotto. NextBe presidia la conoscenza di dominio: requisiti dei Comuni, comprensione delle dinamiche di candidatura ai bandi, relazioni con gli enti, accompagnamento operativo nelle fasi di onboarding.

Questa configurazione è nata da una convinzione precisa: un prodotto verticale per la PA non può essere costruito solo con ottica tecnica, e non può essere costruito solo con ottica amministrativa. I prodotti che falliscono in questo settore sbagliano quasi sempre uno dei due lati — software ben fatto ma scollegato dalle reali esigenze degli uffici, oppure forte conoscenza del dominio ma esecuzione tecnica fragile. Mettere le due competenze nello stesso team, con un prodotto unico, riduce drasticamente questo rischio.

L'accesso a BandiPA è strutturato per essere progressivo. Un Comune che vuole iniziare può registrarsi senza impegno e accedere alle funzionalità fondamentali — consultazione del catalogo, salvataggio dei bandi di interesse, ricezione dei promemoria sulle scadenze. Questa fascia è pensata per permettere a qualsiasi ente di entrare nel sistema, capire come funziona, integrarlo nei propri flussi prima di valutare i piani avanzati.

I piani avanzati sbloccano l'analisi AI di eleggibilità su volume illimitato, l'assistenza nella predisposizione di bozze progettuali, e funzionalità di collaborazione tra più operatori dello stesso ente. Il pricing è calibrato sulle dimensioni dell'ente — un Comune di trecento abitanti non paga come un capoluogo di provincia — proprio per evitare che gli strumenti di automazione restino accessibili solo agli enti più grandi e meglio strutturati.

Gli enti che si sono registrati nelle prime settimane di disponibilità ricevono accesso prioritario alle nuove funzionalità man mano che vengono rilasciate, e tariffe riservate sui piani avanzati. È un modo per ringraziare chi ha scommesso sul prodotto quando era ancora giovane.

BandiPA è in produzione da febbraio 2026. I numeri attuali, fotografati a maggio 2026, danno una misura concreta dello stato del prodotto:

• 900+ bandi nel catalogo attivo, con aggiornamento H24 da fonti accreditate.
• Oltre 20 Comuni attivi in produzione, distribuiti su più regioni italiane.
• Analisi di eleggibilità completate in circa 30 secondi per bando, con report strutturato.
• Zero perdite di dati e uptime stabile dal go-live, su infrastruttura europea.

Sono numeri di una piattaforma in fase di crescita controllata, non di un'esplosione di marketing. La scelta è deliberata: ogni Comune che entra viene seguito nell'onboarding, riceve assistenza diretta nelle prime settimane, ed è una fonte di feedback prezioso per affinare il prodotto. Crescere troppo in fretta su un settore come la PA è il modo più rapido per accumulare debito di prodotto e perdere la fiducia degli early adopter.

I prossimi step sono prevedibili: ampliamento progressivo delle fonti integrate, miglioramento del motore di analisi su tipologie di bando specialistiche (cultura, ambiente, opere pubbliche, sociale), funzionalità di collaborazione tra Unioni di Comuni, integrazione con i sistemi gestionali interni degli enti.

Costruire un prodotto in produzione per la PA è diverso da costruire qualsiasi altro tipo di software che abbiamo affrontato nel nostro lavoro. Vale la pena fissare alcune lezioni che ne sono emerse — utili a chi affronta progetti simili o a chi vuole capire perché il software per la PA italiana è ancora un terreno largamente inesplorato.

La PA non è un mercato omogeneo. Un Comune di duecento abitanti e una città capoluogo hanno bisogni operativi profondamente diversi. Costruire un prodotto che funzioni bene per entrambi significa rinunciare a soluzioni tagliate sull'estremo opposto. La modularità non è un esercizio di stile — è la condizione per essere usabili davvero.

L'AI generalista non basta. Lanciare un modello di linguaggio su un PDF di bando e sperare nel meglio produce risultati sufficienti per una demo, non per un prodotto in produzione. Servono pipeline strutturate, validazione automatica, fallback umano sui casi a bassa confidenza, scelta consapevole del modello giusto per ogni task. Questa è la differenza tra un esperimento e un prodotto — la stessa differenza che caratterizza il nostro approccio all'intelligenza artificiale per le PMI e ai progetti che seguiamo come agenzia di intelligenza artificiale in Italia.

La sicurezza non è una feature, è una precondizione. Il giorno in cui un Comune scopre che i propri dati di programmazione finanziaria stanno transitando su server fuori dall'UE, la conversazione finisce. Ogni decisione tecnica del progetto è stata presa partendo da questo vincolo, non aggiungendolo dopo.

Il dominio si rispetta o si fallisce. Senza una conoscenza solida di come lavora un ente pubblico, di quali sono i vincoli formali, di come vengono prese le decisioni di candidatura, qualsiasi software sembrerà costruito da chi non ha mai messo piede in un ufficio comunale. La partnership con NextBe è la garanzia che questo non succeda.

BandiPA è un progetto in evoluzione. Ogni Comune che entra ci insegna qualcosa di nuovo — un'esigenza che non avevamo previsto, una funzionalità che diventa essenziale, un caso limite che rivela un'assunzione sbagliata. È esattamente il modo in cui un prodotto serio cresce: ascoltando chi lo usa, non chi lo ha solo immaginato.

Se rappresenti un Comune o un ente locale e vuoi capire come BandiPA può integrarsi nei tuoi processi, la registrazione è aperta su bandipa.it. Se invece vuoi capire come costruiamo prodotti come questo per il tuo settore specifico, parla con noi: ogni progetto nasce da una conversazione.