As melhores ideias da minha semana chegavam sempre na caixa de entrada, em newsletters de outras pessoas.
Eu queria levar essas ideias para quem lê em português. Fazer isso à mão significava ler, reescrever, traduzir, formatar, publicar e enviar. Era uma noite inteira de trabalho para uma única edição.
Então construí um pipeline em que o primeiro passo é um gesto só: encaminhar um e-mail.
A partir daí, o sistema salva o e-mail e o Claude escreve um artigo novo em português. Ele cria as versões em inglês e espanhol, confere cada afirmação factual com o e-mail e deixa o texto pronto para minha revisão. Depois que aprovo, o artigo entra no site, e um comando envia tudo pelo Mailchimp.
O primeiro artigo foi do e-mail encaminhado até um post no ar e uma campanha real. Aqui está o sistema completo, para você montar o seu.
O fluxo

O pipeline tem cinco etapas: início, coleta, geração, publicação e envio. O verde mostra o caminho ativo, e o laranja mostra onde uma pessoa continua no controle.
Do que ele é feito
| Camada | Ferramenta | Função |
|---|---|---|
| Recebimento | Amazon SES e S3 | Recebe os e-mails encaminhados e os armazena |
| Importador | Script em Node.js | Filtra, salva e coordena cada execução |
| Escrita | API do Claude | Recria o artigo e faz as traduções |
| Revisão | Pull requests no GitHub | Mantém uma pessoa entre a IA e o público |
| Site | React em S3 e CloudFront | Publica o blog e a página da newsletter |
| Envio | AWS Lambda e Mailchimp | Envia campanhas sem expor a chave da API |
A instalação, passo a passo
1. Dê ao pipeline um endereço próprio. Crie um subdomínio como inbound.seudominio.com e verifique-o no Amazon SES. Adicione um registro MX para esse subdomínio, apontando para o endpoint de entrada do SES na sua região. Seu e-mail principal continua funcionando, porque o MX dele não muda.
2. Salve os e-mails no S3. Crie um bucket privado e uma política que permita ao SES gravar nele. Depois, crie uma regra de recebimento para o novo endereço, com entrega no bucket e verificação de spam e vírus ligada. Adicione uma regra para apagar e-mails antigos e não esqueça o passo que todo mundo perde: ativar o conjunto de regras.
3. Instale o importador. É um projeto em Node.js com um comando principal:
cp .env.newsletter.example .env.newsletter
npm install
npm run import:newsletter -- --dry-run --limit=1O dry run mostra o que seria publicado e não altera o blog. Cada e-mail recebido fica salvo em JSON numa pasta ignorada pelo Git. Assim você mantém o registro completo sem publicar o original.
4. Conecte a IA. Crie uma chave da API do Claude. Aqui tive uma surpresa: o plano Claude Pro não inclui uso da API. A API tem créditos pré-pagos próprios.
Eu não peço ao Claude que traduza. Peço que recrie o artigo: encontre um novo ângulo e uma nova estrutura, mantenha cada fato da fonte e atribua as opiniões a seus autores. A resposta vem em JSON estruturado, com título, texto, comentário, referência e traduções.
5. Torne os fatos verificáveis. Para cada afirmação factual, o Claude precisa citar o trecho exato que a sustenta. O script procura essa citação no e-mail e sinaliza o que não encontrar. No primeiro artigo, as 28 afirmações foram localizadas.
6. Mostre tudo no site. Cada post guarda as traduções e a referência ao original. Quem lê vê o próprio idioma, um comentário identificado da IURIX e um aviso claro de que o texto foi recriado com IA, com link para a fonte.
7. Envie por uma Lambda privada. A chave do Mailchimp fica apenas na AWS. A Lambda não tem URL pública, então só credenciais da AWS conseguem chamá-la. O comando local monta o e-mail e pede o envio à Lambda.
8. Agende. Uma GitHub Action roda todo dia, importa o que houver de novo e abre um pull request. É o merge desse pull request que publica o post.
Configuração
Tudo o que muda de um ambiente para outro fica em variáveis de ambiente ou em um arquivo editável.
| Configuração | O que controla |
|---|---|
ANTHROPIC_API_KEY | Acesso ao Claude. Mantenha fora do código |
NEWSLETTER_SOURCE | A origem dos artigos: S3, RSS, Proton ou Microsoft 365 |
NEWSLETTER_ALLOWED_SENDER | O único endereço autorizado a alimentar o pipeline |
NEWSLETTER_BUCKET | O bucket S3 com os e-mails recebidos |
MAILCHIMP_TEST_EMAIL | Para onde vão as campanhas de teste |
prompt-context.md | Sua voz, seu público e o ângulo de cada comentário |
Esse último arquivo é o mais importante. Algumas frases simples mudam o tom de todos os próximos comentários, sem mexer em código.
O uso no dia a dia
Com tudo pronto, publicar uma edição fica assim:
- Encaminhe uma newsletter que valha a pena recriar.
- Revise o pull request: o texto, as afirmações e o link para o original.
- Faça o merge. O deploy coloca o post no blog e na página da newsletter.
- Teste a campanha, que vai apenas para você:
npm run send:newsletter- Envie para o seu público:
npm run send:newsletter -- --sendO comando de envio se recusa a rodar até o post estar no ar e existir um rascunho testado. Ele também não envia o mesmo post duas vezes no mesmo idioma.
O que quebrou, para o seu não quebrar
Nenhum projeto real funciona de primeira. Estes seis problemas foram os que mais custaram tempo.
| Sintoma | Causa real | Solução |
|---|---|---|
| Não consegui ler a caixa do Proton | Não encontrei uma API pública oficial para ler e-mails | Receber direto no SES |
credit balance is too low | O plano Claude Pro não cobre a API | Comprar créditos da API |
| Os e-mails não chegavam ao S3 | O conjunto de regras do SES existia, mas não estava ativo | Ativar o conjunto |
cannot invoke a durable function | A opção de execução durável foi marcada na Lambda | Recriar como função comum |
| Todas as páginas davam 404 | O domínio apontava para a GoDaddy, não para o CloudFront | Corrigir o CNAME do www e o redirecionamento |
| Testes passavam no Mac e falhavam no GitHub | Meu Mac usava Node 26, e o workflow, Node 24 | Usar um comando de teste que funcione nos dois |
O de DNS é o meu favorito. Eu esperava uma rota faltando para o sitemap.xml. Na verdade, o site estava saudável no CloudFront e o sitemap já estava publicado. O domínio simplesmente não apontava para ele. Confira a camada abaixo da que você suspeita.
As proteções que tornam isso publicável
Publicar rápido sem confiança é só errar mais rápido. Estas regras ficam sempre ligadas:
- Uma pessoa aprova tudo. Nada vai ao ar nem chega aos assinantes sem revisão.
- Só um remetente é aceito. O endereço precisa bater, e a verificação SPF do próprio SES precisa passar.
- O original é sempre creditado, com autoria, publicação, data e link.
- O uso de IA é informado no site e no e-mail.
- Os segredos ficam no servidor. Nenhuma chave de API chega ao navegador.
Um limite merece franqueza. A checagem prova que a citação existe no e-mail, mas não prova que o e-mail está certo. Afirmações sérias ainda precisam de leitura humana. Um artigo recriado também pode ser considerado obra derivada, então verifique os direitos antes de depender de uma fonte.
O que aconteceu na primeira execução
Uma newsletter real encaminhada virou um artigo de 557 palavras em português. As 28 afirmações foram localizadas no e-mail, e o post está no ar com versões em inglês e espanhol. Depois, ele saiu como campanha real, para um público de exatamente uma pessoa.
Essa é a parte honesta: a máquina funciona, e agora ela precisa de leitores. O agendamento diário é a última peça que ainda estou validando em produção.
Quer isso na sua empresa?
O mesmo padrão serve para qualquer time que transforma material bruto em conteúdo publicado: relatórios, pesquisas, comunicados internos ou newsletters para clientes.
Na IURIX, projetamos sistemas de nuvem, dados e IA como este.
- Acompanhe a construção: assine em iurix.com/newsletter.
- Quer um para você? Fale com a gente em iurix.com.