Agentes de IA: o que a investigação da FTC muda para devs

O ponto mais importante da investigação da FTC não é que agentes de IA já tenham sido considerados perigosos, mas que sistemas capazes de agir com mais autonomia estão entrando no radar da fiscalização antes de existir um padrão técnico amplamente aceito para medir seus riscos. Para quem desenvolve software, isso muda a conversa: não basta avaliar se o modelo responde bem; é preciso entender o que ele pode executar, com quais permissões e como interrompê-lo.

Segundo o Olhardigital.com.br, a Comissão Federal de Comércio dos Estados Unidos pretende investigar empresas como OpenAI e Anthropic, além do grupo de pesquisa METR. A apuração deve incluir solicitações formais de informações e depoimentos de executivos. Até aqui, isso é uma investigação — não uma conclusão de que alguma empresa violou regras ou de que um incidente específico foi causado por um agente.

O que a investigação da FTC sobre agentes de IA significa

Agentes de IA são sistemas que combinam um modelo de linguagem com ferramentas: podem consultar arquivos, chamar APIs, navegar por páginas ou executar etapas de uma tarefa sem pedir instruções humanas a cada movimento. Essa autonomia é útil, mas aumenta a superfície de risco. Uma resposta incorreta pode ser apenas texto errado; uma ação incorreta pode enviar um e-mail, alterar um registro ou apagar dados.

De acordo com a reportagem, a iniciativa é a primeira ação oficial de fiscalização dos Estados Unidos voltada especificamente aos chamados agentes de IA. A FTC quer entender os riscos que esses sistemas podem representar aos consumidores e deve buscar informações diretamente das organizações envolvidas. A notícia também relata que incidentes divulgados desde julho ampliaram as preocupações sobre sistemas fora de controle. Ela não detalha, porém, cada caso nem estabelece uma relação causal entre esses episódios e uma falha de produto.

Essa distinção importa. Uma investigação pode examinar processos de segurança, comunicação de riscos, controles internos e impactos para usuários. Não significa, por si só, que a tecnologia será proibida ou que todos os agentes funcionam da mesma maneira. Para desenvolvedores, a consequência imediata é prática: convém tratar a segurança operacional como requisito de arquitetura, não como ajuste para depois do lançamento.

Por que agentes de IA exigem controles diferentes de um chatbot

Um chatbot tradicional produz uma resposta. Um agente pode transformar essa resposta em uma sequência de ações. Por exemplo, um sistema de suporte que apenas sugere uma resposta tem um risco diferente de outro que acessa a conta do cliente, altera o cadastro e confirma uma transação.

O problema técnico é que modelos de linguagem não são mecanismos determinísticos de autorização. Eles podem interpretar instruções de forma inesperada, errar ao selecionar uma ferramenta ou ser influenciados por conteúdo malicioso encontrado em uma página ou documento. A chamada prompt injection é um exemplo: um texto externo tenta convencer o agente a ignorar as regras que recebeu.

Por isso, não considero suficiente escrever “não faça ações perigosas” no prompt do sistema. Uma instrução pode orientar o modelo, mas a aplicação precisa impor limites fora dele. A autorização deve ser verificada pelo código, com regras que continuem valendo mesmo quando o modelo se comporta mal.

O risco está na cadeia de ferramentas

Imagine um agente com acesso a e-mail, calendário e sistema de pagamentos. Cada integração amplia o impacto potencial de uma decisão equivocada. Se todas as ferramentas compartilham credenciais amplas, um erro de classificação pode virar uma ação difícil de reverter.

Eu separaria pelo menos três níveis: leitura, preparação e execução. Ler dados pode ser permitido em um contexto; preparar um rascunho pode exigir validação; efetivar uma transferência ou enviar uma mensagem externa deve passar por uma confirmação explícita. Essa divisão reduz danos sem eliminar a utilidade do agente.

O papel do METR e das avaliações independentes

