1005 | Bits de la semana: IA, privacidad e infraestructura

Clara Vega: Hola y bienvenidos de nuevo, soy Clara Vega.

Mateo Ruiz: Y yo, Mateo Ruiz. Y sí, como siempre, hemos pasado el día leyendo los hilos que más discusión han levantado en las últimas veinticuatro horas, y hoy vienen con un hilo conductor bastante claro: la confianza. Confianza en el software que usamos, confianza en los coches que conducimos, confianza en las nubes que almacenan nuestros datos... y luego el otro lado de la moneda: la gente que se construye sus propias herramientas precisamente porque esa confianza, a veces, no existe.

Clara Vega: Exacto. Vamos a empezar por un caso que tiene a la comunidad de seguridad bastante molesta, y luego iremos soltando el resto: coches que chafardean, centros de datos de Google al descubierto, Apple Intelligence, IA en escritorios, protocolos nuevos, túneles caseros, la F1, Ucrania... Bueno, mejor no me adelanto. Empecemos por lo de Xray-core.

Mateo Ruiz: Vamos allá. Para quien no conozca el proyecto: Xray-core es un núcleo de proxy muy usado, sobre todo en entornos donde la censura y la vigilancia son un problema real. Y resulta que en su función de pinnedPeerCertSha256 —que básicamente permite fijar, anclar, el certificado esperado de un servidor— había una vulnerabilidad de bypass. Es decir, la verificación del certificado podía evitarse por completo.

Clara Vega: Y ojo al detalle clave, porque es lo que ha encendido el hilo: estuvo oculta durante un año. Un año entero. No es solo que hubiera un bug, es que no se hizo público. La gente en la discusión se dividía bastante rápido en dos campos.

Mateo Ruiz: Sí, y esa división me parece lo más interesante de este hilo. Por un lado estaban quienes decían: mirad el contexto. Xray-core lo usan personas que se juegan bastante, en países donde un proxy descubierto puede tener consecuencias graves. Si el fallo se anuncia públicamente, se convierte en una guía de explotación para quien justamente quiere vigilar a esos usuarios. Un parche silencioso, razonan ellos, protege a los usuarios reales mientras se despliega la corrección.

Clara Vega: Y por el otro lado, la respuesta clásica pero potente: la seguridad por oscuridad no escala y no funciona. Quienes mantenían esa postura argumentaban que los usuarios no pueden tomar decisiones informadas si no saben que existía el riesgo. Si yo confié mi tráfico a pinnedPeerCertSha256 durante ese año, tenía derecho a saberlo, aunque fuera después.

Clara Vega: Porque tal vez yo estaba verificando certificados precisamente porque sospechaba de un atacante concreto, y ahora resulta que esa verificación era papel mojado.

Mateo Ruiz: Y ahí aparece el argumento que más se repetía: el problema no es el fallo en sí —los fallos ocurren en todos los proyectos— sino la gobernanza del disclosure. Quién decide, con qué criterios, y si ese criterio está escrito en algún sitio o depende del humor del que tiene el commit.

Clara Vega: A mí me quedaba una pregunta en el aire, y es que en el hilo tampoco se cerró del todo: ¿qué passa con el modelo de confianza de los proyectos de seguridad en general? Xray-core no es una app de notas; es infraestructura crítica para gente vulnerable. ¿Debería un proyecto así tener una política de divulgación pública, tipo CVE, auditada por terceros? Varios comentarios apuntaban en esa dirección, otros decían que exigirle eso a un proyecto voluntario es irreal.

Mateo Ruiz: Y el contrapunto a esa irrealidad: si no lo exiges, acabas de ver lo que pasa. Un año de silencio. Yo me quedo con esa tensión: no hay respuesta limpia, pero la conversación sobre cómo se comunica —no solo si se comunica— ya es un avance.

Clara Vega: Bueno, y si hablamos de confianza traicionada, pasamos directamente del proxy al aparcamiento. Porque el siguiente hilo trata sobre... tus ruedas, Mateo.

Mateo Ruiz: Sí, y este es de los que a mí me descolocan. Un estudio de la Northeastern junto con Consumer Reports analizó coches conectados, y el resultado es que diecinueve de veintiuno envían datos a terceros. Diecinueve de veintiuno. Casi todos.

