Idea principale

In un'organizzazione molto specializzata, chi poteva agire su un ambito era anche chi aveva quell'ambito di competenza: lo sviluppatore scriveva il codice e ne rispondeva, il designer disegnava l'interfaccia e ne rispondeva. Capacità d'azione e responsabilità si sovrapponevano, per cui raramente serviva dire chi risponde di cosa.

Quando un'IA permette a un commerciale di costruire uno strumento interno, a un Product Manager di modificare un'interfaccia o a uno sviluppatore di decidere un comportamento di prodotto, la capacità d'azione circola tra i mestieri. La responsabilità, invece, non circola con lei: il commerciale che costruisce lo strumento non diventa responsabile della sicurezza della piattaforma, il PM che tocca l'interfaccia non diventa garante del sistema di design. Poter agire e rispondere dell'ambito, che andavano insieme, si separano.

Perché è importante

Spiega perché la confusione dei mestieri non elimina i ruoli ma obbliga a rendere esplicite le responsabilità: la sovrapposizione non le proteggeva più, ora vanno nominate. E offre un test semplice davanti a un contributo venuto da altrove: la domanda non è più «chi ha il diritto di toccare cosa?» ma «a partire da quale livello di rischio o di novità la garanzia dell'ambito deve riprendere in mano la situazione?».

Sfumature e limiti

La sovrapposizione non è mai stata perfetta: anche in un funzionamento molto specializzato, alcune responsabilità restavano sospese tra i mestieri. L'IA non crea la separazione, la rende visibile e frequente. E rendere esplicite le responsabilità non basta: se ogni contributo deve essere validato dall'ambito interessato, si ricreano i vecchi passaggi obbligati sotto un altro nome.

Domande aperte

• Quale livello di rischio o di novità conviene fissare perché un ambito riprenda in mano la situazione, senza che quella soglia si trasformi in validazione sistematica?