Saídas estruturadas e function calling na API

Última revisão factual: junho de 2026.

Saídas estruturadas com chamada de função no ChatGPT ajudam a transformar uma conversa em dados previsíveis para sistemas reais. Texto livre é ótimo para conversar, mas é frágil para software: o backend precisa de chaves esperadas, IDs, enums, validação e comportamento testável.

Neste guia, a palavra “ChatGPT” aparece porque é assim que muitas pessoas pesquisam o tema. Na prática, porém, esse tipo de integração normalmente acontece via OpenAI API, Playground, Responses API, Chat Completions ou integrações próprias. A interface comum do ChatGPT não executa automaticamente funções do seu backend.

Observação: GPTs personalizados dentro do ChatGPT podem usar Actions ou Apps para se conectar a APIs externas quando isso é configurado no produto. Isso é diferente do Function Calling na OpenAI API, onde o desenvolvedor controla o backend, a validação, os logs e a execução real da função.

A ideia central é simples: Structured Outputs controlam o formato dos dados, enquanto Function Calling, também chamado de Tool Calling, permite que o modelo solicite o uso de ferramentas definidas pela sua aplicação. O modelo não executa a função sozinho; ele gera uma chamada com nome e arguments, e o seu backend decide o que fazer.

O que são saídas estruturadas?

Saídas estruturadas são respostas do modelo que seguem um formato definido previamente, geralmente por meio de um JSON Schema. Em vez de pedir apenas “responda em JSON”, você descreve quais campos devem existir, quais tipos são aceitos, quais valores são permitidos e se propriedades extras devem ser bloqueadas.

Isso é útil porque aplicações reais não trabalham bem com respostas imprevisíveis. Um CRM não quer interpretar uma frase solta como “acho que esse lead está quente”. Ele precisa de algo como:

{
  "lead_score": "alto",
  "motivo": "Usuário pediu orçamento e informou urgência",
  "proxima_acao": "enviar_proposta"
}

A diferença entre uma saída estruturada e um prompt informal é o nível de contrato. Quando você usa Structured Outputs, o modelo recebe um schema que funciona como uma interface entre a IA e o software. Isso facilita parsing, validação, integração, testes automatizados e automações em produção.

Na prática, saídas estruturadas ajudam quando você precisa extrair dados de mensagens, classificar tickets, gerar payloads para APIs, preencher objetos internos, criar respostas consistentes para frontends ou acionar ferramentas com argumentos previsíveis.

O que é chamada de função no ChatGPT/OpenAI API?

Chamada de função, ou Function Calling, é o mecanismo que permite ao modelo solicitar o uso de uma função ou ferramenta definida pela sua aplicação. Em versões e documentações mais recentes, o termo Tool Calling também é comum, porque uma função é um tipo de ferramenta.

O ponto mais importante é: o modelo não executa sua função diretamente. Ele não acessa seu banco de dados, ERP, CRM ou gateway de pagamento por conta própria. O que ele faz é gerar uma solicitação de tool call com:

o nome da função que deve ser usada;
os arguments em JSON;
um identificador da chamada, dependendo da API usada;
eventualmente uma resposta final depois que o backend devolve o resultado da ferramenta.

O fluxo típico é:

usuário → modelo → tool call → backend valida → backend executa → resultado volta ao modelo → resposta final

Isso significa que sua aplicação continua responsável por autenticação, autorização, validação no backend, logs, regras de negócio e segurança. O modelo pode sugerir a chamada, mas quem executa é o seu código.

Structured Outputs, Function Calling, JSON mode e prompt “responda em JSON”

Esses termos aparecem juntos, mas não significam a mesma coisa. A tabela abaixo resume a diferença prática.