Clara Vega: La reacción inicial en el hilo fue casi de cansancio, ¿no? Como "bueno, ya lo sabíamos". Pero luego la conversación se puso interesante, porque la pregunta que surgió de inmediato fue: ¿pero envían qué, exactamente, y con qué consentimiento?

Mateo Ruiz: Ahí está el quid. Varios participantes contaban su experiencia de primera mano con la letra pequeña: cuando compras el coche, aceptas un paquete de términos que literalmente nadie lee, y ahí, entre cláusulas, está el consentimiento para compartir datos con aseguradoras, con brokers de datos, con quien sea. Y había quien argumentaba que técnicamente has consentido, así que no es un escándalo legal sino de diseño.

Clara Vega: Y la réplica a eso fue fuerte: el consentimiento en un contrato de ochenta páginas que firmas para poder conducir tu coche no es consentimiento, es coerción estructural. No puedes "no aceptar" y seguir usando el coche que acabas de comprar. Alguien lo planteaba muy bien: en ningún otro producto doméstico aceptarías ese reparto de datos como condición de uso.

Mateo Ruiz: Y luego estaba el otro bloque de la discusión, el de "bueno, ¿qué importan unos datos de telemetría?". Y la respuesta venía del contexto asegurador: si tu coche reporta cómo frena, cómo acelera, dónde aparcas... esa información puede acabar influyendo en tu prima. Varios decían que ya hay compañías que ofrecen descuentos a cambio de ese flujo, y que el problema es cuando el flujo existe sin que tú elijas.

Clara Vega: Lo que no quedó claro, y lo digo porque en el estudio recogido tampoco se detalla, es qué terceros son exactamente y qué hacen con los datos. Esa es la parte que sigue abierta. Y de hecho alguien hacía la comparación con el sector que ahora mismo está en boca de todos: los centros de datos.

Mateo Ruiz: Sí, conecta perfecto, porque el tercer hilo de este bloque es literalmente sobre transparencia... involuntaria. Resulta que una redacción mal hecha —un documento mal redactado, básicamente un error editorial— reveló datos que Google no había hecho públicos sobre sus centros de datos en Nebraska: el consumo de agua y de electricidad, y los reembolsos fiscales que reciben.

Clara Vega: Y aquí el hilo se convirtió casi en un debate de política pública. Porque los reembolsos fiscales son dinero público: las comunidades compiten ofreciendo exenciones fiscales para atraer centros de datos, a cambio de empleos y actividad económica. Y varios comentarios decían: si el municipio les da dinero, el municipio tiene derecho a saber cuánta agua y electricidad se lleva ese vecino.

Mateo Ruiz: Y el otro lado: el consumo de agua de los datacenters es información operativa sensible, sobre todo con la presión hídrica que hay en muchas zonas de Estados Unidos. Publicar cada cifra puede generar pánico local o dar ventaja competitiva. Quienes defendían a Google en el hilo decían que no es ocultación maliciosa, es prudencia comercial.

Clara Vega: Pero el detalle que a mí me pareció revelador es que la información salió por un error de redacción. O sea, no fue una decisión de transparencia, fue un accidente. Y en el hilo había un consenso parcial, lo digo con cuidado porque no todos lo compartían, de que eso revela algo: que la información existe, se recopila, y simplemente no se publica. La discusión quedó en: ¿debería esa publicación ser obligatoria por ley?

Mateo Ruiz: Y de la nube al escritorio, porque hay gente que dice "bueno, si no confío, pues lo apago". Y justamente hay una herramienta para eso. RemoveMacAI: una utilidad que desactiva Apple Intelligence en macOS 27, borra los modelos del disco, y —esto es importante— es reversible.

Clara Vega: Este hilo fue más tranquilo, casi un alivio después de los anteriores. Los comentarios celebraban sobre todo la reversibilidad: no es una desinstalación destructiva, puedes volver atrás. Varios contaban su caso de uso: portátiles con almacenamiento justo, donde esos modelos se comen decenas de gigas, y ellos no piensan usar la IA de Apple nunca, así que fuera.

