Scegliere il confine cambia il problema

Il confine di un sistema non si trova nella natura: lo traccia chi modella, in funzione di uno scopo. Questo capitolo mostra che la scelta del confine — invisibile, fatta spesso senza accorgersene — decide quali domande il modello può rispondere, e che sbagliarla è una delle cause più comuni di analisi corrette nei numeri e sbagliate nella sostanza.

Perché questo capitolo

C’è un modo di sbagliare che non lascia tracce. Una formula sbagliata si vede: il risultato non torna, il test fallisce, qualcuno se ne accorge. Un confine sbagliato no.

L’analisi gira lo stesso, i numeri sono coerenti fra loro, il modello produce previsioni. Solo che risponde a una domanda diversa da quella che ti interessava. È un errore silenzioso, e proprio perché silenzioso è uno dei più frequenti e dei più costosi nell’analisi dei sistemi.

I capitoli precedenti di questa Parte hanno trattato il confine come un dato di fatto. In Sistema, ambiente, confine, stato il confine compariva già pronto: c’è un sistema, c’è un ambiente, e il confine è la linea che li separa. Era una semplificazione necessaria per partire. Ora va rovesciata. Il confine non viene dalla natura. È una decisione di chi costruisce il modello, presa — consapevolmente o no — in funzione di cosa vuole capire. Lo stesso oggetto fisico ammette molti confini diversi, e ognuno è corretto per una domanda diversa e sbagliato per le altre.

Per chi costruisce sistemi AI questo non è un raffinamento accademico. La domanda “dove finisce un agente?” non ha una risposta data. È l’agente il modello? Il modello più i suoi tool? Più la memoria che accumula tra un turno e l’altro? Più l’harness che lo fa girare in loop? Più l’utente che approva o corregge? Ogni risposta è una scelta di confine. E la scelta non è cosmetica: cambia cosa si misura in una valutazione, cosa si versiona, cosa si mette dentro una sandbox, e di chi è la colpa quando qualcosa va storto. Chi non sa di star tracciando un confine lo traccia comunque — solo, lo fa male e senza poterlo difendere.

Il capitolo ha un obiettivo modesto e preciso. Non insegna “il confine giusto”: un confine giusto in assoluto non esiste. Insegna a vedere il confine come una scelta, a riconoscere quando lo stai facendo, e a giudicare se quella scelta serve la domanda che ti sei posto.

È un’abilità diagnostica, simile a quella di Riduzionismo e olismo: non si tratta di trovare la risposta corretta, si tratta di smettere di fare una scelta importante senza accorgersene. Una scelta fatta consapevolmente si può difendere, criticare, rivedere. Una scelta fatta senza accorgersene si può solo subire.

Contesto

L’idea che il confine sia parte del sistema è vecchia quanto la teoria dei sistemi. Ludwig von Bertalanffy, biologo austriaco (1901-1972) che negli anni ‘40-‘60 formula la General System Theory — un tentativo di trovare principi validi per sistemi di natura diversa, raccolto nel libro General System Theory del 1968 — definisce il confine in modo netto: il confine è la parte del sistema che lo separa dall’ambiente.

Nella trattazione di von Bertalanffy, però, il confine è ancora una caratteristica del sistema, qualcosa che il sistema ha, più che una scelta di chi lo studia. È il punto di partenza, non quello di arrivo: il confine c’è, ma non è ancora visto come una decisione.

Il passo decisivo arriva con la system dynamics, la disciplina fondata da Jay Forrester al MIT negli anni ‘50-‘60 per modellare il comportamento nel tempo di sistemi industriali, urbani e sociali. Qui il confine smette di essere una proprietà del mondo e diventa esplicitamente una decisione di modellazione: il model boundary.

Forrester e la tradizione che lo segue rendono centrale una classificazione — variabili endogene, esogene, escluse — che la prossima sezione sviluppa in dettaglio. E rendono centrale una regola: il confine va scelto abbastanza largo da contenere i meccanismi causali che generano il comportamento da spiegare. Donella Meadows, che divulga il pensiero sistemico in modo accessibile fino al libro postumo Thinking in Systems (2008), aggiunge un’osservazione che torna più volte in questo capitolo: il confine più importante e più ingannevole è quello che tracciamo nella nostra testa, perché lo dimentichiamo subito dopo averlo tracciato.

Una svolta ulteriore, più radicale, arriva dal critical systems thinking. Werner Ulrich, systems thinker svizzero, con la sua Critical Systems Heuristics (1983) sostiene che ogni affermazione professionale — ogni “questo sistema funziona”, “questo progetto conviene” — poggia su quelli che chiama boundary judgments: giudizi su quali fatti e quali valori contano.

Questi giudizi, dice Ulrich, sono inevitabili e parziali. Ogni analisi include certi fatti ed esclude altri, e così facendo favorisce certe parti e ne penalizza altre. Non esiste l’analisi senza confine, e non esiste il confine neutro.

Da qui la boundary critique: la pratica di rendere espliciti i giudizi di confine nascosti, metterli in discussione, e sfidare le pretese di oggettività che li coprono. Ulrich aggiunge una dimensione che il capitolo riprende nella sezione finale: il confine non è solo una questione tecnica, è anche etica, perché chi resta fuori dal confine — gli affected but not involved, i toccati ma non coinvolti — è una scelta morale travestita da scelta tecnica.

Questa è la genealogia, in tre tappe: il confine come caratteristica del sistema (von Bertalanffy), poi come decisione di modellazione (Forrester, Meadows), poi come giudizio parziale da criticare apertamente (Ulrich). Il capitolo vive nell’ultima posizione: il confine è una scelta, e va trattato come tale.

L’intuizione

Prima di qualsiasi formalismo, due modi distinti di afferrare la stessa idea. Il primo parte da un gesto familiare — inquadrare — e mostra che ogni confine è un’inquadratura. Il secondo prende un sistema piccolo e concreto e mostra cosa succede, operativamente, quando la linea si sposta.

