DiluxNews: la semana en que todo parecía legítimo, y casi nada lo era

DiluxNews: la semana en que todo parecía legítimo, y casi nada lo era
<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Tiempo de Lectura"></span> <span class="bsf-rt-display-time" reading_time="12"></span> <span class="bsf-rt-display-postfix" postfix="minutos"></span></span><!-- .bsf-rt-reading-time -->

¡Hola! 👋 Esta semana leí las noticias y me quedé pensando en una sola pregunta, que se repetía en todas: ¿cómo sabés que algo es lo que dice ser?

Un paquete de código firmado, con su certificado válido y todo, que resultó ser malicioso. La llave que le prueba a Google que sos vos, colgada en la memoria del navegador. Un agente navegando con tu cara y tus contraseñas. Y Europa, del otro lado, decidiendo que por lo menos la IA está obligada a decir que es IA 😅

Nada de esto pasó junto a propósito, pero mirado en conjunto dice bastante sobre dónde estamos parados. Agarrá un café que arrancamos ☕

1️⃣ Un gusano se comió 1.300 paquetes de npm (y venían firmados)

Gráfico con las cifras del incidente ChainDrop: 1.300 paquetes de npm, 2.000 millones de descargas mensuales y 2.212 versiones maliciosas en menos de 4 horas
Gráfico propio, con datos públicos del incidente del 4 de agosto de 2026.

El martes se destapó ChainDrop, y es de las cosas más incómodas que vi en supply chain. Más de 1.300 paquetes de npm comprometidos, con un alcance estimado de unos 2.000 millones de descargas mensuales. Entre ellos, utilidades que muchísima gente tiene instalada sin saberlo: keyv, cacheable, flat-cache, file-entry-cache.

Vamos con el término técnico, porque acá está lo importante. Un gusano no es un virus común: el virus necesita que alguien lo ejecute, el gusano se copia solo de una víctima a la siguiente sin que nadie lo ayude. Y un ataque de supply chain (cadena de suministro) es cuando en vez de atacarte a vos, atacan algo que vos instalás. No te rompen la puerta: se meten adentro de la heladera que vos mismo pediste 🥲

El mecanismo es de manual, y por eso duele. Comprometieron la cuenta de GitHub de un maintainer, dispararon los pipelines de CI de esa misma persona, y desde ahí publicaron las versiones infectadas. Firmadas. Válidas. Cuando hacés npm install, un script que corre antes de instalar baja un runtime alternativo, ejecuta un payload ofuscado, y le saca una foto a la memoria del runner de GitHub Actions para robarse los tokens de publicación. Con esos tokens infecta todos los paquetes que la próxima víctima pueda publicar. Y así, solo.

Lo que me quedó dando vueltas: el eslabón que falló no fue el registry, ni la criptografía, ni la firma. Fue la credencial. Un token de publicación de larga vida, con permiso sobre todos los paquetes del maintainer, sentado en el entorno de CI esperando que alguien se lo lleve.

Y acá quiero ser cuidadoso, porque la conclusión fácil sería “entonces que un humano apruebe cada publicación”, y eso está mal. Automatizar el despliegue es buena práctica, no un descuido: la investigación de DORA viene mostrando hace años que los procesos de aprobación externa empeoran el tiempo de entrega y la frecuencia de despliegue sin mejorar la tasa de fallas, y que las organizaciones que los usan son bastante más propensas a estar entre las de peor rendimiento. Los comités de cambio aprueban más del 90% de lo que revisan: son un sello, no un control 🙃

Pero además, en este caso puntual, un humano aprobando no habría frenado nada: el atacante tenía la cuenta del maintainer, así que el que apretaba “aprobar” iba a ser él. Un permiso manual te protege del error honesto, no de una identidad robada.

Así que la pregunta no es “¿hay un humano en el medio?”, sino “¿qué alcanza cada credencial de mi pipeline, y cuánto tiempo vive?”. Tres preguntas concretas para el lunes a la mañana 🤔

  • ¿Tenés el lockfile commiteado, o cada build resuelve versiones nuevas por su cuenta?
  • ¿Corrés npm ci con --ignore-scripts, para que un paquete no ejecute nada al instalarse?
  • ¿Tus tokens de publicación son eternos y viven en un secret desde 2021, o usás credenciales efímeras? npm tiene trusted publishing con OIDC: el CI pide una credencial que vale solo para esa publicación, no existe fuera del workflow y no se puede copiar. Encima firma la procedencia sola.

2️⃣ Todas tus passkeys de Google cuelgan de una llave que nadie puede revocar

Esquema: una única llave maestra, el security domain secret, de la que cuelgan todas las passkeys sincronizadas
Esquema propio sobre cómo funciona la sincronización de passkeys de Google.

