Ideia principal

Numa organização muito especializada, quem podia agir sobre um domínio era também quem era dono dele: o desenvolvedor escrevia o código e respondia por ele, o designer desenhava a interface e respondia por ela. Capacidade de ação e responsabilidade se sobrepunham, de modo que raramente era preciso dizer quem responde por quê.

Quando uma IA permite que um comercial construa uma ferramenta interna, que um Product Manager altere uma interface ou que um desenvolvedor decida um comportamento de produto, a capacidade de agir circula entre os ofícios. A responsabilidade, essa, não circula junto: o comercial que constrói a ferramenta não se torna responsável pela segurança da plataforma, o PM que mexe na interface não se torna guardião do design system. Poder agir e responder pelo domínio, que andavam juntos, se separam.

Por que isso importa

Isso explica por que o embaralhamento dos ofícios não elimina os papéis, mas obriga a deixar as responsabilidades explícitas: a sobreposição já não as protegia, agora é preciso nomeá-las. E dá um teste simples diante de uma contribuição vinda de fora: a pergunta deixa de ser "quem tem o direito de mexer em quê?" e passa a ser "a partir de que nível de risco ou de novidade a garantia do domínio precisa retomar o controle?".

Nuances e limites

A sobreposição nunca foi perfeita: mesmo num funcionamento muito especializado, havia responsabilidades flutuando entre os ofícios. A IA não cria a separação, ela a torna visível e frequente. E deixar as responsabilidades explícitas não basta: se toda contribuição precisa ser validada pelo domínio envolvido, recriamos as antigas passagens obrigatórias com outro nome.

Questões em aberto

• Que nível de risco ou de novidade fixar para que um domínio retome o controle, sem que esse limite se transforme em validação sistemática?