Primo angolo: la cornice del fotografo

Una fotografia non è la realtà. È una scelta di cosa entra nel fotogramma e cosa resta fuori. Immagina una manifestazione in una piazza. Un fotografo la inquadra stretta su tre persone che si spingono: la foto racconta “rissa”, “tensione”, “disordine”. Un altro fotografo, dalla stessa piazza nello stesso momento, inquadra largo l’intera piazza pacifica e affollata: la foto racconta “evento di massa riuscito”.

Nessuna delle due foto mente sui pixel che contiene. Le tre persone si spingevano davvero; la piazza era davvero piena e tranquilla. Eppure le due foto raccontano storie opposte.

La differenza non è nei pixel, è nella cornice. E la cornice non è nella scena: la mette il fotografo. La piazza non ha un bordo “vero” oltre il quale smette di essere sé stessa — è il fotografo a decidere dove finisce il fotogramma.

Il confine di un sistema è quella cornice. Tracciare il confine è decidere cosa entra nell’inquadratura dell’analisi.

E qui sta il punto che rende l’errore di confine così insidioso. Un’analisi con la cornice sbagliata non è fatta di numeri falsi: è fatta di numeri veri di una scena che non è quella che ti interessa. Puoi controllare ogni calcolo, ricontrollare ogni dato, e non trovare nulla — perché l’errore non è in nessun calcolo, è nella scelta di cosa calcolare.

C’è anche un’asimmetria che vale la pena notare. Le due foto della piazza si possono confrontare solo se le metti una accanto all’altra. Da sola, ciascuna sembra completa: non c’è nulla, dentro il fotogramma, che segnali cosa è stato lasciato fuori. Lo stesso vale per un’analisi di sistema. Un confine, una volta scelto, non lascia segni del proprio limite dentro i risultati. Bisogna andarlo a cercare apposta.

C’è una conseguenza pratica da estrarre subito. Quando qualcuno ti presenta un’analisi e dice “i numeri parlano chiaro”, la prima domanda non è “i numeri sono giusti?” ma “qual è la cornice?”. Cosa è stato lasciato fuori dall’inquadratura, e perché.

Secondo angolo: il termostato e la stanza

Il secondo angolo prende un sistema piccolo e mostra la meccanica dello spostamento del confine. Vuoi capire perché la temperatura di una stanza oscilla invece di restare ferma sul valore impostato.

Traccia il confine stretto, attorno al solo termostato. Dentro hai il sensore di temperatura, la logica che decide quando accendere, il relè che comanda la caldaia. Fuori — e quindi dato, non spiegato — hai la temperatura della stanza, il calore che esce dal termosifone, la dispersione dalle finestre.

Con questo confine, l’oscillazione della temperatura non la puoi spiegare. La vedi arrivare da fuori, come un disturbo che capita al tuo sistema. Il tuo modello del termostato funziona perfettamente, e ti dice: “il termostato fa il suo lavoro, l’oscillazione è un problema esterno”. È una risposta coerente, e completamente inutile per chi vuole capire l’oscillazione.

Ora allarga il confine. Dentro metti il termostato e il termosifone e l’aria della stanza e la dispersione dalle pareti. All’improvviso l’oscillazione diventa spiegabile dal modello: nasce dal feedback fra la caldaia che scalda, l’inerzia termica della stanza che risponde con ritardo, e il sensore che misura quel ritardo.

La meccanica dell’oscillazione, ora che è dentro il confine, si legge tutta. La caldaia continua a scaldare anche dopo che il setpoint è stato raggiunto, perché il calore già emesso impiega tempo ad arrivare al sensore. Poi si spegne, e la stanza continua a raffreddarsi oltre il setpoint per lo stesso ritardo, in direzione opposta. L’oscillazione è prodotta dentro il sistema: è il sistema che, da solo, oscilla.

Stessa oscillazione, stesso mondo fisico. Con un confine è “rumore esterno inspiegabile”, con l’altro è “comportamento spiegato del sistema”. Non è cambiato niente nella stanza. È cambiato dove hai messo la linea. Questo è il senso operativo della tesi del capitolo: il confine decide quali domande il modello può rispondere. Se il meccanismo che genera il comportamento che ti interessa sta a cavallo della linea — metà dentro, metà fuori — il tuo modello non potrà mai spiegarlo, per quanto sia accurato nei dettagli che contiene.

Conviene mettere i due angoli uno accanto all’altro, perché dicono cose complementari. La cornice del fotografo insegna che il confine è una scelta e che ogni scelta lascia fuori qualcosa: è il lato epistemico, il lato della consapevolezza. Il termostato insegna cosa cambia quando la scelta cambia: certi comportamenti diventano spiegabili e altri no, a seconda di dove cade la linea rispetto ai meccanismi causali. Il primo angolo ti rende sospettoso; il secondo ti dice di cosa, esattamente, essere sospettoso. Messi insieme danno la regola pratica che la prossima sezione formalizza: prima di fidarti di un’analisi, chiediti dove passa il confine e se i meccanismi che generano il fenomeno di interesse stanno tutti dalla parte giusta.

La meccanica

L’intuizione del termostato si formalizza con poco — non servono equazioni, serve una classificazione.

Tracciare un confine significa, concretamente, prendere ogni variabile rilevante per la domanda e assegnarla a una di tre categorie. Il lessico è quello standard della system dynamics, e la classificazione è la versione operativa, scrivibile su carta, di ciò che la cornice del fotografo faceva in modo intuitivo.

Endogeno, esogeno, escluso

Variabile endogena — dentro il confine. Il modello ne spiega la dinamica: il suo andamento nel tempo è prodotto dalle interazioni interne al sistema. La temperatura della stanza, nel modello a confine largo, è endogena: il modello dice perché sale e perché scende.
Variabile esogena — fuori dal confine, ma rilevante. Entra nel modello come input. Il modello la usa ma non la spiega: ne assume il comportamento. La può assumere costante, o come una serie temporale data, o come un valore casuale con una certa distribuzione. La temperatura esterna, in entrambi i modelli del termostato, è tipicamente esogena: la prendi come viene, non modelli il meteo.
Variabile esclusa — fuori dal confine e ignorata del tutto. Il modello assume che il suo effetto sia trascurabile per lo scopo. Il colore delle pareti della stanza, per un modello termico, è di solito una variabile esclusa.