El lunes salió una investigación sobre el Password Manager de Google en Chrome, con tres variantes de ataque bautizadas Pass-ta-key. Y quiero empezar por lo que no pasó, porque esto se prestó a titulares medio locos.

Una passkey es el reemplazo de la contraseña: en vez de un secreto que vos escribís (y que te pueden robar por phishing), tu dispositivo guarda una llave privada y firma un desafío para probar que sos vos. Es genuinamente mejor que una contraseña, y eso sigue siendo cierto después de esta noticia. La criptografía no se rompió.

Lo que se rompió es el sync, que es la parte cómoda. Resulta que todas las passkeys que sincronizás se cifran con una única llave maestra, y esa llave se le manda a Chrome durante la configuración inicial y se queda colgada en la memoria del navegador. Si hay malware ya corriendo en tu máquina, la agarra y desencripta todas de una sola vez. Y acá viene la parte que de verdad me preocupa: hoy Google no tiene forma de rotarla ni de revocarla. No es que te robaron una llave y cambiás la cerradura. Es la cerradura.

Ojo con el nivel de alarma: esto necesita malware ya instalado en tu equipo, o sea que no es un ataque remoto contra cualquiera. Pero cambia la cuenta de qué te pasa después de que te comprometen una máquina. Si tenés llaves críticas (las de trabajo, las de la plata), pensar dos veces si querés que vivan sincronizadas en el navegador o en un dispositivo aparte 🔑

3️⃣ Google metió un agente adentro de tu Chrome, con tus contraseñas

Anuncio oficial de Google del 30 de julio de 2026 titulado Gemini Spark now integrates with Chrome
Captura del anuncio oficial de Google, 30 de julio de 2026. © Google.

Y en la misma semana, esto. Gemini Spark ya maneja tu Chrome de escritorio de verdad, no un navegador de mentira en la nube: el tuyo, con tus sesiones abiertas y las contraseñas que tenés guardadas, para hacerte trámites. Empezó a llegar en Estados Unidos el lunes, y AI Pro se habilitó en 160 países más.

Hay dos modos, y la diferencia entre uno y otro es toda la noticia:

  • Remoto: el agente navega desde un browser en la nube. Cuando un sitio le pide que inicie sesión, se frena en seco. Es el modo aburrido y seguro.
  • Local: maneja el Chrome que tenés abierto, con tus sesiones y tus contraseñas guardadas. Entra a todo lo que entrás vos, porque literalmente es tu navegador.

Google puso algunas barandas, hay que decirlo:

  • Los pagos y los posteos en redes piden confirmación manual tuya.
  • Dice tener defensas en capas contra prompt injection, que es cuando una página maliciosa esconde instrucciones en su texto para que el agente las lea y las obedezca como si vinieran de vos.

No voy a decirte que no lo uses, porque la comodidad es real y esto va a estar en todos lados en un año. Lo que sí me parece es que hay que entender qué le estás delegando. Del lado del servidor que recibe la visita no hay forma de distinguir si sos vos o es el agente: mismo browser, misma sesión, mismas credenciales. Todo el modelo de “confío porque estás logueado” se apoya en que adentro de la sesión hay una persona. Esta semana esa premisa dejó de valer 😬

4️⃣ El AI Act europeo ya puede cobrar (y a la vez aflojó)

Página oficial del AI Act Explorer de la Comisión Europea mostrando el artículo 50 y el aviso del Digital Omnibus
Captura del AI Act Explorer de la Comisión Europea. © Unión Europea, 2026.

Esta es la que más me costó ordenar, porque vi titulares que decían “Europa se puso dura” y otros que decían “Europa aflojó”, en la misma semana. Las dos cosas pasaron, y hay que contarlas juntas. Pero antes, dos minutos de contexto, porque si no no se entiende nada 😅

El AI Act es la ley europea de inteligencia artificial, aprobada en 2024. Es la primera del mundo que regula la IA de forma general, y su idea central es simple: funciona por niveles de riesgo, y cuanto más puede lastimarte un sistema, más obligaciones le caen.

  • Prohibido: directamente no se puede. Por ejemplo, puntuar socialmente a las personas.
  • Alto riesgo: se puede, con muchos requisitos encima. Acá caen los sistemas que deciden sobre la vida de alguien.
  • Transparencia: se puede, solo tenés que avisar. Acá caemos casi todos los que hacemos software con IA.
  • El resto: sin obligaciones nuevas.

