API aperte e dati dell'ente: la clausola che salva il capitolato

Proprietà dei dati, formati aperti e API documentate: le clausole da scrivere nel capitolato per non restare prigionieri del proprio fornitore.

C'è un momento preciso in cui un Comune scopre di non possedere davvero i propri dati: quando prova a cambiare fornitore. L'export che «non è previsto», il tracciato non documentato, il preventivo per la migrazione che somiglia a un riscatto. A quel punto la scelta è tra pagare o restare — e molti enti restano, non per soddisfazione ma per sfinimento. Il lock-in non si combatte al momento dell'uscita: si previene al momento della firma. È una lezione che molti enti hanno imparato a proprie spese, e che vale doppio oggi, mentre i Comuni rinnovano i propri sistemi con i fondi della transizione digitale: ogni gara scritta male adesso è un ostaggio consegnato tra cinque anni.

I dati del Comune sono del Comune

Il principio è limpido, e l'ordinamento lo sostiene: il CAD spinge da anni verso formati aperti, riuso e disponibilità dei dati pubblici, e l'intero impianto dell'interoperabilità nazionale presuppone che i dati degli enti possano circolare. Ma i principi, da soli, non migrano un database: la garanzia concreta si scrive nel contratto, prima che il rapporto cominci, quando la forza negoziale è ancora dell'ente. Dopo la firma, ogni richiesta di apertura diventa una trattativa; prima della firma, è un requisito di gara che i fornitori seri accettano senza drammi. La differenza di tono tra i due momenti dice molto su come funziona questo mercato.

Le clausole che contano

Quattro previsioni contrattuali, in particolare, fanno la differenza tra un fornitore e un padrone di casa. Nessuna è esotica: sono pratiche consolidate nel software gestionale moderno, e chiederle non restringe la concorrenza — la seleziona. Chi non può accettarle sta dicendo qualcosa di importante sul proprio modello di business.

• API documentate e accessibili per tutti i dati dell'ente, comprese nel canone e non vendute come modulo aggiuntivo
• Export completo in formati aperti, con tracciato descritto, eseguibile dall'ente in autonomia e in qualsiasi momento
• Nessun costo di uscita sproporzionato a fine contratto: assistenza alla migrazione quantificata già nel capitolato
• Documentazione tecnica aggiornata come obbligo contrattuale, non come cortesia

Le API come infrastruttura quotidiana

Sarebbe però riduttivo pensare alle API solo come assicurazione per il divorzio. Servono ogni giorno: per far dialogare il gestionale con la contabilità che l'ente vuole mantenere, per alimentare il portale regionale, per permettere a un'applicazione di terze parti di leggere i dati senza doppie digitazioni. Ogni integrazione fatta bene restituisce tempo agli uffici e coerenza ai dati; ogni integrazione impossibile condanna qualcuno a fare da ponte umano tra due sistemi. Un ecosistema aperto trasforma ogni integrazione da progetto software a lavoro di configurazione — ed è il motivo per cui piattaforme come comuni.ai espongono API documentate per ogni modulo.

Resta la prova più semplice, da fare in ogni demo commerciale: chiedere «come porto via i miei dati, domani mattina, senza chiedervi il permesso?». Un fornitore serio risponde mostrando la documentazione. Un fornitore evasivo ha appena risposto a una domanda molto più importante. Perché il rapporto con un fornitore di gestionali dura anni, attraversa mandati e riorganizzazioni, e la sua qualità si giudica nei momenti di attrito: la migrazione, l'integrazione imprevista, la richiesta fuori listino. Le clausole sui dati non servono a litigare meglio: servono a non doverlo fare.