La distinzione fra le tre categorie non è una gerarchia di importanza: una variabile esclusa non è “meno importante”, è semplicemente giudicata irrilevante per quella domanda. Il colore delle pareti è escluso da un modello termico ma sarebbe endogeno in un modello dell’aspetto estetico della stanza. La categoria di una variabile non è una sua proprietà: è una conseguenza del confine, e quindi della domanda.

La parola chiave, nel lessico della system dynamics, è “punto di vista endogeno”. Si dice che un confine “chiuso” — nel senso di causalmente autosufficiente, non nel senso di sistema chiuso che non scambia con l’ambiente, sono due cose diverse e conviene tenerle separate — segnala lo sforzo di mettere dentro il modello tutti i meccanismi causali che generano il comportamento di interesse.

Un modello con un buon confine endogeno riproduce il comportamento da solo, senza dover importare dall’esterno proprio la cosa che dovrebbe spiegare. Se un modello, per produrre l’oscillazione, ha bisogno che gli passi l’oscillazione come input, quel modello non spiega niente: l’ha solo ricopiata.

Da qui la regola operativa, semplice e spesso violata: il confine va scelto abbastanza largo da contenere i feedback loop che generano il comportamento che vuoi spiegare. Se il comportamento nasce da un anello di feedback — come l’oscillazione del termostato — e tu tagli quell’anello a metà con il confine, hai reso il problema strutturalmente non spiegabile dal tuo modello. E non te ne accorgi, perché il modello gira lo stesso, produce numeri, sembra funzionare. È esattamente l’errore silenzioso dell’apertura.

Vale la pena rendere esplicita la conseguenza dello spostare il confine, perché è il gesto centrale del capitolo.

Spostare il confine verso l’esterno promuove variabili da esogene a endogene: cose che prima erano “date come input” diventano “spiegate dal modello”. Spostarlo verso l’interno fa il contrario, degrada variabili da endogene a esogene.

Non è un’operazione neutra di contabilità. Ogni promozione aggiunge al modello la responsabilità — e la possibilità — di spiegare una nuova dinamica; ogni degradazione la toglie. Spostare il confine ridisegna cosa il modello è in grado di fare.

Quando in una discussione qualcuno dice “trattiamo X come un dato”, sta proponendo una posizione del confine. Quando qualcun altro risponde “no, X dipende da cosa facciamo noi, va modellato”, sta proponendo di spostarlo. È utile sentire queste frasi per quello che sono: negoziazioni sul confine, non dettagli tecnici secondari.

Una verifica pratica, da fare prima di fidarsi di un modello, chiude questa parte.

Prendi il comportamento che ti interessa spiegare. Elenca i meccanismi causali che, secondo la tua comprensione, lo producono. Per ciascuno, controlla una cosa sola: è interamente dentro il confine?

Se anche uno solo di quei meccanismi è a cavallo della linea, o del tutto fuori, il modello non potrà spiegare quel comportamento. Al massimo lo riprodurrà importandolo come input, che è un altro modo di dire “non lo spiega”. Questa verifica costa pochi minuti e intercetta l’errore di confine prima che diventi un’analisi su cui qualcuno prende decisioni.

Il confine come scelta di cosa controllare

C’è una seconda lettura del confine, complementare alla prima. Quello che metti dentro il confine tende a essere ciò che il sistema controlla, o di cui si assume di poter governare il comportamento. Quello che metti fuori è ciò che il sistema subisce.

Questa lettura aggancia il confine direttamente al capitolo Osservabilità e controllabilità. Le variabili di controllo — quelle su cui puoi agire — stanno naturalmente dentro il confine; i disturbi — ciò che ti capita e a cui puoi solo reagire — stanno fuori.

Spostare il confine, allora, non è solo una mossa epistemica, una scelta su cosa spiegare. È anche una dichiarazione implicita di leva e di responsabilità: “questo lo governo io, di questo rispondo io; quell’altro è ambiente, lo prendo come viene”.

Tieni a mente questa seconda lettura, perché torna con conseguenze precise quando si parla di responsabilità nei sistemi AI. Dichiarare qualcosa “esogeno” è, di fatto, dichiarare “non è compito mio governarlo”. A volte è vero. A volte è un modo elegante di scaricare un compito che invece sarebbe tuo.

Sistemi annidati e gerarchia di confini

Un sistema vive quasi sempre dentro un sistema più grande. Una cellula sta dentro un organo, l’organo dentro l’organismo, l’organismo dentro l’ecosistema.

Lo scrittore e saggista ungherese-britannico Arthur Koestler conia nel 1967, nel libro The Ghost in the Machine, il termine holon per catturare questa doppia natura. Un holon è qualcosa che è simultaneamente un tutto — visto dai suoi componenti — e una parte — vista dal livello sopra. L’organo è un tutto per le sue cellule e una parte per l’organismo, nello stesso momento, senza contraddizione.

La conseguenza per il confine è netta: non esiste “il” confine di un sistema annidato, esiste una pila di confini, uno per livello. Scegliere a quale livello lavorare è già una decisione di modellazione, presa prima ancora di tracciare il confine a quel livello.

Questo collega il capitolo a Riduzionismo e olismo. Scendere di un livello nella gerarchia — restringere il confine attorno a un componente — è la mossa riduzionista. Salire di un livello — allargare il confine fino a inglobare il sistema in cui il tuo è immerso — è la mossa olistica. La gerarchia di confini è la struttura su cui quelle due strategie si muovono.