Como es enorme, no entró en vigor de golpe: viene por etapas desde 2024. Primero las prohibiciones, después las reglas para los modelos de propósito general (los modelos grandes de uso general, esos que todos conocemos), y ahora, el 2 de agosto, tocó la etapa que nos toca a los que construimos software.

Lo que entró en vigor es el artículo 50, el de transparencia. Y cuando digo “si tu producto”, me refiero a algo bien concreto: cualquier software tuyo que use IA de cara a una persona. Por ejemplo:

  • El bot de atención al cliente del sitio.
  • El asistente que responde adentro de la app.
  • El generador de textos o de imágenes.
  • La función que arma un resumen automático.
  • El sistema que estima emociones o datos biométricos por la voz o la cara.

Si algo de eso está en tu producto, el artículo 50 te obliga a avisarlo: que la persona sepa que está hablando con una IA y no con un humano, y que el contenido generado esté marcado como tal. Nada de chatbots haciéndose pasar por “Sofía del equipo de soporte” 🙃

Y la parte nueva de verdad no es la obligación, que ya estaba escrita, sino que ahora se puede cobrar. Recién ahora la Comisión Europea tiene la potestad de investigar y aplicar multas: hasta 15 millones de euros o el 3% de la facturación mundial anual, el que sea mayor (para pymes y startups aplica el menor de los dos, que al menos es algo).

Ahora la otra mitad, la que casi no se contó. El Digital Omnibus, un paquete de la Comisión en vigor desde fines de julio, pateó las obligaciones de alto riesgo a diciembre de 2027 y agosto de 2028. Alto riesgo son los sistemas que deciden sobre la vida de la gente:

  • El que filtra currículums en una búsqueda laboral.
  • El que da o niega un crédito.
  • El que monitorea empleados.
  • Los que se usan en educación o en salud.

Esa era la parte cara de cumplir, la de gestión de riesgos, documentación técnica y evaluación de conformidad, y se corrió dos años. Por eso conviven los dos titulares: se activó lo barato y se pospuso lo caro.

¿Por qué te importa esto si estás en Buenos Aires y no en Bruselas? Porque el AI Act no mira dónde estás vos, mira dónde está el usuario. Alcanza a cualquiera que ponga un sistema de IA en el mercado europeo o cuyo resultado se use en la Unión Europea. Si tenés un cliente en España, un usuario en Alemania o vendés un SaaS que alguien usa desde allá, te aplica igual, aunque tu empresa, tu equipo y tus servidores estén todos acá 🌎

Mi lectura: lo que hoy te toca cumplir es barato, y eso es lo que se está subestimando. Poner el cartel de que hay una IA del otro lado y marcar lo generado es una tarde de trabajo, no un proyecto trimestral, y el costo de no hacerlo ya dejó de ser cero. Y me quedó dando vueltas algo más: en una semana en la que todo giró alrededor de “cómo sé que esto es lo que dice ser”, la única respuesta institucional que apareció fue exactamente esa, obligar a que se declare 🇪🇺

5️⃣ Anthropic se pone a diseñar sus propios chips

Listado de puestos abiertos de Anthropic con las búsquedas Research Engineer Chip Design RL y Silicon Engineer
Captura del listado de puestos abiertos de Anthropic. © Anthropic.

El miércoles Anthropic confirmó que está armando un equipo interno de silicio propio para diseñar chips para Claude, buscando gente que sepa de hardware y de software a la vez, para diseñar el chip y el modelo en conjunto. No suelta a AWS, Google, Nvidia ni AMD: se agrega como fuente propia. Suena Samsung como posible fabricante y no hay fecha de nada.

El término acá es inferencia: es lo que cuesta usar un modelo ya entrenado, cada vez que alguien le hace una pregunta. Entrenar es carísimo pero pasa una vez. Inferir es más barato por unidad, pero pasa millones de veces por día, todos los días. A escala, el costo de inferencia es el negocio.

Por eso todos los que están arriba en IA terminan bajando al fierro. Cuando tu margen depende del costo por token, no podés dejar ese costo en manos de un proveedor. Es la misma película que ya vimos con los hyperscalers y sus chips propios, y engancha directo con la noticia que sigue.

6️⃣ La inferencia se abarató 80%, y tu factura igual va a subir

Gráfico de barras comparando el precio por millón de tokens de entrada antes y después de la baja: Luna de 1,00 a 0,20 dólares y Terra de 2,50 a 2,00
Gráfico propio, con los precios publicados por OpenAI.

OpenAI bajó el precio de GPT-5.6 Luna un 80% (de un dólar a veinte centavos por millón de tokens de entrada, y de seis a un dólar veinte de salida) y el de Terra un 20%. Y confirmó que pasó los 1.000 millones de usuarios activos. Enfrente, Alibaba sacó Qwen 3.8-Max: 2,4 billones de parámetros totales pero solo 95 mil millones activos por token, con ventana de un millón de tokens.