Recurso	Objetivo	Saída típica	Quando usar	Risco principal	Precisa de backend?
Structured Outputs	Fazer a resposta seguir um JSON Schema.	JSON aderente ao schema definido.	Extração de dados, classificação, payloads previsíveis e respostas estruturadas.	Achar que formato correto significa dado comercialmente correto.	Nem sempre, mas é recomendado validar.
Function Calling / Tool Calling	Permitir que o modelo solicite o uso de ferramentas do sistema.	`tool_calls`, `function_call` ou chamada equivalente com nome e `arguments`.	Consulta de pedidos, CRM, ERP, e-commerce, automações, ações no backend e APIs internas.	Executar uma ação sem validação, autenticação ou permissão adequada.	Sim. A função real é executada pela aplicação.
JSON mode	Forçar a saída a ser JSON válido.	JSON parseável, mas não necessariamente aderente a um schema.	Casos simples em que JSON válido já resolve.	Confundir JSON válido com JSON correto para o seu contrato.	Depende do caso.
Prompt “responda em JSON”	Tentar obter JSON apenas por instrução textual.	JSON possivelmente correto, mas sem garantia forte.	Protótipos, testes rápidos e tarefas não críticas.	Falhas de formato, campos extras, campos ausentes e inconsistência.	Não obrigatoriamente, mas não é ideal para produção.

Quando usar Structured Outputs via Function Calling vs response_format/text.format?

A regra prática é direta:

Use Function Calling quando o modelo precisa se conectar a ferramentas, APIs, banco de dados, CRM, ERP, e-commerce, WhatsApp, atendimento ao cliente ou fluxos operacionais.
Use response_format ou text.format quando você quer apenas que a resposta final do modelo venha em JSON estruturado.

Em Chat Completions, você encontrará o uso de response_format para respostas estruturadas. Na Responses API, é comum ver o conceito via text.format. Já quando o assunto é ferramenta, a integração passa por tools, tool calls, function_call ou estruturas equivalentes, dependendo da API e do SDK.

Exemplo: se o usuário pede “classifique essa mensagem como suporte, financeiro ou vendas”, talvez você precise apenas de uma saída estruturada. Mas se ele pede “qual é o status do meu pedido?”, o modelo provavelmente precisa chamar uma função que consulta seu sistema de pedidos. Nesse caso, Function Calling faz mais sentido.

Saídas estruturadas com chamada de função no ChatGPT: exemplo simples com JSON Schema e strict:true

Imagine uma loja virtual brasileira que atende clientes pelo WhatsApp. O usuário pergunta: “Onde está meu pedido 123?”. O modelo precisa identificar que deve chamar uma função do backend chamada consultar_status_pedido.

Um schema simplificado poderia ser assim:

Nota técnica: o exemplo abaixo usa o formato de tools da Responses API. Em Chat Completions, a mesma função normalmente aparece dentro de um objeto function, como {"type":"function","function":{...}}.

{
  "tools": [
    {
      "type": "function",
      "name": "consultar_status_pedido",
      "description": "Consulta o status de um pedido no sistema interno da loja. Use apenas quando o usuário pedir informações sobre entrega, rastreio ou situação de um pedido existente.",
      "strict": true,
      "parameters": {
        "type": "object",
        "properties": {
          "pedido_id": {
            "type": "string",
            "description": "Identificador do pedido informado pelo usuário. Exemplo: 123, BR-9981 ou PED-2026-445."
          },
          "origem": {
            "type": "string",
            "description": "Canal onde a solicitação foi recebida.",
            "enum": ["site", "whatsapp", "app", "marketplace"]
          },
          "incluir_historico": {
            "type": "boolean",
            "description": "Define se o backend deve retornar eventos históricos do pedido além do status atual."
          },
          "observacao": {
            "type": ["string", "null"],
            "description": "Observação adicional do usuário, quando existir. Use null quando não houver observação."
          }
        },
        "required": [
          "pedido_id",
          "origem",
          "incluir_historico",
          "observacao"
        ],
        "additionalProperties": false
      }
    }
  ]
}

O que cada parte faz?

type: "function" indica que a ferramenta é uma função chamável pelo modelo.
name deve ser específico e previsível. Evite nomes genéricos como executar ou processar.
description ajuda o modelo a decidir quando usar a função.
strict: true reforça a aderência ao schema.
parameters descreve o objeto de entrada esperado.
properties lista os campos aceitos.
enum limita valores possíveis, reduzindo variações desnecessárias.
required define campos obrigatórios no contrato.
additionalProperties: false evita campos inesperados.
type: ["string", "null"] permite simular um campo opcional em ambientes que exigem todos os campos em required.

Esse schema não substitui o backend. Ele melhora o contrato entre o modelo e a aplicação, mas você ainda deve validar o pedido, checar se o usuário tem permissão e garantir que a resposta do ERP ou sistema de e-commerce seja tratada com segurança.