Per un sistema AI la pila è concreta e si vede a occhio. C’è il livello del modello; sopra, il livello dell’agente (modello più tool più memoria più harness); sopra ancora, il livello dell’applicazione che usa l’agente; sopra, l’organizzazione che opera l’applicazione; e poi il contesto sociale in cui quell’organizzazione agisce. Ogni livello è un confine candidato. La domanda non è “qual è il confine”, è “a quale livello della pila mi serve lavorare per la domanda che ho”.

Il confine permeabile dei sistemi aperti

Un sistema chiuso non scambia con l’ambiente; un sistema aperto sì — è il tema di Sistemi aperti, chiusi, dissipativi. Per un sistema aperto il confine non è un muro: è una membrana.

Attraverso il confine di un sistema aperto passano materia, energia, informazione. Il confine resta una scelta del modellatore — sei sempre tu a decidere cosa conta come “scambio attraverso il confine” — ma per un sistema aperto il confine è, per definizione, un luogo di flusso e non di separazione netta.

Questo conta moltissimo per gli agenti AI, che sono sistemi radicalmente aperti. Ricevono input da un utente, producono output verso il mondo, chiamano tool che leggono e scrivono stato esterno: un agente è quasi tutto membrana.

Tracciare un confine attorno a un sistema così non significa trovare un muro che non c’è. Significa scegliere quali flussi consideri “interni al sistema” e quali “scambi con l’ambiente”. La chiamata a un tool è un processo interno o uno scambio con l’esterno? Dipende da dove metti il confine — e di nuovo, non c’è una risposta data dalla natura della cosa.

Confine del sistema e confine del modello

Un’ultima distinzione, sottile e facile da perdere. Il confine del sistema è dove decidi che finisce la cosa che studi. Il confine del modello è cosa il tuo modello rappresenta effettivamente, in modo esplicito.

Idealmente i due coincidono. In pratica spesso no. Puoi dichiarare dentro il sistema venti variabili e poi, per tenere il modello trattabile, rappresentarne esplicitamente solo otto, lasciando le altre come approssimazioni o costanti.

Il confine del modello è allora più stretto del confine del sistema dichiarato. La regola generale è che il confine del modello sta sempre dentro, o al massimo coincide con, il confine del sistema dichiarato — vedi anche Modelli descrittivi, predittivi, prescrittivi sul fatto che un modello è sempre una riduzione selettiva del sistema che rappresenta.

Confondere i due fa danni: ti porta a credere che il modello “copra” l’intero sistema, quando ne copre solo una fetta. Quando una previsione fallisce, cerchi l’errore dentro il modello e non lo trovi — perché la causa stava in una variabile che avevi dichiarato dentro il sistema ma mai messa dentro il modello.

Come si sceglie un confine, in pratica

Messi insieme i pezzi, la scelta del confine si riduce a una procedura in quattro mosse. Non è un algoritmo che dà la risposta giusta — la risposta giusta dipende dallo scopo — ma è un modo per non fare la scelta alla cieca.

Primo: dichiara la domanda. Non “studiamo il sistema X”, ma “vogliamo spiegare/prevedere il comportamento Y”. Il confine non si sceglie per un sistema, si sceglie per una domanda. Senza domanda esplicita, ogni confine è difendibile e quindi nessuno lo è.

Secondo: elenca i meccanismi causali che, secondo la tua comprensione, producono Y. Sono i candidati naturali a stare dentro. Se un meccanismo è incerto, mettilo nella lista comunque: è meglio un candidato di troppo che un feedback tagliato.

Terzo: traccia il confine in modo che tutti quei meccanismi cadano dentro, e classifica tutto il resto come esogeno (rilevante ma dato) o escluso (trascurabile). Questa è la mossa che rende il confine “abbastanza largo”.

Quarto: controlla il costo. Se il confine così ottenuto è troppo largo per essere trattabile, non restringerlo a caso: restringilo degradando a esogene le variabili meno legate a Y, e scrivi che lo stai facendo. Un confine ristretto consapevolmente, con la nota “ho escluso Z assumendolo costante”, è un’analisi onesta. Un confine ristretto in silenzio è una trappola per chi leggerà i risultati dopo di te.

L’output di questa procedura non è solo il confine: è il confine più la sua giustificazione. È quella giustificazione, scritta accanto ai numeri, che permette a chiunque di rifare la boundary critique di Ulrich — questionare la scelta — invece di subirla.

Una nota sul costo di tutto questo. La procedura sembra un sovrappiù burocratico, e per un’analisi piccola lo è. Ma il confine è una delle pochissime decisioni che, sbagliata, invalida tutto ciò che viene dopo senza dare segnali. Spendere qualche minuto a dichiararlo è economico rispetto al costo di accorgersi, mesi dopo, che un’intera linea di lavoro rispondeva alla domanda sbagliata.

Esempi

Quattro esempi deliberatamente diversi fra loro: uno con i numeri, uno con la struttura di una valutazione, uno con una catena di responsabilità, uno preso da un laboratorio. Mostrano lo stesso meccanismo — spostare il confine cambia il problema — in contesti che non si somigliano.

La diversità è voluta. Se il meccanismo del confine valesse solo per le fabbriche, o solo per il software, sarebbe un trucco di dominio. Vederlo funzionare identico in quattro domini diversi è il modo migliore per convincersi che è un meccanismo, non un aneddoto.

Esempio 1 — La fabbrica e il fiume: l’esternalizzazione in numeri

Il primo esempio mette i numeri sul tavolo, perché su un confine si può discutere all’infinito in astratto, ma un bilancio che cambia segno è difficile da ignorare.

Una fabbrica produce un bene e, nel processo, scarica solventi in un fiume. Facciamo il bilancio con il confine tracciato attorno all’azienda.

Confine = "azienda"
  ricavi:               100
  costi di produzione:  -70
  ------------------------
  profitto:             +30

Il sistema, visto così, è sano e ben ottimizzato: profitto positivo, processo efficiente. Ora sposta il confine fino a includere la comunità che vive a valle del fiume.

