Privacy Policy, Terms, Support: páginas jurídicas obrigatórias

1. Por que afinal precisamos de Privacy Policy, Terms e Support

Vamos começar com uma verdade incômoda: para a ChatGPT Store, ter uma política de privacidade pública e informações de contato de suporte — não é “boa prática”, é um requisito rígido. Nos guias da OpenAI está escrito explicitamente que todo App deve ter uma Privacy Policy publicada explicando claramente quais dados são coletados e como são usados, além de um contato de suporte.

Mas a história não é só “para o moderador parar de encher”. Esses documentos resolvem várias tarefas ao mesmo tempo.

Em primeiro lugar, é um nível básico de confiança para o usuário. Ele vê que há pessoas reais ou uma empresa por trás do aplicativo, que existem regras do jogo e um lugar para onde pode ir em caso de problema. Em um mundo em que “mais um serviço de IA” aparece todo dia, isso já é uma vantagem competitiva.

Em segundo lugar, é a formalização do que você já implementou na arquitetura. Tudo o que você decidiu nos módulos sobre segurança, registro de logs, retenção, exclusão de dados e trabalho com pagamentos deve estar refletido também em palavras. Se você promete “não armazenamos conversas”, mas registra permanentemente todo o tool‑input, isso não é apenas feio — é motivo para reclamações sérias.

Em terceiro lugar, é mais um nível de contrato entre você e a OpenAI. A Store basicamente diz: “Estamos prontos para mostrar seu App a milhões de pessoas, mas você deve descrever honestamente o que faz com elas e estar disponível quando algo der errado”.

Resumindo: páginas jurídicas não são sobre “os advogados nos obrigaram”. É uma forma de alinhar expectativas: o que o App faz, quais dados ele toca, qual responsabilidade você está disposto a assumir e como o usuário pode falar com você.

2. Onde vivem esses URLs jurídicos no ChatGPT App

Tecnicamente, para um ChatGPT App as páginas jurídicas são URLs públicos comuns que você informa nos metadados do aplicativo e na listagem da Store. Nos guias, geralmente as chamam de algo como privacy_policy_url, terms_of_service_url e contato de suporte.

Esses URLs precisam atender a algumas condições simples, porém importantes:

1. Eles vivem em um domínio estável do seu produto ou da sua empresa. Nada de links temporários do ngrok, ou em uma semana a Store levará o usuário a lugar nenhum.
2. Eles são acessíveis sem autenticação. O usuário (e o revisor) devem conseguir abri-los no navegador sem login e sem rituais complicados.
3. Eles estão atualizados e condizem com a realidade. Se você altera a arquitetura de tratamento de dados, com o tempo precisará atualizar o texto também.

No nosso projeto didático GiftGenius já existe um frontend em Next.js, que deployamos, digamos, na Vercel. Logo, o lugar lógico para as páginas jurídicas são rotas do tipo:

• /legal/privacy
• /legal/terms
• /support

No fundo, são apenas mais três páginas no aplicativo, mas serão justamente elas as vinculadas no formulário de envio do App para revisão.

3. Privacy Policy: como descrever honestamente o que você faz com os dados

Papel da Privacy Policy

A Privacy Policy (política de privacidade, doravante — “Policy”) responde à pergunta principal: “O que este App faz com os meus (do usuário) dados?” Ela deve descrever quais categorias de dados você processa, de onde vêm, por que precisa deles, onde e por quanto tempo são armazenados, a quem são compartilhados e como o usuário pode solicitar sua exclusão.

Uma particularidade de ChatGPT Apps é que o usuário precisa entender exatamente o que você recebe do chat. A OpenAI destaca: seu App não deve tentar reconstruir todo o diálogo, mas trabalhar apenas com os trechos que o modelo ou o usuário enviaram explicitamente para as ferramentas. Isso também deve estar indicado na Policy.

Comece não pelo texto, mas pela arquitetura

Antes de escrever qualquer palavra jurídica, é útil olhar para o seu App com os olhos de um SRE/arquiteto: quais dados realmente passam pelo sistema.

No nosso exemplo — GiftGenius — pode ficar mais ou menos assim:

Você pode manter uma tabela dessas diretamente na documentação do projeto (por exemplo, em /docs): ela será útil para desenvolvimento, para o módulo de Segurança e para a própria Policy.

Depois, “traduzimos” essa estrutura para uma linguagem mais humana.

Estrutura da Privacy Policy para o GiftGenius

No projeto didático não é preciso escrever um épico de 20 páginas, basta uma estrutura compacta, porém honesta. Normalmente, separam-se algumas seções:

1. Introdução: quem vocês são e o que é o App.
2. Quais dados vocês coletam.
3. Como vocês os utilizam.
4. Com quem vocês compartilham.
5. Onde e por quanto tempo armazenam.
6. Direitos do usuário (incluindo solicitação de exclusão).
7. Contatos para questões de privacidade.