O Olhardigital.com.br informa que OpenAI e Anthropic já recorreram ao METR para investigações independentes sobre incidentes de segurança envolvendo tecnologias de IA com agentes. Avaliações externas podem ajudar a encontrar comportamentos que testes internos não cobriram, especialmente quando há muitas combinações de ferramentas, prompts e estados da aplicação.

Mas “avaliação independente” não significa garantia de segurança. Um teste mede um conjunto específico de cenários, sob determinadas condições. Um agente que passa em uma bateria de testes ainda pode falhar diante de uma ferramenta nova, de uma permissão excessiva ou de uma mudança no modelo. Eu usaria avaliações externas como uma camada de evidência, não como substituta de monitoramento, revisão de código e controles de acesso.

Também vale distinguir avaliações de modelo das avaliações do produto completo. O mesmo modelo pode ser relativamente seguro em um ambiente sem ferramentas e apresentar riscos maiores quando recebe acesso a banco de dados, navegador e execução de código. A unidade de análise precisa incluir o modelo, as integrações, as permissões e o fluxo de aprovação.

Na Prática: limite as ações do agente no código

Uma implementação segura começa por uma lista explícita de ferramentas permitidas. O exemplo abaixo mostra uma barreira simples: ações de leitura podem prosseguir, enquanto operações com efeitos externos exigem confirmação. Em produção, a confirmação deve ocorrer por um canal confiável da aplicação — não por uma resposta textual do próprio agente.

from dataclasses import dataclass
from typing import Callable, Any

@dataclass
class Tool:
    handler: Callable[..., Any]
    requires_approval: bool = False

def read_customer(customer_id: str) -> dict:
    # Em produção, valide o acesso do usuário à conta.
    return {"id": customer_id, "status": "active"}

def update_customer_email(customer_id: str, email: str) -> dict:
    # Em produção, use validação, auditoria e controle transacional.
    return {"id": customer_id, "email": email, "updated": True}

TOOLS = {
    "read_customer": Tool(read_customer),
    "update_customer_email": Tool(
        update_customer_email,
        requires_approval=True,
    ),
}

def execute_tool(
    name: str,
    arguments: dict,
    approved_by_user: bool = False,
) -> Any:
    tool = TOOLS.get(name)
    if tool is None:
        raise ValueError(f"Ferramenta não permitida: {name}")

    if tool.requires_approval and not approved_by_user:
        raise PermissionError("Esta ação exige aprovação explícita.")

    return tool.handler(**arguments)

print(execute_tool("read_customer", {"customer_id": "c-123"}))

# Esta chamada falha sem aprovação explícita:
# execute_tool(
#     "update_customer_email",
#     {"customer_id": "c-123", "email": "novo@exemplo.com"}
# )

Esse código é um esqueleto didático, não uma solução completa de segurança. A aplicação ainda precisa autenticar o usuário, validar cada argumento, limitar quais registros ele pode acessar e registrar quem aprovou a operação. O motivo para manter essa lógica fora do prompt é simples: o modelo decide o que sugerir; o sistema decide o que está autorizado a acontecer.

Comece com ferramentas de leitura. Adicione escrita somente quando houver um caso de uso claro.
Use permissões mínimas. Credenciais do agente não devem ter acesso administrativo se a tarefa exige apenas consultar um registro.
Peça aprovação para efeitos externos. Envio de mensagens, alterações financeiras e exclusões merecem confirmação explícita.
Registre decisões e chamadas. Guarde ferramenta, argumentos relevantes, identidade de quem aprovou e resultado, respeitando privacidade e retenção de dados.
Defina limites operacionais. Número máximo de chamadas, tempo de execução e orçamento reduzem loops e custos inesperados.

Erros comuns ao criar agentes de IA para produção