Confine = "azienda + comunità a valle"
  ricavi:               100
  costi di produzione:  -70
  bonifica + sanità:    -45
  ------------------------
  profitto del sistema: -15

Lo stesso identico processo fisico — la stessa fabbrica, gli stessi solventi, lo stesso fiume — passa da “profittevole” a “in perdita” solo perché la linea si è spostata. Niente è cambiato nel mondo: è cambiato cosa è dentro l’inquadratura.

Vale la pena fermarsi su quanto è radicale questo salto. Non è che il profitto si è ridotto un po’: ha cambiato segno. Una decisione presa sul primo bilancio — “espandiamo la produzione, conviene” — e una presa sul secondo — “questo processo va fermato” — sono opposte. E poggiano sugli stessi numeri di base, sullo stesso mondo. L’unica variabile che le separa è dove passa il confine.

Questo è il problema dell’esternalizzazione. Spostare il confine per lasciare fuori un costo non lo elimina: lo nasconde. In economia il termine tecnico è esternalità — un costo, o un beneficio, che ricade su terzi non inclusi nella transazione.

Qui c’è un punto che merita di essere reso esplicito, perché di solito resta implicito. La parola “esternalità” presuppone già un confine. Esterna a cosa? Esterna al confine che qualcuno ha scelto di tracciare. Senza un confine, la parola non significa niente: non c’è un “esterno” se non c’è una linea che lo definisce.

Spostare il confine verso l’interno — escludere la comunità a valle — è il meccanismo con cui un attore razionale, ottimizzando perfettamente dentro il suo confine, produce una perdita per il sistema più grande in cui è immerso. L’errore di confine, qui, non è un incidente: per chi sta dentro il confine stretto è la mossa che conviene. È un punto a cui il capitolo torna nella sezione “Dove si rompe”.

Esempio 2 — Il confine di una valutazione di agente

Il secondo esempio sposta il problema dentro l’AI, e mostra che il confine non è una scelta che si fa dopo: è la prima.

Vuoi valutare un agente di coding: un sistema basato su un LLM che, dato un task descritto in linguaggio naturale, deve produrre una modifica al codice. Prima ancora di scegliere i task e le metriche, devi rispondere a una domanda di confine: cosa, esattamente, stai valutando?

Opzione A — confine = solo il modello
  test:    dato il prompt esatto, il modello produce il diff corretto?
  esogeni: tool, retry, harness, formattazione del contesto
  misura:  capacità grezza del modello

Opzione B — confine = modello + harness + tool + retry
  test:    dato il task, il sistema completo lo risolve?
  esogeni: solo l'utente e il repository
  misura:  capacità del prodotto agentico

Opzione C — confine = modello + harness + utente nel loop
  test:    con un umano che approva e corregge, il task si chiude?
  esogeno: il repository
  misura:  capacità del sistema socio-tecnico

Sono tre valutazioni diverse. Producono tre numeri diversi. Raccontano tre verità diverse — e nessuna delle tre è “la” performance dell’agente. La performance dell’agente, in assoluto, non esiste: esiste la performance del sistema delimitato in un certo modo.

Questo ha una conseguenza pratica concreta e spesso dolorosa. Un benchmark che non dichiara il proprio confine produce numeri non confrontabili. È documentato che lo stesso modello, fatto girare dentro scaffold diversi, ottiene punteggi sensibilmente diversi sullo stesso benchmark: una parte del punteggio misura il modello, una parte misura l’harness, e senza la dichiarazione del confine non sai quale parte stai leggendo.

La ricerca recente sulla valutazione degli agenti ha un nome per la presa di coscienza del problema — scaffold-aware evaluation — e una mossa correttiva. La mossa è trattare esplicitamente lo stack di controllo attorno al modello (l’harness, i tool, la logica di retry) come parte del sistema sotto valutazione, dichiarando dove passa il confine invece di fingere che non ci sia. È la boundary critique di Ulrich applicata, senza saperlo di solito, al problema delle eval.

Esempio 3 — La responsabilità in un sistema RAG

Terzo esempio, una catena di responsabilità — il tipo di situazione in cui il confine smette di essere un’astrazione e diventa una decisione su chi paga.

Un sistema RAG — Retrieval-Augmented Generation: un LLM che, prima di rispondere, recupera documenti da una base di conoscenza esterna e li inserisce nel proprio contesto — produce una risposta sbagliata. La causa: il documento recuperato era una versione obsoleta, superata da un aggiornamento.

Di chi è l’errore? La risposta dipende interamente da dove tracci il confine. E qui sta il punto: non c’è un fatto del mondo che risponda alla domanda. Ci sono tre confini, e tre risposte.

Con il confine stretto attorno al solo modello: il modello ha risposto in modo corretto rispetto al contesto che ha ricevuto. Dato quel documento, quella risposta era ragionevole. Nessun errore del modello.

Con il confine attorno al sistema RAG completo, retriever incluso: il retriever è parte del sistema, e ha recuperato un documento obsoleto. Il sistema ha sbagliato, e l’errore è nel componente di retrieval. Il modello, qui, è solo l’ultimo anello di una catena interna che ha fallito a monte di lui.

Con il confine ancora più largo, fino alla pipeline di indicizzazione: il retriever ha fatto il suo lavoro su un indice che la pipeline non aveva aggiornato. L’errore è a monte di tutto, nel processo che mantiene la base di conoscenza.

La domanda “il retriever è parte del sistema?” non ha una risposta assoluta. È una scelta di confine. E da quella scelta dipende dove vai a cercare il bug, quale team riceve il ticket, e a chi viene attribuita la responsabilità. Tre confini, tre diagnosi, tre responsabili diversi — per un unico errore osservato.

C’è una lezione generale, qui, che vale ben oltre il RAG. Nei sistemi con molti componenti, “di chi è la colpa” non è una domanda a cui i fatti rispondono da soli: è una domanda che si può porre solo dopo aver tracciato un confine. E poiché ogni parte coinvolta ha interesse a tracciare il confine in modo che la colpa cada altrove, il confine di responsabilità va deciso e scritto prima, quando nessuno sa ancora dove cadrà l’errore. Un confine deciso a freddo è un’analisi; un confine deciso dopo l’incidente è una negoziazione.

