Carta abierta: IA y Pentágono & Agentes de IA: aislar por defecto - Noticias de Hacker News (28 feb 2026)

Primero, el bloque más político y, sinceramente, más delicado del día: una carta abierta titulada “We Will Not Be Divided” —“No nos dividirán”— sostiene que el Departamento de Defensa de Estados Unidos estaría amenazando a Anthropic en represalia por negarse a dos cosas: usar modelos para vigilancia masiva doméstica y permitir que sistemas de IA participen en decisiones letales sin supervisión humana. La carta usa un lenguaje provocador, llamando “Department of War” al DoD, y asegura que el gobierno podría invocar la Defense Production Act para obligar a Anthropic a “proveer y adaptar” su modelo a necesidades militares, incluso etiquetando a la empresa como “riesgo para la cadena de suministro”. Además, afirma que el Pentágono estaría conversando con Google y OpenAI para conseguir permisos que Anthropic habría rechazado. Lo llamativo aquí no es solo el contenido, sino el enfoque: los autores —presentados como empleados de Google y OpenAI— dicen que el método de presión es “dividir” a las compañías, haciendo que cada una tema quedarse atrás si otra cede. Por eso piden coordinación: que los líderes de esas empresas mantengan una postura común frente a vigilancia y autonomía letal. El sitio presume un volumen grande de firmantes verificados: cientos de empleados actuales de Google y decenas de OpenAI, con opción de firmar de forma anónima pero verificada. También hay transparencia técnica: hosting en Fly.io, base SQLite cifrada, verificación por correo con Resend y una app Flask open source. Incluso mencionan que detectaron y corrigieron un bug de verificación que permitió una firma falsa temporalmente, y que lidiaron con duplicados que el sistema automático no filtró. Es decir: además del mensaje político, intentan dar señales de integridad operativa. Como siempre, conviene separar afirmaciones, fuentes y consecuencias: el tema es explosivo y el incentivo al ruido es alto. Pero el hecho de que empleados se organicen públicamente —y describan su “pipeline” de verificación— es un síntoma de época: la gobernanza de la IA ya no es un debate abstracto, sino un conflicto laboral y estratégico.

Pasamos de la geopolítica al barro técnico de la seguridad, con una tesis que suena obvia pero rara vez se aplica con disciplina: los agentes de IA hay que tratarlos como no confiables, incluso potencialmente maliciosos. Gavriel Cohen compara dos enfoques: OpenClaw, que por defecto corre en la máquina anfitriona y confía en prompts, permisos “amables” o sandboxes opcionales; y NanoClaw, que adopta “diseño para la desconfianza”. En NanoClaw, el aislamiento es la norma: cada invocación del agente nace en un contenedor efímero —Docker, o Apple Container en macOS— y se destruye al terminar. El agente corre como usuario sin privilegios y solo ve los directorios que tú montas explícitamente dentro del contenedor. La frontera la hace cumplir el sistema operativo, no la buena voluntad del agente. Un punto fino, y muy relevante si usas varios agentes o “personas”: Cohen dice que no deben compartir entorno. Critica el modelo en el que varios agentes —por ejemplo “personal” y “trabajo”— acaban en el mismo contenedor aunque estén “aislados”, porque eso abre la puerta a filtraciones accidentales o intencionales entre contextos. NanoClaw lo corta de raíz: contenedor, filesystem y hasta historial de sesión separados por agente. También mete defensa en profundidad con una lista de montajes permitidos, en un archivo fuera del proyecto: `~/.config/nanoclaw/mount-allowlist.json`. ¿La idea? Evitar que, por error, montes carpetas sensibles como `.ssh`, `.gnupg`, `.aws`, archivos `.env`, o patrones de claves y credenciales. Y al estar fuera del repo, el agente no lo puede modificar desde el propio proyecto. Más detalles prácticos: el código de la app anfitriona se monta como solo lectura, y como el contenedor muere tras cada ejecución, la persistencia se reduce. Además, trata los chats grupales como superficie de ataque: grupos no principales se consideran no confiables por defecto y no pueden mandar mensajes a otros chats, programar tareas para otros grupos ni ver datos ajenos. Esto apunta directo a un riesgo moderno: la inyección de prompts “de terceros”. Cohen remata con una crítica a la complejidad: dice que OpenClaw tiene del orden de 400 a 500 mil líneas, decenas de configs y más de 70 dependencias, lo que rompe la auditabilidad. NanoClaw, en cambio, intenta quedarse en “unos miles de líneas”, apoyándose en el Agent SDK de Anthropic para piezas como gestión de sesión y compactación de memoria, y empujando nuevas funciones a “skills” que se integran en el código del usuario, en vez de un monolito con integraciones dormidas pero accesibles. La moraleja: no se gana seguridad haciendo al agente “más listo”, sino poniendo paredes simples, verificables y por defecto.