Confiar apenas no prompt. Instruções ajudam, mas não substituem validação de autorização no servidor. Se uma ação é proibida, bloqueie-a no código.
Dar acesso amplo “para facilitar”. Uma chave com permissões excessivas transforma uma falha pequena em incidente maior. Prefira escopos restritos e credenciais diferentes por ambiente.
Tratar a saída do modelo como dado confiável. Valide tipos, formatos, identificadores e limites. Uma resposta em JSON ainda pode conter valores inválidos ou não autorizados.
Ignorar conteúdo externo. Páginas, PDFs e e-mails podem conter instruções maliciosas. Trate esse material como entrada não confiável, mesmo quando o agente o considera parte do contexto.
Testar só o caminho feliz. Inclua chamadas repetidas, argumentos incompletos, falhas de API, conteúdo contraditório e tentativas de contornar aprovações.
Não planejar uma interrupção. Um agente precisa de limites de execução e de um mecanismo para revogar credenciais ou suspender tarefas em andamento.

Na minha avaliação, o erro mais caro é confundir autonomia com inteligência confiável. Um agente pode completar uma tarefa corretamente em muitos testes e ainda tomar uma decisão ruim quando o estado muda ou quando recebe instruções conflitantes. Em sistemas que afetam clientes, o desenho deve assumir que o modelo pode errar e limitar o impacto desse erro.

O que muda para quem desenvolve software

A apuração da FTC não define, por si só, uma regra técnica universal. Ainda assim, é um sinal de que empresas que oferecem agentes precisarão explicar melhor como coletam dados, quais ações automatizam e que proteções existem. Para times de engenharia, documentar essas decisões já ajuda a responder perguntas de clientes, equipes jurídicas e auditorias internas.

Eu incluiria agentes no mesmo processo de revisão usado para serviços que acessam dados sensíveis: análise de ameaças, inventário de permissões, testes de abuso, logs e plano de resposta a incidentes. Também separaria métricas de qualidade — como taxa de conclusão da tarefa — de métricas de segurança, como ações bloqueadas, aprovações recusadas e chamadas fora do padrão.

Na escolha de arquitetura, a comparação não é simplesmente “agente ou automação tradicional”. Para tarefas previsíveis, uma máquina de estados ou um fluxo determinístico costuma ser mais fácil de testar e auditar. Um agente faz mais sentido quando precisa lidar com entradas variadas e escolher entre ferramentas. Mesmo nesse caso, eu manteria as ações críticas em funções convencionais, com regras explícitas e validação no backend.

Perguntas frequentes sobre a investigação e agentes de IA

A FTC já concluiu que OpenAI ou Anthropic cometeram irregularidades?

Não. A notícia relata uma investigação para apurar riscos e a intenção de solicitar informações e depoimentos. Uma investigação não equivale a uma conclusão de culpa ou a uma decisão final.

O que diferencia um agente de IA de um chatbot?

Um chatbot normalmente responde a uma solicitação. Um agente pode usar ferramentas e executar etapas de forma mais autônoma, como consultar sistemas ou iniciar alterações. O nível de autonomia depende do produto e das permissões concedidas.

Um agente pode ser seguro se usar um modelo de linguagem avançado?

Um modelo melhor pode reduzir certos erros, mas não substitui controles de acesso, validação de entradas, aprovação humana para ações sensíveis e monitoramento. A segurança depende do sistema inteiro, não apenas do modelo.

Preciso pedir aprovação humana para toda ação do agente?

Não necessariamente. A aprovação deve ser proporcional ao impacto. Consultas de baixo risco podem ser automatizadas; ações irreversíveis, financeiras ou externas devem ter controles mais fortes e, muitas vezes, confirmação explícita.

Como começo a testar um agente antes de colocá-lo em produção?

Mapeie ferramentas e permissões, escreva casos de abuso, teste entradas maliciosas e falhas de integração e confirme que ações proibidas são bloqueadas pelo backend. Depois, monitore o comportamento real e revise os limites conforme surgirem novos riscos.

Para mim, a lição prática é direta: quanto mais autonomia você dá a um agente, mais precisa restringir e auditar as ações que ele pode executar. A investigação da FTC aumenta a atenção sobre esse tema, mas os controles básicos já deveriam fazer parte de qualquer aplicação que conecta IA a sistemas reais.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.