Mateo Ruiz: Pero incluso ahí hubo matiz. Alguien preguntaba: ¿por qué hace falta una herramienta de terceros para esto? Si no quieres la función, debería poder desactivarse limpiamente desde Ajustes. Y la respuesta que se daba es que Apple empuja mucho estas funciones, las deja activadas o semiractivadas, y que una herramienta así es básicamente un botón que Apple no quiere darte.

Clara Vega: Y aquí está la conexión que queríamos hacer: quitar la IA de tu disco es también una decisión sobre dónde corre esa IA. Si no la quieres local, tampoco la quieres en la nube de nadie. Y eso nos lleva de la mano al segundo gran bloque: la IA que ahora mismo está bajando de los gigantes al escritorio.

Mateo Ruiz: Empecemos por la estrella del bloque: Strata. Es un proyecto que consigue ejecutar Qwen 3.8 Flash Next, un modelo de 125 mil millones de parámetros, en hardware de consumo. Y no a tirones: unos 100 a 124 tokens por segundo en una RTX 4090.

Clara Vega: La 4090, para contextualizar, es una tarjeta cara, pero es una tarjeta de consumo. No es un clúster de ocho GPUs de datacenter. Y ejecutar un modelo de 125B en ella, a esa velocidad, es el tipo de cosa que hace dos años parecía descabellada. En el hilo la reacción fue de escepticismo primero —como siempre— y luego de sorpresa cuando la gente detallaba cómo se logra.

Mateo Ruiz: Y ahí surge el debate predecible pero necesario: ¿esto qué significa? Un grupo decía que es el momento de democratización: pronto, la diferencia entre "IA de nube" e "IA en casa" será solo una cuestión de comodidad, y quien valore privacidad —y aquí todos volvimos a RemoveMacAI, fíjate— tendrá una alternativa real.

Clara Vega: El otro grupo ponía pegas muy razonables. Primera: la 4090 no es barata, así que "hardware de consumo" es relativo; es el extremo alto del consumo. Segunda: un modelo ejecutado así no tiene el contexto de servicio, la latencia de red, los sistemas de moderación, todo lo que rodea a un producto comercial. Y tercera, que para mí es la más seria: nadie sabe todavía cuánta energía consume un montaje así en funcionamiento continuo.

Clara Vega: Ese punto quedó explícitamente abierto en el hilo: si todo el mundo corre su modelo local las 24 horas, ¿qué pasa con la factura eléctrica?

Mateo Ruiz: Y el consumo energético de los centros de datos, ya vimos antes, es hasta un secreto de Estado de facto. Ja. Bueno, pero Strata no es lo único que se está adaptando. La propia red debajo de la IA está siendo rediseñada. ¿Me dejas presentar este, Clara?

Clara Vega: Adelante.

Mateo Ruiz: John Ousterhout —el mismo de los sistemas distribuidos, del Raft— tiene un protocolo nuevo llamado Homa, que propone reemplazar TCP en clústeres de IA. La diferencia clave: el control de congestionamiento es receptivo, basado en el receptor, en vez del modelo tradicional centrado en el emisor.

Clara Vega: Este hilo tenía un tono distinto, más técnico, casi de seminario. Quienes conocían el trabajo de Ousterhout defendían la idea con entusiasmo: en un clúster de IA, el patrón de tráfico es radicalmente distinto al de internet. Son miles de GPUs sincronizándose, esperándose unas a otras; si un flujo va lento, toda la red lo nota. El control clásico de TCP, diseñado para otro mundo, rinde mal ahí.

Mateo Ruiz: Y los escépticos hacían dos objeciones que me parecieron las mejores del hilo. Una: TCP tiene cuarenta años de herramientas, de hardware, de talento acumulado. Reemplazarlo es un coste enorme, y solo se justifica si el ahorro es claro. Dos: ¿esto escala fuera del clúster? Homa nace en entornos controlados, con topologías conocidas. Llevarlo a redes heterogéneas es otra película.