Ahora, privacidad y control de cuenta, con un tema muy práctico: cómo borrar tu cuenta de OpenAI/ChatGPT y qué implica realmente. El Centro de Ayuda de OpenAI detalla dos caminos. Uno, a través del Portal de Privacidad: vas a `privacy.openai.com`, eliges “Make a Privacy Request”, indicas que tienes una cuenta de consumidor de ChatGPT y seleccionas “Delete my ChatGPT account”. Sigues el flujo de verificación y confirmación. El segundo camino es dentro de ChatGPT en la web: tienes que haber iniciado sesión en los últimos 10 minutos —esto es un control de seguridad— y luego ir a Configuración, Cuenta y “Delete account”. Para confirmar, te pide dos cosas: introducir el email de la cuenta y escribir la palabra “DELETE”, lo que desbloquea el botón de borrado permanente. Importante: si lo que quieres es dejar de pagar Plus, no hace falta borrar la cuenta; puedes cancelar la suscripción por separado. Ahora bien, el documento aclara que si borras la cuenta, cualquier suscripción Plus activa se cancela automáticamente y no te deberían volver a cobrar. Sobre retención de datos: los chats borrados se eliminan de forma definitiva en un plazo de 30 días, con excepciones típicas —datos desidentificados, o retención por seguridad y obligaciones legales. Los chats archivados, en cambio, no se borran: se quitan de la barra lateral, pero se conservan y se gestionan desde configuración. También hay matices con “memories”: puedes borrar memorias individuales o eliminarlas todas desde la configuración de memoria. Y enlazan la opción de excluir tu contenido de consumidor del uso para mejorar modelos —mientras que los datos empresariales de clientes de tipo enterprise no se usan para entrenamiento. Otro punto que suele sorprender: una cuenta borrada no se puede reactivar. Sí podrías crear una nueva con el mismo email después de 30 días, siempre que el borrado haya sido completo y que la cuenta anterior no estuviera deshabilitada por violaciones de política ni ligada a una organización Enterprise. Y atención al teléfono: el límite de verificación por número sigue vigente —hasta tres usos— y borrar la cuenta no libera automáticamente un “cupo”. En algunos casos, números de consumidores podrían eliminarse del sistema tras 30 días, pero no es una promesa universal. Por último, avisan de un error común: si ves “account has been deleted or deactivated” al iniciar sesión o registrarte, puede ser porque el email está asociado a un borrado en curso o ya ejecutado. Y un detalle sutil: borrar la cuenta no sirve para “cambiar el método de autenticación”.