Exemplo de fluxo completo em um e-commerce brasileiro

Agora vamos transformar o exemplo em um fluxo realista.

1. Usuário envia a mensagem

Onde está meu pedido 123?

2. O modelo gera uma tool call

O modelo identifica que a pergunta depende de dados externos e solicita a função consultar_status_pedido.

Para simplificar a leitura, o exemplo abaixo mostra arguments como objeto. Em respostas reais da API, os argumentos podem aparecer como uma string JSON que o backend precisa converter com JSON.parse, json.loads ou equivalente antes de validar e executar.

{
  "type": "function_call",
  "name": "consultar_status_pedido",
  "arguments": {
    "pedido_id": "123",
    "origem": "whatsapp",
    "incluir_historico": false,
    "observacao": null
  }
}

3. O backend valida antes de executar

Antes de consultar o pedido, o backend deve:

validar se os arguments seguem o schema esperado;
verificar se o usuário está autenticado;
confirmar se o pedido 123 pertence ao usuário;
bloquear campos extras ou valores inesperados;
registrar logs da chamada;
aplicar rate limit quando necessário.

4. O backend consulta o sistema interno

Depois da validação, a aplicação consulta o ERP, plataforma de e-commerce ou sistema logístico.

{
  "pedido_id": "123",
  "status": "em_transporte",
  "transportadora": "Exemplo Logística",
  "previsao_entrega": "2026-06-12",
  "codigo_rastreio": "BR123456789"
}

5. O resultado volta ao modelo

O backend envia o resultado da ferramenta de volta para o modelo. Só então o modelo redige uma resposta amigável:

Seu pedido 123 está em transporte pela Exemplo Logística. A previsão de entrega é 12/06/2026. O código de rastreio é BR123456789.

Esse desenho separa bem as responsabilidades: o modelo entende a intenção e estrutura a chamada; o backend valida, executa e controla segurança; o usuário recebe uma resposta clara.

Regras importantes do schema para Function Calling

Um bom JSON Schema é mais do que uma lista de campos. Ele é parte da arquitetura da sua aplicação. Se o schema for vago, o modelo terá mais espaço para gerar chamadas ambíguas.

Use nomes de funções específicos

Prefira consultar_status_pedido, criar_ticket_suporte ou qualificar_lead_crm em vez de nomes genéricos como buscar, executar_acao ou processar_usuario.

Escreva descriptions claras

A descrição deve explicar quando usar a função, quais dados ela espera e, quando necessário, quando não deve ser usada. Isso reduz chamadas indevidas.

Use enum quando possível

Campos como status, canal, categoria e prioridade geralmente devem usar enum. Isso evita variações como “alta”, “urgente”, “muito urgente” e “prioridade máxima” quando seu sistema só aceita baixa, media e alta.

Defina required corretamente

Em schemas estritos, trate todos os campos esperados como parte do contrato. Quando um campo puder não existir, use uma estratégia explícita, como permitir null.

Use additionalProperties:false

additionalProperties: false impede que o modelo envie campos que não foram definidos no schema. Isso facilita validação, logs e segurança.

Evite schemas grandes demais

Quanto maior e mais complexo o schema, maior o custo cognitivo e operacional da integração. Separe ferramentas por intenção real, combine etapas que sempre acontecem juntas e não peça ao modelo para preencher dados que o seu código já conhece.

Valide também no backend

Mesmo com Structured Outputs e strict:true, a validação no backend continua obrigatória. O schema ajuda no formato; o backend confirma regras de negócio, permissões, ownership check, limites e efeitos colaterais.

strict:true na prática: benefícios e limites

strict:true é útil porque reduz a variabilidade da saída e aumenta a aderência ao contrato definido pelo JSON Schema. Em Function Calling, ele ajuda a fazer com que os arguments sigam a estrutura esperada.

Na prática, isso melhora:

consistência dos campos;
previsibilidade no parsing;
redução de propriedades inesperadas;
testes automatizados;
integração com Pydantic, Zod ou validadores JSON Schema;
clareza entre time de IA, backend e produto.

Mas strict:true não significa que o dado é verdadeiro, autorizado ou seguro. Ele não substitui autenticação, autorização, validação de negócio, logs, revisão humana em ações sensíveis ou controle de permissões.

