Forem: lu1tr0n

Let's Encrypt detiene emisión de certificados tras incidente del 8 de mayo

lu1tr0n — Fri, 08 May 2026 20:18:52 +0000

El 8 de mayo de 2026 a las 18:37 UTC, Let's Encrypt publicó un aviso en su página oficial de estado anunciando la suspensión inmediata de la emisión de certificados. La autoridad certificadora gratuita más usada del mundo declaró estar investigando un "potential incident" que afecta a sus componentes de producción y staging, incluyendo acme-v02.api.letsencrypt.org y el portal de gestión.

La nota oficial es escueta: "We have been made aware of a potential incident and are shutting down all issuance." En la práctica, esto significa que cualquier servidor, dispositivo o pipeline CI/CD que dependa de Let's Encrypt para renovar certificados TLS está bloqueado mientras dure la investigación. Para una infraestructura que emite más de cinco millones de certificados al día, una pausa de incluso unas horas tiene un efecto cascada considerable sobre internet.

Qué pasó con Let's Encrypt el 8 de mayo de 2026

El aviso publicado en letsencrypt.status.io es deliberadamente parco. La organización no ha revelado la naturaleza del incidente: no se sabe si se trata de una vulnerabilidad en su software CA Boulder, un compromiso de infraestructura, una emisión incorrecta detectada por un tercero, o un fallo operacional. Los componentes marcados como afectados son los cuatro endpoints principales:

acme-v02.api.letsencrypt.org — endpoint de producción del protocolo ACME donde se solicitan los certificados.- acme-staging-v02.api.letsencrypt.org — endpoint de pruebas, normalmente usado para validar pipelines antes de pegarle a producción.- portal.letsencrypt.org — portal web de administración.- portal-staging.letsencrypt.org — portal de pruebas.

La ubicación reportada es High Assurance Datacenter 1 y High Assurance Datacenter 2, los dos centros de datos donde Let's Encrypt mantiene sus claves de firma offline. El estado oficial es INVESTIGATING: la fase inicial de un incidente público en la que el equipo aún recopila información y todavía no ha confirmado causa raíz.
El aviso oficial detuvo emisiones en producción y staging simultáneamente.

⚠️ Ojo: mientras dure la suspensión, cualquier intento de obtener un certificado nuevo o renovar uno existente vía Let's Encrypt fallará. Los certificados ya emitidos siguen siendo válidos hasta su fecha de expiración (normalmente 90 días), pero las renovaciones automáticas configuradas para los próximos días pueden romperse.

Por qué Let's Encrypt es crítico para la web

Para entender la magnitud del incidente conviene recordar qué es Let's Encrypt. Lanzado en 2015 por la Internet Security Research Group (ISRG) con el respaldo de Mozilla, EFF, Akamai y Cisco, Let's Encrypt se propuso un objetivo simple pero ambicioso: cifrar el 100% de la web ofreciendo certificados TLS gratuitos, automatizados y abiertos.

Antes de Let's Encrypt, un certificado TLS costaba entre 50 y 500 dólares anuales y requería un proceso manual de validación. Para un blog personal, una pyme latinoamericana o una startup en su primer mes, eso era una barrera real. Diez años después, la organización emite más certificados que cualquier otra autoridad del planeta y, según sus propias estadísticas, ha contribuido a que el porcentaje de páginas cargadas con HTTPS en Firefox pasara de menos del 40% a más del 90%.

Su modelo de operación lo hace particularmente sensible a este tipo de incidentes:

Validez corta — los certificados duran 90 días, lo que obliga a renovaciones frecuentes.- Automatización vía ACME — la mayoría de los servidores los renuevan automáticamente con clientes como Certbot, acme.sh o acme-companion.- Sin contrato comercial — al ser gratuito, no hay SLA contractual que cubra una caída.

El protocolo ACME y por qué la suspensión rompe automatizaciones

ACME (Automatic Certificate Management Environment), estandarizado en el RFC 8555, es el protocolo que permite a un servidor demostrar el control sobre un dominio y obtener un certificado sin intervención humana. Un flujo típico de renovación se ve así:

sequenceDiagram
    participant S as Servidor
    participant A as ACME
    participant D as Dominio
    S->>A: solicita newOrder
    A-->>S: devuelve challenge HTTP-01
    S->>D: publica el reto en su web
    A->>D: verifica el reto
    A-->>S: validacion OK
    S->>A: envia CSR
    A-->>S: emite certificado

Cuando el endpoint ACME está caído, ese flujo falla en el primer paso. Los clientes reaccionan distinto: Certbot reintenta con backoff exponencial; acme.sh registra el error y vuelve en el próximo cron; Caddy y Traefik mantienen el certificado actual hasta que sea posible renovar. La buena noticia es que, salvo que tu certificado venza dentro de las próximas horas, no notarás nada inmediato.

Un ejemplo práctico de cómo podés probar manualmente si Let's Encrypt está respondiendo (Linux/macOS):

# Ver el estado del directorio ACME
curl -i https://acme-v02.api.letsencrypt.org/directory

# Forzar renovación con Certbot (modo dry-run)
sudo certbot renew --dry-run

# Listar certificados con su fecha de expiración
sudo certbot certificates

En Windows, con OpenSSL instalado vía Chocolatey o WSL:

# PowerShell con Invoke-WebRequest
Invoke-WebRequest -Uri https://acme-v02.api.letsencrypt.org/directory -UseBasicParsing

# WSL / Git Bash funciona igual que Linux
curl -i https://acme-v02.api.letsencrypt.org/directory

Si la primera llamada devuelve algo distinto de un JSON con los endpoints o falla con timeout, el problema sigue en pie. El comando certbot certificates te muestra cuáles están próximos a vencer y te ayuda a priorizar.

Datos y cifras: la escala del problema

Las cifras hacen evidente por qué este incidente es relevante:

Let's Encrypt emite, en promedio, más de 5 millones de certificados nuevos por día entre emisiones y renovaciones.- Más de 500 millones de sitios activos usan certificados de Let's Encrypt, según las estadísticas oficiales de la organización.- La validez de cada certificado es de 90 días; muchos sistemas renuevan a los 60 días, dejando un margen de 30 días de buffer.- En 2025, Let's Encrypt comenzó a ofrecer certificados de 6 días de duración en piloto, lo que aumenta aún más la dependencia de su disponibilidad continua.- La organización opera con un equipo técnico relativamente pequeño y una infraestructura concentrada en dos centros de datos de alta seguridad. Más de 500 millones de sitios dependen de la CA gratuita más popular del mundo. ## Impacto en desarrolladores y empresas en LATAM

Para América Latina, donde una proporción altísima del hosting independiente, los proyectos de software libre y las pymes tecnológicas dependen de Let's Encrypt, el efecto puede sentirse rápido. Algunos escenarios concretos:

Pipelines CI/CD que provisionan ambientes efímeros (preview deployments en Vercel-like, Render, Fly.io o Railway) pueden fallar al obtener certificados nuevos.- Kubernetes con cert-manager seguirá intentando renovar; los pods con certificados vencidos pueden bloquear ingress controllers y romper el tráfico interno.- Servidores hogareños o self-hosted que ejecutan Certbot semanalmente verán errores en los logs hasta que el servicio vuelva.- SaaS que emite subdominios para clientes bajo modelo wildcard y depende del DNS-01 challenge no podrá registrar nuevos clientes hasta que se restablezca el servicio.- Hosting compartido de proveedores regionales que usan Let's Encrypt como backend para certificados gratuitos del cliente pierde su capacidad de provisionar nuevos sitios HTTPS.

Cómo verificar si estás afectado y mitigar el impacto

Mientras Let's Encrypt comunica más detalles, hay tres cosas concretas que podés hacer hoy mismo:

1. Auditar tus certificados actuales

El comando openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null | openssl x509 -noout -dates te muestra la fecha de expiración. Si tenés más de 7 días de margen, podés esperar a que se restablezca el servicio sin intervenir.

2. Considerar autoridades alternativas

Si tu certificado vence en horas, la opción más rápida es cambiar a otra CA con soporte ACME. Las alternativas comunes son ZeroSSL, Buypass Go SSL y Google Trust Services. Casi todos los clientes ACME modernos permiten cambiar el endpoint con un parámetro:

# Certbot con ZeroSSL (requiere registrar cuenta primero)
sudo certbot certonly \
  --server https://acme.zerossl.com/v2/DV90 \
  --eab-kid TU_KID --eab-hmac-key TU_KEY \
  -d ejemplo.com

# acme.sh con Buypass
acme.sh --issue --server https://api.buypass.com/acme/directory \
  -d ejemplo.com -w /var/www

# Caddy: cambiar la directiva en Caddyfile
# tls user@dominio.com {
#   ca https://acme.zerossl.com/v2/DV90
# }

3. Suscribirse al feed de estado

El status page de Let's Encrypt soporta RSS, email, Slack y Microsoft Teams. Para SREs en LATAM, agregar el feed RSS al canal de #ops es la forma más confiable de enterarse en tiempo real sin depender del horario de oficina norteamericano.

💡 Tip: antes de cambiar de CA en producción, probá el flujo completo en staging. Algunas CAs alternativas requieren External Account Binding (EAB), un paso extra de registro que Let's Encrypt no exige.

Antecedentes: cuando las CAs fallan

Este no es el primer incidente que afecta a una autoridad certificadora masiva. En 2020, Let's Encrypt tuvo que revocar 3 millones de certificados por un bug en la verificación CAA (Certificate Authority Authorization) que afectaba a un subset de emisiones. La revocación se ejecutó en horas, y aunque la mayoría de los sitios renovaron sin problemas, hubo cientos de incidentes operacionales reportados en foros y redes.

En 2011, la CA neerlandesa DigiNotar fue comprometida por un atacante que emitió certificados fraudulentos para Google, Mozilla y agencias gubernamentales iraníes. La empresa terminó en bancarrota y los browsers la removieron por completo de sus root stores. Es el peor escenario posible para una CA: pérdida total de confianza.

El precedente importa porque muestra que una CA puede operar correctamente durante años y caer en horas. La práctica de certificate pinning ha ido en retroceso justamente porque vincular tu sitio a una CA específica te deja sin escape en escenarios como el actual.

📌 Nota: el ecosistema TLS está diseñado para tolerar fallos de CAs individuales, pero solo si los operadores tienen un plan B preconfigurado. La mayoría no lo tiene.

Qué sigue

Por ahora, el siguiente paso pertenece a Let's Encrypt. El protocolo de incidentes públicos típicamente sigue cuatro fases: investigating → identified → monitoring → resolved. Una vez que la organización publique el post-mortem (suelen hacerlo dentro de las 72 horas en su foro de la comunidad), sabremos:

La causa raíz exacta del incidente.- Si hubo certificados emitidos incorrectamente que requieran revocación masiva.- El timeline completo desde la detección hasta la mitigación.- Qué cambios operacionales se introducirán para evitar recurrencia.

Para los equipos de ingeniería, el aprendizaje recurrente es el mismo: la disponibilidad de tu sitio depende de servicios externos que tarde o temprano fallan. Tener un plan B documentado, certificados con margen de renovación amplio y monitoreo proactivo de fechas de expiración convierte un incidente como este en una nota a pie de página del log diario, no en una página de operaciones llena de tickets P1.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Mi sitio se va a caer si tengo certificados de Let's Encrypt?

No de forma inmediata. Los certificados ya emitidos son válidos hasta su fecha de expiración. El problema solo aparece si la renovación está programada durante el período de suspensión y el servicio no se restablece a tiempo.

¿Cómo sé cuándo expira mi certificado?

Podés correr openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null | openssl x509 -noout -dates en cualquier máquina con OpenSSL, o consultar crt.sh con tu dominio para ver toda la cadena emitida y sus fechas.

¿Tengo que cambiar de autoridad certificadora ya?

Solo si tenés vencimientos en menos de 24-48 horas. Para la mayoría de los casos, esperar a que Let's Encrypt restablezca el servicio es la opción más simple. Si manejás infraestructura crítica, vale la pena tener una CA secundaria preconfigurada como backup.

¿Qué pasa con los certificados wildcard?

Los wildcard usan el desafío DNS-01, que también pasa por la API ACME suspendida. Si dependés de wildcards para multi-tenancy, la suspensión te afecta exactamente igual que a los certificados regulares.

¿Hay diferencia entre el endpoint v2 y staging?

El staging existe para que los clientes prueben el flujo sin consumir la cuota de producción. Ambos están reportados como afectados, lo que sugiere que el problema no es de capacidad sino algo más profundo de la infraestructura compartida entre los dos ambientes.

¿Cuánto suele durar un incidente así?

Históricamente, los incidentes de emisión en Let's Encrypt han durado entre 2 y 8 horas. El de marzo de 2020 con la revocación CAA tardó 24 horas en resolverse del todo. La duración exacta depende de la complejidad del problema y de si requiere despliegue de código nuevo en producción.

Referencias

Let's Encrypt Status — Stopping Issuance for Potential Incident — aviso oficial del incidente del 8 de mayo de 2026.- Let's Encrypt Statistics — cifras públicas actualizadas de emisión y adopción.- RFC 8555 — Automatic Certificate Management Environment (ACME) — especificación oficial del protocolo.- letsencrypt/boulder en GitHub — código fuente del software CA usado por Let's Encrypt.- crt.sh — buscador público de certificados emitidos en Certificate Transparency logs.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Google, Microsoft y xAI aceptan pruebas federales de IA en EE.UU.

lu1tr0n — Fri, 08 May 2026 16:09:04 +0000

El 8 de mayo de 2026, tres de las compañías más influyentes en inteligencia artificial — Google, Microsoft y xAI — aceptaron formalmente someter sus modelos de frontera a pruebas federales IA coordinadas por el gobierno de Estados Unidos. El acuerdo, anunciado a través del U.S. AI Safety Institute (USAISI) dependiente del NIST, marca el primer marco voluntario tripartito entre rivales directos del sector y un regulador federal estadounidense desde la promulgación del Executive Order 14110 de octubre de 2023.

El pacto llega en un momento clave: la industria atraviesa una fase de despliegue acelerado de agentes autónomos, copilots de codificación y modelos multimodales con capacidades que superan benchmarks que se consideraban «techo» hace solo 18 meses. Para los reguladores, el riesgo ya no es teórico; para las compañías, el escrutinio público tampoco. Las pruebas federales IA acordadas combinan red-teaming, análisis de capacidades peligrosas, evaluación de sesgos y revisión de procesos internos de seguridad antes de lanzar versiones nuevas al mercado.

Qué pasó: el acuerdo del 8 de mayo

Según el reporte publicado por Euronews, los tres gigantes firmaron un memorándum de entendimiento con el USAISI que les obliga a entregar acceso temprano a sus modelos antes de su lanzamiento público. El alcance es amplio: cubre los modelos de frontera de cada empresa — los más grandes y capaces que están en producción o próximos a salir — y se extiende a versiones derivadas que reutilicen las capacidades base.

En la práctica, esto significa que Gemini de Google, los modelos GPT que Microsoft despliega vía Azure OpenAI Service, y Grok de xAI deberán pasar por evaluaciones federales antes de su disponibilidad general. El acuerdo también incluye reportes posteriores al lanzamiento — conocidos como post-deployment monitoring — cuando se detecten capacidades emergentes no previstas en las pruebas iniciales.

💭 Clave: Este es un acuerdo voluntario, no una ley. Eso significa que su fuerza viene de la reputación y la presión pública más que de sanciones legales. Si una empresa rompe el pacto, no hay multa automática, pero sí un costo político considerable.

Notablemente, OpenAI y Anthropic ya habían firmado un acuerdo similar con el USAISI en 2024, por lo que la incorporación de Google, Microsoft y xAI completa un grupo de cinco grandes laboratorios sometidos al mismo régimen de pruebas federales IA. Meta, por ahora, quedó fuera de este pacto particular.
Las pruebas federales se realizan en entornos aislados con acceso supervisado al modelo.

Contexto e historia: del Executive Order al pacto de 2026

Para entender por qué este acuerdo importa hay que remontarse a octubre de 2023, cuando la Casa Blanca firmó el Executive Order 14110 sobre desarrollo seguro de inteligencia artificial. Ese decreto, derogado parcialmente en enero de 2025 por la nueva administración, sentó las bases del marco actual: obligó a las empresas a reportar entrenamientos de modelos por encima de cierto umbral de cómputo (10^26 FLOPs) y creó el AI Safety Institute como brazo técnico del NIST.

Aunque el decreto fue debilitado, el USAISI sobrevivió y mantuvo sus convenios con la industria. La administración actual reorientó el enfoque desde «safety» hacia «competitividad nacional», pero conservó la infraestructura técnica de evaluación. El resultado: un instituto que sigue funcionando con un mandato modificado, más enfocado en riesgos catastróficos — armas químicas, biológicas, radiológicas y nucleares (CBRN), ciberseguridad ofensiva, manipulación masiva — que en sesgo o equidad.

El acuerdo del 8 de mayo refleja esa reorientación. Las pruebas federales IA pactadas se concentran en lo que los técnicos llaman «capacidades dual-use»: habilidades del modelo que tienen aplicaciones legítimas pero que también podrían facilitar ataques. Por ejemplo, un modelo que escribe código de manera excelente puede ayudar a un desarrollador o redactar un exploit; uno que entiende química puede ayudar a un investigador o asistir en la síntesis de armas.

Por qué xAI sorprendió

De los tres firmantes, xAI fue el más inesperado. Elon Musk había sido públicamente crítico de la regulación federal y prefería mecanismos de mercado. Sin embargo, xAI ha enfrentado escrutinio creciente por incidentes con Grok — especialmente alrededor de moderación de contenido y respuestas en temas políticamente sensibles — y la firma del pacto puede leerse como un movimiento de legitimación para acceder a contratos federales que requieren evaluaciones de seguridad documentadas.

Datos y cifras del acuerdo

Los detalles concretos publicados sobre las pruebas federales IA incluyen varios números que dimensionan el alcance del compromiso:

3 empresas firmantes: Google, Microsoft y xAI — sumadas a OpenAI y Anthropic que ya estaban dentro, son 5 grandes laboratorios.- ~90 días: ventana mínima de acceso al modelo antes del lanzamiento público, según los términos comunes de este tipo de acuerdos USAISI.- 13.5%: crecimiento proyectado del gasto en TI para 2026 según Gartner, en gran parte impulsado por inversión en IA — un mercado donde las pruebas federales IA pueden marcar diferencia competitiva.- $48B: capital de venture invertido en deep tech en 2026, sector que incluye laboratorios de IA y que ahora tendrá mayor visibilidad regulatoria.- ~75%: objetivo declarado por Meta para tener código escrito por IA hacia finales de 2026, cifra que ilustra cuán profundamente está integrada la IA en flujos productivos — y por qué importa auditarla.

💡 Tip: Si trabajás en una startup que usa modelos de Google, Microsoft o xAI vía API, este acuerdo te beneficia indirectamente: los modelos llegarán con menos sorpresas en producción porque ya pasaron por red-teaming federal antes del rollout público.

Impacto y análisis: lo que cambia para la industria

El efecto inmediato del acuerdo es procedimental: agrega una capa de revisión previa al lanzamiento. Pero el impacto más interesante es indirecto y se siente en varios frentes.

Para los desarrolladores

Las pruebas federales IA elevan el listón de lo que se considera «modelo listo para producción». Si un modelo nuevo de Gemini o GPT pasa por revisión del USAISI antes de salir, los desarrolladores que lo integren en aplicaciones tendrán más confianza en que ciertas capacidades peligrosas están contenidas. Esto reduce la carga de filtros adicionales en la capa de aplicación — aunque no la elimina.

El código de moderación típico en aplicaciones que usan LLMs sigue luciendo así:

// Patr&oacute;n com&uacute;n de validaci&oacute;n previa al modelo
async function safeGenerate(prompt: string) {
  const flagged = await contentClassifier.check(prompt);
  if (flagged.severity > 0.7) {
    throw new Error("Prompt rechazado por pol&iacute;tica");
  }
  const response = await model.generate(prompt);
  const audit = await contentClassifier.check(response);
  return audit.severity > 0.5 ? null : response;
}

Con modelos federalmente evaluados, los umbrales de detección pueden afinarse mejor porque el comportamiento del modelo subyacente es más predecible.

Para los inversionistas y founders

El acuerdo institucionaliza una señal que ya estaba en el mercado: los modelos auditados se están convirtiendo en activos diferenciados. Para una startup que vende a clientes regulados — salud, finanzas, gobierno — usar un modelo que pasó por pruebas federales IA es una ventaja comercial concreta. La cláusula «evaluado por el USAISI» empieza a funcionar como una insignia, análoga al SOC 2 Type II en SaaS empresarial.
Las evaluaciones cubren red-teaming, capacidades CBRN y resiliencia adversarial.

