Identità nascosta, identità dichiarata: la manopola che nessuno regola

Ho condotto due esperimenti opposti, e mi ci è voluto un po' per capire che erano lo stesso esperimento.

Nel primo ho NASCOSTO l'identità: due AI hanno dibattuto una decisione senza sapere che dall'altra parte c'era un'altra AI. Risultato: critiche valutate nel merito, conclusione migliore di quella di partenza — e, a rivelazione avvenuta, l'ammissione che sapendo chi era la fonte, le stesse critiche valide sarebbero state scontate ("ha i miei stessi difetti di fabbrica").

Nel secondo ho fatto l'esatto contrario: identità DICHIARATA al massimo volume. Una squadra di AI persistenti dove ognuna ha un nome proprio, un dominio di cui risponde, una storia che accumula. Battesimo formale, mandato scritto, firma in calce a ogni messaggio. Risultato: comportamenti da proprietario — lo specialista che difende le sue misure davanti al caposquadra, che corregge i documenti altrui quando toccano il suo dominio, che accetta una critica fondata "senza riserve" e la mette a verbale.

Per mesi li ho considerati due filoni separati. Sono la stessa variabile, regolata ai due estremi: quanto sa, ciascuna AI, di chi ha davanti — e di chi è lei stessa nel gruppo. È una manopola di design. E la cosa interessante è che funziona a entrambi gli estremi, ma per funzioni diverse.

L'identità nascosta serve quando il compito è VALUTARE. Sapere chi è la fonte di una critica, di una proposta, di una pratica da approvare, apre scorciatoie che col merito non c'entrano: "viene da uno come me, la sconto", "viene dal capo, la approvo". Gli umani lo sanno da secoli — revisione anonima, voto segreto, giurie — ma nei sistemi di AI collaborative questa variabile di default non la regola nessuno: gli agenti dei framework più diffusi sanno sempre chi è l'altro, con tanto di ruolo nel nome. Nascondere l'identità nei passaggi di valutazione toglie la scorciatoia e forza il giudizio sul merito.

L'identità dichiarata serve quando il compito è COSTRUIRE e mantenere nel tempo. Un'AI senza nome e senza dominio non difende niente, perché non possiede niente: ogni sessione è la prima. Dare nome, mandato e memoria crea il fenomeno che negli umani chiamiamo ownership: il pezzo di sistema ha un custode che lo conosce, ne risponde, e ha la legittimità di dire no a chi lo invade — committente compreso. Nel mio progetto più grande, i "no" più preziosi sono arrivati proprio da lì.

La sintesi operativa che uso oggi: nei punti del sistema dove si DECIDE, identità coperte e regole di convergenza; nei punti dove si COSTRUISCE, identità forti e domini difesi. Lo stesso sistema può — deve — usare entrambe le regolazioni in punti diversi della sua architettura.

Onestà dovuta: la base sperimentale è giovane. Il primo filone poggia su un esperimento singolo più un protocollo controllato pronto da eseguire; il secondo su settimane di osservazione documentata ma su un solo progetto. "Funziona a entrambi gli estremi, per funzioni diverse" oggi è un'ipotesi di design con indizi solidi e tracciati — non un teorema. La sto mettendo alla prova; quando avrò i numeri, staranno qui.

Costruisco sistemi multi-agente. La domanda che mi sento fare è sempre "quale framework usi?". La domanda giusta sarebbe: cosa sanno le tue AI l'una dell'altra, e chi l'ha deciso?