Saída estruturada é um método para forçar modelos de linguagem a retornar dados em um formato predefinido (como JSON), permitindo parsing confiável, automação e integração com sistemas de software. Ela difere do texto livre por impor nomes de campos, tipos de dados e schemas rígidos que as ferramentas seguintes conseguem processar sem limpeza manual.
Veja um exemplo simples de saída estruturada em formato JSON:
{
"task": "summarize",
"title": "Quick AI Guide",
"summary": "This article explains structured output and JSON mode.",
"key_points": ["JSON enforces format", "Reduces parsing errors", "Enables automation"],
"audience_level": "intermediate",
"confidence": 0.95
}O que é saída estruturada
📍 In One Sentence
Saída estruturada significa exigir que o modelo siga um schema fixo — uma lista, uma tabela ou JSON com campos e tipos nomeados — para que ferramentas downstream processem o resultado sem limpeza manual.
💬 In Plain Terms
Texto livre é ótimo para uma pessoa ler e péssimo para um programa usar. Um schema transforma a resposta em algo que um banco de dados aceita direto, em vez de algo que você precisa desmontar com busca de texto toda vez.
Saída estruturada é o método de forçar modelos de linguagem a retornarem dados em um formato predefinido (como JSON). Diferente do texto livre, ela impõe nomes de campos rígidos, tipos de dados e schemas que ferramentas downstream podem processar sem limpeza manual.
O objetivo é sempre o mesmo: transformar uma descrição vaga ("algumas anotações sobre a reunião") em um formato previsível ("título, data, participantes, decisões, riscos").
O que é o modo JSON
O modo JSON é uma variante mais estrita de saída estruturada onde o modelo é instruído a retornar apenas JSON válido. No modo JSON, tudo que o modelo produz deve ser analisável como JSON.
{
"title": "string",
"summary": "string",
"tags": ["string"],
"priority": "low | medium | high"
}Você reproduz esse schema no seu prompt e então pede que o modelo o preencha. Algumas plataformas também oferecem configurações ou APIs específicas que forçam respostas somente em JSON, reduzindo a chance de comentários extras.
Por que saída estruturada e JSON mode importam
Saída estruturada e JSON mode importam porque permitem transformar modelos de linguagem em componentes de sistemas maiores, e não apenas em assistentes de chat. Quando a saída é previsível, você pode:
- Enviar resultados diretamente para bancos de dados, CRMs ou ferramentas de analytics.
- Disparar automações com base em campos como `priority`, `status` ou `confidence`.
- Construir interfaces que exibem os resultados do modelo em cards, tabelas ou dashboards sem formatação manual.
Elas também tornam os prompts mais fáceis de depurar. Se a estrutura vier quebrada, você sabe que o problema está no prompt ou no schema, e não em alguma dimensão vaga de "qualidade".
Modo JSON vs Chamadas de Função vs Prompting com Schema
Três abordagens existem para obter saída estruturada de LLMs.
- Modo JSON: O modelo produz apenas JSON válido. Melhor para: extração de dados, classificação, resumo.
- Chamadas de função: O modelo seleciona qual função chamar e fornece argumentos em JSON. Melhor para: integração de API, uso de ferramentas.
- Prompting com schema: Instruções explícitas + exemplos que exigem que o modelo siga um schema. Melhor para: flexibilidade, modelos locais, formatos personalizados.
Se ainda houver problemas de formatação, você pode adicionar uma instrução simples como "Se estiver em dúvida, deixe o campo como string vazia em vez de adivinhar." A saída estruturada funciona melhor combinada com RAG (geração aumentada por recuperação) para checagem dos dados extraídos. Quando os dados extraídos precisam permanecer em infraestrutura privada, os mesmos padrões de JSON mode se conectam a um vector store on-premise — veja RAG local para dados de negócio para o modelo de implantação em conformidade com a LGPD.
Comparação de modelos: conformidade JSON por fornecedor
Diferentes modelos têm diferentes níveis de suporte ao modo JSON nativo. A partir de abril de 2026:
| Modelo | Modo JSON nativo | Conformidade apenas com prompt | Notas |
|---|---|---|---|
| OpenAI GPT-5.6 | Sim (imposto) | Não necessário | Padrão da indústria para modo JSON. |
| Anthropic Claude Sonnet 5 | Sim (imposto) | Não necessário | Excelente conformidade JSON. |
| Google Gemini 2.0 | Sim (imposto) | Não necessário | Suporte JSON nativo. |
| Meta Llama 3.3 70B | Parcial | Fortemente recomendado | Open-source. |
| Modelos open-source pequenos (<13B) | Não | Necessário com exemplos | Requerem schemas detalhados. |
Exemplo: texto livre versus JSON estruturado
A diferença fica clara quando você compara um prompt de texto livre com um prompt de JSON estruturado para a mesma tarefa. Aqui vamos classificar e resumir um e-mail de cliente.
Prompt ruim
"Leia este e-mail do cliente e resuma o que ele quer."
Prompt bom – JSON mode
"Você é um assistente de suporte ao cliente. Leia o e-mail do cliente abaixo e extraia as informações principais para um objeto JSON. Requisitos: gere apenas JSON válido, com chaves e valores de string entre aspas duplas. Não inclua explicações nem texto extra fora do JSON. Se um valor estiver ausente, use uma string vazia. Schema JSON: { "issue_type": "string", "urgency": "low | medium | high", "summary": "string (max 25 words)", "customer_sentiment": "negative | neutral | positive" } E-mail do cliente: cole o texto do e-mail aqui"
A versão "boa" define o schema, os valores válidos e a exigência de somente JSON, o que torna a saída simples de parsear e usar em outros sistemas.
Boas práticas
Para obter saídas estruturadas confiáveis, você precisa ser explícito e rigoroso em seus prompts. Para conformidade com LGPD/ANPD, a saída estruturada facilita o rastreamento de dados extraídos e transformados — essencial para organizações que processam dados pessoais de cidadãos brasileiros.
- Mostre o schema exato que você espera.
- Declare claramente que apenas JSON deve ser retornado.
- Use nomes de chaves curtos e sem ambiguidade.
- Adicione exemplos de saídas válidas quando a tarefa é complexa.
Saída estruturada em ambientes regulados
A saída estruturada é especialmente valiosa em setores regulados porque impõe extração de dados consistente, trilhas de auditoria e documentação de conformidade. As exigências variam por região:
- União Europeia (GDPR, AI Act): a saída estruturada permite classificação sistemática de dados e rastreamento do direito ao apagamento. O JSON mode deixa você marcar quais campos contêm dados pessoais, facilitando o DPIA (relatório de impacto à proteção de dados) e auditorias de conformidade.
- Japão (Diretrizes de IA do METI, APPI): a extração estruturada com schemas bem definidos atende aos requisitos de transparência e prestação de contas. A conformidade no Japão costuma exigir documentar como os dados são processados — a saída estruturada fornece trilhas de auditoria claras.
- China (regulamentações da CAC, Lei de Segurança de Dados): a saída estruturada ajuda na moderação de conteúdo e no registro de residência de dados. O JSON mode permite classificar sistematicamente conteúdo sensível (dados financeiros, informações pessoais) para atender aos padrões da CAC.
- Brasil (LGPD, ANPD): a saída estruturada facilita o mapeamento de dados exigido pela LGPD, permitindo identificar em quais campos há dados pessoais e sustentar o atendimento aos direitos do titular. Marcar esses campos no schema simplifica o Relatório de Impacto à Proteção de Dados Pessoais (RIPD) e as respostas a solicitações da ANPD.
Erros comuns
Evite estes erros frequentes ao implementar saída estruturada e JSON mode:
- Schemas ambíguos: pedir "extraia os pontos principais" sem definir um schema gera saída inconsistente. Sempre especifique nomes de campos exatos, tipos e restrições.
- Falta de exemplos: fornecer apenas a descrição do schema sem exemplos causa de 20% a 30% de falhas. Sempre mostre de 1 a 3 exemplos de saída válida.
- Não validar a saída: supor que o modelo sempre retornará JSON válido leva a erros de parsing em produção. Sempre valide e trate falhas de parsing com cuidado.
- Não tratar casos-limite: campos que podem estar ausentes, ambíguos ou fora da faixa precisam de um comportamento de fallback definido (null, string vazia ou valor padrão).
- Testar apenas com entradas fáceis: dados reais são bagunçados. Teste seu schema com casos-limite: e-mails incompletos, caracteres especiais, idiomas misturados e entradas muito longas.
Quando usar JSON mode em vez das alternativas
Escolha JSON mode quando precisar de schema rigidamente imposto e saída determinística. Evite quando criatividade e raciocínio aberto forem o que importa.
- ✓ Use JSON mode: schema rígido obrigatório, pipelines de automação, integração com API, extração de dados, tarefas de classificação, saídas determinísticas, sistemas em produção que exigem validação.
- ✗ Evite JSON mode: escrita criativa, raciocínio aberto, brainstorming, redações, geração de código (function calling é melhor), questões filosóficas, conteúdo narrativo.
- Alternativa: function calling quando você precisa de integração com ferramentas e workflows agênticos (o modelo escolhe qual função chamar).
- Alternativa: schema prompting quando você precisa de flexibilidade, trabalha com modelos open source ou não precisa de garantias no nível da API.
Quando você deve usar saída estruturada?
A saída estruturada brilha em três cenários principais. Use-a quando precisar de resultados determinísticos e legíveis por máquina:
- APIs e integrações: envie a saída do LLM diretamente para sistemas seguintes (bancos de dados, CRMs, dashboards). A saída estruturada evita erros de parsing e limpeza manual. Exemplo: extrair dados de clientes de e-mails e gravar no CRM.
- Automação e workflows: dispare ações com base em campos da saída do modelo (prioridade, urgência, categoria). O JSON mode garante extração confiável de campos para lógica condicional. Exemplo: rotear tickets de suporte por nível de urgência.
- Pipelines de dados: processe grandes volumes (documentos, e-mails, logs) em escala. Schemas consistentes viabilizam processamento em lote, validação e tratamento de erros. Exemplo: extrair metadados de 10.000 artigos científicos para um banco de dados pesquisável.
Como Implementar Saída Estruturada
- 1Defina seu schema antes de escrever o prompt. Decida quais campos você precisa, seus tipos e quais são obrigatórios.
- 2Use modo JSON da API quando disponível. OpenAI, Anthropic e Google suportam parâmetros de modo JSON que previnem erros de análise.
- 3Para dados críticos, use chamadas de função. Chamadas de função impõem tipos e campos obrigatórios.
- 4Sempre valide a saída. Mesmo com modo JSON, valide contra seu schema esperado antes de processar os dados.
- 5Inclua um exemplo de boa saída no prompt. Modelos seguem exemplos melhor do que descrições abstratas de schema.
Perguntas Frequentes
O modo JSON garante o schema correto?
Não completamente. O modo JSON garante JSON sintaticamente correto, mas não impõe campos específicos. Use chamadas de função para schema crítico.
Como lido com JSON inválido de LLMs?
Três estratégias: (1) use modo JSON da API, (2) adicione retry automático, (3) use chamadas de função para schema crítico.
O modo JSON é afetado pela conformidade com LGPD?
O modo JSON em si é neutro. Mas a saída estruturada beneficia a conformidade porque permite rastrear sistematicamente dados extraídos, transformados e registrados — requisito da LGPD para dados pessoais.
Veja um exemplo completo de JSON com arrays aninhados, mostrando a hierarquia correta:
{
"articles": [
{
"title": "string",
"author": "string",
"citations": [
{
"title": "string",
"year": "number"
}
]
}
]
}