One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.” It sounds almost funny. In software terms, though, it points to a real problem.
One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.” It sounds almost funny. In software terms, though, it points to a real problem.
“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.
Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”
Different systems, different failures, one question: what does “access denied” mean to an agent?
Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.
We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.
In context
- Topic: Inteligencia Artificial — IA aplicada al negocio: casos, límites, costos y gobierno.
- Source: InfoWorld
- Published: 20/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
Cada semana hay un anuncio que promete cambiarlo todo, y cada semana la mayoría de las organizaciones sigue peleando con lo mismo: datos desordenados, procesos que nadie documentó y una expectativa que corre más rápido que la capacidad. Esta nota se entiende mejor con eso puesto encima.
Lo que miro primero no es la capacidad del modelo sino el dato que lo alimenta. Casi todos los proyectos que vi fracasar no fracasaron por el algoritmo: fracasaron porque el dato estaba en tres sistemas con tres definiciones distintas y nadie quiso ser el que arreglara eso.
Lo que suele salir mal
El error que más veces vi repetirse es no medir nada antes de empezar. Se implementa, todo el mundo siente que mejoró, y cuando alguien pregunta cuánto, no hay respuesta. Sin línea base no hay forma de defender el presupuesto del año siguiente, y ahí es donde mueren buenos proyectos.
Qué mirar
- Dónde quedan los datos y bajo qué contrato, sobre todo si hay información de clientes de por medio.
- Si la organización puede cambiar de proveedor sin rehacer todo, que es la prueba de que no quedó amarrada.
- Qué proceso concreto se toca y cómo se mide antes y después; sin línea base no hay resultado, hay opinión.
Cómo leo esta entrada
Si tuviera que llevar esto a una organización, empezaría por un proceso aburrido y medible — conciliación, atención de primer nivel, revisión documental — y lo dejaría andando con métrica antes de tocar nada vistoso. La credibilidad para los proyectos grandes se compra con un resultado chico que nadie puede discutir.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
