Operating Notes

O que uma IA precisa antes de você deixá-la operar

Um modelo pode ser brilhante e ainda assim não ser seguro para operar. Dez coisas que uma IA precisa antes de receber as chaves, tiradas do desenho de sistemas operacionais e de observar agentes trabalhando dentro de uma operação financeira real.

ONCHAIN FX editorial visual

Na nota passada escrevi sobre a diferença entre um banco de dados e um sistema operacional. Um banco de dados diz o que está armazenado. Um sistema operacional diz o que está acontecendo agora, o que mudou e o que precisa de atenção em seguida.

Aquela nota era sobre a empresa. Esta é sobre a própria IA.

Porque no momento em que você deixa um modelo fazer mais do que responder perguntas, uma segunda pergunta aparece imediatamente. Não "ele é inteligente o suficiente." Algo mais estreito e bem menos confortável.

É seguro deixar essa coisa agir.

Essas não são a mesma pergunta. Eu descobri isso do jeito lento.

Inteligência nunca foi o gargalo

No meu primeiro ano usando IA a sério dentro do negócio, o modelo raramente era o problema. Ele conseguia ler um contrato, resumir uma conversa, redigir uma resposta, encontrar uma inconsistência entre dois documentos mais rápido do que eu.

O problema apareceu quando pedi para ele fazer algo em vez de dizer algo.

Um modelo que redige um email é um redator. Um modelo que envia o email, atualiza um registro ou movimenta dinheiro é um operador. Esses dois papéis exigem coisas diferentes do sistema ao redor do modelo, não do modelo em si.

Comecei a manter uma lista do que um operador realmente precisa. Não o que torna um modelo mais inteligente. O que o torna seguro para operar.

Identidade e autoridade

A primeira coisa que um sistema operacional pergunta para qualquer coisa rodando dentro dele é quem é você e o que você tem permissão para fazer. Todo processo recebe uma identidade. Toda identidade carrega um conjunto de permissões. Nada roda como root por padrão, e o que roda como root é o que todo mundo observa com mais cuidado.

A maioria das implantações de IA pula essa etapa por completo. O modelo é o modelo. Ele tem uma identidade só, geralmente a identidade de quem estiver segurando a chave de API naquele dia. O acesso é concedido como uma unidade só, tudo ou nada.

Isso não sobrevive ao contato com um negócio real. Um agente que consegue ler o histórico de um cliente não deveria automaticamente ser o mesmo agente que aprova um reembolso. Um agente que redige um memorando de compliance não deveria automaticamente ser o agente que o protocola. A identidade precisa ser granular o suficiente para que a autoridade também seja.

Estado atual, e de quem é o significado que vale

A nota passada descreveu um ciclo: evento, estado, decisão, ação, recibo, novo evento. Uma IA operando dentro desse ciclo precisa saber onde o estado realmente está agora, não o que consegue reconstruir a partir das últimas mensagens numa janela de chat.

Isso soa óbvio até você ver falhar. Um modelo com um prompt longo e bem preparado, sem acesso ao estado atual, vai responder com confiança total uma pergunta sobre a conta de um cliente usando uma informação que era verdadeira duas semanas atrás. Ele não vai te avisar disso. Ele não tem como saber que está errado.

Existe uma segunda camada por baixo dessa, e ela importa mais do que parece. Mesmo com acesso ao estado atual, algo precisa decidir o que as palavras dentro desse estado realmente significam. "Fechado" é um ticket fechado ou uma conta fechada. "Pendente" quer dizer esperando por nós ou esperando pelo outro lado. Um humano resolve essa ambiguidade por instinto, geralmente sem perceber que fez isso. Um modelo precisa que esse significado esteja explícito em algum lugar, ou ele vai chutar, e vai chutar com confiança total.

Eu chamo isso de autoridade semântica. Alguém, ou alguma coisa, precisa ser dono do que cada termo significa em toda a operação, ou cada agente inventa o próprio dialeto, e nenhum deles pode ser confiado em conjunto com o outro.

Ferramentas, e a distância entre falar e fazer

Um modelo sem ferramentas só consegue falar. Dê a ele uma ferramenta e ele passa a agir, o que parece um upgrade até você notar o que realmente mudou. Ele não ficou mais capaz de julgamento. Ficou mais capaz de consequência.

Todo sistema operacional de verdade traça uma linha dura ao redor do que um processo pode tocar. Permissões de sistema de arquivos. Chamadas de sistema que exigem modo privilegiado. Um kernel que faz a mediação de cada requisição em vez de confiar que o processo vai se comportar. Nada disso existe porque os engenheiros desconfiam do próprio código. Existe porque o custo de um erro sem mediação é alto demais para ser deixado à boa vontade.