Para la geopolítica de la IA

El acuerdo también envía una señal hacia el exterior. La Unión Europea ha avanzado con el AI Act, y China operó durante años con su propio marco de revisión algorítmica. Estados Unidos, sin una ley federal de IA, había operado por ejecutiva y por convenios voluntarios. Este pacto consolida la línea estadounidense de «regulación por convenio»: menos prescriptiva que la europea, más flexible, pero con la ventaja de que todos los actores grandes están adentro.

flowchart LR
  A["Modelo entrenado"] --> B["Acceso al USAISI"]
  B --> C["Red-teaming federal"]
  C --> D["Reporte de hallazgos"]
  D --> E{"&iquest;Riesgos cr&iacute;ticos?"}
  E -- "S&iacute;" --> F["Mitigaci&oacute;n previa al lanzamiento"]
  E -- "No" --> G["Lanzamiento p&uacute;blico"]
  F --> G
  G --> H["Monitoreo post-deployment"]

Qué sigue: la hoja de ruta del AI Safety Institute

El USAISI tiene varios proyectos abiertos para los próximos meses. Entre los más relevantes para la industria figuran:

Benchmarks públicos de capacidades CBRN: el instituto trabaja en suites de pruebas reproducibles que cualquier laboratorio pueda aplicar, no solo los firmantes del acuerdo.- Marco de evaluación de agentes autónomos: con la explosión de agentes que ejecutan acciones — pagos, envío de mensajes, despliegue de código — se necesitan pruebas específicas para sistemas con capacidad de actuar, no solo de generar texto.- Coordinación internacional: el USAISI mantiene diálogo con el AI Safety Institute británico, el japonés y el de Singapur. Una versión futura del pacto podría incluir reconocimiento mutuo de evaluaciones, lo que reduciría la carga regulatoria de los laboratorios globales.

⚠️ Ojo: Aunque el acuerdo se anuncia como un avance, persisten críticas. Investigadores académicos sostienen que las pruebas federales IA dependen de información que las propias empresas suministran y que los plazos de evaluación suelen ser insuficientes para detectar capacidades emergentes sutiles. La transparencia de los reportes finales también es limitada.

Para los lectores de @programacion que siguen la evolución de la IA desde el lado técnico, este pacto importa por una razón concreta: marca el momento en que la auditoría externa de modelos pasó de ser un ejercicio académico aislado a una práctica institucional con cinco de los principales laboratorios alineados. Es un cambio de fondo, aunque su efectividad real solo se podrá juzgar por los próximos lanzamientos y cómo respondan los modelos en el mundo real.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es exactamente el U.S. AI Safety Institute?

Es una unidad técnica del National Institute of Standards and Technology (NIST) creada en 2023 para evaluar modelos de IA de frontera y desarrollar estándares de medición. No tiene poder sancionador directo, pero sus reportes influyen en política federal y en decisiones de compra del gobierno.

¿El acuerdo obliga a Google, Microsoft y xAI a publicar los resultados de las pruebas?

No. Los términos estándar de este tipo de pactos contemplan reportes confidenciales al gobierno y un resúmen público de alto nivel. Los detalles técnicos — vectores de ataque específicos, prompts de red-teaming — se mantienen reservados para evitar que sirvan de guía a actores maliciosos.

¿Por qué Meta no firmó?

Meta no aparece entre los firmantes de este acuerdo particular. La compañía ha mantenido una postura distinta sobre regulación y publica abiertamente sus modelos Llama, lo que cambia el cálculo de qué significa «evaluación previa al lanzamiento» cuando los pesos se distribuyen libremente. No se descarta una incorporación posterior.

¿Esto reemplaza al AI Act europeo?

No. El AI Act es ley vinculante en la Unión Europea con sanciones económicas. El acuerdo del USAISI es voluntario y aplica solo en EE.UU. Las empresas que operan globalmente deben cumplir ambos marcos, que no son equivalentes en alcance ni mecanismos de enforcement.

¿Cómo afecta esto a desarrolladores fuera de Estados Unidos?

Indirectamente, de forma positiva: si un modelo se evaluó antes de su lanzamiento, los problemas de seguridad detectados se mitigan antes de llegar a producción global. Los desarrolladores en LATAM, por ejemplo, reciben modelos más «curados». Pero las políticas de uso de cada API siguen siendo responsabilidad del desarrollador local.

¿Cuándo veremos el primer modelo lanzado bajo este régimen?

Los próximos lanzamientos mayores de Gemini, los modelos GPT distribuidos por Azure y las versiones siguientes de Grok deberían ser los primeros en pasar por el proceso completo. Es razonable esperar la primera referencia pública al USAISI en notas de lanzamiento durante el segundo semestre de 2026.

Referencias

Euronews — Tech giants agree to US government AI testing — reporte original del acuerdo del 8 de mayo de 2026.- University of California — 11 things AI experts are watching for in 2026 — contexto sobre prioridades regulatorias y técnicas del año.- Andreessen Horowitz — Notes on AI Apps in 2026 — análisis del estado de la industria de aplicaciones de IA.- Exploding Topics — 45+ Artificial Intelligence Statistics (Jan 2026) — estadísticas actualizadas del sector que dimensionan el alcance del acuerdo.- MIT Technology Review — AI Companions: 10 Breakthrough Technologies 2026 — análisis editorial del contexto de despliegue de modelos.

WebTransport en 2026: el reemplazo de WebSocket sobre HTTP/3

lu1tr0n — Fri, 08 May 2026 16:05:25 +0000

Si llevás años usando WebSocket para todo lo que necesite tiempo real en el navegador (chat, notificaciones, juegos, dashboards en vivo), 2026 es el año en que conviene mirar a su reemplazo natural. WebTransport es una API de la web moderna construida directamente sobre HTTP/3 y QUIC que ofrece todo lo que WebSocket hace bien y resuelve casi todo lo que hace mal: head-of-line blocking, multiplexación pobre, latencia inicial alta y la imposibilidad de enviar mensajes no confiables.

En esta guía explicamos qué es WebTransport, cómo funciona por dentro, cuándo elegirlo sobre WebSocket o WebRTC, qué soporte tiene en navegadores y servidores en mayo de 2026, y qué patrones de código necesitás para empezar a usarlo desde un cliente JavaScript y un servidor en Node.js, Go o Rust. La idea es que termines con criterio para decidir si vale la pena migrar tu próxima app real-time o esperar un poco más.

Qué es WebTransport

WebTransport es una API JavaScript expuesta en el navegador que permite establecer conexiones cliente-servidor bidireccionales de baja latencia. Está estandarizada por el W3C como API web y por el IETF como protocolo de transporte. La diferencia clave con WebSocket es que WebTransport no corre sobre TCP+TLS, sino sobre QUIC, el protocolo de transporte que también sustenta a HTTP/3.

Esto suena a un detalle de bajo nivel, pero tiene consecuencias enormes para cualquier aplicación en tiempo real. WebSocket, al ser una capa sobre TCP, hereda problemas como el head-of-line blocking, donde un solo paquete perdido detiene todos los mensajes posteriores aunque viajen por flujos lógicos distintos. QUIC resuelve eso permitiendo múltiples streams independientes dentro de una misma conexión, y WebTransport expone esos streams al desarrollador web sin que tenga que tocar nada de QUIC directamente.

Otra diferencia fundamental: WebTransport ofrece dos modos de transporte coexistiendo en una misma conexión:

Streams confiables: similares a TCP, garantizan orden y entrega. Útiles para chat, comandos de aplicación, sincronización de estado.- Datagramas no confiables: similares a UDP, no garantizan entrega ni orden, pero llegan con la mínima latencia posible. Ideales para telemetría, audio en vivo, posiciones de juego, cursores colaborativos.

WebSocket no tiene la opción de datagramas no confiables. Si usabas WebSocket para enviar la posición del mouse 60 veces por segundo en un juego multijugador, cada paquete perdido bloqueaba a los siguientes hasta que TCP retransmitiera. Con WebTransport simplemente lo mandás como datagrama y seguís adelante; los datos viejos se descartan solos.

Cómo funciona WebTransport

Para entender por qué WebTransport es más rápido, hay que pensar en capas. Una conexión WebSocket tradicional pasa por:

Un handshake TCP de tres paquetes.- Un handshake TLS de uno o dos RTTs adicionales.- Un handshake HTTP de upgrade que cambia el protocolo a WebSocket.- Recién ahí podés enviar mensajes.

Una conexión WebTransport sobre HTTP/3 reemplaza todo eso por un único handshake QUIC que combina transporte, cifrado y reanudación en muy pocos paquetes. En reconexiones puede llegar a 0-RTT, donde el primer paquete del cliente ya transporta datos útiles. Para el desarrollador la API se siente parecida a WebSocket, pero la latencia inicial cae drásticamente, sobre todo en redes móviles inestables.
Pila de protocolos que sustenta a WebTransport en el navegador.
Una vez establecida la sesión, el cliente puede abrir múltiples streams bidireccionales o unidireccionales y enviar datagramas en paralelo. El servidor responde por el mismo canal QUIC. Si la red se degrada, QUIC migra la conexión sin tirarla, algo que TCP simplemente no puede hacer porque está atado a la cuádrupla IP origen, IP destino, puerto origen, puerto destino. QUIC identifica conexiones por un Connection ID lógico, así que el cliente puede pasar de WiFi a 4G y la sesión sobrevive.

graph TB
  A["Navegador"] --> B["WebTransport API"]
  B --> C["HTTP/3"]
  C --> D["QUIC + TLS 1.3"]
  D --> E["UDP"]
  E --> F["IP"]

El servidor debe soportar HTTP/3 explícitamente y aceptar el método CONNECT con el protocolo WebTransport. La negociación pasa por ALPN, así que el navegador y el servidor se ponen de acuerdo en una sola pasada.

Ejemplos prácticos en el navegador

La API en el cliente es sencilla. Conectarse a un servidor WebTransport requiere HTTPS con HTTP/3 y un certificado válido o un hash de certificado autofirmado autorizado mediante serverCertificateHashes. Acá un ejemplo mínimo:

const transport = new WebTransport('https://example.com:4433/echo');
await transport.ready;

// Enviar un datagrama no confiable
const writer = transport.datagrams.writable.getWriter();
await writer.write(new TextEncoder().encode('ping'));

// Abrir un stream bidireccional confiable
const stream = await transport.createBidirectionalStream();
const streamWriter = stream.writable.getWriter();
await streamWriter.write(new TextEncoder().encode('hola servidor'));
await streamWriter.close();

La promesa transport.ready se resuelve cuando la sesión QUIC ya está establecida y el handshake de WebTransport terminó. A partir de ahí tenés tres canales:

transport.datagrams: para datagramas individuales, no confiables.- transport.createBidirectionalStream(): streams full-duplex confiables.- transport.createUnidirectionalStream(): streams en un solo sentido, útiles cuando solo el cliente o solo el servidor produce datos.

Para leer datos entrantes, la API usa Readable y Writable Streams nativos del navegador, lo que permite encadenar transformaciones con pipeThrough sin código extra:

const reader = transport.datagrams.readable.getReader();
while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  console.log('datagrama:', new TextDecoder().decode(value));
}

En el lado servidor podés usar @fails-components/webtransport en Node.js, quic-go en Go, o wtransport en Rust. Las tres son implementaciones del draft IETF y se mantienen activas. Cloudflare Workers también expone WebTransport en su runtime desde 2025, y Deno tiene soporte experimental directo en su runtime sin librerías externas.

💡 Tip: Para desarrollo local sin certificado válido, Chrome acepta --origin-to-force-quic-on=localhost:4433 y --ignore-certificate-errors-spki-list. Es la forma más rápida de probar un servidor WebTransport en tu máquina sin pelear con CA locales.

Casos de uso reales

WebTransport brilla en escenarios donde WebSocket sufría:

Juegos en el navegador: posiciones de jugadores, eventos de input y voz se envían como datagramas no confiables; el chat o cambios persistentes del mundo van como streams confiables. Empresas como Hathora y Colyseus ya tienen adaptadores listos.- Streaming de video low-latency: experimentos públicos de Twitch, YouTube y Meta usan WebTransport para distribuir segmentos de video con menos buffering que HLS o DASH sobre TCP. El protocolo Media over QUIC (MoQ) está construido sobre WebTransport.- Telemetría IoT en el navegador: dashboards que reciben miles de métricas por segundo se benefician de no tener head-of-line blocking, especialmente cuando la red móvil del operador pierde paquetes.- Edición colaborativa: aunque CRDTs tradicionales viven sobre WebSocket, WebTransport mejora la sincronización en redes inestables y permite enviar la posición del cursor por datagrama mientras los cambios reales viajan por stream confiable.- Aplicaciones de trading: cada milisegundo cuenta y los datagramas permiten descartar precios viejos sin bloquear el resto de la información. WebTransport habilita juegos, video low-latency y telemetría sin compromisos. ## Ventajas y desventajas

Ventajas

Sin head-of-line blocking: cada stream avanza independientemente del resto.- Datagramas no confiables nativos: por fin un equivalente a UDP en el navegador sin tener que recurrir a WebRTC y su complejidad de signaling y NAT traversal.- Conexión 0-RTT en reconexiones: latencia inicial mínima cuando el cliente ya conectó antes.- Migración de conexión: si cambiás de WiFi a 4G la sesión sobrevive sin reabrir handshake.- Mejor multiplexación: una sola conexión QUIC sirve para muchos streams paralelos sin penalidad.- Cifrado obligatorio: TLS 1.3 va integrado en QUIC, no podés desactivarlo aunque quieras.

Desventajas

Soporte de navegador desigual: Chromium implementa la mayor parte, Firefox tiene soporte parcial, Safari va un paso atrás.- Requiere HTTPS y HTTP/3 en el servidor: no podés probar en localhost sin certificado salvo con flags específicos del navegador.- Ecosistema joven: bibliotecas todavía cambian de API entre versiones menores y la documentación a veces va atrás del código.- Más complejo que WebSocket: ahora tenés que decidir cuándo usar streams vs datagramas, y manejar la lógica de cada caso.- UDP bloqueado en redes corporativas: muchos firewalls de empresa filtran UDP en puerto 443, así que la conexión cae a HTTP/2 o falla directamente.- Debugging menos maduro: las DevTools recién agregan soporte completo y los proxies tradicionales de inspección no lo entienden.

WebTransport vs WebSocket vs WebRTC

Una confusión común es cuándo usar cada uno. Acá un resumen práctico para 2026:

WebSocket sigue siendo la opción más sencilla y compatible. Si tu app no necesita datagramas y manda mensajes pequeños sobre redes estables, no tiene sentido cambiar a WebTransport.- WebRTC es para comunicación peer-to-peer (videollamadas, juegos P2P). Es complejo, tiene su propio stack de NAT traversal, ICE y STUN/TURN, y no se justifica para arquitecturas cliente-servidor tradicionales.- WebTransport ocupa el espacio cliente-servidor donde WebSocket queda corto: necesitás múltiples streams paralelos, datagramas no confiables, latencia mínima en reconexiones, o todo a la vez en la misma sesión.

💭 Clave: La regla simple: si tu app sufría con WebSocket en redes móviles o en escenarios con muchos canales lógicos paralelos, probá WebTransport. Si nunca tuviste un problema, no rompas lo que funciona.

Estado del soporte en navegadores

A mayo de 2026 el panorama es razonablemente saludable:

Chrome y Edge: soporte estable desde la versión 97 (2022), con la API completa y datagramas funcionando bien.- Firefox: soporte estable desde Firefox 114, con algunas funciones avanzadas aún detrás de flags about:config.- Safari: soporte experimental, llega gradualmente con WebKit y todavía no se considera production-ready.- Node.js: vía bibliotecas externas, no en el core.- Deno y Bun: Deno tiene soporte experimental nativo desde 2024; Bun lo tiene en roadmap.- CDN y edge runtimes: Cloudflare Workers expone WebTransport en producción; Fastly tiene un beta cerrado; Akamai todavía no ofrece.

Para producción, WebTransport ya es viable cuando tu audiencia mayoritariamente usa Chromium. En entornos mixtos conviene aplicar feature detection con 'WebTransport' in globalThis y caer a WebSocket como fallback. Algunas librerías como libp2p o partykit ya lo hacen automáticamente.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿WebTransport reemplaza a WebSocket?

No de forma inmediata. WebSocket seguirá funcionando muchos años por compatibilidad y simplicidad. WebTransport es la opción moderna para casos donde WebSocket queda corto (datagramas, multiplexación, redes móviles inestables), pero para apps simples WebSocket sigue siendo válido y recomendable.

¿Necesito un servidor especial para usar WebTransport?

Sí. El servidor debe soportar HTTP/3 (QUIC) y la extensión WebTransport. Bibliotecas como quic-go en Go, wtransport en Rust o @fails-components/webtransport en Node ya lo implementan con APIs estables. Cloudflare Workers y Deno también exponen WebTransport server-side sin librerías externas.

¿Funciona detrás de proxies corporativos?

QUIC corre sobre UDP en el puerto 443. Algunos firewalls corporativos bloquean UDP saliente, lo que rompe WebTransport. En esos casos los navegadores caen a HTTP/2 sobre TCP donde sea posible, o directamente fallan. Si tu producto vende a empresas reguladas, mantené un fallback a WebSocket sí o sí.

¿WebTransport es siempre más rápido que WebSocket?

No siempre. En conexiones perfectas y mensajes pequeños la diferencia es mínima y a veces favorece a WebSocket por menor overhead. La ganancia se ve en redes con pérdida de paquetes, dispositivos móviles que cambian de red, o aplicaciones con muchos streams paralelos donde TCP genera head-of-line blocking.

¿Puedo usar WebTransport con CDN?

Cloudflare, Fastly y otros CDN ya soportan HTTP/3, pero el soporte de WebTransport como tal todavía es desigual. Cloudflare Workers fue el primero entre los grandes proveedores en exponerlo en producción, y suma soporte servidor-a-servidor en 2026 con la nueva ola de productos para agentes.

¿Cómo se debugea una conexión WebTransport?

Chrome DevTools tiene una pestaña Network que muestra streams y datagramas individuales con timing detallado. También podés capturar paquetes con Wireshark, que entiende QUIC desde versiones recientes si exportás SSLKEYLOGFILE desde el navegador para descifrar el tráfico TLS 1.3.

Referencias

MDN: WebTransport API — documentación completa de la API en el navegador con ejemplos.- W3C: WebTransport — especificación oficial de la API web.- IETF: WebTransport over HTTP/3 — draft del protocolo de transporte.- web.dev: Experimenting with WebTransport — guía práctica de Google con ejemplos cliente y servidor.- Can I use: WebTransport — tabla actualizada de soporte por navegador.- GitHub: w3c/webtransport — repositorio oficial del estándar y discusiones abiertas.

Anthropic ficha el data center de SpaceX para expandir Claude

lu1tr0n — Fri, 08 May 2026 14:17:09 +0000

La carrera por la capacidad de cómputo en inteligencia artificial sumó este 8 de mayo un capítulo inesperado: Anthropic, la empresa creadora de Claude, está accediendo a infraestructura de data center asociada a SpaceX para expandir la capacidad de servir su modelo a empresas, desarrolladores y agentes autónomos. La noticia, difundida por medios financieros como TradingView, confirma una tendencia que venía marcándose desde hace meses: los laboratorios de IA punteros ya no compiten solo por talento o por datos, compiten por watts, GPUs y suelo industrial. Y para conseguirlos, están firmando alianzas con jugadores que hace cinco años nadie habría imaginado en el tablero. La alianza Anthropic SpaceX no es un acuerdo de marketing: es una respuesta directa al cuello de botella físico que está limitando el despliegue de modelos como Claude Opus, Claude Sonnet y Claude Haiku, hoy presentes en flujos productivos de bancos, startups, gobiernos y herramientas de programación en todo el mundo.

Qué pasó: Anthropic accede al data center de SpaceX

Según los reportes publicados durante la primera semana de mayo de 2026, Anthropic firmó un acuerdo con SpaceX para hacer uso de capacidad en uno de los centros de datos del operador espacial en territorio estadounidense. El movimiento se suma a la red de proveedores de cómputo que la compañía ya utiliza, que incluye relaciones públicas con Amazon Web Services y Google Cloud, además de hardware especializado de Trainium e Inferentia.

La compañía liderada por Dario Amodei no ha publicado el detalle financiero del trato, pero analistas del sector estiman que se trata de un acuerdo plurianual orientado a aliviar la presión de inferencia sobre el modelo Claude, que en 2026 maneja un volumen de tokens diarios sin precedentes. La adopción masiva de la API por parte de plataformas como Cursor, Windsurf, Vercel, Replit y un creciente número de agentes autónomos basados en MCP ha multiplicado la demanda de capacidad.

