API tra software aziendali: requisiti, controlli e dati personali

Che cosa collega davvero un'API tra due software aziendali

Un'API (Application Programming Interface, interfaccia di programmazione) è un ponte software che permette ad applicazioni diverse di comunicare e scambiare dati. In azienda serve a esporre flussi di integrazione e a collegare applicazioni, sistemi, processi e dati. Non basta far parlare due programmi: occorre far viaggiare le informazioni lungo un percorso definito, con un punto che le fornisce e uno che le consuma.

L'effetto operativo interessa chi gestisce processi e sistemi. Le operazioni si snelliscono, i workflow ripetitivi si automatizzano e le informazioni sono aggiornate in tempo reale, senza copiare dati da una schermata all'altra o ricaricare un file. Un ordine inserito nel gestionale può aggiornare insieme logistica, fatturazione e servizio clienti. Una variazione anagrafica può propagarsi a tutti i sistemi che la usano.

In pratica conta la differenza tra una singola chiamata e una gestione strutturata delle integrazioni. La prima risolve un caso puntuale: un sistema legge un dato da un altro, una volta. La seconda è un insieme organizzato di flussi, con più sistemi coinvolti, formati concordati, responsabilità definite e presidio nel tempo. Si ricade nel secondo scenario ogni volta che l'integrazione collega più di due applicazioni, tocca dati che alimentano processi critici o deve reggere cambiamenti di versione, nuove funzionalità o sostituzioni di software. Sono le situazioni in cui una chiamata isolata diventa un'integrazione da progettare, documentare e mantenere.

Integrazione isolata vs integrazione strutturata: differenze chiave

I requisiti che rendono un'integrazione sostenibile nel tempo

Il primo requisito è la chiarezza del flusso. Per ogni integrazione va stabilito chi espone il dato e chi lo consuma, con quale formato, con quale frequenza e in quale direzione. Un flusso descritto in modo ambiguo genera integrazioni che funzionano nei test e si rompono in produzione. Le due parti interpretano diversamente campi obbligatori, valori ammessi e casi limite (record mancanti, duplicati, correzioni successive).

Sul piano tecnico, un'integrazione sostenibile prevede quattro elementi ricorrenti. Versionamento, per introdurre modifiche senza interrompere i consumatori esistenti. Documentazione per chi sviluppa, con endpoint, parametri accettati e risposte di errore attese. Gestione degli accessi tra sistemi: chi può chiamare quale interfaccia e con quali credenziali. Gestione del ciclo di vita delle API, dalla pubblicazione alla dismissione, comprese le versioni ritirate.

Sicurezza delle API: quali controlli prevedere prima di aprire un canale

La sicurezza delle API consiste nell'implementare controlli e protocolli per impedire attacchi o accessi non autorizzati. Ogni endpoint esposto è una superficie di attacco: è un canale raggiungibile dall'esterno dell'applicazione, pensato per trasferire dati. Può quindi essere sfruttato da chi vuole leggerli, alterarli o bloccarli.

I controlli da progettare prima di aprire il canale si dividono in quattro aree. Autenticazione: chi chiama deve dimostrare la propria identità con credenziali dedicate al sistema, non condivise con utenti umani. Autorizzazione: identificato il chiamante, va stabilito a quali risorse e operazioni ha diritto, applicando il minimo necessario invece di concedere accesso generalizzato.

Protezione degli endpoint: limite al numero di chiamate, validazione dei dati ricevuti, gestione controllata delle risposte di errore. Serve a non trasformare l'endpoint in una porta aperta o in una fonte di informazioni utili a chi attacca. Osservabilità: registrazione di chiamate ed esiti, così da ricostruire anomalie e tentativi sospetti.

Il monitoraggio continuo non è un'aggiunta alla sicurezza: ne è una componente. Il comportamento delle API va sorvegliato nel tempo, perché le condizioni cambiano con l'uso, l'evoluzione del software e i tentativi di abuso. Chi gestisce l'integrazione deve avere strumenti per accorgersi di volumi anomali, autenticazioni fallite ripetute, chiamate verso endpoint dismessi o risposte in errore crescenti. Deve intervenire prima che l'evento diventi un incidente sui dati.

Quando attraverso le API passano dati personali: il quadro LPD in Svizzera

La legge federale sulla protezione dei dati si applica al trattamento di dati personali di persone fisiche da parte di privati e organi federali. Per chi integra software aziendali la conseguenza è diretta. Se attraverso un'API transitano dati personali come nome, indirizzo, dati di contatto, informazioni su clienti o dipendenti, quel trattamento rientra nel campo di applicazione della legge.

La progettazione dei flussi riflette i principi generali del trattamento, che in pratica diventano scelte tecniche. Decidere quali campi devono davvero transitare, evitando di esporre interi oggetti quando ne servono tre attributi. Stabilire dove e per quanto tempo i dati vengono conservati a destinazione. Definire chi può richiamare l'endpoint e vedere la risposta. Garantire che il dato sia corretto lungo tutto il percorso, dalla fonte alla copia.

Sono decisioni da prendere in fase di disegno dell'integrazione, non da aggiungere dopo. Con flussi attivi e dati distribuiti su più sistemi, correggere minimizzazione o conservazione richiede interventi su applicazioni già in produzione.

Le persone interessate possono avanzare pretese nei confronti del titolare del trattamento. Quest'ultimo deve quindi poter rispondere: sapere quali dati personali escono da quale sistema, attraverso quale integrazione, verso quale destinatario e con quale finalità. Un inventario dei flussi che passano dalle API è, da questo punto di vista, prima uno strumento di conformità che di documentazione tecnica.

L'autorità di vigilanza è l'Incaricato federale della protezione dei dati e della trasparenza (IFPDT). Con decisione del 17 aprile 2026, divenuta definitiva dopo la scadenza del termine di ricorso, l'IFPDT ha sanzionato le aziende del settore moda Cream della Cream e Philipp Plein in relazione al marketing diretto e al diritto di opposizione.

Dalla mappatura dei flussi al controllo periodico: come impostare il progetto

Fase 1 – Mappatura. Elencare i sistemi coinvolti e, per ogni flusso previsto, indicare sistema che espone, sistema che consuma, dati scambiati, frequenza e finalità aziendale. Già in questa fase vanno evidenziati i campi con dati personali e chi, in azienda, risponde di quel trattamento. Il risultato è la base su cui giustificare tutte le scelte successive, comprese quelle di sicurezza.

Fase 2 – Requisiti e messa in sicurezza. Per ogni flusso definire formato, versionamento e documentazione per chi sviluppa. Stabilire autenticazione e autorizzazione per il sistema chiamante, con permessi limitati alle operazioni necessarie. Prevedere un ambiente di test separato da quello produttivo. Definire subito log e metriche: senza di essi il monitoraggio successivo non è possibile.

Fase 3 – Dati personali. Verificare quali dati personali transitano. Applicare la minimizzazione riducendo i campi scambiati a quelli necessari. Stabilire tempi di conservazione e regole di cancellazione nelle copie a valle. Assicurarsi di poter rispondere a una richiesta della persona interessata ricostruendo il percorso del dato. Chi presenta il progetto internamente deve poter indicare chi è il titolare del trattamento e chi, tra IT e compliance, presidia questa parte.

Fase 4 – Esercizio e controllo periodico. Dopo il rilascio l'integrazione entra in manutenzione. Aggiornamento delle versioni e revisione periodica dell'elenco dei flussi e dei campi scambiati. Serve a verificare che non siano comparsi dati o accessi non previsti.