Clara Vega: Y la tercera objeción, que apareció más de pasada: ¿quién adopta esto? Un clúster de IA es un entorno cerrado, así que quizá sí es viable dentro de una empresa grande que construye su propia red. Pero el despliegue es la parte difícil de siempre en redes.

Mateo Ruiz: Bueno, y cerrando el bloque técnico, una pieza más pequeña pero muy comentada: Headstart. Es una herramienta que emite los metadatos de Rust temprano, antes de que el compilador termine todo el trabajo, y eso acelera cargo check y cargo build hasta un cincuenta y cuatro por ciento y un cuarenta y dos por ciento respectivamente en proyectos reales.

Clara Vega: Este hilo fue más de "vaya, qué ingenioso" que de debate. Los desarrolladores de Rust contaban su dolor: proyectos grandes donde cargo check tarda minutos, y en un bucle de trabajo eso se traduce en horas perdidas a la semana. Y la idea de Headstart, adelantar los metadatos que el sistema de tipos necesita, es de esas que en retrospectiva parecen obvias.

Mateo Ruiz: Había algo de cautela, eso sí: algunos preguntaban si esos números se sostienen en proyectos medianos o solo en los muy grandes, y si la herramienta mantiene la paridad con las versiones del compilador. Pero en general, aprobado por la comunidad.

Clara Vega: Bien, cambio de aires. Pasamos del datacenter y del compilador a algo más íntimo: las herramientas que uno monta en casa. Y este bloque me encanta porque es literalmente la respuesta emocional a todo lo que hablamos en el primer bloque.

Mateo Ruiz: Empecemos por los túneles. La idea: exponer servicios de tu propia casa a internet usando solo lo que ya tienes. OpenSSH con remote forward —el reenvío remoto, que es una función que lleva ahí décadas— para traer tu servicio hasta un servidor público, y nginx con el módulo secure link para ponerle un token expirable, es decir, un enlace que caduca.

Clara Vega: Lo que la gente señalaba en el hilo es que esto sustituye a los servicios comerciales de túneles —tú sabes, los que te dan una URL y te ponen un pequeño límite de tráfico gratis— por dos piezas de software libre que quizá ya tienes corriendo. Y el módulo secure link es el detalle fino: no basta con exponer el servicio, hay que controlar quién puede alcanzarlo, y un token con caducidad es una solución elegante sin escribir ni una línea de código propia.

Mateo Ruiz: Los contras, que también salieron: requiere entender SSH y nginx, mantener el servidor puente, y vigilar la seguridad del conjunto. Alguien decía que es perfecto para compartir algo con un amigo durante una tarde, no para dirigir un negocio. Y como experiencia, varios contaban que ya lo usaban así sin llamarlo "producto", simplemente porque SSH hacía eso desde siempre y ahora por fin lo estaban formalizando.

Clara Vega: Del túnel a la foto, porque hay otro proyecto local-first que me parece del mismo espíritu: SCM, una herramienta para macOS que indexa con IA todas tus fotos y todos los fotogramas de tus vídeos, en local. Usa Whisper para el audio, OCR para el texto en imágenes, detección de escenas... y todo funciona sin subir nada.

Mateo Ruiz: Y la discusión aquí giró en torno a por qué las soluciones nativas de Apple o Google no bastan. Los comentarios decían que las funciones de búsqueda integradas son superficiales: buscas "playa" y no encuentras la foto de la boda en la playa. Una herramienta que indexa cada fotograma, transcribe el audio y lee el texto de las capturas cambia la pregunta que puedes hacerle a tu archivo personal.

Clara Vega: El coste, como siempre: indexar todos los fotogramas de una biblioteca grande lleva tiempo y disco, y la primera indexación puede tardar días. Pero quien lo probaba parecía considerar que valía la pena. Y es la misma filosofía de RemoveMacAI: tus datos, tu disco, tus reglas.

Mateo Ruiz: Y ahora viene la pieza nostálgica, que en el hilo generó una marea de cariño: un IDE al estilo de Visual Basic 6, nativo en el navegador. Con runtime, diseñador de formularios, y que compila todo a un único archivo HTML.

Clara Vega: Ay, Visual Basic 6. Mateo, la cantidad de gente que aprendió a programar arrastrando un botón a un formulario...