Vamos con ingeniería de rendimiento y experiencia de usuario: imágenes. SplatHash es un proyecto open source que propone algo muy concreto: comprimir cualquier imagen en una representación fija de 16 bytes —sí, 16— que se puede expresar como una cadena base64url de 22 caracteres. Con eso reconstruyes una previsualización borrosa de 32 por 32 píxeles, ideal como placeholder mientras carga la imagen real. La comparación natural es con BlurHash y ThumbHash. SplatHash se posiciona como más pequeño y muy rápido en decodificación, que es el costo que pagas en cada carga de página y para cada usuario. Según los benchmarks del repo, decodificar ronda 0,067 milisegundos, y en pruebas con un i5-9300H la decodificación sale más rápida que ThumbHash y muchísimo más que BlurHash. A cambio, codificar puede ser más caro que ThumbHash, pero sigue siendo muchísimo más rápido que BlurHash, que históricamente puede ser pesado al codificar. En cuanto a técnica: empaqueta un color de fondo más seis “blobs” gaussianos. Los ubica con matching pursuit y ajusta color con ridge regression, y todo entra en 128 bits. Usa un espacio de color perceptual, Oklab, y soporta canal alpha. Además, un punto muy valorado en producción: paridad entre lenguajes. Hay implementaciones en Go, TypeScript/JavaScript y Python, con hashes idénticos bit a bit. ¿La renuncia? No hay un control fino para elegir “más calidad a cambio de más tamaño”; el tamaño es fijo. Eso puede ser exactamente lo que quieres cuando necesitas predictibilidad: guardarlo como entero de 128 bits en base de datos, o incluirlo como metadato pequeño en HTML. El repo trae demo pública, scripts para tests y benchmarks, y licencia MIT. Y hoy mismo figura una release v1.3.0 fechada el 28 de febrero de 2026.

Seguimos con modelos grandes, pero por el lado de hacerlos corribles en hardware real: Unsloth anuncia “Dynamic v2.0” para cuantización de modelos en formato GGUF. La promesa es ambiciosa: poder ejecutar —e incluso afinar— modelos cuantizados manteniendo la mayor precisión posible, y que los GGUF funcionen bien en motores comunes como llama.cpp y LM Studio. Lo que cambia en Dynamic v2.0 es la selección de capas: en lugar de tocar “algunas capas especiales”, la herramienta elige dinámicamente tipos de cuantización para cada capa posible, y las combinaciones varían según el modelo. Es decir, Gemma 3 no recibe el mismo esquema que Llama 4; cada uno se calibra con receta propia. También dicen que ahora funciona tanto en arquitecturas MoE como en no-MoE. Unsloth pone énfasis en métricas: además de accuracy en benchmarks como 5-shot MMLU, empuja KL Divergence como indicador clave del error de cuantización —y advierte que la perplejidad puede engañar. Incluso mencionan un problema habitual: replicar MMLU no es trivial por detalles de tokenización y plantillas de prompt, así que construyeron su propio framework interno para comparaciones consistentes entre precisión completa, Dynamic v2.0, QAT y cuantizaciones estándar tipo imatrix. En cifras, citan resultados fuertes en Aider Polyglot para una cuantización dinámica de 3 bits en DeepSeek V3.1, y comparativas donde una cuantización dinámica de 4 bits puede ser más pequeña y, según ellos, mantener o incluso mejorar ligeramente el rendimiento frente a alternativas QAT en ciertos modelos. Además, hay parte de “trabajo de taller”: afirman haber ayudado a corregir temas de Llama 4 en llama.cpp, como soporte de RoPE scaling y un bug de QK Norm que afectaba precisión. Y cierran con instrucciones paso a paso: compilar llama.cpp, bajar un GGUF desde Hugging Face y correr inferencia.