Também é importante observar a configuração de chamadas paralelas. Em alguns ambientes e documentações, Structured Outputs com Function Calling exige atenção a parallel_tool_calls, especialmente quando o objetivo é manter aderência estrita ao schema. Em integrações críticas, teste explicitamente o comportamento com uma chamada, múltiplas chamadas e ausência de chamada.

Segurança e produção: como evitar problemas em aplicações reais

Function Calling é poderoso porque conecta o modelo a ferramentas. Essa também é a razão pela qual exige cuidado. Quando uma IA pode solicitar ações, o sistema deve ser projetado como qualquer outra integração sensível.

Não dê permissões amplas ao modelo

O modelo deve ter acesso apenas às ferramentas necessárias para a tarefa. Evite uma função genérica como executar_sql ou chamar_api_interna se você pode expor funções menores e mais controladas.

Nunca execute tool calls sem validação

Antes de executar qualquer função, valide schema, tipos, enums, limites e regras de negócio. Use bibliotecas como Pydantic em Python, Zod em TypeScript ou validadores JSON Schema no backend.

Verifique identidade e propriedade dos recursos

Se o usuário pede “mostre meu pedido 123”, não basta o modelo extrair pedido_id: "123". O backend precisa confirmar que aquele pedido pertence ao usuário autenticado.

Use idempotência em ações sensíveis

Para ações como reembolso, cancelamento, alteração cadastral ou envio de nota fiscal, use chaves de idempotência, confirmação explícita e, quando necessário, revisão humana.

Registre logs e auditoria

Armazene o nome da ferramenta, os arguments, o usuário, o resultado, erros e decisões importantes. Logs ajudam a depurar, auditar e melhorar segurança.

Reduza dados sensíveis enviados ao modelo

Considere a LGPD desde o desenho da integração. Envie ao modelo apenas os dados necessários para a tarefa e evite expor informações pessoais, financeiras ou internas sem necessidade.

Considere prompt injection e excessive agency

Prompt injection acontece quando entradas maliciosas tentam alterar o comportamento do modelo. Excessive agency ocorre quando um sistema baseado em LLM recebe funcionalidade, permissões ou autonomia demais. A mitigação não é apenas “melhorar o prompt”; é arquitetura: menor privilégio, validação, autorização, limites, confirmação e observabilidade.

Casos de uso no Brasil

Saídas estruturadas com chamada de função são especialmente úteis em operações digitais que já possuem sistemas internos, APIs ou fluxos de atendimento.

Atendimento via WhatsApp

Classificar intenção do cliente, consultar pedidos, abrir tickets, atualizar cadastro e encaminhar casos para atendimento humano.

Consulta de pedidos em e-commerce

Transformar perguntas como “cadê minha compra?” em chamadas controladas para sistemas de pedido, logística e rastreamento.

Triagem de tickets de suporte

Extrair categoria, prioridade, produto afetado, sentimento do cliente e próximo passo recomendado.

CRM e qualificação de leads

Classificar leads por segmento, urgência, orçamento, fit e próxima ação comercial.

Automação de notas fiscais e ERP

Coletar dados estruturados de solicitações internas, validar campos obrigatórios e iniciar fluxos controlados no ERP.

Extração de dados de contratos

Gerar objetos estruturados com partes envolvidas, datas, valores, cláusulas críticas e obrigações.

Classificação de mensagens

Identificar se uma mensagem é reclamação, dúvida, elogio, solicitação financeira, problema técnico ou pedido comercial.

Copilotos internos para equipes

Permitir que times consultem bases internas, abram tarefas, atualizem registros e recebam respostas com base em ferramentas seguras.

Erros comuns ao usar Function Calling e Structured Outputs

Achar que o ChatGPT executa a função sozinho

O modelo gera a chamada. Quem executa é a aplicação. Essa diferença é essencial para segurança e arquitetura.

Usar funções genéricas demais

Funções amplas aumentam risco e ambiguidade. Prefira ferramentas específicas com permissões limitadas.

Não validar arguments

Mesmo que os arguments pareçam corretos, valide no backend antes de qualquer ação.

Confundir JSON mode com Structured Outputs

JSON mode ajuda a produzir JSON válido, mas não garante aderência a um schema específico. Structured Outputs existe para reduzir esse problema.

