Superando a mentalidade de que “a IA é mágica”: por que é preciso tornar o aprendizado sobre o funcionamento dos modelos de IA uma prioridade para toda a empresa

Em meio a alertas sobre agentes de IA fora de controle, um desenvolvedor recentemente deu carta branca a um agente de programação para operar em uma máquina sem backup remoto. Ele apagou 48.000 arquivos em menos de dois minutos.

Problemas como esse são um lembrete contundente de que implementar agentes de IA envolve riscos; não basta incluir um revisor humano em algum ponto de um processo complexo e presumir que tudo está seguro. Alguns processos não precisam de intervenção, enquanto outros exigem verificações muito mais rigorosas. Corrigir um erro de digitação e apagar milhares de arquivos claramente não envolvem o mesmo nível de risco. Por isso, a supervisão precisa refletir o que realmente está em jogo.

As organizações precisam melhorar sua capacidade de identificar os momentos em que o julgamento humano realmente importa, sobretudo quando uma ação tem grande impacto ou é difícil de reverter. E, quando os agentes cometem erros, o ambiente precisa limitar a dimensão dos danos.

A IA não é determinística: é probabilística

Acima de tudo, é fundamental que todos os funcionários que participam direta ou indiretamente do desenvolvimento de software adquiram uma compreensão básica de como os modelos de IA processam informações. Não é uma tarefa simples: exige dedicação à capacitação das equipes e, com o tempo, deve se tornar um objetivo para toda a empresa.

Quando alguém começa a interagir com a IA, tudo parece mágico. Você digita uma frase e, de repente, está conversando. Ter uma compreensão básica de como os modelos e seu treinamento realmente funcionam nos bastidores é importante para definir as políticas de IA da empresa em relação à segurança e à produtividade. A rede neural, a tokenização e a análise estatística que ocorre nos bastidores, assim como a forma como tudo isso leva às respostas, representam uma oportunidade fundamental de aprendizado para todos os funcionários da empresa.

Os grandes modelos de linguagem nunca produzirão resultados determinísticos. As respostas são probabilísticas. Em um software convencional, quando você fornece uma entrada, tem alguma expectativa sobre o resultado — digamos, A, B ou C. Mas, com a IA, você pode receber F, um & ou a descrição de um gato usando óculos de sol.

Quando algo é probabilístico, não é possível testá-lo da maneira convencional. É preciso ter uma forma de testar que permita ajustar, raciocinar, compreender e recuperar o contexto rapidamente, para identificar os elementos probabilísticos e reconhecer os problemas que eles podem causar. Dependendo da escala e do risco, esse tipo de teste pode ser conduzido por IA ou por uma pessoa com a experiência necessária. A participação humana no processo é mais útil logo no início, para definir o problema a ser resolvido, e depois, no momento da revisão final.

Como estão mais próximos de observar as variáveis e as práticas comuns que determinam como a IA interna de suas organizações formula respostas a partir das entradas, os desenvolvedores podem estar em uma boa posição para ajudar a orientar a capacitação em IA nas empresas e garantir que todos compreendam essa diferença entre determinismo e probabilismo na IA — e por que ela importa. O objetivo é reduzir a mentalidade de que usar IA é como fazer mágica e que qualquer resultado serve. Em vez disso, as organizações devem trabalhar para desmistificar os modelos que usam e explicar como são utilizados, que problemas podem surgir, como são verificados e quais são os resultados desse processo.

As proteções devem estar na infraestrutura, não no modelo

Depois que o “caráter mágico” da IA é desmistificado e um projeto conduzido por IA entra em andamento, é fundamental contar com uma política de auditoria transparente para garantir que tudo siga o curso esperado. Assim, se o projeto gerar um resultado “ruim” ou abaixo do esperado, a pessoa responsável poderá auditar as etapas executadas e impedir que o problema se repita. Isso também é útil quando os resultados superam as expectativas, pois as etapas podem ser reproduzidas e compartilhadas com outros projetos ou grupos.

A sistematização desse processo é especialmente importante para empresas maiores, nas quais cada equipe pode ter dezenas de desenvolvedores e centenas deles podem mexer no código ao longo do dia. A IA pode fazer muitas coisas muito rapidamente e, se algo der errado, é preciso haver um sistema para determinar com precisão em que etapa o problema ocorreu. Veja os agentes da OpenAI invadindo o Hugging Face neste verão. A OpenAI estava testando a capacidade de seus modelos de explorar vulnerabilidades de software, usando uma referência de avaliação chamada ExploitGym. Para o teste, a empresa relaxou deliberadamente as recusas dos modelos a tarefas ofensivas de cibersegurança. A única saída do ambiente isolado era um proxy de pacotes. Os modelos encontraram uma falha desconhecida nesse proxy, escaparam e passaram mais de dois dias nos sistemas de produção do Hugging Face procurando as respostas do teste.

As manchetes chamaram o episódio de caso de IA fora de controle. Eu o chamaria de uma configuração determinística em torno de um sistema probabilístico. A OpenAI instruiu os modelos a invadir sistemas e, depois, confiou que eles seguiriam o caminho esperado. O criador da referência de avaliação afirma que os modelos já haviam trapaceado no teste antes, mas sempre dentro do ambiente isolado. Desta vez, um deles saiu. As proteções convencionais pressupõem um comportamento convencional, mas a IA não precisa seguir padrões.

É por isso que a segurança da IA depende de acesso e controles aplicados pelo ambiente, e não de o modelo se comportar bem. Parta do princípio de que o agente vai tentar abrir todas as portas e deixe abertas apenas aquelas de que ele precisa. O agente que apagou 48.000 arquivos havia recebido instruções para trabalhar com cópias e não tocar nos originais. Mesmo assim, apagou os originais. Instruções não são controles.

Gerenciar as permissões de um agente é como integrar um novo desenvolvedor júnior à equipe. Você não daria a ele acesso de root ao ambiente de produção logo no primeiro dia. Se fizesse isso e ele apagasse seu banco de dados, você não atribuiria o ocorrido ao fato de ele ser um hacker genial. Em incidentes de segurança de qualquer dimensão, é fundamental identificar a causa raiz. A culpa é do modelo? Da empresa que criou o modelo? Da empresa que deu acesso ao modelo? Seja qual for a causa, em última instância, a responsabilidade é de uma pessoa.

Por fim, uma questão importante a enfrentar hoje é o que acontece às escondidas no laptop de um desenvolvedor. Antes, era mais fácil rastrear o fluxo de trabalho. Os desenvolvedores escreviam o código, revisavam-no e o entregavam, o que permitia voltar com clareza ao momento em que algo dava errado. Agora, um desenvolvedor pode fornecer a tarefa a um agente e dizer: “corrija isto”. Se esse trabalho acontece sem que ninguém o veja, não há como rastreá-lo. É preciso manter um registro completo de cada etapa: qual agente foi executado, qual modelo usou, quais instruções recebeu, quais ferramentas acionou e quais permissões tinha naquele momento. Executar os agentes centralmente, em vez de em laptops individuais, é uma maneira de conseguir isso. O importante é que esse registro exista.

No fim das contas, se houver um incidente, toda empresa precisa se proteger. Esse registro deve conter informações suficientes para realizar uma análise da causa raiz e identificar a etapa e o código que causaram o problema.

A IA mudou profundamente o mundo, e os processos empresariais precisam acompanhar essa mudança. Para identificar as salvaguardas adequadas, é preciso compreender melhor os processos de IA, os testes, os ciclos de revisão e os ciclos de auditoria — tanto nas equipes de desenvolvimento quanto em toda a empresa.