When AI use goes wrong, have the record.
Someone pastes a customer contract into a personal chatbot. A model gives a customer a wrong answer. A vendor announces a breach. The incident register is where each of these is recorded, contained and closed, with a timeline nobody can rewrite and a report you can hand over.
Interactive example with fictional records. Try it. Move the incident through its statuses. It will not close without a closing note.
- Open
- Contained
- Resolved
- Closed
- 4 Nov 10:12Reported by an employee. Customer contract text was pasted into a personal Perplexity account.
- Workflow
- Open, contained, resolved, closed
- Timeline
- Append-only
- Report
- AI incident report, PDF or Word
- Plans
- Govern and Enterprise
Enough to answer "what happened and what did you do".
An incident record holds what a customer, an auditor or a regulator would ask for:
- What happened: a title, a description, when it occurred and when it was detected.
- A category: data exposure, wrong or harmful output, policy violation, availability, security, bias or fairness, or other.
- A severity: low, medium, high or critical.
- How it was found: reported by an employee, GhostAudit monitoring, a customer, a notice from the vendor, an audit or review, or security tooling.
- The AI systems involved, linked to their inventory records, and the number of people affected.
- Actions, of two kinds: containment (stop it getting worse) and corrective (stop it happening again), each with an assignee and a due date.
A near miss is recorded the same way and marked as one. Near misses are the cheapest lessons a governance programme gets, and most organizations lose them because there is nowhere to write them down.
- Drafts can be saved before an incident is opened
- Incidents linked to an AI system appear as evidence in its assessments
Status moves one way, in the open.
An incident is open, then contained, then resolved, then closed. A step can be skipped forwards, because a near miss is often resolved at once. Going backwards reopens the incident, and that is recorded too.
Status changes through one action only, and every change adds an entry to the incident's timeline: who, when, from what to what. The timeline is append-only. Entries are not edited or removed.
Closing needs a closing note. An incident with no account of how it ended is not closed, it is forgotten. The register refuses.
Open incidents that need attention are listed on the console overview.
A checklist of duties to consider. Not a legal opinion.
Whether an incident must be reported to someone outside the company depends on facts and law that software cannot judge. What the register can do is make sure the question was asked.
Each incident carries a short checklist: was notification considered to the data protection authority, to the people affected, to customers under contract, to the AI vendor, to a cyber insurer, and under the EU AI Act's serious-incident rules for high-risk systems. Each line has a one-sentence reminder of when the duty typically arises, for example that a personal data breach is reported within 72 hours under GDPR Article 33 unless it is unlikely to result in a risk to people, and a link to the regulation tracker where it has an entry.
You record, for each line, that it was considered and what was decided. That record is often what a regulator asks for first.
- The checklist is a prompt to think and to ask counsel. It does not decide that a duty applies
A report generated from the record.
The document template "AI incident report" writes a report from one incident: summary, timeline, systems and people affected, containment and corrective actions, the notification checklist and its decisions, and lessons learned. It goes through the same review and approval as every other document and exports to PDF or Word.
Incident records are kept apart from the rest of the product on purpose. They are loaded only for the incident report template, are not part of the context of any other generated document, and are never sent to a language model.
If you export logs to a security tool, incident events are available as their own stream.
Register details
- Statuses
- Draft, open, contained, resolved, closed. Closing requires a closing note. Reopening is allowed and logged.
- Categories
- Data exposure, wrong or harmful output, policy violation, availability, security, bias or fairness, other.
- Severities
- Low, medium, high, critical.
- Timeline
- Append-only, one entry per change, with the person and the time. Also the source of the incident stream in log export.
- Access
- Read-only for viewers. Incidents are organization data: included in the workspace export and removed when the workspace is deleted.
- Not included
- Automatic detection of incidents, paging or on-call. An incident is created by a person.
- Plans
- Govern and Enterprise. Pricing
Questions
- Does GhostAudit detect incidents automatically?
No. Monitoring can show you that a prohibited tool was opened or that a sensitive-data warning fired, and you can record an incident from what you see. Creating the incident is a person's decision.
- Does it tell us whether we must notify a regulator?
No. It gives you a checklist of the notifications to consider and records what you decided. Whether a duty applies depends on facts and law; ask counsel.
- Should near misses really be recorded?
Yes. A near miss costs nothing and shows where the next real incident will come from. Recording them is also a sign of a working programme, which is what questionnaires and auditors look for.
- Can incident details reach a language model?
No. Incident records are loaded only for the incident report template and are excluded from the context that any AI drafting feature can see. AI drafting is also off on the hosted service.
Have the record before you need it.
Start a 14-day trial with every Govern feature, connect one discovery source and enroll a handful of devices. No card is needed to start, and nobody is asked to change how they work.