É importante entender que, mesmo em um projeto didático, isso não é apenas um “texto de exemplo”. Você já pensou, no módulo de segurança, sobre prazos de retenção de logs, política de exclusão, backups — agora é preciso formular isso com cuidado.

Implementação mais simples da página no Next.js

Vamos criar a página /legal/privacy no nosso aplicativo. No App Router, isso é literalmente um arquivo:

// app/legal/privacy/page.tsx
export default function PrivacyPage() {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>Privacy Policy – GiftGenius</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {/* a seguir vêm as seções da política */}
    </main>
  );
}

Este exemplo é propositalmente simples: o objetivo é fixar a URL estática. Em um projeto real, o texto da política quase sempre fica separado (por exemplo, em um arquivo .md) e é carregado, para não espalhar toneladas de texto pelo JSX.

Por exemplo, dá para fazer um loader básico:

// app/legal/privacy/page.tsx
import policyHtml from "./policy.html"; // HTML pré-compilado

export default function PrivacyPage() {
  return (
    <main
      className="mx-auto max-w-3xl p-8 prose"
      dangerouslySetInnerHTML={{ __html: policyHtml }}
    />
  );
}

Comentários do tipo “não repita isso sem entender” são pertinentes aqui: dangerouslySetInnerHTML é seguro apenas se você controla a origem do HTML (por exemplo, gerando-o você mesmo a partir de markdown no CI).

Vínculo com processos reais

O mais importante: não é permitido declarar na Policy algo que você não tem no código. Se você afirma que:

• não armazena o texto das solicitações por mais de 7 dias;
• mediante solicitação do usuário, exclui totalmente o perfil dele;
• não usa esses dados para treinar seus próprios modelos,

então você precisa ter:

• configurações de retenção nos logs;
• um endpoint ou um processo administrativo para exclusão do usuário;
• ausência de código que despeje logs em um armazenamento de terceiros “para Data Science”.

E o inverso: se você ativou métricas de uso, experimentos A/B ou análise por país, precisa dizer isso honestamente na Policy. E dar ao usuário pelo menos direitos básicos: saber o que é armazenado e solicitar a exclusão.

Com os dados e a Privacy Policy resolvidos, resta formalizar não só o tratamento de dados, mas também as “regras do jogo” — essa é a tarefa dos Terms.

4. Terms of Use / Service: regras do jogo e disclaimers de IA

Por que precisamos de Terms, se já existe a Policy

A Privacy Policy responde à pergunta “o que você faz com os dados”. Os Terms of Use/Service (doravante — “Terms”) respondem à pergunta “em que condições é possível usar o App”. É um contrato jurídico entre você e o usuário.

Nele se descreve:

• o que é o GiftGenius e quais funções ele oferece;
• quais ações do usuário são permitidas e quais não são;
• onde estão os “limites da magia” da IA (disclaimers de IA);
• quais são as suas limitações de responsabilidade;
• como os litígios são resolvidos e qual é a jurisdição aplicável.

Para um app de IA, dois pontos são especialmente importantes: o disclaimer de precisão e a limitação de responsabilidade.

Especificidades de IA: “o modelo pode errar”

Nosso GiftGenius dá recomendações de presentes. É algo simpático e relativamente seguro, mas mesmo aqui há armadilhas: o usuário pediu “presente para alguém com alergia a nozes”, o modelo gerou algo inadequado, a pessoa se prejudicou, todos ficam infelizes.

Claro que os Terms não são um colete à prova de balas contra todos os riscos, mas eles deixam claro:

• que os resultados são gerados por IA e podem ser imprecisos, desatualizados ou simplesmente estranhos;
• que o usuário deve verificar por conta própria informações importantes, especialmente as relacionadas à saúde, finanças e outras áreas sensíveis;
• que você não dá garantias de “perfeição” das recomendações e não se responsabiliza pelo uso inadequado do resultado.

As formulações deverão ser trabalhadas depois com um advogado, mas para o desenvolvedor é importante entender a ideia.

Nuances de comércio

Se o seu App realiza quaisquer ações de pagamento (o módulo sobre ACP e commerce ainda será visto em mais detalhes, mas isso está previsto no curso), nos Terms é preciso descrever cuidadosamente:

• por onde passam os pagamentos (Stripe, ACP, outro sistema);
• quais dados de pagamento você efetivamente vê;
• quais são as condições de reembolso e cancelamento de pedidos;
• o que exatamente é considerado uma transação bem‑sucedida.

A recomendação da plataforma, em termos gerais, é declarar explicitamente que os dados do cartão são processados pelo provedor de pagamentos, não pelo seu servidor, e que você armazena apenas o mínimo (por exemplo, o ID da transação).