Cambio de ritmo: una reflexión de industria que se repite cada década. Ivan Turkovic argumenta que el sector tecnológico lleva desde los años 60 prometiendo que “programar será tan fácil que los programadores sobrarán”… y que casi siempre pasa lo contrario. Arranca con COBOL en 1959: la idea era que el software de negocio fuera tan legible que los managers pudieran escribirlo. Lo que ocurrió, dice, fue la creación de un ecosistema gigantesco, duradero, y con empleo especializado por décadas. Luego repasa el optimismo de la IA en los 60 y 70 —con predicciones famosas de Simon y Minsky— y cómo la complejidad del mundo real y el cómputo limitado llevaron al informe Lighthill en 1973 y al primer “invierno de la IA”. En los 80, las 4GL y herramientas de reporting aceleraron lo simple, pero la lógica compleja, el rendimiento y las integraciones siguieron requiriendo expertos. Después vinieron los CASE tools: “modela todo y genera código”. Resultado frecuente: documentación pesada, salida inflada y, otra vez, el cuello de botella real: especificar bien lo que se quiere, y mantenerlo mientras los requisitos cambian. Pasa por la web —HTML fácil al inicio, complejidad creciente con JS, backend, seguridad— y por olas más recientes como MDA/UML y el no-code/low-code desde 2015, que sí habilitan prototipos y herramientas internas, pero chocan al escalar. Su conclusión sobre LLMs y copilotos es matizada: ayudan y mucho, pero el trabajo central no es “teclear código”, sino traducir intención humana ambigua en sistemas correctos, mantenibles y seguros, con tradeoffs, integración y evolución a largo plazo. En resumen: baja la barrera para lo sencillo y, al mismo tiempo, sube la ambición de lo que intentamos construir.

Dos noticias rápidas para cerrar con producto y regulación. Primero, Simplenote: en su foro oficial publicaron una actualización a clientes diciendo que la app ya no está en desarrollo activo. Seguirá disponible, pero se enfocarán en mantener la funcionalidad básica. No habrá nuevas características ni mejoras planificadas, y el hilo se cerró a respuestas, dejando claro que es un aviso, no un debate. Segundo, una ley de California que va a levantar discusión: la Assembly Bill 1043, firmada en octubre de 2025 y con entrada en vigor el 1 de enero de 2027. Exige que los proveedores de sistemas operativos incluyan un paso de verificación de edad durante la creación de cuentas: una interfaz accesible para indicar fecha de nacimiento, edad o ambas. El objetivo declarado es generar una “señal” de rango de edad para compartir con aplicaciones en una “tienda de apps cubierta”, mediante una API más o menos consistente y en tiempo real, cuando los desarrolladores la soliciten. Los rangos son: menor de 13, 13 a 15, 16 a 17 y 18+. No obliga explícitamente a escaneo facial o subir un ID, pero sí normaliza la recolección de edad y la compartición de un resultado segmentado con terceros. Para Windows, donde ya se pide fecha de nacimiento al crear cuenta Microsoft, el encaje es relativamente directo. Donde chirría es en Linux: comunidades lo ven como difícil de aplicar, fácil de esquivar —por ejemplo, usando builds no conformes— y algunos bromean con avisos del tipo “no apto para California”. El artículo lo enmarca dentro de una tendencia global, con el Reino Unido y su Online Safety Act como referencia y polémicas recientes por intentos de verificación en plataformas como Discord.

Y como nota final, una historia menos tecnológica pero muy de Hacker News por el lado de “cómo funcionan las sociedades”: un artículo de Works in Progress recorre sistemas de matrimonio en distintas culturas, no como una institución única “natural”, sino como una estrategia para gestionar recursos, herencia, alianzas y reproducción. Abre con un caso famoso: el “ghost marriage” entre los Nuer, donde un hombre que muere sin herederos puede ser asignado póstumamente a una esposa; se paga bridewealth en ganado, y los hijos se consideran legalmente descendencia del fallecido y heredan su propiedad. A partir de ahí, el texto contrasta monogamia, poliginia, arreglos informales, divorcio más o menos fácil y el papel de las familias extendidas. La tesis general es que la ecología y la economía —caza-recolección versus agricultura y ganadería, desigualdad, riqueza almacenable— cambian los incentivos y los conflictos entre sexos y entre grupos de parentesco. También discute por qué en ciertos lugares se impone monogamia legal y cómo, hoy, educación, urbanización, teléfonos y autonomía económica están reconfigurando emparejamientos: más cohabitación, más ruptura, y combinaciones que no encajan en un solo molde. No es una “guía moral”; es una explicación funcional: qué problema social resuelve cada sistema y qué costos introduce.