Antes de entusiasmarnos, dos aclaraciones que me parecen importantes. La primera: no es una promoción, la baja está atribuida a mejoras de eficiencia en cómo sirven los modelos, así que es permanente. La segunda: no es un evento, es una curva. El precio de una misma capacidad viene cayendo alrededor de diez veces por año desde hace rato, y se espera que eso modere a tres o cinco veces por año hasta 2027. O sea que esto no es la noticia de una semana, es la tendencia de fondo del negocio 📉

Ese número raro de “parámetros activos” es lo que se llama mixture of experts: el modelo es gigante, pero para cada token enciende solo una fracción chica de sí mismo, como una oficina enorme donde para cada consulta trabajan cinco personas en vez de las mil. Por eso se puede bajar el precio sin bajar la calidad. No es magia, es no pagar por lo que no usás.

Ahora, fijate en el gráfico de arriba, porque ahí está lo que casi no se cuenta: la baja es asimétrica. El modelo barato bajó 80%, el capaz bajó 20%. Lo que se está volviendo commodity es la capacidad del año pasado, no la frontera. La distancia entre el modelo económico y el de punta no se está cerrando, se está ensanchando, y encima cada generación nueva de frontera vuelve a acomodar el precio para arriba. Que el piso se derrumbe no quiere decir que el techo baje 🤨

Y acá viene lo que más me interesa, porque va contra la intuición: los tokens bajan y las facturas suben igual. En 2025 el uso típico era una pregunta y una respuesta. En 2026 el uso pasa por agentes que planifican, llaman herramientas y dan vueltas hasta terminar, y en cada paso reenvían todo el contexto otra vez. Una tarea agéntica consume del orden de mil veces más tokens que una consulta de chat, y Google multiplicó por más de trescientas veces los tokens que procesa por mes en apenas dos años. Si tu consumo se multiplica por mil y el precio se divide por cinco, adiviná para dónde va la cuenta 💸

Entonces, ¿qué significa esto para el que construye? No es que el modelo dejó de importar, es que elegir un solo modelo dejó de ser una decisión de arquitectura seria. El trabajo es otro:

  • Enrutar por nivel: mandar al modelo barato todo lo que el barato resuelve bien, y reservar el caro para lo que de verdad lo necesita.
  • Medir por tarea, no por token: el precio del token no te dice nada si no sabés cuántos se come cada tarea de punta a punta.
  • Ponerle presupuesto y límite de pasos a los agentes antes de soltarlos. Y esto no es paranoia: hay casos documentados de sistemas multiagente que quedaron en loop días enteros quemando decenas de miles de dólares.

Y el ángulo de acá, que para mí es el que más pesa: cuando cobrás en pesos y pagás la inferencia en dólares, el costo por token no es un detalle de infraestructura, es tu margen. La buena noticia es que la capacidad que hace dos años era carísima hoy está al alcance de cualquier equipo chico en la región 🌎 La mala es que el ahorro no te lo regalan, te lo tenés que ganar con ingeniería.

🎯 En resumen

La semana entera se puede resumir en que la confianza dejó de venir de arrastre:

  • Una firma válida no alcanza, si lo comprometido es el pipeline que firma.
  • Un login no prueba que del otro lado haya una persona.
  • Una llave que no se puede revocar no es una llave, es un problema esperando fecha.

El consejo práctico, para el lunes: agarrá tus pipelines de CI y hacete la pregunta incómoda. No “¿esto publica sin que un humano diga que sí?”, porque automatizar está bien y agregar un aprobador no te salva de una cuenta robada. La pregunta es “¿hasta dónde llega cada credencial que hay acá adentro, y cuánto tiempo vive?” 🛠️

Si la respuesta es “llega a todo y no vence nunca”, ahí tenés trabajo para esta semana. Y es de lo más barato que podés hacer con lo que aprendimos estos días.

¿Lo estás viendo igual que yo, o me estoy poniendo paranoico? Te leo en los comentarios, o en el hilo que armé en X 👇

El hilo de esta edición en X

Acerca de

Professor. Techie. Ice cream fan (dulce de leche). My favorite phrase: "Todos los días pueden no ser buenos ... pero hay algo bueno en todos los días". Currently I´m Engineering Manager at MODO (https://modo.com.ar), the payment solution that allows you to connect your money and your world to simplify everyday life. Modo is a payment solution in which you can send, order and pay from your mobile device in the safest, most practical and convenient way. I enjoy a lot of educational, technological talks and a good beer. If you want to talk, write me to [email protected].

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*