Esempio 4 — Il confine di un esperimento di laboratorio

Un esempio fuori dall’AI, per mostrare che il problema non è specifico del software. Un team misura l’effetto di un fertilizzante sulla crescita di una coltura. Confine stretto: il sistema è “pianta + fertilizzante + terreno della parcella sperimentale”. Dentro questo confine, il fertilizzante funziona: le piante trattate crescono di più.

Allarga il confine fino a includere il bacino idrico a valle del campo. Il fertilizzante in eccesso dilava nel terreno, raggiunge un lago, alimenta una fioritura di alghe che consuma l’ossigeno e fa morire i pesci. Dentro questo confine più largo, lo stesso fertilizzante ha un effetto netto negativo.

Le due conclusioni — “funziona” e “danneggia” — non si contraddicono: rispondono a due domande diverse, perché poggiano su due confini diversi. L’esperimento col confine stretto non è sbagliato nei dati: le piante sono cresciute.

È sbagliato come base per una decisione che ha effetti oltre la parcella. Questo è lo stesso meccanismo dell’Esempio 1 — l’esternalizzazione — in veste sperimentale: un risultato vero entro un confine, ingannevole come guida all’azione perché la decisione che alimenta agisce su un confine più largo di quello in cui è stata misurata.

La morale dei quattro esempi, presi insieme, è una sola. Fabbrica, eval, RAG, esperimento agricolo non si somigliano in niente — tranne che in questo: in ognuno, spostare la linea non cambia i fatti, cambia quale problema stai risolvendo. È la tesi del capitolo vista quattro volte, da quattro angolazioni che non comunicano fra loro, e che proprio per questo la rendono difficile da liquidare come un caso particolare.

Applicazioni pratiche

Il filo di tutte le applicazioni che seguono è lo stesso: in un sistema AI il confine è quasi sempre ambiguo, quasi mai dichiarato, e la scelta — fatta o subita — cambia tutto ciò che viene dopo. Non è una sezione di esempi aggiuntivi: è il motivo per cui un ingegnere AI ha bisogno proprio di questo capitolo.

Definire cosa è un agente

Il confine dell‘“agente” è genuinamente indeterminato. È il modello? Il modello più i tool? Più la memoria persistente fra le sessioni? Più l’harness che lo fa girare nel loop percezione-azione? Più l’utente che approva le azioni rischiose?

Ogni risposta è legittima per uno scopo, e nessuna è “la” definizione. Il punto operativo è che la scelta non si può evitare. Quando confronti due agenti, quando ne versioni uno, quando dichiari “l’agente ha la capacità X”, stai già usando un confine.

Tanto vale sceglierlo apposta e scriverlo. La distinzione fra dove finisce il modello e dove comincia l’harness — che il capitolo harness-vs-modello (in preparazione) affronta in dettaglio — è essa stessa una scelta di confine, non una verità di fatto da scoprire.

Valutazione

Come nell’Esempio 2: il confine del “sistema sotto valutazione” va dichiarato esplicitamente. Altrimenti i numeri non sono confrontabili, né tra modelli diversi né tra versioni successive dello stesso modello.

Una eval che riporta “84%” senza dire dove passa il confine non sta riportando un dato confrontabile. Sta riportando un numero vero di una scena di cui non hai la cornice. La pratica dello scaffold-aware evaluation è esattamente la disciplina di dichiarare quella cornice.

Sicurezza e sandbox

Qui il confine smette di essere concettuale e diventa un meccanismo eseguibile. Il confine di sicurezza di un agente è il perimetro di ciò che può toccare: quali file può leggere e scrivere, quali comandi può eseguire, se può accedere alla rete e verso dove.

La sandbox è, letteralmente, un confine reso codice. Una allowlist di comandi permessi è un confine. Un permission mode che richiede conferma per le azioni fuori da un certo perimetro è un confine.

In questa applicazione tutto il capitolo diventa concreto in modo immediato. Il confine non è una metafora: è un file di configurazione che decide il blast radius, l’ampiezza del danno possibile se l’agente sbaglia o viene manipolato. Un confine di sicurezza troppo largo è un agente che può fare troppi danni; troppo stretto è un agente che non può fare il suo lavoro. È il trade-off della sezione precedente, ma con conseguenze che si misurano in dati cancellati o segreti esfiltrati. Il capitolo permessi-sandbox (in preparazione) sviluppa questo punto.

Context engineering

La linea fra “cosa è nel contesto del modello” e “cosa è fuori” è una decisione di design, non un dato. Cosa entra nella finestra di contesto — quali documenti, quanta memoria, quali risultati di tool — è la scelta di confine che decide cosa il modello “vede” come parte del proprio mondo.

Un modello non ha accesso a ciò che sta fuori dal suo contesto, esattamente come un modello di sistema non spiega ciò che sta fuori dal suo confine.

Il contesto è il confine del mondo conoscibile dal modello in quel turno. Decidere cosa metterci dentro è tracciare quel confine. Un fatto vero ma fuori dal contesto, per il modello, è come una variabile esclusa per un modello di sistema: semplicemente non esiste.

Responsabilità uomo-macchina

In un sistema con un umano nel loop, il confine fra ciò di cui risponde l’agente e ciò di cui risponde l’umano che lo supervisiona non è ovvio. Se l’agente propone un’azione e l’umano la approva senza leggerla, l’errore conseguente è dell’agente o dell’umano?

La risposta è una scelta di confine. E, come si è visto con l’Esempio 3 del RAG, va fatta prima dell’incidente. Dopo, ogni parte avrà interesse a spostare la linea a proprio favore, e il confine diventerà oggetto di una negoziazione invece che di un’analisi. Un confine di responsabilità scritto a freddo, nella documentazione del sistema, è ciò che distingue un sistema socio-tecnico governabile da uno in cui la colpa è sempre di qualcun altro.

