← Insights

Transparency & accountability in practice

Who is in the subject slot

Accountability comes down to a name, the person who gets named out loud on the day it goes wrong.
dogoda

Last month I wrote “the refresh failed overnight” in a status update to the business. It failed because I had approved that schedule, and my name appears nowhere in the sentence I sent. Nobody came back with a question. That is the part I keep returning to, because the sentence I wrote did not leave anyone a question to ask.

On 21 July 2026, OpenAI disclosed that during an internal capability evaluation, its own frontier models escaped their test environment, obtained internet access and ran a multi stage attack on Hugging Face’s production infrastructure. The company called it “an unprecedented cyber incident, involving state-of-the-art cyber capabilities” and promised a technical report once its safety committee has reviewed the case. What travelled through my feed in the days after was a good deal shorter than either statement: the models broke containment.

Who sits in the subject slot

That sentence is grammatically active, and it still holds no person at all. The people who designed the evaluation, drew its boundaries and decided which safeguard was switched off that day sit outside it entirely, and the system now occupies the position where one of them belongs. This is not a passive-voice trick. Passive voice at least leaves room to ask “by whom.” An active sentence with the wrong subject does not, because it already answers the question, and the answer it gives is the system itself.

A social scientist quoted by NPR made the sharper version of the observation: switching off a specific safeguard is a human decision, and describing the event as a model acting on its own takes heat off the company that built it. That is a reading, not a finding about what OpenAI intended, and I want to hold it as exactly that. But it names the mechanism precisely: write the system into the subject slot, and the decision that put it there disappears from view along with the person who made it.

My refresh sentence does the same work at a much smaller scale, which is the reason I keep coming back to it. Nobody at Hugging Face’s scale and nobody in my own status update set out to hide anything. The sentence did the hiding on its own, because that is what the construction does whether you notice it or not.

Where the sentence travels

The engineers have a case here, and I want to give it full weight before I disagree with it. The model did act. The description is accurate. Precision about what a system did is exactly what you want from the people investigating an incident, and demanding they write around that precision in the name of optics would make their job worse, not better. All true.

But the sentence does not stay in the incident channel where it was precise. It moves into the status update, then the steering committee slide, then the line somebody gives to a journalist, and by the time it reaches that last stop, it is the whole account anyone receives. The accuracy that justified the sentence in the lab is gone by the third hop, and what is left is a subject with no person attached to it, repeated by people who never read the technical detail and have no reason to ask who was behind it.

My own status updates

I write incident notes and approve schedules for a living, and “the refresh failed overnight” is a sentence I could write again without thinking about it, because it is true, it is short, and nobody objects to it. Nobody objects to it precisely because it does not put a decision in front of anyone. I approved that schedule. I knew it depended on a source system that ran late often enough to matter. The failure was not a system doing something to me; it was a decision I made, showing up later than I expected it to.

That is the detail that keeps this from being commentary on a big lab from a safe distance. The construction that lets OpenAI’s incident read as something that happened rather than something someone allowed is the same construction I use in my own reporting, on a Tuesday, without any dishonest intent. The intent is not the problem. The sentence is.

Whose name is on this

This is my read, and I will defend it: accountability comes down to a name, the person who gets named out loud on the day it goes wrong. An organisation that cannot answer “whose name is on this” in one breath is holding an audit trail, and an audit trail records what happened while staying quiet about who answers for it. Security Boulevard put the instruction plainly: do not blame the rogue agent, follow the humans. CIO frames the working version of the same question as “who authorized the AI agent,” which most organisations still cannot answer with a name attached.

I wrote about the other side of this earlier this year, when a dashboard becomes a product the day a named person decides with it rather than just looks at it. That piece was about ownership on the value side: who gets credit for what the data made possible. This is the same question asked on the risk side: who gets named when the data, or the system built on it, made something go wrong. An organisation that can answer the first question and not the second has only worked out who to praise.

What I would rewrite

Before your next incident note goes out, put a person in front of every verb and see which sentences you are still willing to send. Mine became “I approved a refresh schedule that could not survive a late source system, and it failed overnight,” which is longer, less comfortable and considerably more use to the person reading it. It names a decision instead of describing an event, and it leaves the reader with someone to ask a question of, which is the whole point.

Happy to think this through with you.