Shadow IT não escala para dentro de uma empresa regulada

Qualquer pessoa da sua equipa consegue hoje construir uma automação útil numa tarde. Um script lê uma caixa de correio, chama um modelo, deixa um resumo num ticket. A demonstração é linda. Corre num portátil. Durante algum tempo, até ajuda.

Só que existe um abismo entre essa automação e um agente que a organização opera de facto, e o abismo não é sobre a qualidade do modelo. É sobre tudo aquilo que a demonstração nunca teve de tratar: identidade, privilégio mínimo, drift, auditoria, e o simples facto de a coisa atuar agora sobre dados que não gerou.

A maioria das equipas lê mal esta distância, como se fosse um problema de prompt. Assume que um prompt melhor, um modelo maior ou uma cadeia mais engenhosa transformam o script de portátil em algo que a empresa consegue defender. Não transformam. A distância entre uma automação de portátil e um agente em produção é de arquitetura, não de prompting. As peças em falta são estruturais, e nenhuma dose de engenharia de prompts as faz aparecer.

Uma regra determinística e um agente probabilístico são sistemas diferentes

Veja a diferença em concreto.

Uma regra determinística de validação de faturas passa ou falha, e falha sempre da mesma maneira. Consegue testá-la uma vez e confiar no teste. Toda a sua governação de TI assenta nesse pressuposto: uma build testada continua testada, as entregas passam por controlo de alterações, e o mesmo input produz o mesmo output.

Um agente que valida um dossiê de crédito quebra os três pressupostos. Lê documentos que nunca viu, raciocina sobre eles de forma probabilística, e pode chegar amanhã a outra conclusão porque o modelo subjacente foi atualizado durante a noite. Nada no seu processo de controlo de alterações foi desenhado para reparar que o sistema mudou sem que tenha entregue nada.

É esta a primeira coisa a admitir com honestidade. Uma automação de portátil pode ser genuinamente útil e completamente irresponsabilizável ao mesmo tempo. Essas duas propriedades não estão em tensão na máquina de alguém. Tornam-se irreconciliáveis no momento em que a coisa toca em trabalho regulado.

Três viragens definem o abismo

O abismo não é um muro. São três, e cada um é onde um piloto bem-intencionado morre em silêncio.

De código de confiança a input controlado pelo adversário. O software tradicional processa dados que os seus sistemas produziram. Um agente lê conteúdo que não escreveu: um email de cliente, um contrato digitalizado, um PDF de um terceiro. Esse conteúdo não é de confiança. Se um documento envenenado contiver texto que se lê como uma instrução, e o agente o tratar como tal, o documento acabou de sequestrar um sistema com acesso às suas plataformas centrais. É a prompt injection indireta, e a configuração sozinha não a trava. O script de portátil nunca teve de se preocupar. O agente em produção não se pode dar ao luxo de não se preocupar.

De entregas estáticas a drift contínuo. O seu processo de entregas assume que a mudança é um evento que se agenda. Uma atualização de modelo é uma mudança que não agendou e não entregou. O comportamento do agente move-se debaixo dos seus pés. Um sistema que se portou bem na demonstração do mês passado pode degradar-se em silêncio este mês, e sem monitorização de drift fica a saber por um cliente, não por um painel.

Da stack de um fornecedor à stack do seu regulador. Num portátil, quem desenvolve escolhe o modelo que for mais conveniente. Numa empresa regulada, que modelos pode usar, e onde correm, é definido pelo seu regime regulatório e pela sua própria homologação de segurança. A conveniência não é um input admissível nessa decisão.

Cada viragem corresponde a uma peça de arquitetura que a demonstração nunca teve. A automação passou na demonstração precisamente porque nenhuma das três estava em âmbito. A versão empresarial não escala porque as três estão.

A identidade é onde o modelo do portátil parte primeiro

Das três viragens, a identidade é a que trava projetos no comité de segurança, por isso vale a pena ser preciso.

A automação de portátil corre sob o token pessoal de quem a fez, com acesso permanente a produção. É eficiente e é também a constatação que acaba com o projeto. Um token de programador roubado é uma chave-mestra. Nada nele é delimitado, de curta duração, nem registado ao detalhe que um processo regulado exige.

A postura de produção é o oposto. Cada agente corre sob a sua identidade não humana, com credenciais de curta duração e privilégio mínimo e uma allow-list de saída explícita. Ao agente são concedidas algumas capacidades com nome, read_dossier, request_document, post_decision_for_review, e mais nada. Uma credencial de agente roubada passa então a não valer quase nada, porque não há segredo estático para roubar e a identidade só consegue executar o punhado de ações para que foi delimitada, para o punhado de destinos que pode alcançar.

Repare no que isto muda para quem tem de aprovar. "O agente pode tocar nos nossos sistemas" não é auditável nem aprovável. "O agente pode executar estas sete ações com nome, cada uma registada" é um controlo que um comité consegue assinar. Essa tradução, de uma capacidade vaga para um conjunto de ações nomeadas e testáveis, é quase tudo o que transformar shadow IT num ativo empresarial significa na prática.

Transformar uma ferramenta num ativo que a empresa consegue defender

Nada disto é um argumento contra as pessoas construírem automações. Essas experiências são a forma de as boas ideias aparecerem, e devem continuar a acontecer. O argumento é contra fingir que uma experiência é um sistema de produção por funcionar numa demonstração.

Transformar uma automação de portátil em algo que a organização opera significa dar-lhe três coisas que nunca teve: uma identidade, uma fronteira à volta do que lê, e um registo do que decidiu e porquê. Acrescente monitorização de drift para que uma atualização silenciosa de modelo não a degrade sem se dar por isso. Acrescente uma camada de política para que as decisões com consequência fiquem com uma pessoa. Não é burocracia em cima de uma ferramenta que funciona. É a diferença entre uma ferramenta e um ativo que a empresa consegue defender perante um regulador.

As organizações presas no cemitério dos pilotos quase sempre passaram na demonstração e depois bateram num destes muros. Projeta-se que cerca de 40% dos projetos de IA agêntica sejam cancelados até 2027 (Thoughtworks), e a maior parte dessa falha é arquitetural, não técnica. Escalaram o portátil, não a arquitetura, e as duas coisas não são a mesma.

O reenquadramento que vale a pena levar à próxima revisão de arquitetura é este. Não "como tornamos a nossa automação mais exata?", mas o que é que a nossa organização tem de construir para que isto possa atuar aqui em segurança, sob uma identidade, sobre dados que não controlamos, com um registo que conseguimos inspecionar? Responda a isso e atravessou o abismo. Salte-o, e fica com uma demonstração muito boa que nunca sairá do portátil.

Se quiser pôr à prova onde é que uma das suas automações se situa nesse abismo, marque uma reunião e traga-nos a mais difícil.