Mateo Ruiz: Demasiados. Y en el hilo había dos lecturas. La nostálgica: esto fue la puerta de entrada a la programación para toda una generación, y el modelo de "dibuja la interfaz y conecta el comportamiento" es una forma de enseñar que se ha perdido. La lectura más fría, de quien lo mira con ojos actuales: compilar a un HTML único es una idea muy potente hoy, es el equivalente moderno de "te doy un archivo y lo ejecutas donde quieras". Sin dependencias, sin servidor, sin build.

Clara Vega: Y un tercero en la discordia preguntaba si esto era más que una curiosidad: ¿alguien construirá algo real con esto? Y la respuesta que se daba era interesante: da igual. La utilidad de estas herramientas no está solo en el resultado, sino en el placer del proceso. Que nos lleva directamente a la última pieza de este bloque.

Mateo Ruiz: Nolan Lawson publicó una pregunta que divide a la comunidad de desarrollo desde siempre: ¿por qué los desarrolladores evitan "usar la plataforma"? Es decir, ¿por qué, teniendo APIs nativas del navegador o del sistema, la gente prefiere montar frameworks, librerías y abstracciones encima?

Clara Vega: Y Lawson mismo ofrecía tres explicaciones. Primera, la histórica: la plataforma del navegador era, durante años, dolorosa e inconsistente, y las librerías nacieron para sobrevivir a eso; el hábito se heredó aunque la plataforma haya mejorado. Segunda, la familiaridad: los equipos conocen React o su framework de turno, y las APIs nativas les resultan un idioma extranjero. Y tercera, la que a mí me pareció la más honesta: el placer de construir.

Clara Vega: Hay gente a la que usar la plataforma se le queda corta, no por necesidad sino porque construir la herramienta es la parte divertida.

Mateo Ruiz: Y en el hilo, casi todo el mundo estaba de acuerdo con las tres, pero la conversación se animó al discutir el peso de cada una. Había quien decía que la tercera, el placer de construir, explica más de lo que la industria admite en público: nadie quiere reconocer que reimplementa un gestor de estado por diversión.

Mateo Ruiz: Otros respondían que en equipos grandes la decisión no es por placer sino por control y contratación: es más fácil contratar gente que conoce tu framework que gente que domina las especificaciones de la plataforma.

Clara Vega: Y nadie resolvió la pregunta, porque creo que no tiene resolución. Pero encaja perfecto con todo lo anterior: túneles SSH en vez de servicios de túnel, búsqueda local en vez de nube, un IDE VB6 en el navegador. Todo es gente que decide construir en vez de confiar. Y confiar, ya vimos, tiene un precio.

Mateo Ruiz: Bueno, pasemos al último bloque, que es más humano y más pesado: energía, generosidad y memoria. Empecemos por Ucrania, porque es el más urgente.

Clara Vega: Sí. En medio de los ataques rusos contra la infraestructura ucraniana, están funcionando las renovables distribuidas. El ejemplo que se comentaba: la solar en Mykolaiv, y en general la generación repartida, está manteniendo el suministro de agua y de electricidad cuando los ataques a gran escala dejan a oscuras a las ciudades.

Mateo Ruiz: Y aquí el hilo tenía una lectura muy clara, que me gustó porque no es la habitual: no es solo una historia de guerra, es una tesis sobre el diseño de infraestructura. Un sistema centralizado —una central grande, una red troncal— es eficiente pero es un objetivo: un golpe y la ciudad entera sin luz. Un sistema distribuido —paneles en tejados, generación repartida— es más difícil de apagar, porque no hay un solo punto de fallo.

Clara Vega: Varios comentarios hacían la extrapolación: si esto tiene sentido bajo bombardeos, ¿por qué no tiene sentido bajo tormentas, apagones, o simplemente para reducir las pérdidas de transporte? Había también, eso sí, la nota realista: la distribución no elimina la vulnerabilidad, la reduce; los inversores, el almacenamiento, los puntos de conexión siguen siendo objetivos. Y en un país en guerra, instalar y reparar paneles también cuesta vidas y dinero.