Não usar required e additionalProperties corretamente

Sem required bem definido e additionalProperties:false, sua aplicação pode receber payloads incompletos ou inesperados.

Expor ferramentas perigosas

Evite funções que permitam executar comandos, SQL livre, alterações irreversíveis ou chamadas internas sem escopo.

Esquecer logs e auditoria

Sem logs, é difícil entender por que uma ferramenta foi chamada, quais argumentos foram usados e onde ocorreu uma falha.

Usar prompt “responda em JSON” como solução de produção

Esse tipo de prompt pode funcionar em demonstrações, mas não é um contrato robusto para automações críticas.

Checklist final antes de colocar em produção

O schema tem nomes de funções claros e específicos.
As descrições explicam quando usar e quando não usar cada função.
strict:true está ativado quando aplicável.
Todos os objetos relevantes usam additionalProperties:false.
Os campos esperados estão em required.
Campos opcionais usam uma estratégia explícita, como null.
O backend valida os arguments antes da execução.
O sistema verifica autenticação e propriedade dos recursos.
As ferramentas seguem o princípio de permissões mínimas.
Há testes com entradas inválidas, ambíguas e maliciosas.
Existe fallback quando não houver tool call.
Chamadas e resultados são registrados em logs.
Ações sensíveis usam idempotência ou confirmação.
O fluxo está documentado para produto, backend e segurança.
Riscos de prompt injection e excessive agency foram revisados.

Conclusão

Saídas estruturadas com chamada de função no ChatGPT são uma forma prática de transformar linguagem natural em ações controladas por software. Elas não servem apenas para “responder em JSON”; servem para criar um contrato mais confiável entre o modelo, o backend e os sistemas da empresa.

A regra prática é:

Structured Outputs controlam o formato.
Function Calling conecta o modelo a ferramentas.
strict:true ajuda a reforçar o contrato.
O backend continua responsável por segurança, execução, validação e regras de negócio.

Quando bem implementado, esse padrão permite construir aplicações SaaS, automações, copilotos internos e atendimentos inteligentes com mais previsibilidade. Quando mal implementado, pode criar riscos de segurança, permissões excessivas e decisões difíceis de auditar. A diferença está menos no prompt e mais na engenharia do sistema.

FAQ sobre saídas estruturadas com chamada de função no ChatGPT

O que são saídas estruturadas com chamada de função no ChatGPT?

São respostas ou argumentos gerados pelo modelo seguindo um schema definido, geralmente em JSON, para acionar uma função ou ferramenta da aplicação de forma previsível.

Structured Outputs e Function Calling são a mesma coisa?

Não. Structured Outputs controlam o formato da saída. Function Calling permite que o modelo solicite o uso de uma ferramenta. Eles podem ser usados juntos quando os argumentos da ferramenta precisam seguir um JSON Schema.

JSON mode ainda é necessário?

Pode ser útil em casos simples, mas Structured Outputs é mais adequado quando você precisa garantir aderência a um schema. JSON mode garante JSON válido, mas não garante que todos os campos sigam seu contrato.

O ChatGPT executa minhas funções?

Não. O modelo gera uma tool call com nome da função e argumentos. A execução real acontece no backend da sua aplicação, que deve validar, autorizar, executar e devolver o resultado.

Quando usar strict:true?

Use strict:true quando quiser reduzir variações e fazer os argumentos seguirem melhor o JSON Schema definido. Ele é especialmente útil em integrações de produção, mas não substitui validação no backend.

Preciso validar no backend mesmo usando Structured Outputs?

Sim. Structured Outputs ajudam no formato, mas o backend deve validar tipos, permissões, ownership, regras de negócio, limites e efeitos colaterais antes de executar qualquer função.

Function Calling funciona para e-commerce, CRM e ERP?

Sim. É um bom padrão para consultar pedidos, qualificar leads, criar tickets, buscar dados em ERP, atualizar registros e acionar fluxos internos, desde que o backend controle permissões e validação.

Posso usar isso com Pydantic ou Zod?

Sim. Pydantic em Python e Zod em TypeScript são úteis para definir, validar e manter schemas próximos do código da aplicação. Eles também ajudam a reduzir divergências entre contrato e implementação.

Table of Contents