Chiamate esterne come primitiva, non come eccezione.

Collegare due sistemi la prima volta è un lavoro finito e stimabile. Quello che nessuno stima correttamente è cosa succede dopo: il fornitore cambia un campo, aggiunge un parametro obbligatorio, modifica il formato di una data, introduce una nuova versione.

Nell'approccio tradizionale ogni integrazione è codice scritto a mano: quando qualcosa cambia, qualcuno deve trovarlo, capirlo e modificarlo — e nel frattempo il flusso si ferma. Peggio, spesso quel codice è stato scritto da una persona che non c'è più, e quindi la modifica comincia con una fase di archeologia.

Quando un servizio esterno è dichiarato — quali chiamate espone, quali campi vuole, cosa restituisce, cosa fare in caso di errore — l'adeguamento è la modifica di quella dichiarazione. Non elimina il lavoro, ma lo riduce a un pomeriggio invece di una settimana, e soprattutto non richiede di toccare nient'altro.

• Chiamata diretta a un servizio: la forma migliore quando il sistema di destinazione espone interfacce. Sincrona, verificabile, con gestione esplicita degli errori e interruttore di protezione.
• Scambio di file strutturati: la realtà più diffusa con i sistemi di una certa età e con molti operatori logistici o pubblici. Funziona bene, a patto di progettare con cura la frequenza, la gestione delle differenze e cosa succede quando due mondi divergono.
• Webhook in ingresso: quando è il sistema esterno a voler notificare un evento. Il webhook diventa un ingresso dichiarato che alimenta una pipeline, con le stesse verifiche di autorizzazione degli altri percorsi.
• Microservizio dedicato: quando serve un'elaborazione che non ha senso mettere in una pipeline — lettura di documenti, conversioni, calcoli specializzati. Vive come componente a sé con la propria coda, e viene richiamato come qualsiasi altra risorsa dichiarata.

Quello che non facciamo mai è scrivere direttamente nella base dati di un sistema esterno aggirando la sua logica applicativa. È la scorciatoia che sembra risolvere tutto e produce i danni peggiori, mesi dopo e in forme difficili da ricondurre alla causa.

Nei progetti che usano l'AI, la scelta del fornitore di modelli è una decisione che cambia nel tempo: cambiano i prezzi, cambiano le prestazioni, cambiano i vincoli normativi, e talvolta cambia l'opinione dell'organizzazione su dove i dati possono transitare.

Per questo il modello è trattato come una risorsa dichiarata e intercambiabile, non come una dipendenza incorporata: sostituirlo è una modifica di configurazione, non una riscrittura delle automazioni. Comprende l'opzione di modelli ospitati in un perimetro che controllate, che è la scelta di chi ha vincoli stringenti sulla riservatezza.

È anche la ragione per cui vale la pena separare, nelle valutazioni, la domanda "quale modello usiamo" dalla domanda "come governiamo ciò che il modello fa". La seconda è architetturale e ha conseguenze durature; la prima è una scelta che rifarete più volte.