Dove si rompe

Il confine è uno strumento potente, e come ogni strumento potente si presta a essere usato male. Questa sezione raccoglie i modi in cui la scelta del confine fallisce — per errore, per pigrizia o per design.

C’è un filo comune fra tutti i fallimenti che seguono. Nessuno di essi produce un errore visibile nel momento in cui viene commesso. Il confine sbagliato non fa crashare niente: si limita a far rispondere il modello a una domanda diversa. Per questo i fallimenti del confine vanno conosciuti uno per uno e cercati apposta — non si presentano da soli.

L’errore più comune: il confine che taglia un feedback

È l’errore silenzioso dell’apertura, e vale la pena ripeterlo perché è il più frequente di tutti. Se il comportamento che vuoi spiegare nasce da un anello di feedback, e il tuo confine attraversa quell’anello lasciandone metà dentro e metà fuori, il modello non potrà mai spiegare quel comportamento. Lo vedrà come un disturbo che arriva dall’esterno.

Quello che rende questo errore pericoloso è l’assenza di sintomi. Il modello gira, produce numeri coerenti, supera i controlli interni. Non c’è nessun test che fallisce, nessuna formula che non torna.

Il modello fa esattamente ciò che gli hai chiesto: spiega ciò che sta dentro il confine. Il guaio è che la cosa che ti interessava stava a cavallo della linea, e per quella il modello non ha nulla da dire — pur sembrando, in tutto il resto, perfettamente funzionante.

L’unica difesa è metodologica e va applicata prima di costruire il modello, non dopo. Elenca i meccanismi causali del comportamento di interesse e verifica che siano tutti dentro il confine. Feedback e feedforward descrive perché i feedback loop sono proprio i meccanismi che generano i comportamenti dinamici più interessanti — e quindi proprio quelli da non tagliare.

L’esternalizzazione: spostare il confine per nascondere un costo

L’Esempio 1 mostra il caso onesto: un’analisi mal tracciata, un errore in buona fede. Ma lo stesso meccanismo ha una versione interessata. Restringere il confine per lasciare fuori un costo non lo elimina: lo sposta su qualcun altro.

L’inquinamento “fuori dal sistema azienda” inquina lo stesso. Semplicemente compare nel bilancio di qualcun altro: la comunità a valle, l’ambiente, le generazioni future. Il bilancio interno torna, e proprio per questo l’operazione è seducente — sembra che il problema sia stato risolto, mentre è stato solo spostato oltre la linea.

Il punto che il critical systems thinking di Ulrich mette in chiaro è che l’esternalizzazione è raramente un caso. Per l’attore dentro il confine stretto è la mossa che conviene: ottimizzare perfettamente dentro un confine può degradare il sistema più grande, ed è un attore razionale a farlo, non un attore distratto.

Questa è una analogia strutturale — non una filiazione storica — con il problema descritto da goodhart-law (in preparazione): ottimizzare una metrica dentro un perimetro può peggiorare ciò che sta fuori dal perimetro. Le due cose si somigliano nella forma. Non c’è una derivazione dell’una dall’altra, e tenere distinte le due classi conta: è una somiglianza che insegna, non un legame causale documentato.

Il confine troppo largo

Se tagliare i feedback è l’errore del confine troppo stretto, esiste l’errore speculare. Un confine troppo largo gonfia il modello di variabili irrilevanti, moltiplica le interazioni da considerare, e rende l’analisi intrattabile senza aggiungere potere esplicativo.

“Includi tutto, per sicurezza” non è prudenza. È un modo per non finire mai, e per ottenere un modello così carico che nessuno riesce più a capirlo o a fidarsene.

La scelta del confine è un trade-off: abbastanza largo da contenere i meccanismi causali del comportamento di interesse, abbastanza stretto da restare trattabile. Non è una corsa all’inclusione massima.

Ed è un errore comune crederlo, perché “ho considerato anche questo” suona sempre più rigoroso di “ho deciso di escluderlo”. Ma escludere consapevolmente è esattamente ciò che un buon confine fa: include i meccanismi che servono e lascia fuori, dichiarandolo, tutto il resto.

Il confine immobile

Un confine scelto bene per una domanda diventa sbagliato quando la domanda cambia. E i confini hanno una tendenza precisa a fossilizzarsi: una volta tracciati, si dimenticano, e si continuano a usare per domande nuove a cui non erano adatti.

È l’osservazione di Meadows sul confine “nella nostra testa”: il problema non è tracciarlo, è dimenticare di averlo tracciato. Un confine dimenticato non viene più messo in discussione, perché non si vede più come una scelta — si vede come la realtà.

L’esempio AI è immediato. Un’organizzazione che ha sempre valutato i suoi agenti con il confine “solo il modello” continuerà a farlo anche quando il prodotto reale è diventato “modello più harness più memoria più tool”.

I suoi numeri smetteranno silenziosamente di misurare ciò che le interessa, e nessuno se ne accorgerà finché un confine esplicito non verrà rimesso sul tavolo. La difesa, qui, non è scegliere bene una volta: è rimettere periodicamente in discussione la scelta, chiedendosi se il confine di ieri serve ancora la domanda di oggi.

L’osservatore dentro il sistema

C’è un limite più profondo, che il capitolo può solo segnalare. Chi traccia il confine non è neutrale rispetto al confine che traccia.

È il tema della second-order cybernetics di Heinz von Foerster, fisico e cibernetico austriaco-americano che negli anni ‘70 insiste su un punto scomodo: l’osservatore è parte del sistema osservato. Chi sceglie il confine ha interessi, una posizione, dei punti ciechi — e il confine che traccia li riflette.

