AI: The Reputation Signal · Issue 11

When AI is being done to you

Elif Güvençer · 2 September 2026

There is not a day that goes by that we do not hear an "AI gone bad" story, whether it's the AI labs almost one-upping themselves about whose agents has been the most naughty and jailbroke, to scary deepfakes that are putting people at serious risk.

AI-related problems are many. For the sake of this issue, I looked at the actual incidents reported. I have done a deep dive on The AI Incident Database (AIID). Myself and Claude, we have analysed 1,112 incidents, in the archive dated between 1 January 2023 and 15 August 2026. I cut to 2023 onwards so the picture would be about the generative era.

You can find more 'methodology' details of this little experiment I ran at the end of the newsletter but the short version is: an incident in AIID is a real, reported event with at least one press source. It records incidents that were reported and covered, which means it counts press attention as much as it counts harm. It skews heavily towards English-language sources and Western organisations.

So I’ve done this analysis to show the shape of the problem.

What I found

Over half of the incidents are AI being done to you

Roughly half the archive is somebody else's AI pointed at you: fraud, election disinformation, sexual imagery and reputational impersonation. The top two types, fraud and election disinformation, are 39% of everything on their own. When you add non-consensual sexual imagery and reputational impersonation and you reach 52.5%.

The other half is your own AI, and that divides again into what it said and what it decided. What it said covers false information given to a user, fabricated citations and records, model behaviour and chatbot harm. What it decided covers automated judgements made against a person, alongside plain system failure.

Why this matters: Almost every AI governance framework in circulation assumes you are the deployer of AI. Approve it, test it, monitor it, retire it. For half of what actually happens, that playbook does nothing at all, because there is nothing of yours to approve.

Two in five incidents harm something with no claimant

440 of the 1,112 name an abstract party as harmed. Public trust. Democratic integrity. Epistemic integrity. Journalistic integrity. Judicial integrity.

Why this matters: This means they do not reach a risk register, because a risk register needs a claimant. The mechanism only starts once there is a party who was harmed and who can be identified. Where the injury is to public trust, there is no such party, so the most commonly recorded category of damage in the archive is invisible to the machinery built to catch damage.

There are places where harm without a private claimant does get pursued like environmental law and consumer protection but those routes are slow, discretionary, and they sit outside the organisation entirely.

AI frameworks have the same loophole. They also cover harm in the actual materialistic sense and do not include reputational harm by default.

Children and education appear in 15% of incidents. Minors, students, teachers, schools. That is higher than financial victims. It is also almost entirely absent from the AI governance conversation. I'll park this topic for a different newsletter.

Official guidance has no ‘respond’ stage but even if it did, that is mitigation not prevention

Let’s look at the published frameworks, meaning the frameworks an organisation adopts rather than buys. There are a lot of them and several are good. OECD, NIST's AI Risk Management Framework, the ISO 42001 family, the ICO's guidance, the EU AI Act's obligations, and the various MLOps (used to automate and simplify machine learning deployments) practices sitting underneath all of it. They start at problem definition and end at retirement, with design, build, testing, validation, deployment and monitoring stages in between.

What they do not contain, anywhere in that sequence, is a stage where somebody has to tell anyone outside the organisation what is happening. Incident response exists everywhere as a policy you are supposed to have, and nowhere as a stage the process actually reaches. A team working the lifecycle end to end never gets there.

They also only cover half of what happens. All of it is written for the party deploying the AI, so when somebody else's AI is pointed at you there is nothing to approve, test or retire. There is extensive security guidance for being the target: detect, contain, preserve evidence, report. What does not exist is guidance on what to say, who authenticates it, on what channel and how fast. That gets left to crisis communication, which is mostly called after the fact.

The law runs in the same direction. Under the EU AI Act, serious incidents go to the market surveillance authority, and the distributor, deployer, importer all appear on the notification lists. The public does not. California's SB 53 routes to emergency services. MITRE's incident sharing scheme is explicitly anonymised, which is a mechanism for learning from incidents without disclosing them. Where a notification does reach the individual, it is either because the incident was also a personal data breach, or because of disclosure requirements; I have to be told that what I am dealing with is a machine or that content is synthetic.

(Singapore is the exception worth naming. Its Model AI Governance Framework for Generative AI puts incident reporting as one of nine top-level dimensions rather than burying it).

You might think it is by design. A lifecycle is scoped to the system. Incident communication belongs to crisis and incident management, which are different functions with their own standards. Which is fair, but this federation of duties is also part of the problem. Every one of these processes hands the problem sideways and none of them owns the handover.

Companies of course can buy services on these areas. Consultancies sell AI incident playbooks, governance vendors sell incident logging and reporting workflows, and crisis firms will certainly sell you deepfake response. All true, and beside the point. The frameworks I looked at are published and adoptable, which means they set the floor for every organisation that has not thought to hire anybody, whereas a bought playbook only exists where somebody already knew to ask for it. A playbook is also a document and not a gate, so nothing in the pipeline obliges anyone to open it.