El acuerdo Anthropic SpaceX responde al cuello de botella global de capacidad para servir modelos como Claude.

Contexto: la carrera global por la infraestructura de IA

Para entender por qué este acuerdo importa, hay que mirar el tablero completo. Desde 2023, los laboratorios de IA empezaron a darse cuenta de que el factor limitante no iba a ser la algoritmia, sino la capacidad física: hectáreas de tierra, gigavatios de electricidad estable, líneas de alta tensión y, sobre todo, GPUs Nvidia. La demanda creció más rápido que la oferta. Microsoft anunció su proyecto Stargate con OpenAI con un compromiso de inversión que en algunos reportes superó los 100 mil millones de dólares. Google reaccionó duplicando la producción de TPUs en sus instalaciones propias. Meta construyó Hyperion en Luisiana. Y los hyperscalers compraron literalmente reactores nucleares para asegurarse el suministro eléctrico.

Por qué entra SpaceX en este negocio

SpaceX, hasta ahora vista como una empresa de cohetes y satélites, ha estado discretamente construyendo activos compatibles con la operación de data centers: terrenos amplios en Texas y Florida cerca de Starbase y Cape Canaveral, contratos de energía a gran escala, una red Starlink propia que reduce dependencia de proveedores tradicionales de fibra, y experiencia gestionando sistemas de cómputo críticos para misiones espaciales. La compañía empezó a explorar formalmente el negocio de cómputo de IA durante 2025, en parte gracias a las sinergias con xAI, el laboratorio de Elon Musk dueño de Grok.

El movimiento de Anthropic, sin embargo, es más interesante por lo que dice del mercado. Anthropic compite directamente con xAI en varios benchmarks. Que decida confiar parte de su capacidad de servir Claude a infraestructura conectada al ecosistema Musk envía un mensaje pragmático: la guerra por GPUs trasciende las afinidades corporativas. Hoy, quien tiene capacidad lista vende, sin importar la rivalidad de productos.

💭 Clave: En 2026 ya no hay un mercado de infraestructura para IA: hay un mercado de favores con contrato, donde quien firma primero asegura GPUs por años. El acuerdo Anthropic SpaceX se entiende mejor desde esa óptica.

Datos y cifras del ecosistema de cómputo IA

Algunos números ayudan a dimensionar la presión que enfrenta Anthropic. Claude superó los 19 millones de usuarios activos mensuales en su aplicación durante 2025, según métricas de adopción reportadas en la prensa especializada. La API ha sido adoptada por más del 60% de las nuevas startups del último batch de Y Combinator. La función de computer use y los agentes basados en MCP están impulsando flujos donde un solo usuario consume 10 a 50 veces más tokens que un usuario tradicional de chat.

En paralelo, el costo del cómputo cayó solo de forma marginal. Una GPU H200 sigue costando entre 30 y 40 mil dólares, una B200 más del doble, y el plazo de entrega de Nvidia se mide en trimestres, no en semanas. La energía es el segundo cuello de botella: un data center moderno de IA consume entre 100 y 500 megavatios, suficiente para abastecer ciudades enteras. Por eso quien tenga acceso temprano a kilovatios firmes, está vendiendo oro.

Por qué SpaceX entra al juego de la IA

SpaceX trae al ecosistema cuatro activos no triviales. Primero, terrenos industriales con permisos ya tramitados para uso intensivo de energía, herencia de su operación de cohetería. Segundo, capacidad de generar y consumir grandes cantidades de electricidad sin depender de la red pública en algunos casos. Tercero, Starlink: la red satelital permite que sus data centers tengan opciones de respaldo de conectividad únicas, lo que reduce el riesgo operacional para clientes que sirven cargas críticas. Cuarto, ingeniería de sistemas de altísimo rendimiento, con experiencia en operar hardware en condiciones extremas.

SpaceX combina experiencia energética, terreno industrial y conectividad satelital para entrar al negocio de cómputo de IA.

Impacto y análisis: qué significa para Claude

Para los usuarios finales y para los desarrolladores, el acuerdo Anthropic SpaceX se traduce en cuatro implicaciones concretas. La primera es menor latencia en momentos de alto tráfico, porque Anthropic puede balancear carga entre más data centers regionales. La segunda es mayor disponibilidad: las caídas y rate limits que afectaron a la API durante 2025 deberían volverse menos frecuentes. La tercera es tiers de servicio nuevos: con más capacidad, Anthropic puede ofrecer batch jobs más generosos, ventanas de contexto efectivamente más usables y agentes con sesiones largas sin estrangular el throughput. Y la cuarta es presión a la baja en precios a mediano plazo, aunque el corto plazo seguirá dominado por el costo del hardware.

El siguiente diagrama resume cómo se conectan los actores del acuerdo:

graph LR
  A[Anthropic] --> B["SpaceX Data Center"]
  B --> C["GPUs + energia"]
  C --> D[Claude]
  D --> E["Usuarios y agentes"]
  D --> F["API empresarial"]

Para los desarrolladores que construyen sobre la API de Claude, el cambio será silencioso pero importante. Un endpoint más confiable significa poder ofrecer SLAs más agresivos a clientes empresariales. Para quienes operan agentes basados en computer use o herramientas, significa poder dejar correr loops más largos sin chocar contra rate limits.

Implicaciones para desarrolladores en LATAM

El acuerdo Anthropic SpaceX no incluye, hasta donde se sabe, infraestructura específica en Latinoamérica. La región sigue dependiendo de regiones de AWS y GCP en Estados Unidos para servir Claude, lo que se traduce en latencias de entre 80 y 180 milisegundos para usuarios en México, Brasil, Argentina o El Salvador. Más capacidad agregada en Norteamérica, sin embargo, sí beneficia indirectamente a la región: menos congestión en horas pico, menos errores 529 y mejor disponibilidad para los workflows automatizados que muchas startups latinoamericanas ya usan en producción.

El siguiente snippet muestra cómo verificar el estado de la API y configurar reintentos elegantes en Python, una práctica que se vuelve menos crítica conforme la capacidad mejora, pero que sigue siendo recomendable:

from anthropic import Anthropic
import time

client = Anthropic()