Implementação de /legal/terms no Next.js

Tecnicamente, tudo é muito parecido com a Privacy Policy. Criamos a página:

// app/legal/terms/page.tsx
export default function TermsPage() {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>Terms of Use – GiftGenius</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {/* seções: descrição do serviço, restrições, disclaimer de IA, responsabilidade */}
    </main>
  );
}

E, assim como na Policy, é melhor manter o texto em um arquivo separado ou em uma CMS, deixando o mínimo de marcação no código.

Você pode extrair um layout comum para as páginas jurídicas:

// app/legal/LegalLayout.tsx
export function LegalLayout(props: { title: string; children: React.ReactNode }) {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>{props.title}</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {props.children}
    </main>
  );
}

Depois, use-o tanto para a Policy quanto para os Terms. Não é sobre “código bonito”, e sim para você não esquecer de colocar a data de atualização e manter um estilo uniforme.

5. Support / Contact: aonde o usuário vai quando algo dá errado

Mínimo e “boas práticas”

Os guias da OpenAI indicam que o App deve oferecer uma forma clara de o usuário entrar em contato com o desenvolvedor para suporte. Pode ser um email simples, mas ele deve existir, receber mensagens e pelo menos às vezes obter respostas.

Opção mínima para um projeto didático:

• uma página separada /support com um breve texto e mailto:support@yourdomain.com.

Opção mais madura:

• formulário de contato;
• link para documentação ou Help Center;
• talvez — link para Slack/Discord, se você estiver construindo uma comunidade em torno do produto.

Página /support no Next.js

Vamos começar com a opção mais simples:

// app/support/page.tsx
export default function SupportPage() {
  return (
    <main className="mx-auto max-w-xl p-8 prose">
      <h1>GiftGenius Support</h1>
      <p>
        If you have issues or questions, email us at{" "}
        <a href="mailto:support@giftgenius.app">support@giftgenius.app</a>.
      </p>
    </main>
  );
}

Uma opção um pouco mais avançada — adicionar um formulário simples:

// app/support/page.tsx
"use client";

export default function SupportPage() {
  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    // aqui haverá a chamada de API que enviará o email/ticket
  };

  return (
    <main className="mx-auto max-w-xl p-8 prose">
      <h1>GiftGenius Support</h1>
      <form onSubmit={handleSubmit}>
        <input name="email" placeholder="Your email" className="border p-2 w-full" />
        <textarea name="message" placeholder="How can we help?" className="border p-2 w-full mt-2" />
        <button type="submit" className="mt-4 px-4 py-2 border rounded">
          Send
        </button>
      <form>
    </main>
  );
}

Mesmo que você não implemente um backend real para esse formulário no projeto didático, o simples fato de ter uma URL clara e a estrutura da página já o aproxima dos requisitos da Store.

Conexão com o gerenciamento de incidentes

A página de Support não é apenas “para onde escrever se tudo caiu”, mas parte do seu panorama operacional. Em módulos posteriores, você falará sobre incidentes e a vida operacional do App. Lá, a página de Support se torna a “porta de entrada” para os usuários: por ela chegam bug reports, dúvidas e solicitações de exclusão de dados. Por ora, é importante ao menos garantir que essa porta exista e não leve a um “404 Not Found”.

6. Integração das páginas jurídicas no aplicativo e na listagem

Configuração única de URLs dentro do projeto

Para não espalhar “strings mágicas” de URLs pelo código, é conveniente criar uma configuração simples:

// lib/appConfig.ts
export const legalLinks = {
  privacy: "https://giftgenius.app/legal/privacy",
  terms: "https://giftgenius.app/legal/terms",
  support: "https://giftgenius.app/support",
} as const;

Você usará os mesmos URLs em:

• nas configurações do ChatGPT App (metadados);
• na landing page do produto;
• em emails, se implementar notificações por email.

Dentro do widget, você pode dar ao usuário acesso rápido a essas páginas via openExternal.

// dentro do widget React do GiftGenius
import { legalLinks } from "../lib/appConfig";

function FooterLinks() {
  const handleOpen = (url: string) => {
    window.openai?.openExternal({ url }); // Apps SDK helper
  };

  return (
    <footer className="mt-4 text-xs text-gray-500">
      <button onClick={() => handleOpen(legalLinks.privacy)}>Privacy</button>
      <span> · </span>
      <button onClick={() => handleOpen(legalLinks.terms)}>Terms</button>
    </footer>
  );
}

No código real do widget, é melhor usar o hook useOpenExternal do Apps SDK; aqui, para brevidade, mostramos uma chamada direta via window.openai.

Assim você aumenta a transparência: o usuário consegue abrir em um clique os documentos jurídicos a partir do widget, sem precisar procurá-los em algum lugar da Store.