Risk and issue management needs a different gear

Across 90 hand-read cases (picked from each of the 12 buckets of incidents I identified), the biggest gap is between what the system said it does and what it actually does. That is the gap crisis communication is expected to fill, and it arrives at the point where it is most expensive to close. By the time you have to respond, it is already too late.

The vulnerability that leads to a legal fine or a reputational problem starts earlier in the deployment stages. It is critical to catch issues before they become crises because AI changes the crisis dynamics.

Crisis practice depends on a traceable chain. A decision was made, by someone, in a context, and you can work back through it. AI breaks that. Increasingly you will not be able to construct the chain of events, not as cleanly or as fast as the situation requires. So risk management will increasingly involve responding rather than explaining = you might not have all the facts on why/how something happened but you can have a clear idea on how to respond.

Bolt yourself onto stages that already exist

The fact that communication needs to be on the governance table for AI is not a new argument. But it is not the norm.

(If you need arguments around the unique contributions of comms to AI governance, take a look at the Trust Consequence dimension of The Two Clocks).

One of the barriers might be because the question has been more focused on ethics as the primary case, and that gets perceived as a soft ask or a friction against technology. But this is changing. Issues around that 'soft ask'; good conduct or lack thereof is what gets fined.

A smart way to get involved is for Communications to bolt itself onto workflows and stages that already exist.

The pipeline an organisation actually runs, whatever it calls it, is usually some version of these nine steps. Use-case intake and registration, where somebody proposes an AI use and it gets written down. Risk tiering, deciding how much scrutiny it gets. Business case, the promise made to get it funded. Build or proof of concept, where the system gets its instructions, its source material and its permissions. Pilot, limited live use with real people. Pre-deployment validation, the last check before it goes wide. Production release. Monitoring. And periodic re-attestation, where somebody re-confirms on a schedule that the system still does what the register says it does.

Communications should have questions to ask at every one of these stages. To illustrate my point, I will use the beginning and the end of the lifecycle.

At business case, which is the stage furthest from communications and the one where 'the overpromising' might start: what are we promising this will do, and would we stand behind that promise in public? Who outside the project has checked these claims against the evidence?

At re-attestation. Today, re-attestation checks the system against the register, which is the internal record of what was approved. Far less often does anyone check the system against the public account: what the website says, what an executive said on the podcast, what the customer was told at sign-up, what the annual report claims. Both are records of the same deployment.

This matters more than it sounds, because the system does not stand still between attestations. Changes do get logged. You can usually find out who edited the system prompt etc and when. But the change does not trigger a reputational review. There is plenty of engineering change control and no reputation risk control, so the gap between what was said and what is running widens quietly until somebody outside the building notices it first.

What I have set out here is a way of thinking: where communication belongs in the deployment of AI and what it should be asking when it gets there. You can do three things this week:

• Find out what kind of deployment journey your company follows, not everyone follows the full lifecycle.
• Think about what questions you would have for each of the stages.
• Find out if there is anyone in the organisation that checks AI systems actually do what the company said publicly about them now and over time.
• Position yourself as additive to the current process. Less risk of resistance from IT or whoever leads the deployment this way.

Methodology notes for my experiment

Analysis comes from the AI Incident Database's weekly export, cut to the 1,112 incidents dated 1 January 2023 to 15 August 2026 out of a full archive of 1,641. The database records reported incidents, so it counts coverage as much as harm, and it skews to English-language press and Western organisations.

All 1,112 were sorted into 12 incident types, with the harmed-party field parsed into 9 categories. The 12-type sorting is mine, assisted by an LLM working from incident titles. There was no second human coder and no inter-rater reliability check.

The 12 types, with their share of the 1,112: fraud, scam and impersonation (23%), election and political disinformation (16%), false information given to a user (9%), non-consensual sexual imagery (8%), own system failure and data loss (8%), automated judgement made against a person (7%), fabricated citations and records (7%), reputational impersonation (5%), physical harm from autonomous systems (5%), model behaviour and bias (5%), chatbot psychological harm (5%), and creators and workers displaced (2%). The harmed-party field is free text, 2,801 distinct strings across 5,137 mentions, mapped to 9 categories by rule.

Impersonation appears twice on purpose. Fraud and scam impersonation is someone cloning a voice or a face to extract money, usually from an individual. Reputational impersonation is someone counterfeiting an organisation, its brand or its executives, with no payment involved. Same technique, different problem.

An incident can name several harmed parties, so those shares sum to more than 100%.

Ninety cases were then read by hand, drawn across all 12 types. The hand-read cases skew towards incidents with a named deploying organisation, so they describe the deployer side better than they describe the target side. That is why there are no stage-level percentages anywhere in this piece.

If you want to check any of it, the AIID export is public and the sorting is reproducible. If I have missed something or got something wrong, tell me and I will correct it.