As ferramentas que um agente recebe deveriam ser delimitadas da mesma forma. Acesso de leitura não é acesso de escrita. Acesso para rascunho não é acesso para envio. Uma ferramenta que consulta um saldo é uma ferramenta diferente de uma que o movimenta, mesmo quando o mesmo modelo chama as duas.

Memória e permissão precisam andar juntas

Memória sem permissão é um passivo. Um agente que lembra de tudo o que já viu, em qualquer contexto, eventualmente vai fazer algo aparecer num lugar em que não deveria. Uma conversa de suporte não deveria vazar para uma conversa de vendas só porque o mesmo modelo atendeu as duas.

Permissão sem memória é quase inútil. Um agente que começa toda sessão do zero não consegue aprender o que já falhou, o que já foi tentado, o que um cliente já explicou duas vezes. Ele vai fazer a mesma pergunta pela terceira vez, e a pessoa do outro lado vai perder a paciência com a ideia inteira de IA, com razão.

As duas coisas precisam ser desenhadas juntas. O que um agente lembra, e para quem ele tem permissão de lembrar, é uma única decisão de desenho, não duas decisões tomadas por dois times em dois momentos diferentes.

Evidência é a ação

Eu disse isso na nota passada e aqui é ainda mais verdadeiro. Um modelo produzir uma resposta não é a mesma coisa que a empresa tomar uma ação. O recibo é o que fecha essa distância.

Toda ação real que um agente toma deveria deixar um rastro que um humano consiga ler sem precisar confiar na própria versão do agente sobre o que ele fez. Uma requisição. Um horário. Uma identidade. Um antes e um depois. Se um agente não consegue produzir esse rastro, ele não deveria ter tido permissão para agir, independente de quão confiante o resultado pareceu.

Eu não trato isso como uma exigência de compliance que estou tolerando. É o único mecanismo que encontrei que me permite ampliar a autoridade de um agente ao longo do tempo sem ampliar a minha própria ansiedade na mesma proporção.

Rollback é uma funcionalidade, não um conserto

Sistemas operacionais partem do princípio de que as coisas vão dar errado. Transações podem ser revertidas. Deploys podem ser desfeitos. Uma escrita ruim não precisa virar um fato permanente só porque aconteceu.

A maioria das primeiras tentativas de dar autoridade real a uma IA ignora isso por completo, porque a demonstração nunca falha. A produção sempre acaba falhando. Um agente que consegue agir mas não pode ser desfeito não é um operador. É uma porta sem volta, e portas sem volta deveriam exigir a mão de um humano em cima, sempre.

A pergunta que faço antes de conceder qualquer capacidade nova a um agente hoje é simples. Se isso der errado, como a gente desfaz, e em quanto tempo. Se a resposta honesta for "não dá," a capacidade ainda não está pronta, não importa quão bom seja o modelo.

Portões humanos não são falta de confiança no modelo

Essa é a parte que mais me surpreendeu. Adicionar portões humanos não deixou o sistema mais lento como eu esperava no início. Isso me deixou confortável para expandir o sistema mais rápido, porque a fronteira do que podia dar errado deixou de ser o negócio inteiro e passou a ser uma decisão de cada vez.

Evidência não é aprovação. Um teste limpo não é uma decisão de negócio. Um agente recomendar uma ação, mesmo corretamente, não é a mesma coisa que essa ação estar autorizada. A linha entre o que uma máquina pode preparar e o que uma pessoa precisa aprovar não é uma limitação da IA. É o que torna possível dar à IA mais espaço no mês seguinte do que ela tem hoje.

O que mudaria minha opinião

Não acho que essa lista esteja completa, e ficaria surpreso se ela mantivesse exatamente esse formato daqui a um ano. Se eu encontrasse uma forma de tornar identidade, evidência e rollback baratos o suficiente para deixarem de exigir desenho deliberado, boa parte dessa nota se tornaria desnecessária, e eu ficaria feliz com isso.

O que eu não estou afirmando é que qualquer coisa disso torna uma IA confiável por conta própria. Não torna. Isso torna o ambiente ao redor da IA confiável o suficiente para que os erros da IA fiquem pequenos, visíveis e reversíveis. Essa é uma régua mais baixa do que "o modelo está certo." Também é, até agora, a única régua que encontrei que sobrevive ao contato com uma operação real.