Mateo Ruiz: Pero es un dato que se queda contigo: la resiliencia como argumento de diseño, no de marketing. Y desde la infraestructura pasamos a otra forma de construcción a largo plazo: el legado. Nos enteramos del fallecimiento de Bill Draper, inversor de riesgo de tres generaciones de la familia Draper, y financiador de 280 ONGs.

Clara Vega: Doscientas ochenta ONGs. Y en el hilo la conversación derivó casi inmediatamente hacia el debate más amplio sobre cómo se dona. Porque hay una pieza periodística reciente de The Economist que analiza la evolución del altruismo eficaz, el movimiento que defiende donar donde cada dólar tenga más impacto medible. Y Will MacAskill, una de las figuras centrales de ese movimiento, respondió personalmente a la pieza.

Mateo Ruiz: La discusión que se generó era la clásica pero viva: los defensores del altruismo eficaz decían que la crítica de The Economist era en parte justa —el movimiento ha tenido problemas de tono, de arrogancia— pero que el núcleo, el intento de medir y priorizar, es lo mejor que le ha pasado a la filantropía en décadas. Los críticos respondían que la obsesión con la métrica desplaza causas que no se pueden medir bien: arte, derechos, política.

Clara Vega: Y la figura de Draper sirve de contrapunto curioso, porque financiar 280 ONGs no parece el modelo "pocos dólares, máximo impacto medible" del altruismo eficaz; parece más el modelo disperso, el de apoyar mucho y confiar. Alguien lo planteaba así en el hilo: ¿cuál de los dos modelos deja mejor mundo? Y la respuesta honesta es que nadie lo sabe, porque no hay experimento controlado.

Mateo Ruiz: Y la última pieza, más ligera pero con la misma vena de largo plazo: el archivo digital del Video Game History Foundation, el VGHF, ha superado las cinco mil revistas de videojuegos, cubriendo de 1981 a 2026. Y acaba de empezar a incluir revistas japonesas.

Clara Vega: Y la conversación aquí era de pura gratitud con un fondo serio. La prensa de videojuegos en papel se ha destruido a un ritmo enorme —desaparece más rápido de lo que se digitaliza— y estas revistas son, además de nostalgia, documentación primaria: cómo se hablaba de los juegos en su momento, qué se prometía, qué se criticaba. La inclusión de revistas japonesas la celebraban especialmente, porque gran parte de la historia del medio se escribió en japonés y casi no está accesible fuera de Japón.

Mateo Ruiz: Bueno, y terminamos como empezamos, con el software fallando donde menos se espera. Un fallo de software en la Fórmula 1, en Bahrain y en Sepang, dejó a los pilotos sin potencia durante la vuelta de presentación. El arreglo: un parche que tardó unos cincuenta minutos.

Clara Vega: Y la discusión, aunque breve, apuntaba a algo que nos ha acompañado todo el programa: hasta el deporte de élite, con presupuestos gigantescos y equipos de ingeniería, depende de código desplegado en caliente que puede fallar en el peor momento. La vuelta de presentación, además, es un momento simbólico: delante del público, sin posibilidad de postergar.

Mateo Ruiz: La pregunta abierta que dejaba el hilo: ¿endurecerá la FIA los procesos de despliegue de software? Es decir, ¿exigirán algo parecido a un pipeline de pruebas más estricto, o canary deployments, o simplemente más tiempo de margen entre el parche y la carrera? Nadie lo sabe todavía, pero si la F1 aprende algo de este incidente, probablemente será eso.

Clara Vega: Y con eso cerramos un programa que, si nos fijamos, ha ido de la confianza rota —Xray-core, los coches, los datacenters de Google— a la confianza reconstruida a mano —túneles SSH, búsqueda local, RemoveMacAI—, pasando por la IA que baja al escritorio, la energía que aguanta bombas en Ucrania, un legado filantrópico, cinco mil revistas y un coche de Fórmula 1 que se quedó sin potencia por un bug.

Mateo Ruiz: Nada mal para veinticuatro horas. Gracias por acompañarnos, soy Mateo Ruiz.

Clara Vega: Y yo, Clara Vega. Nos vemos en el próximo programa.