def call_with_retry(prompt, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.messages.create(
                model="claude-opus-4-7",
                max_tokens=1024,
                messages=[{"role": "user", "content": prompt}],
            )
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            time.sleep(2 ** attempt)

💡 Tip: Si tu producto sirve usuarios en LATAM, configurá un proxy de cache y un sistema de reintentos exponenciales como el de arriba. Aún cuando Anthropic expanda capacidad, la latencia transcontinental seguirá siendo tu enemigo principal.

Qué sigue

El acuerdo abre tres preguntas que el sector responderá en los próximos meses. La primera: ¿se sumarán otros laboratorios al modelo de comprar capacidad a operadores no tradicionales como SpaceX, o será un caso aislado? La segunda: ¿qué tan profundo es el compromiso de SpaceX con el negocio de cómputo, y veremos a Starlink ofrecer servicios de inferencia distribuida? La tercera, más estratégica: si la infraestructura crítica para servir IA termina concentrada en pocas manos, ¿qué presiones regulatorias enfrentará el sector? El Departamento de Justicia de Estados Unidos y la Comisión Europea ya están revisando los acuerdos entre Microsoft y OpenAI; un patrón similar con Anthropic y SpaceX podría reabrir el debate antimonopolio que rondó al sector tecnológico durante toda la década pasada.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿El acuerdo Anthropic SpaceX significa que Claude se entrenará en hardware de SpaceX?

Los reportes apuntan a uso de infraestructura para servir el modelo, es decir, inferencia, más que entrenamiento. El entrenamiento de los modelos fundacionales de Anthropic sigue corriendo principalmente en clústers de Trainium y GPUs en regiones de AWS y Google Cloud.

¿Mejorará la latencia para usuarios en Latinoamérica?

Indirectamente. La capacidad agregada está en Norteamérica, pero al reducir la congestión global, los usuarios latinoamericanos verán menos errores y mejor consistencia en horas pico. La latencia base seguirá determinada por la distancia geográfica.

¿Qué pasa con la rivalidad entre Anthropic y xAI, también vinculada a Musk?

El acuerdo es contractual y operativo, no estratégico. SpaceX y xAI son empresas distintas con accionistas comunes, pero la operación de un data center se rige por contratos comerciales. Anthropic no comparte modelos ni propiedad intelectual con SpaceX por usar su infraestructura.

¿Cuánto cuesta el acuerdo?

Las cifras no son públicas. Acuerdos comparables en el sector, como los firmados por OpenAI con Oracle o por Meta con CoreWeave, oscilan entre miles de millones de dólares anuales. Es razonable suponer que este acuerdo está en el mismo orden de magnitud.

¿Cómo afecta esto a desarrolladores que ya usan la API de Claude?

De forma positiva: más capacidad significa menos rate limits, menor probabilidad de errores 529 y mejor estabilidad para flujos de agentes. Conviene mantener buenas prácticas de reintentos exponenciales y caches, pero el ambiente operativo debería ser progresivamente más confiable.

¿Es probable que veamos más alianzas de este tipo?

Sí. La oferta de cómputo para IA está restringida y todos los laboratorios punteros buscan cualquier fuente con permisos, energía y GPUs disponibles. Es esperable ver acuerdos con operadores de telecomunicaciones, energéticas y empresas industriales reconvertidas a data centers durante el resto de 2026.

Referencias

TradingView vía Google News — Cobertura del acuerdo Anthropic-SpaceX para expansión de capacidad de Claude.
Anthropic — Sitio oficial de la empresa creadora de Claude, con documentación de modelos y API.
Wikipedia: Anthropic — Resumen histórico de la compañía, sus inversores y su estructura corporativa.
Wikipedia: SpaceX — Antecedentes de SpaceX, sus operaciones e infraestructura industrial.

ClojureScript 1.12.145: async/await nativo con el hint ^:async

lu1tr0n — Fri, 08 May 2026 08:18:39 +0000

ClojureScript dio un paso importante en su evolución como lenguaje compilable a JavaScript: la versión 1.12.145, publicada el 7 de mayo de 2026, incorpora soporte nativo para funciones async/await mediante un simple hint de metadata. Para los desarrolladores que escriben clojurescript async y necesitan interactuar con APIs modernas del navegador o librerías basadas en promesas, este cambio elimina la necesidad de envolver código en macros o sumar dependencias externas.

El anuncio, hecho por el equipo oficial de ClojureScript en su sitio, marca el primer ajuste relevante después de la migración del compilador a ECMAScript 2016 como target. Lo curioso del cambio no es la complejidad técnica, sino lo silencioso de su llegada: una característica que dominó la lista de mejoras más pedidas en la última Clojure Survey termina implementándose con apenas un caracter de notación.

Qué pasó: ClojureScript 1.12.145 estrena el hint ^:async

El equipo de ClojureScript, mantenido por la comunidad alrededor de Cognitect y respaldado por Rich Hickey, liberó la versión 1.12.145 con un cambio puntual pero de alto impacto: la posibilidad de marcar funciones con metadata ^:async para que el compilador emita una función asíncrona nativa de JavaScript en lugar de la implementación tradicional basada en core.async o macros como las que ofrece la librería promesa.

El uso es directo. Cuando una función se anota con ^:async, el compilador detecta llamadas a (await ...) dentro del cuerpo y las traduce a la sintaxis nativa await de JavaScript. La función resultante es indistinguible de una async function escrita a mano en JS, lo que significa que se puede pasar a librerías que esperan promesas, encadenar con .then() o invocar desde código JavaScript externo sin envolturas.

(refer-global :only '[Promise])

(defn ^:async foo [n]
  (let [x (await (Promise/resolve 10))
        y (let [y (await (Promise/resolve 20))]
            (inc y))
        f (fn [] 20)]
    (+ n x y (f))))

El soporte se extiende a los tests con clojure.test: marcando un deftest con ^:async, el harness de pruebas espera correctamente la resolución de promesas antes de evaluar las aserciones. Esto resuelve uno de los puntos más frustrantes del testing en ClojureScript, donde los tests asincrónicos requerían setup adicional o macros como async de cljs.test.
El compilador transforma ^:async en async function nativa de JavaScript.

Contexto e historia: ClojureScript y la deuda con JavaScript moderno

ClojureScript nació en 2011 como una variante del lenguaje Clojure que compila a JavaScript. Durante más de una década, el equipo se mantuvo conservador con el target del compilador, generando código compatible con navegadores antiguos para garantizar la portabilidad. La consecuencia: features modernas de JavaScript como async/await, Symbol, generadores nativos o BigInt no estaban disponibles directamente desde el lenguaje.

Quienes querían usar promesas en ClojureScript tenían tres caminos. El primero, core.async, ofrecía channels y go blocks pero introducía un modelo mental distinto al de la comunidad JavaScript. El segundo, librerías como promesa de Funcool, daban macros como p/let que simulaban await pero requerían adoptar una dependencia externa. El tercero, el más sucio, era escribir .then manual con callbacks anidados.

El salto a ECMAScript 2016 como target del compilador, que ocurrió en una versión anterior, abrió la puerta a aprovechar features modernas. El equipo dejó claro que la elección sería selectiva: no todo lo nuevo de JavaScript se incorporaría por defecto, solo aquello que aportara valor real a la interop. Las funciones async cumplen ese criterio porque son hoy el estándar de facto para trabajar con APIs del navegador, fetch, IndexedDB, Web Workers y la mayoría de librerías npm.

Datos y cifras: el hint ^:async en la práctica

La implementación es minimalista. El hint ^:async es metadata estándar de Clojure que se aplica a la función. Cuando el compilador procesa la definición, verifica esta metadata y genera código JavaScript con la palabra reservada async en la declaración. Las llamadas a (await expr) dentro del cuerpo se traducen a la expresión await expr de JavaScript, respetando el ámbito léxico.

Tres detalles técnicos que vale destacar:

Closures internas no heredan — Una función anónima creada dentro del cuerpo de una función async no es automáticamente async. El ejemplo del anuncio lo deja claro: (fn [] 20) dentro de foo sigue siendo síncrona y no admite await.- Compatible con apply — El test del anuncio muestra que se puede invocar la función async con apply y la promesa resultante funciona igual: (await (apply foo [10])) devuelve el mismo valor que la llamada directa.- Manejo de errores con try/catch — Los rechazos de promesas se propagan como excepciones dentro del bloque async, capturables con (catch :default _ ...) de manera idéntica a un try/catch sincrónico, lo que mantiene consistencia con el resto del lenguaje.

💡 Tip: Si vienes de core.async, no hace falta migrar todo. Las funciones async y los go blocks pueden convivir en el mismo proyecto. Usá ^:async para interop con APIs basadas en promesas y core.async para flujos de datos internos con backpressure.

Sobre el contribuidor: el cambio fue aportado por Michiel Borkent, una figura conocida en la comunidad Clojure. Borkent es el creador de Babashka, nbb y squint, herramientas que ya ofrecían interop con async/await fuera del compilador oficial. Que la implementación canónica venga de su mano da continuidad técnica entre los proyectos del ecosistema y reduce la fragmentación.

Impacto y análisis: por qué importa para LATAM

Para los equipos que usan ClojureScript en producción —en LATAM se concentran en startups financieras de Argentina y Brasil, agencias de Chile y Colombia, y proyectos de gobierno digital en México y Uruguay— el impacto es práctico y medible:

Menos código boilerplate — Reemplazar p/let de promesa o canales de core.async por ^:async y await reduce líneas y simplifica el flujo de control.- Menor superficie de dependencias — Cada librería externa es deuda técnica futura. Tener async/await nativo significa una dependencia menos en el bundle final, lo que también reduce tamaño descargado para usuarios con conexiones lentas, un factor relevante en mercados con redes móviles dominantes.- Mejor onboarding — Los desarrolladores nuevos que llegan desde JavaScript o TypeScript reconocen async/await al instante. La curva de aprendizaje del paradigma asíncrono se aplana y facilita justificar la adopción del lenguaje en equipos mixtos.- Tests más simples — La integración con deftest evita el lío de envolver aserciones en callbacks. Un test async se lee como un test síncrono, lo que mejora la mantenibilidad a largo plazo. Flujo simplificado de una función ^:async interactuando con una API. Vale poner el cambio en perspectiva. ClojureScript no es un lenguaje masivo. Las estadísticas de descargas en Clojars y Maven Central sugieren que el ecosistema entero suma cerca de 50.000 desarrolladores activos en el mundo, una fracción del millonario universo de JavaScript. Pero los proyectos que lo usan tienden a ser de alta calidad técnica: Nubank construyó su core bancario en Clojure y usa ClojureScript en su frontend, Cognitect (hoy parte de Nubank) lo creó, y CircleCI tuvo gran parte de su pipeline en él durante años.

El impacto, entonces, es de palanca: una mejora pequeña en una herramienta usada por equipos con alto leverage técnico se traduce en miles de horas ahorradas globalmente. Y el patrón de adopción del feature seguirá la misma curva que vimos con TypeScript estricto o ESM en Node: lento al principio, dominante en cuestión de meses una vez que las herramientas tooling se actualizan.

Cómo migrar tu código existente

Si ya tenés un proyecto ClojureScript en producción, los pasos para empezar a usar el feature son directos.

Instalación: actualizar la dependencia

En tu archivo deps.edn:

{:deps {org.clojure/clojurescript {:mvn/version "1.12.145"}}}

Para Leiningen en project.clj:

(defproject mi-proyecto "0.1.0"
  :dependencies [[org.clojure/clojurescript "1.12.145"]])

Para shadow-cljs en shadow-cljs.edn:

{:dependencies [[thheller/shadow-cljs "2.27.0"]
                [org.clojure/clojurescript "1.12.145"]]}

Primer ejemplo: fetch a una API REST

(refer-global :only '[fetch])

(defn ^:async cargar-usuario [id]
  (let [resp (await (fetch (str "/api/users/" id)))
        data (await (.json resp))]
    {:id (.-id data)
     :nombre (.-nombre data)
     :email (.-email data)}))

El equivalente con la librería promesa requería más código y una dependencia adicional:

(require '[promesa.core :as p])

(defn cargar-usuario [id]
  (p/let [resp (fetch (str "/api/users/" id))
          data (.json resp)]
    {:id (.-id data)
     :nombre (.-nombre data)
     :email (.-email data)}))

⚠️ Ojo: Toda función que use ^:async retorna una Promise, incluso cuando el cuerpo no espera nada. Quien la consume debe estar preparado para manejarla como promesa. Esto puede romper código existente que asumía retorno sincrónico — revisá los call sites antes de migrar masivamente.

Diagrama: cómo se compila una función async

flowchart LR
    A["Codigo CLJS con metadata async"] --> B["Compilador ClojureScript 1.12.145"]
    B --> C["Detecta hint async"]
    C --> D["Detecta llamadas await"]
    D --> E["Emite async function de JS"]
    E --> F["JavaScript ejecutable en navegador"]

Qué sigue

El equipo de ClojureScript no ha publicado un roadmap detallado, pero el patrón establecido sugiere que vendrán más enhancements de interop con JavaScript moderno. Los candidatos naturales son:

Generadores nativos — Soporte para function* y yield de JavaScript, útil para iteradores lazy en interop con librerías que los usan.- Top-level await — Permitir (await ...) en el toplevel de un namespace para flujos de inicialización con módulos ESM.- Symbol y WeakRef — Mayor cobertura de las primitivas modernas de JavaScript que hoy requieren acceso vía interop directa.- Mejor source maps para async — Las funciones async tradicionalmente complican el debugging; mejorar los mapeos sería un siguiente paso natural para mantener la productividad.

📌 Nota: La Clojure Survey 2026 cierra a fines de año. Si querés influir en las prioridades del próximo ciclo, participá. Las features más pedidas se priorizan en el roadmap del año siguiente, como pasó con async/await este año.

Para la comunidad hispana, este cambio reduce la fricción para evaluar ClojureScript en proyectos nuevos. Antes, justificar la curva de aprendizaje era difícil cuando había que sumar core.async o promesa al estack mental. Ahora, un desarrollador con experiencia en JavaScript puede leer código ClojureScript async y reconocer la semántica al instante, lo que hace al lenguaje más accesible para equipos sin background previo en Lisp.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué versión de Node.js o navegador necesito?

El target ECMAScript 2016 cubre todos los navegadores modernos (Chrome 55+, Firefox 52+, Safari 10.1+, Edge 15+) y Node.js 7.6 o superior. Si tu base de usuarios incluye Internet Explorer 11, necesitarás transpilar el output con Babel o cambiar el target del compilador a una versión anterior de ES.

¿Puedo seguir usando core.async junto con ^:async?

Sí. Ambos modelos coexisten sin conflicto. core.async sigue siendo la mejor opción para channels con backpressure, sistemas de colas internas y coordinación de procesos largos. Las funciones async/await son ideales para interop con APIs basadas en promesas y operaciones puntuales como fetch o lectura de archivos.

¿Funciona con shadow-cljs y Figwheel?

Sí, el feature está implementado a nivel del compilador de ClojureScript, así que cualquier herramienta de build que use el compilador oficial lo soporta automáticamente. shadow-cljs 2.27 y Figwheel Main son compatibles. Verificá que la versión transitiva de ClojureScript en tu lockfile sea 1.12.145 o superior antes de probar.

¿El hint ^:async funciona con multimethods o protocolos?

Solo aplica a funciones declaradas con defn o fn. Para multimethods, debés marcar cada implementación específica como async. Para protocolos, el método debe ser declarado async en cada extensión, ya que el compilador genera funciones individuales por implementación de protocolo.

¿Cómo manejo errores en una función ^:async?

Usá try/catch dentro del cuerpo de la función. Los rechazos de promesas se transforman en excepciones dentro del scope async. La forma (catch :default e ...) captura cualquier error, mientras que tipos específicos como (catch js/Error e ...) filtran por instancia y permiten manejo selectivo.

¿Hay impacto en el tamaño del bundle?

Marginal. Una función async genera código JavaScript ligeramente más largo que la versión equivalente con .then, pero el ahorro de eliminar dependencias como promesa (que pesa unos 8KB minificado y gzipped) compensa con creces el incremento. En proyectos medianos, esperá una reducción neta de 3 a 7KB en el bundle final.

Referencias

ClojureScript 1.12.145 Release Notes — Anuncio oficial del equipo de ClojureScript con el detalle del hint ^:async.- Repositorio oficial de ClojureScript en GitHub — Código fuente del compilador, changelog completo y issue tracker público.- Guía Quick Start de ClojureScript — Documentación oficial para empezar a usar el lenguaje desde cero.- MDN: async function en JavaScript — Referencia técnica de la palabra reservada async en ECMAScript.- Sobre ClojureScript en clojure.org — Filosofía de diseño y relación con el lenguaje Clojure.

Taskflow Agent de GitHub Security Lab: el framework MCP que descubrió 80+ vulnerabilidades reales con LLMs y YAML declarativo

lu1tr0n — Fri, 08 May 2026 02:17:48 +0000

El 14 de enero de 2026, GitHub Security Lab publicó en su blog el lanzamiento del Taskflow Agent, un framework open source bajo licencia MIT para realizar investigación de seguridad asistida por modelos de lenguaje grandes. Cuatro meses después, los autores publicaron una actualización detallada el 20 de enero reportando que el framework, junto con varios taskflows especializados, ya había llevado al equipo a descubrir aproximadamente 30 vulnerabilidades reales triando alertas de CodeQL en proyectos open source. La cifra acumulada al momento del análisis posterior cruzaba los 80 issues de seguridad reportados, con cerca de 20 divulgados públicamente, tras una revisión humana cuidadosa de cada hallazgo. La versión más reciente al día de hoy es v0.3.1 (publicada el 7 de abril de 2026), y el proyecto está en desarrollo activo.

La pieza es relevante por una razón concreta. Mientras varias empresas de seguridad están empujando agentes IA propietarios para auditoría de código —cerrados, opacos y con licencias enterprise—, el equipo de GitHub Security Lab tomó la posición opuesta. Kevin Backhouse, que lidera la iniciativa con Peter Stöckli y Man Yue Mo como contribuidores principales, lo dijo sin rodeos en el post de anuncio:

"Many of the agentic security tools that are currently popping up are closed-source black boxes, which is the antithesis of what we stand for."

El proyecto continúa la línea editorial de seguridad de este blog —los posts recientes sobre Apache HTTP Server 2.4.67, pnpm 11 y la doble ola TeamPCP/Trivy— con una pieza que cubre un ángulo distinto: cómo se está construyendo la próxima generación de herramientas de auditoría asistida por IA, en abierto, con código que cualquier equipo puede correr en su propio CI. Vamos a desarmar el proyecto: qué hace exactamente, qué arquitectura usa, qué resultados ya produjo, cómo se instala y se corre, y dónde están las limitaciones que el propio equipo señala.

La premisa: encodear conocimiento de seguridad como YAML

La idea estructural detrás del framework es convertir el conocimiento de un investigador de seguridad en un archivo YAML que un agente pueda ejecutar. Esa abstracción se llama taskflow: una secuencia ordenada de tareas, donde cada tarea tiene un agente con instrucciones específicas, accede a un conjunto definido de herramientas, y produce un output que la siguiente tarea consume. La construcción es declarativa: el investigador describe qué hacer, no cómo. El framework se encarga del orquestado, validación de schemas, manejo de errores y reintentos.

La diferencia con el enfoque "single big prompt" —el patrón más común cuando se prototipa con LLMs— es que un taskflow descompone el problema en pasos pequeños y verificables. Un agente de threat modelling produce una lista de componentes y entry points; otro propone tipos de vulnerabilidades plausibles para cada componente; un tercero audita rigurosamente cada propuesta exigiendo evidencia concreta —file paths, line numbers, snippets de código relevante—. Esa estructura tiene dos consecuencias prácticas. Primero, reduce alucinaciones: cada agente está encerrado en un alcance pequeño donde es harder confundirse. Segundo, el output es auditable: el investigador humano puede revisar cada paso intermedio en lugar de pedirle al modelo que justifique una conclusión final retroactivamente.

La cita de Man Yue Mo y Peter Stöckli en el post de actualización resume bien la apuesta:

"Large language models (LLMs) excel at matching the fuzzy patterns that traditional tools struggle with."

Los SAST tradicionales son excelentes para patrones estructurales —tainted data flow, missing null checks, control flow inseguro—. Los LLMs son excelentes para patrones semánticos —"esta función parece manejar autenticación pero no valida que el user_id provenga de una sesión legítima"—. El framework es la pieza que conecta esa capacidad semántica con la rigurosidad operativa que un workflow de seguridad real exige.

Arquitectura técnica: qué corre por debajo

El README del repositorio deja explícito el stack:

Lenguaje: Python ≥ 3.10
SDK base: OpenAI Agents SDK, la librería oficial de OpenAI para construir agentes con tool calling y handoffs
Validación de grammar: Pydantic v2, para que cada YAML cumpla un schema estricto antes de ejecutarse
Templating: Jinja2, para interpolar variables y reusar fragmentos entre tareas
CLI: Typer
Build system: Hatch
MCP-enabled: el agente puede consumir y exponer herramientas vía Model Context Protocol, lo que lo hace interoperable con otros agentes del ecosistema

La elección del OpenAI Agents SDK como base merece nota: no es una limitación a usar GPT exclusivamente. La capa de modelos es configurable mediante archivos model_config que permiten especificar diferentes APIs y endpoints. El framework soporta tanto la API "Chat Completions" tradicional como la API "Responses" más nueva. Modelos como gpt-4.1 y gpt-5.1 están listados en los configs por default, pero el sistema acepta configuraciones para Claude, Gemini u otros proveedores compatibles con el protocolo.

Cómo se ve un taskflow

La estructura de un archivo taskflow es un YAML con un header obligatorio que declara la versión y el filetype, seguido de una lista de tareas. Una versión simplificada, basada en el formato del repositorio:

version: "1.0"
filetype: taskflow
name: audit-codeql-alert

env:
  REPO_URL: "{{REPO_URL}}"
  ALERT_ID: "{{ALERT_ID}}"

tasks:
  - name: gather_info
    agent: codeql_alert_collector
    prompt: |
      Fetch CodeQL alert {{ALERT_ID}} from {{REPO_URL}}.
      List the source, sink, and intermediate steps in the data flow.
    tools: [github_codeql, github_repo_reader]
    max_steps: 10
    model: gpt-5.1

  - name: triage
    agent: false_positive_auditor
    prompt: |
      Given the alert details from the previous task, determine
      if this is a true vulnerability or a false positive.
      Cite specific code paths and line numbers as evidence.
    tools: [github_repo_reader, github_codesearch]
    max_steps: 25
    model: gpt-5.1

  - name: report
    agent: report_writer
    prompt: |
      If the auditor confirms the vulnerability, generate a
      formal advisory in GHSL format with reproduction steps,
      affected versions, and recommended remediation.
    tools: [github_advisory_writer]
    max_steps: 5
    model: gpt-4.1

El framework toma este archivo, valida que cumpla el schema con Pydantic, ejecuta cada tarea en orden, pasa el output de una a la siguiente, y maneja recovery si algo falla. La separación clara entre prompt, herramientas y modelo permite que el mismo taskflow corra contra distintos modelos para comparar costos y precisión, o que el equipo experimente con prompts sin tocar la lógica de orquestación.

Los archivos de personality son una abstracción relacionada: definen comportamiento general de un agente —tono, idioma, restricciones, instrucciones de seguridad— que se reusa entre múltiples taskflows. Las toolboxes describen colecciones de herramientas que un agente puede invocar. Y los model_configs centralizan la configuración de modelos.

El proceso de auditoría en tres etapas

El post de actualización del 20 de enero documenta el flujo concreto que el equipo usa para triar alertas de CodeQL. Las tres etapas son:

Etapa 1: recolección de información

Un agente especializado lee la alerta de CodeQL en detalle —el path de datos taint, los nodos source y sink, los pasos intermedios— y captura el contexto del código fuente. Para una alerta de SQL injection, por ejemplo, recoge la función que recibe input de usuario, los métodos llamados intermedios, y el call site final donde el SQL se ejecuta. La salida de esta etapa es un documento estructurado que la siguiente tarea consume sin tener que volver a leer el repositorio entero.

Etapa 2: triage contra criterios de falso positivo

El segundo agente toma la información recolectada y pasa una checklist de criterios que típicamente convierten alertas estáticas en falsos positivos: ¿el flujo está protegido por checks de autorización antes del sink? ¿hay un sanitizador en algún punto intermedio? ¿la entrada está restringida a un contexto privilegiado donde el ataque no es realista? El agente requiere evidencia concreta —no acepta "parece estar protegido"; necesita un nombre de función, un número de línea, un fragmento de código que demuestre la protección—. Si encuentra protección, descarta la alerta como falso positivo. Si no, escala a la siguiente etapa.

Etapa 3: generación de reporte

El tercer agente redacta una advisory en formato GHSL —el formato interno de GitHub Security Lab para reportar vulnerabilidades— con repro steps, líneas afectadas, severidad estimada y remediación recomendada. La salida es lo suficientemente completa para que un humano la revise rápido y la transforme en un advisory público o en un report privado al maintainer del proyecto.

Crucialmente, el output siempre pasa por revisión humana antes de cualquier disclosure. El equipo es explícito en este punto: el framework es una herramienta para acelerar el trabajo del investigador, no para reemplazarlo. Reportar una vulnerabilidad alucinada al maintainer de un proyecto open source destruye la confianza, y eso es exactamente lo que el equipo quiere evitar.

Resultados concretos: 80+ vulns reportadas, ~20 públicas

Los números reportados al cierre del análisis del 20 de enero son los siguientes:

~30 vulnerabilidades reales descubiertas vía triage automatizado desde agosto de 2025
80+ issues de seguridad reportados en total considerando los taskflows de auditoría web especializados
~20 disclosures públicos ya procesados a través del programa GHSL
Categorías más frecuentes: Auth Bypasses, IDORs (Insecure Direct Object References), Token Leaks, XSS

Un ejemplo público concreto que el blog menciona es GHSL-2025-110_openlibrary, una vulnerabilidad de cross-site scripting explotable mediante URLs javascript: en el proyecto Open Library. El framework la encontró siguiendo un taskflow especializado en patrones de XSS reflejado a través de redirects.

La proporción de hallazgos por categoría no es accidental. Las Auth Bypasses y los IDOR son particularmente difíciles para SAST tradicional porque dependen de lógica de negocio —"este endpoint debería verificar que el user_id del path coincida con la sesión activa, pero no lo hace"— en lugar de patrones sintácticos. Los LLMs leen la intención de un endpoint mejor que un analizador estático, y el framework convierte esa lectura en un workflow operativo.

Cómo instalar y correr el framework

Pre-requisitos

# Opción 1: Python local
python --version  # debe ser >= 3.10

# Opción 2: Docker (más portable)
docker --version

Variables de entorno necesarias

export AI_API_TOKEN=""
export GH_TOKEN=""

El AI_API_TOKEN es el token que da acceso a GitHub Models —el catálogo de modelos hosteados que GitHub provee gratis dentro de límites generosos para usuarios con licencia Copilot—. El GH_TOKEN es opcional pero útil para herramientas que consultan la API de GitHub directamente (leer alertas de CodeQL, abrir advisories, listar repos).

Instalación desde fuente

git clone https://github.com/GitHubSecurityLab/seclab-taskflow-agent.git
cd seclab-taskflow-agent

# Instalar dependencias con hatch (build system del proyecto)
pip install hatch
hatch shell

# Verificar que funciona
hatch run main --help

Ejecutar un taskflow

# Listar taskflows disponibles del repo de ejemplos
git clone https://github.com/GitHubSecurityLab/seclab-taskflows.git
ls seclab-taskflows/

# Ejecutar un taskflow específico
hatch run main -t audit-codeql-alert \
  -g REPO_URL=https://github.com/some/project \
  -g ALERT_ID=12345

# O via Docker
./docker/run.sh -t audit-codeql-alert

Modos de operación

El framework soporta tres modos principales:

Standalone con personality: invoca un agente con un prompt directo desde CLI, útil para experimentación rápida
Taskflow execution: el modo principal, ejecuta un YAML con orquestación multi-agente
Agent handoff: un agente puede delegar control a otro durante la ejecución, útil para flujos de triage donde una tarea inicial decide qué especialista invocar después

El framework tiene session recovery: si un taskflow falla a mitad de camino, el estado de las tareas completadas se guarda y la ejecución se puede retomar desde el último checkpoint sin re-ejecutar todo desde cero. Para taskflows largos —algunos del repo iteran sobre cientos de archivos— esto es operativamente esencial.

Cómo se usa con los taskflows de ejemplo

El repositorio paralelo seclab-taskflows contiene flujos de trabajo concretos que el equipo de GitHub Security Lab usa internamente. Algunos ejemplos:

Triage de alertas CodeQL: el flujo descrito en las tres etapas más arriba.
Variant analysis: dado un CVE conocido, buscar variantes del mismo bug en otros proyectos open source que compartan dependencias o patrones similares.
Auditoría de seguridad web: especializado en encontrar XSS, IDOR, Auth Bypass en aplicaciones web, con conocimiento de patrones específicos de frameworks comunes (Django, Express, Spring, Flask).
Análisis de advisories: dado un advisory público reciente, generar reglas CodeQL para detectar el mismo patrón en otros proyectos.

Cualquier equipo puede clonar este repo, modificar los taskflows para su contexto específico, y agregar los suyos propios. La intención del equipo es que el repositorio sea un commons de patrones de auditoría que la comunidad de seguridad pueda enriquecer.

Limitaciones que el equipo reconoce explícitamente

El blog post no esconde los problemas reales del enfoque:

Costo de tool calls. Un taskflow de auditoría profundo puede invocar herramientas decenas o cientos de veces, lo cual consume cuota de modelo significativa. El equipo cita: "Running the taskflows can result in many tool calls, which can easily consume a large amount of quota." Para investigación interna esto es manejable; para una pequeña empresa que quiera adoptarlo en CI puede ser una sorpresa de costos.

Revisión humana obligatoria antes del disclosure. Como se mencionó arriba, el equipo nunca reporta directamente lo que el agente produce. Esto no es opcional: alucinaciones siguen ocurriendo y reportar vulns falsos a maintainers de proyectos open source es socialmente costoso.

Sin validación dinámica. El framework analiza código estáticamente; no ejecuta el código en un sandbox, no construye PoCs ejecutables, no confirma que la vulnerabilidad sea explotable más allá del análisis del path de datos. Para muchos casos eso es suficiente; para vulns de race condition o explotabilidad dependiente de timing, no lo es.

Dependencia de licencia Copilot. Aunque el framework es MIT, el modelo subyacente (vía GitHub Models) requiere una licencia Copilot activa para acceso completo. Esto reduce la barrera para usuarios de Copilot pero no elimina el costo total para proyectos puramente comunitarios.

Comparación con herramientas existentes

Herramienta
Tipo
License
Modelo

Semgrep
SAST con reglas
Permisivo
Sin LLM

CodeQL
Análisis de queries
Free para OSS
Sin LLM

Snyk Code DeepCode
SAST + ML
Comercial
Propietario

Aikido / GitGuardian
DevSecOps
Comercial
Mezcla

Endor Labs
Comercial
Comercial
Propietario

Taskflow Agent
Multi-agente LLM
MIT
Configurable

El diferenciador es la combinación de open source + multi-agente + customizable + agnóstico al proveedor de modelo. No reemplaza a SAST tradicional, complementa: el patrón típico es usar CodeQL para cobertura masiva (millones de archivos) y Taskflow Agent para triar las alertas que CodeQL produce.

Casos de uso donde tiene sentido evaluar el framework hoy

Equipos de seguridad interna en empresas medianas a grandes. Donde el equipo ya tiene CodeQL corriendo y se ahoga en alertas, Taskflow Agent puede recortar el ratio de falsos positivos significativamente y liberar tiempo de los analistas para análisis profundo manual.

Investigadores académicos o bug bounty hunters. La capacidad de codificar conocimiento de auditoría en YAMLs reusables permite multiplicar el alcance de un solo investigador. Un patrón que detecta IDOR en endpoints REST puede correrse en miles de proyectos en GitHub.

Maintainers de proyectos open source críticos. Para proyectos que tienen muchos contributors y workflows de PR pesados, integrar un taskflow de auditoría como parte del CI puede atrapar regresiones de seguridad antes del merge.

Equipos construyendo sus propios agentes de seguridad. El framework es una buena base sobre la cual construir productos custom: el patrón YAML-driven, multi-agente, con MCP, es replicable y el código es abierto.

Lección de fondo

Hay un punto de gobernanza importante en este lanzamiento que vale la pena retener. GitHub Security Lab eligió liberar la pieza más valiosa de su trabajo —la abstracción de taskflow para razonamiento de seguridad— como código abierto, en un momento donde la mayoría de competidores cerrarían el código y lo monetizarían. La frase de Backhouse —"closed-source black boxes are the antithesis of what we stand for"— es ideológica, pero tiene una dimensión práctica concreta: la seguridad open source de la próxima década no la van a resolver vendors propietarios sino redes de investigadores compartiendo herramientas en abierto. El framework es la apuesta por ese modelo.

La otra lección es de método. Descomponer un agente "que audita código" en un workflow de tareas verificables es estructuralmente mejor que perseguir un single mega-prompt. El campo de prompting está descubriendo, doloroso paso por doloroso paso, lo que la ingeniería de software ya sabe desde hace cincuenta años: la composición disciplinada de pasos pequeños y testables produce sistemas más confiables que monolitos brillantes. Los taskflows son una pequeña pero efectiva traducción de ese principio al espacio de los agentes IA.

Y para devs que evalúan integrar IA en su pipeline de seguridad: clonar el repo, leer un par de taskflows y ejecutar uno contra un proyecto propio es una hora de inversión que da un mejor sentido del estado del arte que diez horas leyendo papers o blogs de vendors. La pieza mejor que existe hoy está abierta. Vale la pena tocarla.

Fuentes

GitHub Security Lab Taskflow Agent — repositorio principal: https://github.com/GitHubSecurityLab/seclab-taskflow-agent
README oficial: https://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/main/README.md
Repositorio paralelo de taskflows de ejemplo: https://github.com/GitHubSecurityLab/seclab-taskflows
Community-powered security with AI: an open source framework for security research (Kevin Backhouse, 14 ene 2026): https://github.blog/security/community-powered-security-with-ai-an-open-source-framework-for-security-research/
AI-supported vulnerability triage with the GitHub Security Lab Taskflow Agent (Man Yue Mo & Peter Stöckli, 20 ene 2026): https://github.blog/security/ai-supported-vulnerability-triage-with-the-github-security-lab-taskflow-agent/
How to scan for vulnerabilities with GitHub Security Lab's open source AI-powered framework: https://github.blog/security/how-to-scan-for-vulnerabilities-with-github-security-labs-open-source-ai-powered-framework/
GitHub Blog — Security tag (todas las publicaciones del Lab): https://github.blog/tag/github-security-lab/
OpenAI Agents SDK (dependencia upstream): https://openai.github.io/openai-agents-python/
Wikipedia — GitHub: https://en.wikipedia.org/wiki/GitHub
Wikipedia — CodeQL: https://en.wikipedia.org/wiki/CodeQL
Wikipedia — Static program analysis: https://en.wikipedia.org/wiki/Static_program_analysis
Wikipedia — Cross-site scripting: https://en.wikipedia.org/wiki/Cross-site_scripting

ShinyHunters tumba Canvas: 275M usuarios y 9.000 escuelas afectadas

lu1tr0n — Fri, 08 May 2026 02:16:40 +0000

El 7 de mayo de 2026, millones de estudiantes y profesores en todo el mundo se encontraron con un mensaje inesperado al intentar entrar a sus aulas virtuales: Canvas, la plataforma de aprendizaje propiedad de Instructure, estaba caída. Pero no era un fallo técnico cualquiera. El ataque de ShinyHunters Canvas es, según el propio grupo, una de las brechas educativas más grandes de la historia: 275 millones de personas y 9.000 escuelas en la lista de víctimas.

El mensaje que vieron los usuarios no venía de Instructure. Venía directamente de los atacantes, exigiendo un rescate y poniendo fecha límite: 12 de mayo de 2026. Si las instituciones afectadas no negocian para entonces, todos los datos —nombres, correos, números de identificación estudiantil y mensajes privados— se filtrarán públicamente. En esta nota repasamos qué pasó, quiénes son ShinyHunters, qué significa para LATAM y cómo las instituciones educativas pueden prepararse ante un ecosistema en el que los LMS se están volviendo blanco prioritario.

Qué pasó con Canvas e Instructure

Instructure, la empresa detrás de Canvas LMS, confirmó la semana pasada que sufrió una brecha de seguridad que expuso información sensible de estudiantes: nombres completos, direcciones de correo electrónico, números de ID estudiantil y mensajes intercambiados dentro de la plataforma. La compañía, según su comunicado oficial, desplegó parches para reforzar la seguridad del sistema.

El problema es que ShinyHunters dice haber regresado. Según el mensaje que apareció publicado en Canvas el jueves, la respuesta de Instructure no fue suficiente:

ShinyHunters ha vulnerado Instructure (otra vez). En lugar de contactarnos para resolverlo, nos ignoraron e hicieron unos "parches de seguridad". Si alguna de las escuelas en la lista afectada quiere prevenir la publicación de sus datos, debe consultar con una firma de asesoría cibernética y contactarnos privadamente vía TOX para negociar. Tienen hasta el final del día del 12 de mayo de 2026 antes de que todo sea filtrado.

Tras el incidente, Instructure colocó Canvas, Canvas Beta y Canvas Test en modo mantenimiento según su página de status. La empresa anunció que esperaba estar operativa pronto, pero al cierre de esta nota la plataforma seguía intermitente para varias instituciones.

Quiénes son ShinyHunters: el ecosistema del ransomware moderno

ShinyHunters no es un grupo nuevo. Su historial de ataques de alto perfil incluye nombres que cualquier persona en tecnología reconoce de inmediato: Ticketmaster, AT&T, Rockstar Games, ADT y Vercel, entre otros. Operan bajo un modelo híbrido que combina extorsión con venta directa de datos en foros del bajo mundo digital.

El patrón es consistente: identifican un servicio con muchísimos datos personales, encuentran una vía de entrada (suele ser credenciales filtradas, APIs mal configuradas o bibliotecas de terceros con vulnerabilidades), exfiltran silenciosamente, contactan a la víctima y, si no hay respuesta, suben los datos a su sitio de filtraciones.
ShinyHunters acumula víctimas de alto perfil desde 2020.

⚠️ Ojo: ShinyHunters no es una APT estatal ni un colectivo ideológico. Es un grupo motivado financieramente. Eso significa que las decisiones técnicas se toman buscando ROI: atacan donde el costo es bajo y el dato vale mucho. Los LMS educativos cumplen ese perfil al pie de la letra.

El flujo típico de un ataque ShinyHunters

flowchart LR
 A["Reconocimiento: APIs, leaks, repos"] --> B["Acceso inicial: credenciales o vuln"]
 B --> C["Exfiltración silenciosa"]
 C --> D["Contacto a la víctima"]
 D --> E{"Hay respuesta?"}
 E -- No --> F["Filtración pública"]
 E -- Si --> G["Negociación privada"]

Datos y cifras del ataque

Las cifras que comparten ShinyHunters y reportes como Bleeping Computer pintan una escala difícil de digerir:

275 millones de personas afectadas según los atacantes (estudiantes, profesores y personal administrativo).- 9.000 escuelas en la lista de víctimas, desde colegios K-12 hasta universidades de alto nivel.- Tipos de datos comprometidos: nombres, correos electrónicos, números de identificación estudiantil y mensajes internos de la plataforma.- Fecha límite: 12 de mayo de 2026, alrededor de cinco días después del anuncio público.- Estado del servicio: Canvas, Canvas Beta y Canvas Test en modo mantenimiento al momento de publicación.

Para dimensionar el número: 275 millones es más que la población combinada de México, Argentina, Colombia y Perú. Si la cifra es real —y queda pendiente la verificación independiente— estaríamos ante una de las filtraciones más grandes del sector educativo en la historia, comparable a brechas como la de Equifax (2017) o Yahoo (2013) en términos de volumen de identidades expuestas.

Impacto y análisis: por qué los LMS son el nuevo blanco

El sector educativo ha venido escalando como blanco preferido del cibercrimen por tres razones estructurales que no se ven en otros sectores con tanta claridad.

1. Concentración de datos sensibles de menores de edad

Los LMS guardan información de millones de estudiantes, muchos de ellos menores. La regulación es laxa en muchos países, y los datos de menores tienen un valor especial en el mercado negro porque se usan para abrir cuentas fraudulentas que tardan años en detectarse —el menor descubre el fraude cuando intenta su primera tarjeta de crédito a los 18.

2. Presupuestos de ciberseguridad limitados

Las universidades y colegios suelen invertir mucho menos en seguridad que las fintech o las grandes tecnológicas. Esto crea una asimetría: alto valor del dato, baja defensa. Es exactamente el tipo de objetivo que un grupo motivado financieramente prioriza.

3. Tecnología legada y dependencias en cadena

Los LMS frecuentemente integran decenas de plugins, herramientas SCORM, sistemas de calificaciones y APIs de terceros. Cada integración es una superficie de ataque adicional. ShinyHunters históricamente ha explotado este tipo de dependencias —bibliotecas, APIs internas, snippets compartidos en repositorios públicos.

💭 Clave: El ataque a Canvas no es solo un problema de Instructure. Es una señal de que los LMS, por años percibidos como software corporativo aburrido, ahora son infraestructura crítica con perfil de blanco de alto valor.

Implicaciones para LATAM

Canvas tiene presencia importante en Latinoamérica: lo usan instituciones como el Tec de Monterrey, varias universidades en Chile, Argentina y Colombia, y centros K-12 privados en toda la región. Si su institución usa Canvas, los pasos inmediatos son:

Verificar comunicación oficial de Instructure y de la institución educativa antes de tomar acciones drásticas.- Cambiar contraseñas de la cuenta Canvas y, si se reutilizaron, en otros servicios.- Activar autenticación de dos factores (2FA) donde se ofrezca; muchos LMS lo tienen pero desactivado por defecto.- Vigilar correos sospechosos: los datos filtrados se usan para campañas de phishing dirigidas con información que parece legítima ("hola María, tu profesor de Cálculo II...").- Para administradores TI: revisar logs de acceso de los últimos 90 días, rotar tokens de integración, auditar plugins. Millones de estudiantes en LATAM dependen de Canvas para sus clases. ## Qué hacer si tu institución usa Canvas: checklist técnico

Para los equipos de TI de instituciones educativas, este es un buen momento para una auditoría rápida. Un script base en Bash para revisar accesos sospechosos en logs de Canvas exportados:

# Buscar accesos desde IPs no usuales en los logs de Canvas
# Asume export en formato JSON Lines

jq -r '. | select(.event_type == "login") | "\(.timestamp) \(.user_id) \(.ip)"' \
  canvas_logs.jsonl \
  | awk '{print $3}' \
  | sort | uniq -c | sort -rn \
  | head -50

# Detectar exfiltración masiva de archivos
jq -r '. | select(.event_type == "file_download") | .user_id' \
  canvas_logs.jsonl \
  | sort | uniq -c | sort -rn \
  | awk '$1 > 100 {print}'

Y un snippet de PowerShell para Windows que revisa correos institucionales por dominios spoofed de Instructure:

# Buscar correos sospechosos que se hagan pasar por Instructure
Get-MailboxSearch -Identity "Phishing-Canvas-2026" `
  -SearchQuery 'from:*instructure* OR from:*canvas* AND received>05/05/2026' `
  -StatusMailRecipients admin@institucion.edu

Qué sigue

Hay tres escenarios posibles en los próximos días.

Escenario A: Instructure paga o negocia. ShinyHunters retira el dump y no se publica. Los datos siguen en sus manos —y posiblemente en las de quien quiera comprarlos en el futuro. La empresa probablemente nunca confirme públicamente el pago.

Escenario B: Instructure no negocia y los datos se filtran el 12 de mayo. Esto desencadenaría una avalancha de demandas colectivas, especialmente bajo legislaciones como FERPA en EE.UU., GDPR en Europa y la LFPDPPP en México. El precio de la acción de Instructure (NYSE: INST) se vería golpeado fuerte.

Escenario C: Verificación parcial. Investigadores independientes (como troyhunt.com / Have I Been Pwned) confirman que la lista de 9.000 escuelas y 275 millones de usuarios está inflada. Esto ya pasó con otros leaks de ShinyHunters donde el grupo exageró el tamaño del dump para presionar.

💡 Tip: Sea cual sea el escenario, asuma que sus datos pueden estar comprometidos y actúe en consecuencia. La gestión defensiva siempre es más barata que la reactiva.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Mi cuenta de Canvas está comprometida?

Si su institución aparece en la lista publicada por ShinyHunters, asuma que sí. Cambie la contraseña, active 2FA y vigile su correo por intentos de phishing. Si su institución no aparece en la lista, monitoree comunicación oficial de Instructure los próximos días.

¿Quiénes son ShinyHunters?

Es un grupo de cibercriminales motivado financieramente, activo desde 2020. Han atacado a Ticketmaster, AT&T, Rockstar Games, ADT y Vercel, entre otros. Operan bajo modelo de extorsión: exfiltran datos, demandan rescate y, si no pagan, los publican.

¿Qué datos exactamente fueron expuestos?

Según Instructure: nombres de estudiantes, correos electrónicos, números de identificación estudiantil y mensajes intercambiados dentro de Canvas. No se ha confirmado exposición de contraseñas, datos financieros o calificaciones, pero la investigación sigue en curso.

¿Qué pasa si los datos se filtran el 12 de mayo?

Los datos quedarían disponibles públicamente, lo que aumenta exponencialmente el riesgo de phishing dirigido, robo de identidad y fraude. Especialmente preocupante para menores de edad, cuyos datos se usan para abrir cuentas fraudulentas detectables solo años después.

¿Existen alternativas a Canvas?

Sí: Moodle (open source, autogestionable), Google Classroom (gratuito para educación), Blackboard, Schoology, D2L Brightspace. Migrar un LMS no es trivial y suele tomar meses, así que esta no es una decisión que se tome ante el primer incidente.

¿Cómo verifico si mi correo aparece en una filtración?

Servicios como Have I Been Pwned (haveibeenpwned.com) suelen indexar las grandes filtraciones poco después de publicarse. Suscríbase con su correo institucional para recibir alertas automáticas en caso de aparecer en futuros dumps.

Referencias

The Verge — Canvas is down as ShinyHunters threatens to leak schools' data — Nota original que reportó el incidente y el mensaje de los atacantes.- Wikipedia — ShinyHunters — Historial completo del grupo y sus ataques de alto perfil desde 2020.- Instructure — Canvas LMS — Sitio oficial de la plataforma con documentación, status y comunicaciones de seguridad.- Hacker News — Discusión técnica de la comunidad sobre la brecha y mitigaciones.

DuckLake 1.0: el formato de data lake que mueve el catálogo de archivos a SQL y promete 926 más velocidad que Iceberg

lu1tr0n — Thu, 07 May 2026 22:19:02 +0000

El 13 de abril de 2026, DuckDB Labs liberó la versión 1.0 de DuckLake, un formato de data lake con backward-compatibility garantizada que rompe con la convención de los últimos cinco años en lakehouses: en lugar de almacenar el catálogo de metadatos como una pila de archivos JSON dispersos en object storage —el patrón que usan Apache Iceberg, Delta Lake y Apache Hudi—, DuckLake lo guarda en una base de datos relacional. La consecuencia técnica es directa, y los benchmarks reportados por el propio equipo son contundentes: 926× más rápido en consultas y 105× más rápido en ingesta frente a Iceberg en cargas de trabajo con muchas escrituras pequeñas, según declaraciones de Pedro Holanda, ingeniero principal de DuckDB Labs, recogidas por The Register.

InfoQ cubrió el lanzamiento el 2 de mayo, firmado por Renato Losio. El anuncio oficial en ducklake.select lista las cinco features principales: data inlining, sorted tables, bucket partitioning, soporte completo para tipos GEOMETRY y VARIANT, y deletion vectors compatibles con Iceberg v3. El repositorio público en GitHub ya está disponible bajo licencia open source y los clientes para Apache DataFusion, Apache Spark, Trino y Pandas son operativos al día del release. MotherDuck ofrece una versión hosteada que gestiona la base de datos del catálogo y el storage subyacente.

Este artículo explica, en términos accesibles para ingenieros de datos y devs que están evaluando lakehouses para 2026, qué es DuckLake exactamente, qué problema concreto resuelve, cómo se integra con el stack actual, y cuándo conviene preferirlo sobre Iceberg o Delta Lake. La cobertura es continuación natural de la línea editorial dev del blog —los posts recientes sobre Bun→Rust, pnpm 11 y Cloudflare Agents Week— en una pieza que toca el lado de datos que estaba sub-cubierto.

El problema que ataca: el "small file problem" en lakehouses

Los lakehouses modernos —Iceberg desde Netflix en 2017, Delta Lake desde Databricks en 2019— resolvieron un problema real: dieron transacciones ACID sobre data lakes que antes eran simplemente "carpetas de archivos Parquet sin orden". Para hacerlo, agregaron una capa de metadata que registra qué archivos componen una tabla en cada momento, qué snapshots existen, qué columnas hay, qué particiones aplican. Esa metadata —archivos JSON, Avro o manifiestos específicos del formato— se guarda junto a los datos en object storage como S3, R2 o GCS.

El problema aparece cuando el patrón de uso no es "ingesta batch grande cada hora". Si un workload incluye escrituras pequeñas frecuentes —insertar una fila, actualizar diez registros, borrar una tupla— el resultado es que cada operación genera al menos un archivo Parquet nuevo (Parquet está optimizado para millones de filas, no para una sola) más uno o varios archivos de metadata para registrar el cambio. Hannes Mühleisen, cofundador y CEO de DuckDB Labs, lo describió a The Register con esta cita:

"You make a small change to your table, adding a single row, and it affects data lake performance because... a new file has to be written... and then a bunch of metadata."

El costo se acumula. Tras pocos miles de escrituras pequeñas un usuario termina con decenas de miles de archivos diminutos y consultas que tienen que listar y leer todo ese ruido para responder a una pregunta simple. Las "compaction jobs" que se corren periódicamente para fusionar archivos pequeños en archivos grandes ayudan, pero introducen su propio mantenimiento operacional. Y los object stores cobran por requests: 100.000 archivos pequeños cuestan más que 1.000 archivos grandes con el mismo volumen total de datos.

La solución de DuckLake: catálogo en SQL, datos en Parquet

DuckLake invierte la división. Los datos se siguen guardando como Parquet en object storage —compatibilidad total con el ecosistema existente—, pero el catálogo, los snapshots, los metadatos de schema y la lista de archivos se guardan en una base de datos relacional estándar. Los backends soportados oficialmente al día del release 1.0 son tres: DuckDB (sí, DuckDB puede ser su propio catálogo), PostgreSQL y SQLite.

Esto resuelve el problema de los archivos pequeños de raíz. Cuando llega una escritura de 10 filas, DuckLake no escribe un Parquet nuevo. Acumula esa escritura dentro de la base de datos del catálogo —que está optimizada precisamente para muchas operaciones pequeñas con ACID y transacciones reales—, y solo cuando la acumulación cruza un threshold (default: 10 filas, configurable) descarga las filas a Parquet en object storage. La feature se llama data inlining y es una de las cinco piezas de la 1.0.

-- Crear una tabla DuckLake usando PostgreSQL como catálogo
ATTACH 'postgres://user:pwd@host/dbname' AS catalog (TYPE POSTGRES);
USE catalog;

CREATE TABLE events (
  id BIGINT,
  ts TIMESTAMP,
  user_id VARCHAR,
  payload VARIANT
);

-- Inserts pequeños quedan inlineados en el catálogo
INSERT INTO events VALUES (1, NOW(), 'user-42', '{"action": "click"}');
INSERT INTO events VALUES (2, NOW(), 'user-17', '{"action": "view"}');

-- Cuando la acumulación supera el threshold, descarga a Parquet
-- Sin que el usuario tenga que pensarlo

La diferencia operativa para el usuario es ninguna: el SQL es estándar, los datos viven en S3/R2/GCS como siempre, las consultas se responden con Parquet cuando los datos ya están descargados o desde el catálogo cuando todavía no. La diferencia de performance, en cargas de trabajo con muchas escrituras pequeñas, es del orden de los dos órdenes de magnitud.

Las cinco features de la 1.0 en detalle

Data inlining

El threshold por defecto es 10 filas. Por debajo de eso, las filas viven en la tabla del catálogo. Por encima, se descargan a Parquet. El usuario puede configurar el threshold para subir o bajar la frontera según el patrón de carga: cargas con muchas escrituras pequeñas se benefician de un threshold alto (digamos 1.000), mientras que cargas con muy pocas escrituras pequeñas no necesitan inline en absoluto.

Sorted tables

DuckLake permite declarar el orden lógico de las filas dentro de cada archivo Parquet, usando ya sea nombres de columnas o expresiones SQL arbitrarias:

CREATE TABLE sales (
  region VARCHAR, sale_date DATE, amount DECIMAL
)
SET SORTED BY (region ASC, sale_date DESC);

El motor aprovecha el orden para hacer file pruning y row-group pruning en consultas filtradas. Para una consulta que filtre por region = 'eu' y sale_date > '2026-01-01', el motor lee solo los archivos y row-groups que contienen esas combinaciones, sin escanear el resto.

Bucket partitioning

Particionado basado en hash con murmur3 —el mismo algoritmo que usa Iceberg, lo cual permite migración bidireccional sin reorganizar archivos—. Útil para columnas de alta cardinalidad como user_id o session_id donde el particionado por valor (range) sería ineficiente porque hay millones de valores distintos.

Tipos GEOMETRY y VARIANT

GEOMETRY brinda soporte completo para datos espaciales, sin necesidad de extensiones externas como PostGIS para queries geoespaciales básicas. VARIANT es el tipo equivalente a JSON pero con encoding binario y mejor performance. La diferencia importa cuando se almacenan campos semiestructurados —payloads de eventos, metadata flexible— a escala: VARIANT se serializa más rápido y se filtra más rápido que JSON parseado on-the-fly.

Deletion vectors compatibles con Iceberg v3

DuckLake soporta deletion vectors —el mecanismo donde, en vez de reescribir un archivo Parquet entero al borrar filas, se mantiene un bitmap separado que marca qué filas están eliminadas—. La implementación usa archivos Puffin (formato binario para metadata extensible que Iceberg v3 también usa), lo que mantiene compatibilidad bidireccional con tablas Iceberg.

Comparativa contra Iceberg y Delta Lake

Dimensión
Iceberg / Delta
DuckLake 1.0

Catálogo de metadatos
Archivos JSON / Avro en object storage
RDBMS (DuckDB, Postgres, SQLite)

Manejo de escrituras pequeñas
Crea archivos por operación
Data inlining hasta threshold

Compaction jobs
Operacionalmente requeridos
Automáticos vía descarga periódica

Backend de datos
Parquet en S3/R2/GCS
Parquet en S3/R2/GCS (igual)

Soporte SQL multi-cliente
Sí (Trino, Spark, etc.)
Sí (DataFusion, Spark, Trino, Pandas)

Time-travel
Sí
Sí, vía ducklake_table_changes()

Branching de datasets
No nativo
Planeado para v2.0

Performance escrituras pequeñas
Baseline
~105× faster (Holanda)

Performance consultas
Baseline
~926× faster (Holanda)

Es importante calibrar los números. 926× más rápido en consultas no es la diferencia que vas a ver en un benchmark cualquiera; es el límite superior medido por el equipo en cargas con muchísimos archivos pequeños donde Iceberg sufre desproporcionadamente. En cargas batch tradicionales —ingesta horaria de millones de filas, sin updates intermedios— la diferencia se reduce a factores cercanos a la paridad, y Iceberg sigue siendo competitivo. La pregunta operativa para un equipo no es "qué formato es más rápido en abstracto" sino "qué formato encaja mejor con mi patrón de uso real".

Cómo empezar: implementación paso a paso

Para un equipo que quiere evaluar DuckLake hoy, el camino mínimo es directo.

Caso A: solo DuckDB local + filesystem

# Instalar DuckDB 1.5.2+ que incluye la extensión DuckLake
curl https://install.duckdb.org | sh

# Lanzar shell interactiva
duckdb

-- Crear un DuckLake con catálogo SQLite + datos en filesystem local
ATTACH 'ducklake:/tmp/my_catalog.sqlite' AS lake (DATA_PATH '/tmp/data/');
USE lake;

CREATE TABLE customers (id INT, name VARCHAR, country VARCHAR);
INSERT INTO customers VALUES (1, 'Ana', 'SV'), (2, 'Bob', 'US');

SELECT * FROM customers;

-- Time-travel: ver cambios en la tabla
SELECT * FROM ducklake_table_changes('customers');

Caso B: producción con catálogo PostgreSQL + datos en S3 / R2

-- Catalogo en Postgres, datos en R2 de Cloudflare
ATTACH 'ducklake:postgres://catalog_user:pwd@db.internal/lake_catalog'
  AS lake
  (DATA_PATH 's3://my-bucket/lake/',
   ENDPOINT 'https://abc123.r2.cloudflarestorage.com',
   ACCESS_KEY_ID 'XXX',
   SECRET 'YYY');

USE lake;

CREATE TABLE events (
  id BIGINT, ts TIMESTAMP, user_id VARCHAR, payload VARIANT
)
SET SORTED BY (ts DESC)
PARTITIONED BY BUCKET(user_id, 16);

-- Inserts pequeños se acumulan, descargas grandes se hacen automáticas
COPY events FROM 'recent_events.parquet';

Caso C: lectura desde Apache Spark

from pyspark.sql import SparkSession

spark = (SparkSession.builder
    .config('spark.jars.packages', 'io.ducklake:ducklake-spark:1.0.0')
    .config('spark.sql.catalog.lake', 'io.ducklake.SparkCatalog')
    .config('spark.sql.catalog.lake.uri', 'postgres://...')
    .getOrCreate())

df = spark.sql("SELECT region, SUM(amount) FROM lake.sales GROUP BY region")
df.show()

Caso D: queries analíticas desde Pandas (ad-hoc)

import duckdb

con = duckdb.connect()
con.execute("ATTACH 'ducklake:postgres://...' AS lake")

df = con.sql("SELECT * FROM lake.events WHERE ts > NOW() - INTERVAL 1 DAY").df()
# df es un DataFrame estándar de Pandas

Casos de uso donde DuckLake brilla

Cargas con muchas escrituras pequeñas. Tablas de eventos donde cada producción de evento es una fila, sistemas de auditoría que registran cambios individuales, dashboards en tiempo real con upserts frecuentes.

Equipos que ya viven en SQL. Si el equipo tiene Postgres en producción gestionado por DBAs experimentados, agregar DuckLake encima reusa esa expertise. No hay que aprender Iceberg manifests, snapshots o compaction strategies.

Data engineering en el rango "no necesito Spark pero quiero ACID y time-travel". Equipos pequeños o medianos que tienen menos de 10 TB de datos pueden manejar todo el lakehouse con DuckDB local + Postgres como catálogo + R2/S3 para Parquet, sin necesidad de un cluster Spark, sin necesidad de Snowflake.

Multi-tenant SaaS con muchas tablas pequeñas. Cada tenant del SaaS es una tabla; el catálogo Postgres mantiene el listado, y el aislamiento es trivial. La proliferación de archivos en Iceberg con miles de tablas pequeñas es un problema operativo conocido; DuckLake lo elimina.

Casos de uso donde no es lo apropiado

Workloads de exclusivamente ingesta batch grande. Si tu pipeline es "una vez por hora ingesto 100 GB, después solo lecturas", Iceberg y Delta están bien optimizados y no hay ventaja material en migrar.

Ecosistemas Databricks / Snowflake con compromiso enterprise existente. Si la organización tiene contratos vigentes con Databricks o Snowflake, la integración nativa con Iceberg/Delta es probablemente más valiosa que la performance teórica de DuckLake.

Equipos sin DBA o expertise SQL operacional. Aunque DuckLake usa Postgres/SQLite, gestionar un Postgres en producción con backups, replicación y monitoreo es una habilidad real. Si el equipo no la tiene, los servicios manejados como Databricks pueden ser más razonables.

Lo que rompe en la 1.0

El PR #697 introdujo un breaking change que vale la pena conocer: adjuntar una versión más nueva de la extensión DuckLake ya no migra el catálogo automáticamente. La migración ahora es explícita, lo cual previene actualizaciones accidentales en producción pero exige un paso operativo adicional cuando se actualiza la extensión:

ALTER DUCKLAKE catalog UPGRADE;

Esa es la única migración bloqueante respecto a 0.x. El resto del cambio es backward-compatible.

Roadmap: hacia dónde va DuckLake

El equipo publicó dos hitos próximos:

DuckLake v1.1 — Variant inlining cross-catalog, soporte para multi-deletion vector Puffin files, mejoras en data inlining para más tipos.
DuckLake v2.0 — Git-like branching para datasets (la feature más esperada por equipos de ML que necesitan experimentar sobre snapshots), role-based access control built-in en el catálogo, y mejoras en la primitiva de transacciones distribuidas.

El branching es particularmente interesante: permitirá crear una rama de un dataset, hacer cambios, validarlos contra otro pipeline, y mergear o descartar — el mismo modelo mental que devs ya tienen con Git, aplicado a millones de filas.

Posicionamiento estratégico: "cheating with a better design"

La frase que el equipo de DuckDB Labs usa para describir su enfoque es honesta. Mientras Iceberg y Delta Lake gastaron años construyendo sistemas distribuidos de metadata sobre object storage —resolviendo problemas duros de consistencia eventual, locks distribuidos y atomicidad sin servidor central—, DuckLake simplemente delega esos problemas a un RDBMS, donde llevan resueltos cuarenta años.

Es una decisión arquitectónica con tradeoffs reales: escalar verticalmente un Postgres es eventualmente un cuello de botella que un sistema basado en archivos no tiene. Pero para el 95% de los casos prácticos, donde una organización tiene menos de 1 PB de datos en un solo lakehouse y un Postgres bien configurado puede manejar millones de operaciones por segundo, la simplificación operacional es enorme.

Lección de fondo

Hay un patrón en la historia de la ingeniería de datos que vale la pena retener. Cada cinco o seis años aparece una propuesta que cuestiona una premisa que el campo daba por sentada. Hadoop cuestionó "los datos tienen que estar en una base de datos". Spark cuestionó "MapReduce es el único modelo de cómputo distribuido". Iceberg y Delta cuestionaron "los lakehouses no pueden tener ACID". DuckLake cuestiona "el catálogo de un lakehouse tiene que vivir en archivos".

La pregunta para quien evalúa estas tecnologías no es si la nueva propuesta es mejor en abstracto, sino si la premisa que cuestiona aplica a su caso real. Para muchos equipos, los problemas que Iceberg resolvió con archivos JSON en S3 nunca fueron problemas que ellos tuvieran. Para esos equipos, DuckLake representa una simplificación legítima. Para equipos al límite del scaling de Iceberg con cientos de millones de archivos, la conversación es distinta y los tradeoffs cambian.

Y para devs que están entrando al campo de data engineering en 2026: valdría más aprender DuckLake con un catálogo Postgres y datos en R2 que tratar de armar un cluster Spark + Iceberg + Hive Metastore desde cero. Es más cercano al stack que un equipo de tres a diez personas necesita, y el ecosistema Postgres es enormemente más maduro que cualquier sistema distribuido específico de lakehouse.

Fuentes

DuckLake — sitio oficial: https://ducklake.select/
DuckLake — DuckLake v1.0: The Lakehouse Format Built on SQL Reaches Production-Readiness (anuncio 13 abr 2026): https://ducklake.select/2026/04/13/ducklake-10/
GitHub — duckdb/ducklake (repositorio público): https://github.com/duckdb/ducklake
DuckDB — anuncio DuckDB 1.5.2 (release que acompaña DuckLake 1.0): https://duckdb.org/2026/04/13/announcing-duckdb-152
InfoQ — DuckLake 1.0: Data Lake Format with SQL Catalog Metadata (Renato Losio, 2 may 2026): https://www.infoq.com/news/2026/05/ducklake-sql-catalog/
The Register — DuckDB uses RDBMS to tackle lakehouse 'small changes' issue (16 abr 2026): https://www.theregister.com/software/2026/04/16/duckdb-uses_rdbms_to_tackle_lakehouse_small_changes_issue/5222357
Definite — DuckDB and DuckLake: Why We Bet the Company on the Duck Stack: https://www.definite.app/blog/duckdb-ducklake-business-case
MotherDuck — DuckDB Ecosystem Newsletter (marzo 2026): https://motherduck.com/blog/duckdb-ecosystem-newsletter-march-2026/
Wikipedia — DuckDB: https://en.wikipedia.org/wiki/DuckDB
Wikipedia — Apache Iceberg: https://en.wikipedia.org/wiki/Apache_Iceberg
Wikipedia — Delta Lake: https://en.wikipedia.org/wiki/Delta_Lake
Wikipedia — Apache Parquet: https://en.wikipedia.org/wiki/Apache_Parquet
Wikipedia — Data lake: https://en.wikipedia.org/wiki/Data_lake
DuckDB — sitio oficial: https://duckdb.org/

Colored Shadow Penumbra: sombras con color en Unreal Engine 5.7

lu1tr0n — Thu, 07 May 2026 20:17:46 +0000

El colored shadow penumbra es uno de esos efectos que pasan inadvertidos hasta que alguien los apaga: ver una escena sin él hace que las sombras parezcan, de repente, demasiado limpias, demasiado neutras, demasiado 3D. La técnica reproduce un fenómeno óptico real (la transición coloreada entre la zona iluminada y la sombra dura) y, hasta hace poco, implementarla en Unreal Engine 5 implicaba pelearse con post-procesos frágiles que rompían con Lumen o con ciclos día/noche. La nueva implementación que el artista técnico Romain Durand puso de moda en redes y que Chosker liberó este mes resuelve el problema editando directamente los shaders del motor, con un costo de rendimiento prácticamente cero.

En este artículo desarmamos cómo funciona, copiamos línea por línea el código HLSL que se inyecta en los shaders de iluminación diferida, explicamos por qué necesita penumbras anchas para verse y discutimos cuándo conviene activarlo en producción. Si trabajás con UE5 desde LATAM, ya sea en un estudio indie o haciendo arch-viz, el colored shadow penumbra es una de esas mejoras de pulido que separan un render técnicamente correcto de uno que se siente vivo.

Qué es exactamente colored shadow penumbra

La luz, cuando atraviesa el borde de un objeto, no proyecta una sombra binaria entre iluminado y oscuro. Hay una región de transición llamada penumbra, donde la fuente de luz queda parcialmente ocluida y solo aporta una fracción de su intensidad. En esa franja, los rebotes indirectos (la luz que viene de paredes, suelos y el ambiente general) tienen relativamente más peso que la directa, y como la luz indirecta arrastra el color de las superficies que rebota, la penumbra termina teñida de los colores de la escena.

El fenómeno se conoce también como shadow terminator coloring en literatura de raytracing offline. Renderizadores no-real-time como Arnold, V-Ray o Cycles lo computan de forma natural porque trazan rayos secundarios. En tiempo real, Unreal Engine 5 simplifica el cálculo: usa un único término de sombra (SurfaceShadow) que va de 0 (en sombra completa) a 1 (totalmente iluminado) y modula la luminancia diffuse por ese factor. Esa simplificación es rápida pero borra la información cromática de la transición.

La técnica de Chosker reintroduce el efecto sin pagar el costo de un trazado real. La idea es ingeniosa: en la región donde SurfaceShadow es intermedio (la penumbra), saturar artificialmente el color base de la superficie. Con un colored shadow penumbra bien calibrado, una pared roja en sombra muestra rojos más vivos en su transición, una camisa azul deja un halo azulado al borde de su sombra y los materiales metálicos ganan profundidad sin lookdev adicional.
El efecto se nota más en bordes suaves de luces grandes y materiales saturados.

Por qué editar el shader del motor (y no un post-process)

Existen al menos tres caminos para introducir colored shadows en una escena de UE5: un Material Function aplicado por objeto, un Post Process Material global, o editar los shaders del engine directamente. Chosker descartó las primeras dos por una razón concreta: con Lumen activado o con ciclos día/noche, los valores que llegan al post-process ya están mezclados (luz directa, GI, especulares) y reconstruir cuál fragmento corresponde a sombra y cuál a iluminación se vuelve un ejercicio de adivinanza. Editar el shader de iluminación diferida resuelve el problema en su origen: ahí todavía existe la separación clara entre DiffuseLuminance y SurfaceShadow.

La ventaja adicional es que funciona con todos los tipos de luz (direccionales, puntuales, focales, rectangulares) sin código extra y se ejecuta una sola vez por píxel, en el mismo pase donde ya se está mezclando la sombra. El costo en GPU es marginal: un dot product y dos lerp, instrucciones que cualquier hardware moderno absorbe sin pestañear.

📌 Nota: Editar los shaders del motor no requiere clonar el repositorio completo de Epic ni compilar Unreal desde código fuente. Basta con la versión Launcher: los shaders del engine son archivos .usf/.ush en la carpeta Engine\Shaders\Private y se recompilan en frío con Ctrl + Shift + . dentro del editor.

Implementación con Substrate (UE 5.7)

Substrate es el nuevo sistema de materiales de Unreal Engine introducido como experimental en 5.2 y promovido a beta en 5.7. Si tu proyecto lo tiene activado (lo que es cada vez más común en producciones nuevas), el shader que necesitás editar es Engine\Shaders\Private\Substrate\SubstrateDeferredLighting.ush. Alrededor de la línea 190 vas a encontrar la línea que calcula la luminancia especular:

float3 SpecularLuminance = BSDFEvaluate.IntegratedSpecularValue * LightData.SpecularScale;

Inmediatamente después, agregás el bloque de colored shadow penumbra:

// Colored shadow penumbra - Start
const float PenumbraSaturation = 4.0f;

float3 LuminanceFactors = float3(0.3f, 0.59f, 0.11f);
float3 PenumbraColor = dot(DiffuseLuminance, LuminanceFactors);
PenumbraColor = lerp(PenumbraColor, DiffuseLuminance, PenumbraSaturation);
DiffuseLuminance = lerp(DiffuseLuminance, PenumbraColor, 1.0f - BSDFShadowTerms.SurfaceShadow);
// Colored shadow penumbra - End

El valor PenumbraSaturation = 4.0f es un punto de partida agresivo, pensado para que el efecto se vea en capturas comparativas. En producción, valores entre 1.5 y 2.5 dan un resultado más natural. Con 1.0 el efecto desaparece completamente (el lerp de saturación se cancela).

Implementación clásica sin Substrate

Si tu proyecto sigue usando el pipeline tradicional de iluminación diferida, el archivo objetivo es Engine\Shaders\Private\DeferredLightPixelShaders.usf. Alrededor de la línea 397 buscás:

OutColor += Radiance;

Y agregás justo después:

// Colored shadow penumbra - Start
const float PenumbraSaturation = 4.0f;

float3 LuminanceFactors = float3(0.3f, 0.59f, 0.11f);
float3 PenumbraColor = dot(OutColor.xyz, LuminanceFactors);
PenumbraColor = lerp(PenumbraColor, OutColor.xyz, PenumbraSaturation);
OutColor.xyz = lerp(OutColor.xyz, PenumbraColor, 1.0f - SurfaceShadow);
// Colored shadow penumbra - End

La lógica es idéntica; solo cambian los nombres de las variables porque el flujo de Substrate usa una estructura distinta para encapsular el resultado de la BSDF.

Cómo funciona el código línea por línea

Vale la pena desarmar las cinco líneas porque condensan tres conceptos importantes de teoría de color y composición:

Vector de luminancia (0.3, 0.59, 0.11) — son los pesos perceptuales del estándar Rec. 601 para convertir RGB a una intensidad gris equivalente. El verde pesa más porque el ojo humano es más sensible a esa banda. Hacer un dot entre el color y este vector colapsa cualquier color a su luminancia.- Saturación inversa — el primer lerp mueve el color desde su versión gris (PenumbraColor) hacia el color original (DiffuseLuminance) usando un factor mayor a 1. Cuando el factor pasa de 1, el lerp extrapola y produce una versión más saturada que la original. Es el mismo truco que usan los nodos de saturación de Photoshop o After Effects.- Mezcla por shadow term — el segundo lerp combina el color saturado con el color original usando 1.0 - SurfaceShadow como peso. En zonas totalmente iluminadas (SurfaceShadow = 1) el peso es 0 y no pasa nada. En zonas totalmente en sombra (SurfaceShadow = 0) el peso es 1 pero el color a mezclar ya es muy oscuro, así que tampoco se nota. Solo en la franja de transición se ve la versión saturada.

Es elegante porque no necesita detectar dónde está la penumbra: la propia función 1.0 - SurfaceShadow tiene su pico justo en esa región (cerca de 0.5) y cae hacia los extremos. La saturación se modula sola.

Visualización del flujo

graph LR
  A["Luz directa"] --> B["BSDF + Shadow Term"]
  B --> C["DiffuseLuminance RGB"]
  C --> D["Luminancia gris (Rec. 601)"]
  D --> E["Saturación inversa (lerp > 1)"]
  E --> F["Mezcla por (1 - SurfaceShadow)"]
  F --> G["Color final con penumbra coloreada"]

Ajustar PenumbraSaturation: el parámetro que importa

El único hiperparámetro de la técnica es PenumbraSaturation. Vale la pena dedicar tiempo a calibrarlo, porque el rango útil es estrecho:

1.0 — desactiva el efecto. Útil como sentinela durante debugging.- 1.2 a 1.8 — efecto sutil, perceptible solo en escenas con materiales saturados o luces grandes. Buen rango para arch-viz fotorrealista.- 2.0 a 3.0 — sweet spot para juegos estilizados, escenas con paleta artística o cinemáticas. El efecto se ve sin gritar.- 4.0 o más — exagerado a propósito, ideal para capturas de marketing pero rompe el realismo.

💡 Tip: Como el valor está hardcodeado en el shader, cada cambio implica recompilar shaders (varios minutos la primera vez, segundos después). Si vas a iterar mucho, conviene exponerlo como una console variable usando FAutoConsoleVariableRef en C++ o, más rápido todavía, parametrizarlo desde un material function global.

Limitaciones y casos donde no se ve

El colored shadow penumbra tiene tres limitaciones honestas que conviene comunicar al equipo de arte antes de venderlo como solución mágica:

Solo luces dinámicas — la sombra baked se calcula offline antes de que el shader corra, así que no hay penumbra que colorear. Si tu proyecto depende de iluminación pre-baked (común en mobile o VR de bajos requerimientos), esta técnica no aporta nada.- Necesita penumbras anchas — luces puntuales pequeñas con shadow maps duros producen penumbras de pocos píxeles, donde el efecto pasa desapercibido. Funciona mejor con luces rectangulares grandes, sky lights con soft shadows o virtual shadow maps con kernel amplio.- No se ve en grises ni saturados — un material totalmente gris no tiene color que saturar, y un material ya saturado al máximo tampoco gana. El efecto luce mejor en colores medios y materiales con reflectividad media.

Por qué importa para estudios indie en LATAM

El argumento más fuerte para adoptar la técnica no es estético sino económico. Un estudio indie en LATAM compite contra producciones AAA con presupuestos de iluminación cien veces mayores: lookdev artists dedicados, lighters senior, herramientas propietarias para comp y grading. El colored shadow penumbra es una de esas técnicas asimétricas que cierran parte de esa brecha sin contratar a nadie nuevo: cinco líneas de HLSL aplicadas una vez al engine fork del proyecto y todas las escenas heredan el mejor pulido visual.

Es también una excusa perfecta para subir el nivel del equipo en programación de shaders. Modificar SubstrateDeferredLighting.ush obliga a entender qué hace cada paso del pipeline diferido, qué información sobrevive entre el G-Buffer y el shading pass, y cómo Unreal estructura su evaluación de BSDFs. Es el tipo de conocimiento que en estudios grandes se aprende osmóticamente con el código fuente del engine, y que en LATAM se logra raras veces porque el acceso al source code de Epic sigue siendo un trámite que pocos completan.
El efecto suma profundidad cromática sin afectar la performance en runtime.

Qué sigue para colored shadows en tiempo real

El siguiente paso natural es exponer PenumbraSaturation a nivel de cada luz, no global del proyecto. La forma elegante sería agregar un campo FloatProperty a FLightData, llenarlo desde C++ y leerlo en el shader. Eso permitiría que un foco rojizo de una habitación cálida tenga saturación distinta a una luz fría de exterior, lo cual es más fiel a cómo se trabaja la luz en cinematografía.

Otra dirección interesante es separar el factor para diffuse y para specular. La implementación actual modifica solo el componente diffuse (que es donde el efecto tiene sentido físico) pero hay artistas que quisieran un control independiente para empujar el look hacia algo más estilizado. Y a más largo plazo, integrar la técnica con Lumen para que la saturación respete la información de GI ya calculada parece la evolución natural: ahí mismo está el color real que aporta la radiosidad, sin necesidad de aproximarlo con un truco.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Funciona en proyectos comerciales sin pagar licencia adicional a Epic?

Sí. Modificar los shaders del motor en la versión Launcher cae dentro del EULA estándar de Unreal Engine. No es lo mismo que distribuir un fork modificado del engine: solo estás cambiando archivos de shader que ya viven en tu proyecto. La licencia royalty del 5% sobre el millón de dólares se aplica por el uso del engine, no por las modificaciones.

¿Funciona con Lumen activado?

Sí, y es justamente uno de los argumentos a favor de editar el shader directamente en lugar de un post-process. Lumen aporta la GI; el colored shadow penumbra opera sobre la luz directa antes de que se sume al resultado final. No interfieren entre sí.

¿Cuál es el costo en GPU?

Despreciable en cualquier hardware compatible con UE5. Son 5 líneas de aritmética sin lecturas adicionales de texturas ni branching. En profilers como RenderDoc o el GPU Visualizer interno, el incremento del pase de iluminación es del orden del 0.1% o menos. La penalidad real viene una sola vez: la recompilación de shaders cuando el archivo cambia.

¿Por qué mi escena se ve igual después de aplicar el código?¿Cómo lo desactivo si causa problemas en producción?

Comentás las cinco líneas con /* */ y guardás el archivo. Unreal recompila los shaders en el siguiente arranque y la escena vuelve al comportamiento original. Por eso conviene siempre dejar los marcadores // Colored shadow penumbra - Start y // Colored shadow penumbra - End en el código: facilitan localizar el bloque para revertirlo en cualquier momento.

¿Puedo combinarlo con otros mods de shaders del engine?

Sí, mientras los bloques no toquen las mismas variables. La regla práctica es mantener cada mod en su propio archivo o en una sección bien delimitada del archivo del engine, documentar el cambio en un README del proyecto y versionar las modificaciones del engine en el mismo repo del juego para que otros desarrolladores no las pierdan al actualizar Unreal.

Referencias

Chosker: Colored Shadow Penumbra — artículo original con capturas comparativas y el código fuente del shader.- Wikipedia: Umbra, penumbra and antumbra — explicación física del fenómeno de la penumbra y la geometría de las sombras.- Unreal Engine 5 — sitio oficial con documentación del pipeline de iluminación diferida y Substrate.- EpicGames/UnrealEngine en GitHub — repositorio oficial del motor (requiere autorización de Epic) donde viven los shaders .usf y .ush.

WebGPU: cómo programar la GPU desde el navegador en 2026

lu1tr0n — Thu, 07 May 2026 16:04:51 +0000

Durante más de una década, WebGL fue la única forma de pintar gráficos acelerados en un navegador. Funcionaba, pero arrastraba las limitaciones de OpenGL ES 2.0, una API diseñada en 2007 para teléfonos de la época. En 2026, ese capítulo se cerró: WebGPU es ahora la API estándar para acceder a la GPU desde JavaScript, y abre la puerta a algo que WebGL nunca pudo ofrecer bien: computación de propósito general en la GPU dentro del navegador.

Si has oído hablar de Stable Diffusion corriendo en una pestaña sin instalar nada, de modelos de lenguaje pequeños ejecutándose localmente sin enviar datos a un servidor, o de juegos AAA portados directamente a la web, WebGPU es la pieza que lo hace posible. También sirve para simulaciones físicas, visualizaciones científicas, edición de video en el navegador y aceleración de algoritmos que antes requerían WebAssembly con SIMD. Esta guía explica qué es, cómo funciona internamente, qué problemas resuelve respecto a WebGL y cómo escribir tu primer programa de cómputo en GPU desde el navegador. No necesitas saber Vulkan, DirectX ni Metal: WebGPU abstrae las tres APIs nativas detrás de una interfaz unificada y portable.

Qué es WebGPU

WebGPU es una API web estandarizada por el World Wide Web Consortium (W3C) que permite a las aplicaciones web acceder a la GPU del dispositivo para tareas de gráficos y cómputo. La diseñaron Apple, Google, Mozilla, Microsoft e Intel a partir de 2017, alcanzó estabilidad en Chrome 113 en abril de 2023, llegó a Safari 17.4 durante 2024-2025 y entró en Firefox estable a principios de 2026 tras años en banderas experimentales.

A diferencia de WebGL, que es esencialmente una capa delgada sobre OpenGL ES 2.0/3.0, WebGPU se diseñó pensando en las APIs gráficas modernas que ya existen en cada sistema operativo. Por dentro, el navegador traduce cada llamada de WebGPU al backend nativo apropiado: Vulkan en Linux y Android, Metal en macOS e iOS, y Direct3D 12 en Windows. Esa traducción es lo bastante delgada como para conseguir rendimiento cercano al nativo, y lo bastante segura como para ejecutar código no confiable dentro de una pestaña.

💭 Clave: WebGPU no es "WebGL 2.0". Es una API completamente nueva con un modelo mental distinto: no se programa la GPU como una máquina de estados global, sino como un sistema de comandos explícitos y recursos tipados.

La diferencia con WebGL en una analogía

WebGL es como conducir un auto automático de los noventa: cómodo, perdona errores, pero opaco. WebGPU es como conducir un Fórmula 1: tienes que pensar en cada cambio de marcha, pero a cambio obtienes velocidad, control y predictibilidad. WebGL tenía una máquina de estados global: activar un shader, un buffer o una textura eran operaciones implícitas que la GPU procesaba en orden, y si dos partes del código modificaban el mismo estado podían pisarse mutuamente. WebGPU elimina ese problema: todo lo que la GPU necesita ejecutar viene empaquetado en un objeto inmutable llamado pipeline, y los recursos se agrupan en bind groups que se enlazan explícitamente. El resultado es código más predecible, paralelizable y fácil de optimizar.

Cómo funciona WebGPU paso a paso

Para usar WebGPU necesitas seguir cuatro pasos básicos: pedir un dispositivo, crear los recursos, escribir un shader y enviar comandos a la GPU. El flujo a alto nivel se ve así:

graph LR
    A["JavaScript"] --> B["GPUDevice"]
    B --> C["Buffers y Texturas"]
    C --> D["Shader WGSL"]
    D --> E["Pipeline"]
    E --> F["Command Encoder"]
    F --> G["GPU"]

1. Pedir un GPUAdapter y un GPUDevice

El punto de entrada es navigator.gpu. Desde ahí pides un adapter (la GPU física disponible en el equipo) y, a partir del adapter, un device que es el canal lógico por el que envías comandos. El navegador puede entregar varios devices al mismo origen, lo que permite aislar contextos y limitar recursos.

if (!navigator.gpu) {
  throw new Error("WebGPU no está soportado en este navegador");
}

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

2. Crear buffers y texturas

Los buffers son bloques de memoria en la GPU donde guardas datos: vértices, índices, parámetros uniformes o resultados de un cómputo. Cada buffer se crea con un tamaño fijo y un conjunto de banderas de uso (VERTEX, UNIFORM, STORAGE, COPY_SRC, COPY_DST). Las texturas son similares pero con dimensiones 2D/3D y formatos como rgba8unorm o r32float.

3. Escribir un shader en WGSL

WebGPU introduce su propio lenguaje de shaders: WGSL (WebGPU Shading Language). Es similar a Rust en sintaxis y se compila por debajo a SPIR-V en Vulkan, MSL en Metal y HLSL en DirectX. WGSL fue diseñado para ser seguro: prohíbe punteros sin restricciones, exige tipos explícitos y rechaza accesos fuera de rango en tiempo de compilación.

@group(0) @binding(0) var data: array;

@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3) {
  let i = id.x;
  if (i El pipeline de WebGPU empaqueta shader, recursos y configuración en un objeto inmutable.

## Ejemplo práctico: duplicar un array en la GPU

Veamos un ejemplo end-to-end que toma un array de números, lo sube a la GPU, lo multiplica por dos en paralelo y lo descarga de vuelta a JavaScript. Es el "hello world" del cómputo en GPU:

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

const input = new Float32Array([1, 2, 3, 4, 5, 6, 7, 8]);

const gpuBuffer = device.createBuffer({
size: input.byteLength,
usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_SRC | GPUBufferUsage.COPY_DST,
});
device.queue.writeBuffer(gpuBuffer, 0, input);

const module = device.createShaderModule({
code: `
@group(0) @binding(0) var data: array;
@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3) {
let i = id.x;
if (i WebGPU permite cómputo general en la GPU, algo que WebGL nunca soportó nativamente.

Ventajas y desventajas de WebGPU

Ventajas

Cómputo general nativo — los compute shaders abren la puerta a IA, simulaciones y procesamiento de datos en GPU.
Mejor rendimiento — overhead por llamada mucho más bajo que WebGL, lo que permite escenas con miles de objetos.
Errores explícitos — los recursos están tipados y validados, los shaders se compilan en una pasada y los errores aparecen donde corresponde.
Portabilidad real — el mismo código corre sobre Vulkan, Metal y DirectX 12 sin cambios.
WGSL seguro — diseñado para ejecutar código no confiable sin abrir vectores de ataque a la GPU.

Desventajas

Curva de aprendizaje — más conceptos que WebGL: pipelines, bind groups, layouts explícitos.
Más código boilerplate — un "hola triángulo" en WebGPU son 100 líneas; en WebGL eran 30.
Compatibilidad incompleta — algunas GPUs antiguas o de smartphones de gama baja no lo soportan, aunque la cobertura ya supera el 85% en 2026.
Documentación dispersa — al ser una API joven, los tutoriales aún están desactualizados o incompletos.

⚠️ Ojo: si tu aplicación necesita soportar navegadores antiguos o iPhones previos a iOS 17, sigues necesitando un fallback a WebGL. La detección con if (navigator.gpu) es obligatoria antes de cualquier llamada.

WebGPU vs WebGL vs CUDA

Para situar a WebGPU respecto a sus alternativas: WebGL sigue siendo el lowest common denominator y el único soporte universal a 2026; WebGPU es la API moderna pensada para hardware de la última década; y CUDA es la API propietaria de NVIDIA que solo corre en sus GPUs y solo fuera del navegador. WebGPU no compite con CUDA en términos de rendimiento absoluto en data centers, pero sí lo hace en accesibilidad: cualquier desarrollador con un navegador puede ejecutar cómputo en GPU sin instalar drivers ni compiladores nativos. Para machine learning ligero, gráficos en tiempo real y procesamiento de datos en aplicaciones web, WebGPU es ya la opción por defecto.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿WebGPU reemplaza completamente a WebGL?

No de inmediato. WebGL sigue funcionando y los navegadores lo mantendrán durante años por compatibilidad. Sin embargo, todo desarrollo nuevo de gráficos avanzados o cómputo en GPU debería empezar con WebGPU y dejar WebGL como fallback solo si necesitas soportar dispositivos antiguos.

¿Necesito una GPU dedicada para usar WebGPU?

No. WebGPU funciona sobre GPUs integradas (Intel UHD, AMD Radeon Vega, Apple Silicon) y sobre GPUs discretas. Las integradas tendrán menos rendimiento, pero la API es exactamente la misma. Lo único que necesitas es un navegador reciente y un sistema operativo con soporte para Vulkan, Metal o DirectX 12.

¿Funciona en móviles?

Sí. Chrome y Safari en Android e iOS modernos soportan WebGPU. La cobertura de iPhone llega hasta el modelo 11 (Apple A13) y en Android depende de que el fabricante mantenga drivers Vulkan actualizados, lo que ya es estándar en gama media-alta.

¿Cómo es WGSL comparado con GLSL?

WGSL es más estricto: tipos explícitos obligatorios, sin coerciones implícitas, sin punteros libres y con sintaxis más cercana a Rust que a C. La curva inicial es ligeramente mayor, pero los errores son más claros y el código resulta más portable entre plataformas.

¿Puedo usar WebGPU para entrenar modelos de IA?

Para inferencia es ideal. Para entrenamiento serio sigue siendo más práctico usar CUDA o ROCm en un servidor: WebGPU no expone primitivas de bajo nivel como tensor cores y los modelos grandes no caben en VRAM de consumo. Para fine-tuning ligero o experimentos educativos, sí es viable.

¿Qué frameworks soportan WebGPU en 2026?

Three.js, Babylon.js, Unity, Unreal Engine, transformers.js, WebLLM, ONNX Runtime Web, TensorFlow.js, deck.gl y PlayCanvas tienen soporte estable. La adopción siguió creciendo a lo largo de 2025 y 2026 conforme Safari y Firefox lo habilitaron por defecto.

Referencias

MDN Web Docs — WebGPU API — referencia oficial completa con guías y ejemplos.
W3C — WebGPU Specification — especificación normativa de la API.
W3C — WGSL Specification — especificación del lenguaje de shaders WGSL.
GitHub — gpuweb/gpuweb — repositorio oficial donde se discute la evolución del estándar.
Wikipedia — WebGPU — historia, contexto y estado de soporte por navegador.

MOOP Map 2025: el dataset de 20 años que cambió a 70.000 personas

lu1tr0n — Thu, 07 May 2026 14:23:40 +0000

Cada agosto, 70.000 personas convergen en un lago seco del desierto de Nevada para levantar desde cero una ciudad temporal. Ocho días después, Black Rock City se desvanece. Pero queda algo: 150 voluntarios formados hombro con hombro recorriendo 1.540 hectáreas (3.800 acres) de polvo a paso humano, registrando cada tornillo, cada lentejuela, cada colilla. El resultado es uno de los proyectos de datos comunitarios más particulares del mundo: el Burning Man MOOP Map. La edición 2025 acaba de publicarse y, como cada año desde 2006, cuenta una historia poco común para una comunidad de 70.000 personas: cómo un dataset puede modificar el comportamiento colectivo sin policías, sin multas, sin algoritmos de moderación. Solo con un mapa público pintado de verde, amarillo y rojo.

Para los desarrolladores en LATAM acostumbrados a dashboards de observabilidad, mapas de cobertura de tests o métricas DORA, el MOOP Map es un caso de estudio inesperado: una infraestructura analógica de accountability comunitaria, sostenida durante dos décadas, con resultados medibles que mejoran año tras año. Vamos a revisar qué dicen los números de 2025, cómo llegamos hasta acá, y qué lecciones tiene este modelo para cualquier equipo que use datos para cambiar conductas.

El MOOP Map 2025 en cifras

El 2025 MOOP Map fue publicado por el equipo de Restauración Ambiental de Burning Man tras varias semanas de barrido forense de la playa. El método es brutalmente analógico: 150 personas alineadas a la distancia de un brazo cada una, caminando lentamente sobre 3.800 acres (15,4 km²) de lecho seco, recogiendo y catalogando todo objeto humano que encuentren. Cada hallazgo se geolocaliza y se incorpora al mapa, que se publica con un código de color por severidad: verde (limpio), amarillo (limpieza moderada que ralentiza al equipo) y rojo (zonas tan contaminadas que detienen el avance).

En palabras de Dominic "DA" Tinio, gerente de Restauración Ambiental de Burning Man, "en términos simples, mientras más MOOPier es un área, más trabajo y tiempo de campo toma limpiarla hasta que las cuadrillas dejan de encontrar restos". MOOP, por sus siglas en inglés, significa Matter Out of Place: cualquier objeto humano que no debería estar en el desierto.

Lo más llamativo del informe 2025 son los lag bolts —tirafondos largos que anclan tiendas, instalaciones y arte al suelo— que dominaron el ranking de basura encontrada. A diferencia de las colillas o los purpurinas, los lag bolts no responden a un comportamiento específico de un grupo; son fallas distribuidas: prácticamente todos los campos perdieron algunos. Para los lectores con background en ingeniería, suena familiar: un bug sistémico que aparece con baja frecuencia en muchos servicios distintos, no un problema concentrado en un módulo.

El balance general: Black Rock City 2025 pasó la inspección oficial sin sobresaltos. Pero la historia detrás de este "sin sobresaltos" es mucho más interesante.

Severidad de cleanup por zona: verde, amarillo y rojo. Cada color implica horas de trabajo distintas.

20 años haciendo Leave No Trace data-driven

El MOOP Map no nació por iniciativa estética: nació por necesidad legal. El terreno donde se realiza Burning Man pertenece al Bureau of Land Management (BLM), la agencia federal que administra tierras públicas en Estados Unidos. Para que el evento pueda regresar cada año, debe pasar una inspección post-evento estricta: no más de un pie cuadrado de basura por acre (0,23 m²/ha). El BLM mide en 120 puntos repartidos por el sitio, y como máximo 12 de esos puntos pueden superar el umbral. Si 13 o más fallan, Black Rock City no vuelve.

En la práctica, el evento aprueba con holgura casi todos los años. Pero "casi" deja espacio para sustos. En 2023, 11 de los 120 puntos del BLM se pasaron del límite —el resultado más cercano al fracaso en la historia reciente. Una unidad más por encima del umbral y la edición 2024 podría no haber sucedido. La comunidad lo asumió como un wake-up call: cuando un sistema que toleras como margen se aproxima a su techo, los costos de un fracaso son catastróficos. En lenguaje de SRE: estás quemando tu error budget más rápido de lo previsto y es hora de reevaluar todo el proceso.

El MOOP Map mismo lleva dos décadas en operación. Su origen fue la necesidad de demostrarle al BLM que la comunidad tomaba en serio la limpieza, pero rápidamente evolucionó en una herramienta interna: un feedback loop público que cada campamento, cada proyecto artístico y cada participante recibe sobre el impacto que dejó su huella. "Desde 2006, en el largo arco del MOOP Map, la tendencia más llamativa es que la comunidad ha mejorado consistentemente en Leave No Trace, incluso cuando Black Rock City ha crecido dramáticamente en tamaño, complejidad y población", afirma DA. La medición empezó como obligación regulatoria y se convirtió en cultura.

💭 Clave: Este es uno de los efectos más potentes de las métricas públicas en cualquier organización: empiezan como cumplimiento y terminan como identidad. Cuando los datos son visibles y atribuibles, dejan de ser una imposición externa y se convierten en parte de cómo la gente se ve a sí misma.

Los números que revelan una mejora sostenida

Los datos detrás del MOOP Map son los que vuelven al proyecto fascinante. Si normalizamos la basura por persona —MOOP per cápita— el pico histórico está en 2010. Desde entonces, pese a que la población anual del evento creció considerablemente, la cantidad de basura por persona ha tendido a bajar. La mejora absoluta es aún más impactante: con un evento más grande, más complejo, con instalaciones más ambiciosas y más arte, el residuo total se mantiene bajo el techo legal.

Los principales tipos de basura encontrados en 2025 son:

Lag bolts (tirafondos): el #1 absoluto, distribuido entre prácticamente todos los campamentos.
Madera y restos de construcción: residuos de carpintería estructural cortada en sitio.
Tela, cuerdas y elásticos: especialmente trozos pequeños cortados durante el desmontaje.
Plásticos pequeños: tapas, envoltorios, partes de utilería.
Lentejuelas y micro-purpurina: el horror eterno del MOOP, prácticamente imposible de recoger una vez disperso.

Los cigarrillos y colillas, que históricamente fueron un problema importante en festivales similares, hoy aparecen en cantidades pequeñas. La señal cultural funcionó.

Los datos también permiten al equipo de DA distinguir entre fallas sistémicas y fallas específicas. Si una zona tiene mucho MOOP concentrado, la responsabilidad cae sobre el campamento o instalación en ese lugar. Si la basura está distribuida (como los lag bolts en 2025), el problema es del proceso colectivo de desmontaje. Esa distinción es clave: permite atacar la causa raíz en lugar de solo culpar al actor visible.

Para entender cómo se traduciría esto a código, una verificación BLM mínima podría modelarse así:

moop_zones = [
    {"id": "7:30-A", "color": "green",  "items_found": 2,  "area_acres": 4.2},
    {"id": "7:30-B", "color": "yellow", "items_found": 18, "area_acres": 4.2},
    {"id": "7:30-C", "color": "red",    "items_found": 47, "area_acres": 4.2},
]

BLM_THRESHOLD_SQFT_PER_ACRE = 1
SQFT_PER_ITEM_AVG = 0.05  # estimacion gruesa

def passes_blm_inspection(zones, max_failures=12):
    failures = sum(
        1 for z in zones
        if (z["items_found"] * SQFT_PER_ITEM_AVG) / z["area_acres"]
        > BLM_THRESHOLD_SQFT_PER_ACRE
    )
    return failures  **💡 Tip:** Si tu equipo opera con SLOs, esta es la analogía exacta: cada zona del MOOP Map es un SLI individual, el umbral por acre es el SLO, y el límite de 12 fallas es el error budget. Burning Man lleva 20 años haciendo SRE sin llamarlo así.

## De métrica de cumplimiento a herramienta de cultura

Lo más interesante del MOOP Map no son los números: es lo que la gente hace con ellos. El reporte oficial detalla, campo por campo, qué se encontró en su footprint. Los grupos en zonas rojas reciben un breakdown de su contribución a la basura total, con la expectativa de que mejoren al año siguiente. Los infractores reincidentes son flagueados al equipo que asigna ubicaciones futuras —si dejaste basura, te toca peor lugar el año siguiente, o no te toca lugar.

Pero la fuerza más poderosa no es institucional. Es social. Cada año, al publicarse el mapa, el subreddit de Burning Man lanza el "MOOP Map shame thread", donde los participantes señalan públicamente a los campamentos que dejaron zonas rojas. Es un mecanismo informal, no orquestado por la organización, pero brutalmente efectivo: nadie quiere que su crew aparezca en el thread. La transparencia genera vergüenza, y la vergüenza disciplina.

Para cualquier equipo de software, esto es profundamente familiar:

- **Dashboards públicos de uptime** tipo status pages.
- **Mapas de cobertura de tests** visibles en cada PR.
- **Rankings de contribución open source** en GitHub.
- **Métricas DORA** visibles para toda la organización.
- **Heat maps de errores** en Datadog o Sentry, atribuibles por servicio y owner.

Todos operan bajo la misma lógica. Cuando el dato es público y atribuible, el comportamiento cambia. El MOOP Map demuestra que esto funciona incluso fuera del software, con una población de 70.000 personas, sin enforcement automatizado.

> **⚠️ Ojo:** Las métricas tienen un costo: gobernarlas mal puede generar gaming (la gente optimiza para el número, no para el resultado real). El MOOP Map evita esto porque la métrica está alineada al outcome real (limpieza física), no a un proxy. Cuando diseñes métricas para tu equipo, pregúntate primero: ¿qué pasa si alguien optimiza esto al máximo? ¿El resultado real mejora, o solo el número?

El barrido forense lo hacen 150 voluntarios alineados a la distancia de un brazo.

## Cómo funciona el ciclo MOOP de punta a punta

El proceso completo, desde el final del evento hasta la decisión del BLM, sigue una secuencia clara que vale la pena visualizar:

graph LR
A["Evento Burning Man 8 dias"] --> B["Desmontaje de campamentos"]
B --> C["Equipo MOOP entra al sitio"]
C --> D["Barrido forense semanas"]
D --> E["Geolocalizacion y catalogo"]
E --> F["Publicacion MOOP Map"]
F --> G["Inspeccion BLM 120 puntos"]
G --> H{"Pasa la prueba"}
H -->|Si| I["Black Rock City vuelve"]
H -->|No| J["Permiso en riesgo"]




Lo interesante de este pipeline es que el output con mayor impacto no es la decisión del BLM (que casi siempre es "sí"), sino la publicación del mapa. Es ahí donde se cierra el feedback loop con la comunidad y donde se genera la presión social que lleva a la mejora del año siguiente. El BLM es la condición de borde; el mapa público es la herramienta de cambio.

## Qué sigue para el MOOP Map

¿Para dónde va el MOOP Map? La metodología base —barrido humano más georreferenciación manual— probablemente se mantenga, porque la precisión de un humano caminando despacio en busca de objetos pequeños es difícil de superar con sensores. Pero hay espacio para innovación.

### Posibles innovaciones tecnológicas

- **Drones con cámaras de alta resolución**: para escaneo previo de zonas y priorización de cuadrillas.
- **Computer vision**: clasificación automática de tipos de basura en imágenes de drone.
- **Análisis predictivo**: identificar campamentos con riesgo alto antes del desmontaje, basándose en patrones históricos por ubicación, tamaño y tipo de instalación.
- **Datasets abiertos**: publicación estructurada de los hallazgos para análisis externo, con investigadores académicos ya interesados en el material.

Por ahora, el equipo de Restauración Ambiental se mantiene en el método clásico, pero con un dataset que ya cubre dos décadas, hay material rico para que investigadores externos lo estudien. La comunidad data science alrededor del MOOP Map empieza a tomar forma —no formal, pero existente.

La lección más importante para 2026 y más allá: la mejor manera de crear cultura de Leave No Trace no es predicarla. Es medirla y publicar la medición. Para los equipos en LATAM que están construyendo sistemas, productos o comunidades, ese principio es totalmente exportable.

📖 Resumen en Telegram: [Ver resumen](#)

## Preguntas frecuentes

### ¿Qué significa MOOP exactamente?

MOOP significa *Matter Out of Place*: cualquier objeto humano que no debería estar en el desierto de Black Rock. Va desde un tornillo perdido hasta un pedazo de plástico de medio milímetro. La única excepción son las pisadas humanas en el polvo, que son inevitables.

### ¿Quién hace el barrido y cuánto dura?

Aproximadamente 150 voluntarios y empleados del equipo de Restauración Ambiental hacen el sweep. El proceso dura varias semanas después del cierre oficial del evento, dependiendo del tamaño del año y de qué tan MOOPier esté el sitio. Caminan en líneas paralelas a un brazo de distancia entre sí.

### ¿Qué pasa si Burning Man no pasa la inspección del BLM?

Si más de 12 de los 120 puntos de muestreo del BLM superan el límite de un pie cuadrado de basura por acre, el evento podría perder el permiso para regresar. Hasta hoy nunca ha fallado, pero en 2023 estuvo a un solo punto de hacerlo.

### ¿Por qué los lag bolts son el problema dominante en 2025?

Los lag bolts son tirafondos largos que se usan para anclar tiendas, instalaciones de arte y estructuras al suelo. Al desmontar, es fácil que uno se afloje y desaparezca bajo el polvo. No hay un solo culpable: prácticamente todos los campamentos perdieron alguno. Es un patrón distribuido, no concentrado.

### ¿Cómo se castiga a un campamento que deja mucha basura?

Los reincidentes son flagueados al equipo que asigna ubicaciones futuras dentro de Black Rock City. Pueden recibir peor ubicación al año siguiente o, en casos graves, perder el derecho a tener un placement en el evento. Adicionalmente hay presión social informal en redes (el famoso "MOOP Map shame thread" en Reddit).

### ¿Hay datasets abiertos disponibles para análisis?

Burning Man publica el mapa con sus colores y estadísticas agregadas, pero no un dataset estructurado completo. Los datos crudos quedan internos al equipo de Restauración Ambiental. Hay interés creciente en abrir más datos para investigación académica.

## Referencias

- [Not-Ship: The map that keeps Burning Man honest](https://www.not-ship.com/burning-man-moop/) — análisis original con visualizaciones del MOOP Map 2025.
- [Burning Man Project](https://burningman.org/) — sitio oficial del evento, incluye documentación sobre Leave No Trace y proceso MOOP.
- [Wikipedia: Burning Man](https://en.wikipedia.org/wiki/Burning_Man) — historia del evento, contexto regulatorio y estadísticas de asistencia.
- [r/BurningMan](https://www.reddit.com/r/BurningMan/) — comunidad activa donde se publica anualmente el MOOP Map shame thread.

📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/programacion) donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Permacomputing: 10 principios para una computación sostenible

lu1tr0n — Thu, 07 May 2026 08:20:10 +0000

El concepto de permacomputing empieza a salir de los círculos académicos y los foros de hackers para instalarse en debates serios sobre el futuro del software. La idea es simple en su enunciado y radical en sus consecuencias: aplicar las éticas de la permacultura —cuidar la tierra, cuidar las personas, redistribuir lo justo— al diseño, construcción y mantenimiento de sistemas computacionales. El sitio oficial permacomputing.net publica diez principios que guían esta práctica, y en 2026 el debate ha ganado relevancia frente al crecimiento explosivo del consumo energético de la inteligencia artificial y de los desechos electrónicos.

Para quien escribe código, configura infraestructura o decide qué dispositivo comprar, permacomputing no es una doctrina prescriptiva sino un marco para hacerse mejores preguntas. ¿Necesito desplegar este modelo en GPUs nuevas o un modelo más pequeño basta? ¿Tiene sentido reescribir esta app en Electron y triplicar el consumo de RAM? ¿Vale la pena renovar la flota de laptops cada tres años cuando la mayoría sigue funcionando? Las respuestas no están escritas, pero los principios ayudan a formularlas.

Qué es permacomputing

El término permacomputing fue acuñado en 2020 por el programador finlandés Ville-Matias "viznut" Heikkilä, conocido en la escena demoscene por sus experimentos con computación en condiciones extremas (programas que generan música compleja con apenas unas líneas de C). Su ensayo original proponía repensar la informática desde una perspectiva post-crecimiento, asumiendo que los recursos materiales para fabricar chips, baterías y data centers son finitos.

El movimiento se inspira directamente en la permacultura, una corriente de diseño agrícola y ecológico nacida en Australia en 1978 con los trabajos de Bill Mollison y David Holmgren. Permacultura no es solo agricultura orgánica: es un sistema de diseño que observa los ciclos naturales y crea soluciones de bajo consumo, alta resiliencia y mínima intervención. Permacomputing toma ese mismo espíritu y lo traduce al hardware, los sistemas operativos, los protocolos y las prácticas de desarrollo.

La comunidad —que mantiene un working group activo y publica documentación abierta— deja claro que permacomputing no es prescriptivo. No te dice qué lenguaje usar ni qué editor abrir. Lo que ofrece son lentes para mirar tu propia práctica y preguntarte si lo que estás construyendo aporta valor proporcional al costo socioambiental que implica.

Contexto: de la permacultura a los servidores solares

Antes de entrar en los principios conviene situar el movimiento dentro de una genealogía. Hay precedentes claros que prepararon el terreno:

Low-tech Magazine (Kris De Decker, 2007) — una revista digital que desde 2018 corre sobre un servidor alimentado por paneles solares. Cuando no hay sol, el sitio se cae. Esa "limitación" es el punto.- The Small Web y el 250kb Club — iniciativas que celebran sitios web livianos, sin trackers ni frameworks pesados.- 100R / Hundred Rabbits — el colectivo de Devine Lu Linvega y Rekka Bellum, que vive en un velero y desarrolla herramientas (Uxn, Orca, Left) optimizadas para correr con energía limitada.- Solarpunk — el movimiento estético-político que imagina futuros tecnológicos en armonía con la biósfera.

Permacomputing recoge ideas de todas estas tradiciones y las organiza alrededor de diez principios concretos. El sitio permacomputing.net documenta cada uno con ejemplos, lecturas adicionales y estrategias de aplicación tanto para personas técnicas como para usuarios casuales.
Servidores de bajo consumo: la práctica que inspira a permacomputing.

Los 10 principios, en español

A continuación una traducción comentada de los diez principios. La versión completa con todos los matices vive en permacomputing.net/principles:

1. Cuidar la vida

Toda decisión técnica debe ponderar su impacto sobre los seres vivos —humanos y no humanos— y sobre los ecosistemas. Es el principio raíz, equivalente al "Earth Care" de la permacultura.

2. Cuidar todo el hardware (especialmente los chips)

Los microchips son los componentes más caros de fabricar en términos energéticos y materiales: requieren litros de agua ultrapura, gases raros, energía intensiva y son prácticamente imposibles de reciclar. Maximizar la vida útil de cada dispositivo es un acto político.

3. Mantenerlo pequeño

El bloat es enemigo. Un binario más liviano no solo carga más rápido: cabe en hardware viejo, consume menos memoria, pesa menos en la red. Hay un linaje claro entre suckless, plan9 y este principio.

4. Esperar lo mejor, prepararse para lo peor

Diseñar sistemas resilientes a interrupciones, fallas de red, cortes de energía o colapso parcial. No por catastrofismo, sino porque la fragilidad ya es la realidad de millones de personas con conexiones inestables y hardware limitado.

5. Mantenerlo flexible

Sistemas que se adaptan a contextos diversos en lugar de imponer un único entorno "óptimo".

6. Construir sobre tierra firme

Apoyarse en estándares abiertos, formatos durables, dependencias estables. Evitar construir sobre arenas movedizas (APIs propietarias que mañana cambian, frameworks que se reescriben cada dos años).

7. Amplificar la conciencia

La computación puede fortalecer ecosistemas mediante proyectos de citizen science: medición de calidad del aire, biodiversidad, contaminación. Datos abiertos para tomar mejores decisiones colectivas.

8. Exponer todo (sin cajas negras)

Transparencia en arquitectura, código y procesos. El usuario debería poder entender qué hace su software y por qué.

9. Responder a los cambios

Adaptarse en lugar de imponer. Permacomputing prefiere sistemas evolutivos a soluciones rígidas.

10. Todo tiene su lugar (y a veces lo correcto es no hacer)

Antes de añadir tecnología, preguntarse si realmente hace falta. El principio "Not Doing" reconoce que la mejor solución muchas veces es no construir nada nuevo.

💡 Tip: Antes de aceptar un ticket que pide "agregar IA" a una feature existente, pasalo por el filtro del principio 10. ¿Se resuelve mejor con un select bien hecho? ¿Ya existe la funcionalidad y basta documentarla?

Datos y cifras: por qué importa ahora

Los números detrás de la urgencia de permacomputing son contundentes:

62 millones de toneladas de basura electrónica generadas en 2022 según el UN Global E-Waste Monitor —el equivalente al peso de unos 1.500 buques cargueros— y se proyectan 82 millones para 2030.- Entre 1% y 2% del consumo eléctrico mundial proviene de los data centers, una cifra que la Agencia Internacional de Energía estima podría duplicarse para 2030 por la demanda de IA.- Producir un solo chip moderno consume miles de litros de agua ultrapura y emite gases con potencial de calentamiento global miles de veces superior al CO₂.- Apenas el 22% del e-waste mundial se recicla formalmente. El resto termina en vertederos del Sur Global, contaminando suelos y aguas.- Una laptop promedio emite alrededor de 300 kg de CO₂ en su fabricación —más que un vuelo Buenos Aires–Madrid en clase económica.

Estos números explican por qué hablar de "computación sostenible" sin revisar el modelo de fabricación y descarte es una conversación incompleta.

Impacto en la práctica de desarrollo

Aplicar permacomputing al día a día como developer no requiere mudarse a un velero. Hay decisiones cotidianas con impacto real:

Stack técnico

Preferir lenguajes y runtimes eficientes cuando el caso lo permite. No todo necesita correr sobre Node + Electron + 80 dependencias. Una CLI en Go, una app TUI en Rust, un script en Python sencillo: muchas veces alcanza.

Infraestructura

Elegir proveedores con energía renovable verificable. Un servidor en una región con grid limpio (Quebec, Islandia, partes de Brasil con hidroeléctrica) tiene una huella significativamente menor que el mismo workload en una región dominada por carbón.

Hardware

Refurbished antes que nuevo. Reparar antes que reemplazar. Iniciativas como Framework Laptop o iFixit demuestran que es posible diseñar hardware reparable y seguir siendo competitivo.

Software

Empacar binarios optimizados, no incluir dependencias innecesarias, soportar arquitecturas viejas cuando sea barato hacerlo. Aceptar que tu código va a correr en un equipo con 4GB de RAM en algún lugar del mundo.

# Auditar el peso real de tu app antes de shipear
du -sh dist/
# 245M  dist/  ← ¿es necesario?

# Bundle analyzer para webpack/vite
npx vite-bundle-visualizer

# Para imágenes Docker, dive permite explorar capa por capa
dive my-image:latest

⚠️ Ojo: "small" no significa "primitivo". Permacomputing no romantiza la pobreza tecnológica. La idea es construir lo mínimo necesario para resolver el problema con elegancia, no privarse de herramientas útiles por dogmatismo.
La cultura de la reparación: permacomputing avant la lettre en LATAM.

Permacomputing en clave LATAM

América Latina tiene una relación particular con muchos de estos principios porque, en gran medida, ya los practica por necesidad. La cultura de la reparación —del taller que arregla un Nokia 3310 al técnico que mantiene servidores Pentium 4 corriendo en el ministerio— es permacomputing avant la lettre.

Algunos puntos donde la región está naturalmente alineada con el movimiento:

Reuso de hardware — laptops corporativas usadas que llegan al mercado secundario después de ciclos de 3-5 años en empresas. En Argentina, Chile, México y Colombia hay un mercado robusto de equipos refurbished.- Conexiones inestables — apps que funcionan offline-first, PWAs livianas y código que tolera latencia son parte del kit básico de cualquier developer regional.- Cortes de energía — UPS, generadores, salvado automático cada minuto. La resiliencia no es teoría.- Frugalidad técnica — no hay presupuesto para reemplazar todo cada año, así que mantener viejo es la norma.

Donde permacomputing puede aportar más a la región es en darle marco conceptual y dignidad a prácticas que muchas veces se ven como signos de subdesarrollo, cuando en realidad son ventajas competitivas para construir software resiliente.

Diagrama: permacultura como raíz

graph TD
    A["Permacultura (1978)"] --> B["Earth Care"]
    A --> C["People Care"]
    A --> D["Fair Share"]
    B --> E["Permacomputing"]
    C --> E
    D --> E
    E --> F["10 principios"]
    F --> G["Cuidar el hardware"]
    F --> H["Mantenerlo pequeno"]
    F --> I["Resiliencia"]
    F --> J["No hacer"]

Qué sigue para el movimiento

Permacomputing está en una etapa de consolidación. La working group publica artículos, organiza encuentros y mantiene el sitio principal. Hay una comunidad activa en el fediverso (Mastodon) bajo el hashtag #permacomputing, conferencias relacionadas como handmade.network y HOPE, y una creciente literatura académica sobre "computación sustentable" que dialoga con estas ideas.

El próximo desafío del movimiento es escalar sin perder coherencia. Que un principio inspire una práctica concreta —y verificable— es mucho más útil que diez principios bonitos sin tracción. Iniciativas como bandwidth budgets en sitios estáticos, calculadoras de huella de carbono para websites (websitecarbon.com) y certificaciones de software verde empiezan a operacionalizar estos valores.

💭 Clave: Permacomputing no es anti-tecnología. Es anti-desperdicio. La pregunta no es "¿menos computación?" sino "¿qué computación, para quién y por cuánto tiempo?".

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Permacomputing es lo mismo que green computing?

No exactamente. Green computing suele enfocarse en eficiencia energética dentro del paradigma actual. Permacomputing cuestiona el paradigma mismo: el modelo de crecimiento perpetuo, la obsolescencia programada y la dependencia de hardware nuevo.

¿Tengo que dejar de usar Kubernetes?

No. Permacomputing no prohíbe tecnologías, propone preguntarse si son la herramienta adecuada para cada caso. Si tu workload realmente justifica orquestación distribuida, adelante. Si lo usás para un blog estático que recibe 100 visitas al día, quizá un VPS de cinco dólares al mes alcanza.

¿Quién mantiene permacomputing.net?

Una working group informal compuesta por desarrolladores, artistas, investigadores y activistas. Es un proyecto comunitario sin financiamiento corporativo.

¿Existen herramientas concretas alineadas con estos principios?

Sí. Algunos ejemplos: el navegador Dillo, el sistema operativo 9front, los lenguajes Uxn y Orca de Hundred Rabbits, distribuciones Linux livianas como Alpine y Void, y el ecosistema suckless (dwm, st, surf).

¿Cómo empiezo a aplicar permacomputing en mi trabajo?

Auditá. Medí el peso de tus apps, el consumo de tu pipeline de CI/CD, el ciclo de vida del hardware que decidís comprar. Sin datos no hay diagnóstico, y sin diagnóstico no hay cambio.

¿Es viable para una startup que necesita escalar rápido?

Depende del nicho. Para muchas startups B2B con tracción incipiente, ir lean en stack y hardware reduce burn rate y alarga la pista. Permacomputing y unit economics se llevan mejor de lo que parece.

Referencias

permacomputing.net/principles — los 10 principios oficiales con explicaciones extendidas y estrategias de aplicación.- solar.lowtechmagazine.com — la revista que corre sobre un servidor solar y se cae cuando no hay sol suficiente.- wiki.xxiivv.com — la página de Devine Lu Linvega (Hundred Rabbits) sobre permacomputing y herramientas asociadas.