Blog

Nossas últimas novidades

Tempo de Leitura

min

Tool calling (function calling): como integrar LLM a sistemas com segurança e auditoria

Guia de tool calling: como funciona, quando usar, como desenhar ferramentas com schema rígido, autorização no backend, logs e checklist para reduzir riscos como agência excessiva.

27 de fevereiro de 2026

A diferença entre “IA útil” e “IA perigosa” geralmente é: quem valida a ação.
Tool calling só é bom quando a aplicação mantém o controle.

Tool calling (também chamado de function calling) é o padrão onde o modelo não “executa” nada sozinho. Ele pede para a aplicação executar uma ferramenta (API, busca, cálculo, consulta) e devolve um payload estruturado (geralmente JSON). A aplicação valida, executa, retorna o resultado e o modelo finaliza a resposta.

Em outras palavras: o LLM vira um orquestrador, e o seu backend continua sendo a fonte de verdade.

O que você vai encontrar aqui

Como tool calling funciona (fluxo básico)
Quando usar (e quando não usar)
Como desenhar ferramentas que não viram uma superfície de ataque
Segurança e auditoria: autorização, validação e logs
Checklist final para colocar em produção

O fluxo básico (sem mistério)

O fluxo típico é este (com variações por fornecedor):

sua aplicação chama o modelo e descreve quais ferramentas existem
o modelo responde com uma “tool call” (nome + parâmetros)
sua aplicação executa a ferramenta (código real)
sua aplicação devolve o resultado para o modelo
o modelo responde ao usuário (ou faz novas tool calls)

Esse padrão aparece em documentações como a da OpenAI e de outros provedores, justamente porque separa “texto gerado” de “ação real”.

Quando tool calling é a escolha certa

Use tool calling quando você precisa:

consultar dados atualizados (estoque, status, dados internos)
executar cálculos ou regras determinísticas
chamar APIs externas (mapas, pagamentos, CRM, ERP)
transformar texto em estruturas (extrair campos com JSON, por exemplo)
criar automações com rastreabilidade

Evite tool calling quando:

a tarefa é só redação/sumário sem dependência de dados externos
o risco de ação é alto e você ainda não tem governança (melhor começar com read‑only)
você quer “um assistente que faz tudo” (isso tende a virar agência excessiva)

A regra de ouro: ferramenta boa é ferramenta pequena

Uma ferramenta com escopo muito amplo (“executar qualquer comando”, “rodar qualquer query”, “enviar qualquer e-mail”) cria risco desnecessário.

Padrões que ajudam:

ferramentas específicas (ex.: buscar_pedido, listar_produtos, gerar_relatorio_pdf)
parâmetros com tipos e enums
limites (paginação, tamanho máximo, janelas de data)
resultados enxutos (só o necessário para responder)

Exemplo conceitual de schema (simplificado):

{
  "name": "buscar_status_pedido",
  "description": "Retorna status e eventos do pedido do usuário autenticado",
  "parameters": {
    "type": "object",
    "properties": {
      "pedido_id": { "type": "string" }
    },
    "required": ["pedido_id"],
    "additionalProperties": false
  }
}

Repare no “usuário autenticado”: a autorização não pode depender do modelo.

Segurança: onde a maioria erra

1) Autorização é no backend (“complete mediation”)

Mesmo que o modelo “pareça obedecer”, a autorização deve acontecer na API.

O modelo não decide se pode acessar dados.
O modelo não decide se pode executar uma ação.
O backend aplica regra por usuário, papel, tenant e contexto.

Isso também melhora auditoria e compliance.

2) Validação de entrada (não confie no JSON do modelo)

Mesmo com schema, trate como input não confiável:

valide tipos, ranges, enums
recuse campos inesperados (additionalProperties: false)
aplique limites (ex.: limit <= 50)
normalize strings e datas

3) Idempotência e confirmação humana para ações críticas

Se a ferramenta executa algo irreversível (cancelar, deletar, publicar), boas práticas:

exigir confirmação explícita do usuário (human‑in‑the‑loop)
usar chaves de idempotência (para não repetir sem querer)
registrar trilha de auditoria (quem pediu, quando, o que foi feito)

Isso conversa com riscos como “agência excessiva” (um LLM fazendo coisas demais com autonomia demais).

4) Logs e observabilidade

Para operar com confiança, logue:

ferramenta chamada + parâmetros (com redaction de PII)
tempo de execução e erros
origem (qual conversa, qual usuário)
resultado resumido (IDs, não dados sensíveis)

Se você ainda não estruturou isso, vale ler: LLMOps: métricas, logs e evals.

Como tool calling se conecta com RAG e segurança

Tool calling e RAG são complementares:

RAG ajuda a responder “o que é / como funciona” com base em documentos
tools ajudam a responder “qual é o status / qual é o dado atual” com fonte de verdade

Atenções: