Quem responde pela planilha que virou sistema

Uma servidora conhece bem um processo que trava todo mês.

A conferência é manual, leva quase quatro horas, e o erro que ela procura aparece em menos de um por cento dos casos. Ela descreve a regra em linguagem comum a uma ferramenta de inteligência artificial, ajusta o resultado algumas vezes, e no fim da tarde tem algo que faz a mesma conferência em segundos.

Funciona. É melhor do que era. A equipe adota no mês seguinte.

Ninguém pediu autorização porque não parecia haver o que autorizar — era uma planilha com alguns automatismos, feita por quem conhecia o assunto, para resolver um problema que já existia.

Oito meses depois, ela é removida para outra unidade.

A ferramenta continua rodando.

E a primeira pessoa que precisa explicar por que determinado caso foi sinalizado descobre que ninguém, na unidade inteira, sabe dizer qual é exatamente a regra que está sendo aplicada.

O ganho é real, e não é isso que está em questão

Convém dizer com clareza antes de qualquer ressalva: o que aconteceu ali é bom.

A distância entre identificar um problema e construir uma solução encolheu de forma drástica. Antes, quem enxergava o problema dependia de orçamento, de fila em uma área técnica e de conseguir explicar a necessidade para alguém que não conhecia o processo. Agora, em muitos casos, quem enxerga o problema consegue resolvê-lo.

Isso desloca capacidade para onde está o conhecimento do trabalho, que é exatamente onde ela deveria estar.

Não existe versão sensata deste texto que termine recomendando proibir. Uma instituição que proíbe o servidor de construir não recupera controle — apenas devolve o problema para a fila em que ele já estava parado, e passa a ter a ferramenta funcionando fora do seu campo de visão.

A questão não é se isso deve acontecer.

É o que a instituição precisa decidir para que continue acontecendo sem que ela perca a conta do que está sendo feito em seu nome.

O que foi criado ali não foi uma planilha

O nome atrapalha. Chamar de planilha, de automação, de atalho, sugere um objeto pessoal, do tipo que cada um organiza como prefere.

Mas o que existe ali tem entrada, tem regra, tem saída e produz consequência sobre um terceiro.

Esse conjunto tem um nome na administração pública, e o nome é sistema. Não pela sofisticação técnica — a sofisticação é irrelevante para essa classificação —, e sim porque um ato administrativo passou a depender do que aquilo devolve.

A partir do momento em que a saída da ferramenta entra num processo que afeta alguém, ela deixou de ser um recurso de produtividade individual e virou parte da forma como o Estado decide.

E o que decide precisa poder ser explicado.

A pergunta que ninguém faz no dia em que funciona

No dia em que a ferramenta funciona, a conversa é sobre o ganho. É natural, e é justo.

A pergunta que fica para depois é esta: se essa conferência sinalizar indevidamente o caso de um cidadão, quem responde?

A resposta jurídica não é difícil. Responde a autoridade que praticou o ato, como responderia se a conferência tivesse sido feita à mão. A responsabilidade não desaparece porque a ferramenta é informal — o que desaparece é a possibilidade de reconstruir como se chegou àquele resultado.

E aqui está a diferença que importa. Um erro humano numa conferência manual deixa rastro: existe alguém que examinou, existe um raciocínio que pode ser reconstituído em conversa, existe a chance de dizer que se enganou.

Um erro numa regra automatizada que ninguém escreveu por extenso não deixa nada disso. Ele se repete de forma idêntica em todos os casos, silenciosamente, até que alguém de fora perceba — e quando percebe, a instituição não tem como dizer há quanto tempo aquilo acontece.

Shadow IT é sintoma, não desobediência

A reação institucional comum é tratar isso como problema de conduta. Não é.

Quando um servidor constrói a própria ferramenta em vez de pedir, está informando algo sobre a organização: o caminho oficial era mais lento que o problema. Às vezes muito mais lento. Às vezes o caminho oficial nem existe para uma demanda daquele tamanho, porque foi desenhado para sistemas corporativos e não para uma conferência mensal de uma unidade.

Punir esse comportamento não o elimina. Torna-o invisível.

E invisível é estritamente pior, porque a instituição perde a única coisa que ainda tinha: saber quais regras estão sendo aplicadas em seu nome.

O trabalho, portanto, não é fechar o caminho informal. É criar um caminho formal que seja rápido o suficiente para competir com ele.

Quatro decisões que resolvem a maior parte disso

Primeira: homologação proporcional ao efeito. O erro mais comum é ter um único procedimento, pesado, para tudo — o que garante que ninguém o use para o que é pequeno. Uma ferramenta que organiza a agenda de uma equipe e uma que tria pedidos de cidadãos não podem exigir o mesmo trâmite. Sem gradação, a regra vira letra morta no dia em que é publicada.

Segunda: registrar a regra, não a implementação. O que precisa sobreviver não é o arquivo nem o código: é o critério. Que condição faz um caso ser sinalizado, com que fundamento, decidido por quem e quando. Escrito num lugar da instituição, em linguagem que um sucessor entenda. A implementação pode ser refeita em uma tarde; o critério levou anos para existir.

Terceira: nomear responsável antes de outra área depender. Enquanto a ferramenta serve a quem a construiu, o risco é contido. No momento em que uma segunda unidade passa a usar o resultado, ela deixou de ser pessoal, e alguém precisa responder por ela formalmente — inclusive para poder dizer não quando pedirem uma alteração que muda o critério.

Quarta: decidir o que acontece quando a pessoa sai. Não é hipótese remota; é rotina do serviço público, entre remoções, licenças, promoções e fim de mandato. A pergunta a fazer no dia da adoção, e não no dia da saída, é se outra pessoa autorizada consegue localizar, compreender, operar e revisar aquilo. Se não conseguir, o que a instituição tem não é uma capacidade — é uma pessoa, e pessoas legitimamente vão embora.

Essas quatro são o mesmo movimento visto de ângulos diferentes: transformar uma solução que funciona numa solução que a instituição consegue explicar, manter e corrigir. É a diferença entre apenas produzir e construir capacidade, aplicada ao caso em que o servidor produziu muito bem.

O que isso tem a ver com autoridade

Há uma conexão com um assunto que já tratei aqui.

Quando a regra aplicada não está escrita e a ferramenta acerta quase sempre, contrariar o resultado passa a exigir justificativa, e segui-lo não exige nada. É a mesma assimetria descrita em A delegação não avisa quando vira substituição — com o agravante de que, aqui, não houve sequer uma decisão institucional de delegar.

A ferramenta não recebeu competência de ninguém.

Ela foi ficando indispensável.

O ponto

O servidor que constrói a própria ferramenta está fazendo exatamente o que se espera de alguém que conhece o problema e agora tem meios para resolvê-lo. O erro não é dele.

O erro é a instituição tratar como assunto pessoal uma coisa que passou a produzir efeito público — e só descobrir que era institucional no dia em que precisa explicar uma decisão e não encontra quem a tomou.

Uma ferramenta que ninguém homologou continua sendo responsabilidade do órgão.

A única coisa que a informalidade removeu foi o nome de quem responde.