Lo mejor que leía cada semana siempre llegaba a mi bandeja de entrada, en newsletters de otras personas.
Quería compartir esas ideas con más lectores. Hacerlo a mano significaba leer, reescribir, traducir, dar formato, publicar y enviar. Era una tarde entera de trabajo para un solo número.
Así que construí un pipeline cuyo primer paso es un solo gesto: reenviar un correo.
A partir de ahí, el sistema guarda el correo y Claude escribe un artículo nuevo en portugués. Añade las versiones en inglés y español, comprueba cada afirmación factual con el correo y deja el texto listo para mi revisión. Cuando lo apruebo, el artículo se publica en mi web y un comando lo envía por Mailchimp.
El primer artículo pasó del correo reenviado a un post publicado y una campaña real. Aquí tienes el sistema completo, para que montes el tuyo.
El flujo
El pipeline tiene cinco etapas: inicio, recogida, generación, publicación y envío. El verde marca el camino activo, y el naranja, los pasos en los que una persona mantiene el control.
De qué está hecho
| Capa | Herramienta | Función |
|---|---|---|
| Recepción | Amazon SES y S3 | Recibe los correos reenviados y los almacena |
| Importador | Script en Node.js | Filtra, guarda y coordina cada ejecución |
| Redacción | API de Claude | Recrea el artículo y lo traduce |
| Revisión | Pull requests en GitHub | Mantiene a una persona entre la IA y el público |
| Web | React en S3 y CloudFront | Sirve el blog y la página de la newsletter |
| Envío | AWS Lambda y Mailchimp | Envía campañas sin exponer la clave de la API |
La instalación, paso a paso
1. Dale al pipeline su propia dirección. Crea un subdominio como inbound.tudominio.com y verifícalo en Amazon SES. Añade un registro MX para ese subdominio, apuntando al endpoint de entrada de SES en tu región. Tu correo principal sigue funcionando, porque su MX no cambia.
2. Guarda el correo en S3. Crea un bucket privado y una política que permita a SES escribir en él. Después, crea una regla de recepción para la nueva dirección, con entrega en el bucket y análisis de spam y virus activado. Añade una regla para borrar correos antiguos y no olvides el paso que todos pasan por alto: activar el conjunto de reglas.
3. Instala el importador. Es un proyecto en Node.js con un comando principal:
cp .env.newsletter.example .env.newsletter
npm install
npm run import:newsletter -- --dry-run --limit=1El dry run muestra lo que se publicaría y no modifica el blog. Cada correo recibido se guarda en JSON en una carpeta ignorada por Git. Así conservas el registro completo sin publicar el original.
4. Conecta la IA. Crea una clave de la API de Claude. Aquí me llevé una sorpresa: el plan Claude Pro no incluye el uso de la API. La API tiene sus propios créditos de prepago.
No le pido a Claude que traduzca. Le pido que recree el artículo: que encuentre un nuevo ángulo y una nueva estructura, mantenga cada hecho de la fuente y atribuya las opiniones a sus autores. La respuesta llega en JSON estructurado, con título, texto, comentario, referencia y traducciones.
5. Haz que los hechos se puedan comprobar. Para cada afirmación factual, Claude debe citar el pasaje exacto que la respalda. El script busca esa cita en el correo y señala lo que no encuentra. En el primer artículo, se localizaron las 28 afirmaciones.
6. Muéstralo en la web. Cada post guarda sus traducciones y la referencia al original. Quien lee ve su propio idioma, un comentario identificado de IURIX y un aviso claro de que el texto se recreó con IA, con enlace a la fuente.
7. Envía con una Lambda privada. La clave de Mailchimp solo está en AWS. La Lambda no tiene URL pública, así que solo las credenciales de AWS pueden llamarla. El comando local prepara el correo y le pide el envío a la Lambda.
8. Prográmalo. Una GitHub Action se ejecuta a diario, importa lo nuevo y abre un pull request. El merge de ese pull request es lo que publica el post.
Configuración
Todo lo que cambia de un entorno a otro está en variables de entorno o en un archivo editable.
| Ajuste | Qué controla |
|---|---|
ANTHROPIC_API_KEY | Acceso a Claude. Mantenla fuera del código |
NEWSLETTER_SOURCE | El origen de los artículos: S3, RSS, Proton o Microsoft 365 |
NEWSLETTER_ALLOWED_SENDER | La única dirección autorizada para alimentar el pipeline |
NEWSLETTER_BUCKET | El bucket S3 con los correos recibidos |
MAILCHIMP_TEST_EMAIL | Adónde van las campañas de prueba |
prompt-context.md | Tu voz, tu público y el ángulo de cada comentario |
Ese último archivo es el más importante. Unas pocas frases cambian el tono de todos los comentarios futuros, sin tocar el código.
El uso en el día a día
Con todo listo, publicar un número es así:
- Reenvía una newsletter que merezca la pena recrear.
- Revisa el pull request: el texto, las afirmaciones y el enlace al original.
- Haz el merge. El despliegue coloca el post en el blog y en la página de la newsletter.
- Prueba la campaña, que solo te llega a ti:
npm run send:newsletter- Envíala a tu público:
npm run send:newsletter -- --sendEl comando de envío se niega a ejecutarse hasta que el post esté publicado y exista un borrador probado. Tampoco envía el mismo post dos veces en el mismo idioma.
Lo que se rompió, para que no se rompa lo tuyo
Ningún proyecto real funciona a la primera. Estos seis problemas fueron los que más tiempo me costaron.
| Síntoma | Causa real | Solución |
|---|---|---|
| No pude leer el buzón de Proton | No encontré una API pública oficial para leer correo | Recibir directamente con SES |
credit balance is too low | El plan Claude Pro no cubre la API | Comprar créditos de la API |
| Los correos no llegaban a S3 | El conjunto de reglas de SES existía, pero no estaba activo | Activarlo |
cannot invoke a durable function | La ejecución duradera estaba marcada en la Lambda | Recrearla como función normal |
| Todas las páginas daban 404 | El dominio apuntaba a GoDaddy, no a CloudFront | Corregir el CNAME de www y el redireccionamiento |
| Las pruebas pasaban en local y fallaban en GitHub | Mi Mac usaba Node 26, y el workflow, Node 24 | Usar un comando de prueba que funcione en ambos |
El de DNS es mi favorito. Esperaba una ruta que faltaba para sitemap.xml. En realidad, la web funcionaba en CloudFront y el sitemap ya estaba publicado. El dominio simplemente no apuntaba a ella. Revisa la capa que está debajo de la que sospechas.
Las protecciones que lo hacen publicable
Publicar rápido sin confianza es solo equivocarse más rápido. Estas reglas siempre están activas:
- Una persona lo aprueba todo. Nada se publica ni llega a los suscriptores sin revisión.
- Solo se acepta un remitente. La dirección debe coincidir, y debe pasar la comprobación SPF del propio SES.
- El original siempre se acredita, con autoría, publicación, fecha y enlace.
- El uso de IA se indica en la web y en el correo.
- Los secretos se quedan en el servidor. Ninguna clave de API llega al navegador.
Un límite merece franqueza. La comprobación demuestra que la cita existe en el correo, pero no que el correo sea cierto. Las afirmaciones serias siguen necesitando lectura humana. Un artículo recreado también puede considerarse obra derivada, así que comprueba los derechos antes de depender de una fuente.
Qué pasó en la primera ejecución
Una newsletter real reenviada se convirtió en un artículo de 557 palabras en portugués. Las 28 afirmaciones se localizaron en el correo, y el post está publicado con versiones en inglés y español. Después salió como campaña real, para un público de exactamente una persona.
Esa es la parte honesta: la máquina funciona, y ahora necesita lectores. La programación diaria es la última pieza que aún estoy validando en producción.
¿Quieres esto en tu empresa?
El mismo patrón sirve para cualquier equipo que convierta material de origen en contenido publicado: informes, investigaciones, comunicaciones internas o newsletters para clientes.
En IURIX, diseñamos sistemas de nube, datos e IA como este.
- Sigue la construcción: suscríbete en iurix.com/newsletter.
- ¿Quieres uno propio? Habla con nosotros en iurix.com.