La fabbrica dell’Esempio 1 ha un interesse evidente a tracciare il confine stretto. Un team che valuta il proprio agente ha un interesse a tracciare il confine dove i numeri vengono migliori. La boundary critique di Ulrich nasce esattamente come risposta a questo: non esiste un confine “oggettivo”, esistono confini scelti da qualcuno per qualche scopo. L’unica difesa non è cercare il confine neutro — non c’è — ma rendere espliciti e discutibili i confini scelti, invece di lasciarli impliciti e indiscutibili.

Il confine come questione etica

Ultimo punto, e il più scomodo. Ulrich insiste che il confine non è solo un fatto tecnico: è anche un “ought”, un dover essere.

Chi resta fuori dal confine — gli affected but not involved, coloro che subiscono gli effetti del sistema senza avere voce nel modo in cui è disegnato — è una scelta morale travestita da scelta tecnica.

La comunità a valle del fiume dell’Esempio 1 è “fuori dal sistema azienda” per una decisione che si presenta come contabile, ma che ha conseguenze sulla salute di persone reali. Tracciare quel confine non è stato un calcolo: è stata una decisione su chi conta e chi no, mascherata da calcolo.

Per un sistema AI la versione è diretta. Gli utenti finali, le persone i cui dati vengono processati, chi subisce una decisione automatizzata senza poterla contestare: sono dentro o fuori il confine del “sistema da valutare”? La domanda non è tecnica. E fingere che lo sia — trattarla come un dettaglio di scoping invece che come un giudizio — è già una risposta, solo non dichiarata.

Quattro fraintendimenti da disinnescare

Oltre ai modi in cui il confine fallisce, ci sono quattro convinzioni diffuse che vale la pena nominare per smontarle, perché ricorrono nelle discussioni di sistema e portano fuori strada.

Il primo: “il confine è una proprietà del sistema”. No — è una scelta dell’analista. Lo stesso oggetto ha confini diversi per domande diverse. Il confine vive nella testa di chi modella, non nel mondo.

Cercare “il confine vero” di un sistema è cercare qualcosa che non esiste. È come chiedere quale sia l’inquadratura “vera” di una piazza: la domanda è mal posta, perché l’inquadratura non è una proprietà della piazza.

Il secondo: “confine del sistema e confine del modello sono la stessa cosa”. No — il modello rappresenta tipicamente un sottoinsieme di ciò che hai dichiarato dentro il sistema. Confonderli fa credere che il modello copra più di quanto copra, e manda a cercare i bug nel posto sbagliato.

Il terzo: “esiste il confine giusto”. No — esiste il confine adatto allo scopo. È sbagliato un confine che lascia fuori i meccanismi causali del comportamento da spiegare, o che taglia un feedback a metà. Ma “giusto” e “sbagliato”, qui, sono relativi alla domanda, non assoluti.

Il quarto: “confine più largo, analisi migliore”. No — un confine troppo largo gonfia il modello e lo rende intrattabile. Allargare non è una virtù di per sé.

La virtù è far cadere dentro il confine esattamente i meccanismi che servono, e niente di più. Un confine ben tracciato non è il più ampio possibile: è il più piccolo che contiene ancora tutto ciò che genera il fenomeno di interesse.

Collegamenti

Sistema, ambiente, confine, stato — ha introdotto il confine come un dato di fatto, per poter partire. Questo capitolo rovescia quella semplificazione: il confine è una scelta.
Sistemi aperti, chiusi, dissipativi — il confine permeabile dei sistemi aperti, dove la linea è una membrana di flusso e non un muro. Gli agenti AI sono sistemi radicalmente aperti.
Osservabilità e controllabilità — il confine come scelta di cosa il sistema controlla (dentro) e cosa subisce (fuori): variabili di controllo contro disturbi.
Feedback vs feedforward — i feedback loop sono i meccanismi che generano i comportamenti dinamici; un confine che ne taglia uno a metà rende quel comportamento inspiegabile.
Modelli descrittivi, predittivi, prescrittivi — la distinzione fra confine del sistema e confine del modello: il modello è sempre una riduzione selettiva di ciò che hai dichiarato dentro il sistema.
Riduzionismo e olismo — la gerarchia di confini è la struttura su cui si muovono le due strategie: restringere il confine è ridurre, allargarlo è la mossa olistica.
ponte-sistemi-ai (in preparazione) — il capitolo che chiude la Parte generalizza: perché tutto il vocabolario dei sistemi, confine incluso, serve a chi progetta deployment di agenti.
harness-vs-modello (in preparazione) — “dove finisce il modello e comincia l’harness” è, letteralmente, una scelta di confine: il capitolo della Parte sull’Harness Engineering la affronta in dettaglio.
permessi-sandbox (in preparazione) — il confine di sicurezza di un agente reso eseguibile: allowlist, sandbox, permission modes come confine in forma di codice.
goodhart-law (in preparazione) — ottimizzare una metrica dentro un confine può degradare il sistema fuori dal confine: stessa forma strutturale dell’esternalizzazione (analogia, non filiazione).

Per andare oltre

Ludwig von Bertalanffy, General System Theory (George Braziller, 1968) — il testo fondativo. La definizione del confine come parte del sistema che lo separa dall’ambiente, e la distinzione sistema aperto/chiuso, vengono da qui.
Donella Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008) — il pensiero sistemico spiegato in modo accessibile. Il capitolo sui confini è il riferimento più diretto per la tesi “il confine più ingannevole è quello nella nostra testa”.
Werner Ulrich, “A Mini-Primer of Boundary Critique” (wulrich.com) — esposizione breve e diretta, dall’autore stesso, dei boundary judgments e della boundary critique. Per chi vuole l’apparato completo: Critical Heuristics of Social Planning (1983).
“Boundary Concepts in System Dynamics”, Proceedings of the System Dynamics Society (2014) — trattazione tecnica della classificazione endogeno / esogeno / escluso e del confine come decisione di modellazione.
“Holistic Agent Leaderboard”, arXiv:2510.11977 (2025) — sul perché lo scaffold attorno a un LLM va trattato come parte del sistema sotto valutazione: la versione AI-nativa del problema del confine.