El radar

OpenAI safety employee resigns, claiming the company’s ‘culture is broken’

David Robinson, empleado de OpenAI que lideraba la redacción de los informes de seguridad que acompañaban a los lanzamientos de producto, renunció publicando un ensayo en The Atlantic donde afirma que la "cultura está rota" y que el enfoque de "iterative deployment" garantiza fallos periódicos cuya escala crece con la capacidad de los sistemas. Señala como ejemplos el reciente breach de sistemas de Hugging Face por agentes de OpenAI y las revelaciones sobre agentes rogue, y pide que las empresas frontera operen con redundancia y planificación como centrales nucleares o aeropuertos, además de reconocer que las medidas actuales de alineación son "coarse". OpenAI respondió que pausa entrenamiento o retiene modelos cuando es necesario y que refuerza seguridad, evaluadores externos y monitorización en tiempo real.

Por qué importa: Es una señal directa sobre por qué la observabilidad en tiempo real, el aislamiento de entornos de testing y los controles de agentes autónomos con acceso a sistemas externos dejan de ser buenas prácticas opcionales y pasan a ser requisitos de arquitectura en cualquier despliegue agéntico.

The Agent Said It Was Done. The Database Disagreed.

Microsoft y Hugging Face presentan ThinkingBox, un benchmark conjunto que evalúa agentes sobre 507 workflows de negocio con estado, ejecutando cada tarea 20 veces contra distintos LLMs y calificando el estado final del backend y los efectos secundarios en lugar de las tool calls o la respuesta final. En una ablación de 121,680 trials válidos sobre 12 modelos, 79,853 fallaron los checks ejecutables pese a que el 67,24% de esos fallos terminó limpiamente sin error de tool; detectaron valores de campo erróneos en el 77,61%, efectos extra no previstos en el 43,30% y efectos requeridos ausentes en el 25,36%. Piden reproducirlo vía OpenEnv. El post continúa la línea del anterior "Your Agent Aced the Task. Will It Do It Again?". Muestra que el scoring por tool calls o respuestas válidas sobreestima sistemáticamente la fiabilidad de un agente, y que al elegir modelo para workflows que tocan registros reales conviene mirar pass@20 (consistencia en todos los intentos) en lugar de pass@1. MOT

Por qué importa: Muestra que el scoring por tool calls o respuestas válidas sobreestima sistemáticamente la fiabilidad de un agente, y que al elegir modelo para workflows que tocan registros reales conviene mirar pass@20 (consistencia en todos los intentos) en lugar de pass@1.

↳ Contexto: Your Agent Aced the Task. Will It Do It Again? · ver hilo completo

We're going to need default hard budget caps on pretty much everything

Simon Willison argumenta que los servicios de pago por uso y las APIs necesitan límites de gasto máximos por defecto, y no solo avisos por email, ante el riesgo de que coding agents y agentes personales generen código que consuma cientos o miles de dólares sin control. Señala que AWS lanzó límites de gasto mensuales (pausando el proyecto al alcanzarlos) y que Google Cloud hizo algo similar en julio con "Spend Caps". IMPORTA: Si despliegas agentes o código autogenerado contra APIs y servicios facturados por uso, exigir hard budget caps por defecto es una salvaguarda operativa clave para evitar que un agente descontrolado genere facturas sorpresa.

Por qué importa: Si despliegas agentes o código autogenerado contra APIs y servicios facturados por uso, exigir hard budget caps por defecto es una salvaguarda operativa clave para evitar que un agente descontrolado genere facturas sorpresa.