Fluxo do usuário e do revisor

Vamos ver o fluxo de interação em um pequeno esquema:

flowchart TD
  A[Página de listagem na ChatGPT Store] --> B[Usuário lê a descrição do App]
  B --> C[Abre Privacy / Terms pelo link]
  B --> D[Instala / começa a usar o App]
  D --> E[Inicia o widget do GiftGenius]
  E --> F["Se necessário, clica em 'Support' ou 'Privacy'"]

O revisor da ChatGPT Store percorre um caminho semelhante, apenas com um olhar mais crítico. Ele observa:

• o que está escrito na listagem;
• o que a Policy e os Terms prometem;
• como o App se comporta em um cenário real;
• se o comportamento condiz com o que você escreveu.

Se tudo for honesto e previsível, a chance de passar na revisão aumenta bastante.

7. Exercício prático para o seu App

Para não ficar só na teoria, é útil rascunhar agora mesmo os documentos do seu aplicativo.

A abordagem pode ser assim.

Primeiro, no nível de arquitetura, descreva:

• quais categorias de dados você processa (texto da solicitação, pedidos, email, métricas);
• se você armazena as solicitações de texto e, se sim, por quanto tempo;
• quais serviços externos estão conectados (hospedagem, banco de dados, pagamentos, analytics).

Depois disso:

1. Monte a estrutura da Privacy Policy com as seções “o que coletamos”, “por quê”, “para onde encaminhamos/compartilhamos”, “por quanto tempo mantemos”, “como excluir os dados”.
2. Monte a estrutura dos Terms: descrição do serviço, regras de uso, restrições (conteúdo proibido e abusos), disclaimer de IA, limitação de responsabilidade, links para a Policy.
3. Crie a página /support com um texto curto e um email.
4. Adicione ao projeto o lib/appConfig.ts com os URLs das páginas jurídicas e use-os no widget e em quaisquer links externos.

Mesmo que os textos sejam rascunhos por enquanto e você planeje “mostrar depois ao advogado”, você já terá feito um trabalho importante: conectar a implementação técnica à descrição jurídica.

8. Erros comuns ao preparar as páginas jurídicas

Erro nº 1: copiar uma política de privacidade aleatória da internet e não alterar.
Às vezes dá vontade de pegar a primeira política de privacidade que aparecer, trocar o nome do produto e dar a tarefa por encerrada. O problema é que esse texto quase certamente não condiz com a sua arquitetura. Ele pode ter seções sobre aplicativo móvel, push notifications ou serviços analíticos específicos que você não usa e, por outro lado, não dizer nada sobre servidor MCP, logs de ferramentas e trabalho via ChatGPT. O revisor notará as discrepâncias, e os usuários sentirão que o texto “é de outra pessoa”.

Erro nº 2: prometer na Policy o que não está implementado no código.
Exemplo clássico — a frase “excluímos todos os seus dados a qualquer momento mediante solicitação”, quando no código não há endpoint de exclusão, nem mesmo um mecanismo para buscar dados de um usuário específico. O mesmo vale para prazos de retenção de logs e frases como “não armazenamos o texto das suas mensagens”, quando na verdade você joga o tool‑input em um sistema de logs sem retenção. Essa inconsistência é perigosa tanto para a revisão quanto para usuários reais.

Erro nº 3: ignorar as especificidades de IA nos Terms.
Se nos Terms não há nada dizendo que as respostas são geradas por um modelo e podem ser imprecisas, o usuário pode esperar do seu App um nível de “verdade absoluta”. Para serviços de recomendação (presentes, viagens, seleção de produtos) isso ainda é tolerável, mas para medicina, finanças ou aconselhamento jurídico, tal lacuna pode terminar muito mal. É melhor declarar de forma explícita e honesta as limitações e a responsabilidade.

Erro nº 4: página de Support sem contato real ou com endereço morto.
A página /support que aponta para mailto:hello@example.com, para onde ninguém jamais olha, existe formalmente, mas é inútil na prática. O usuário não recebe retorno, os relatórios de bugs se perdem e a reputação do App cai. A plataforma também espera que você responda a reclamações e problemas. Mesmo que você seja uma equipe pequena, é importante revisar a caixa de entrada ao menos a cada poucos dias e responder.

Erro nº 5: esquecer-se da data e da versão dos documentos.
Às vezes, nas páginas jurídicas, não há qualquer indicação de quando foram atualizadas. Para o revisor, isso é um sinal de alerta: não está claro se os documentos correspondem ao estado atual do produto. Um bloco simples “Last updated: …” resolve o problema para você e para os usuários, além de ajudar a manter um histórico de mudanças caso, com o tempo, você evolua a arquitetura e, consequentemente, o texto da Policy/Terms.