Products / Incident Review
DNLA Incident Review
When an AI system causes harm, makes a wrong decision, or triggers an operational incident, DNLA runs an independent investigation: the AI equivalent of a Root Cause Analysis, built for systems where the "root cause" can be a model, a prompt, a data source, an integration, or a process failure.
Why independence matters
The team that built the system is rarely the right team to investigate it
Not because of bad faith, but because of incentives. The people who built or operate a system are the least likely to be objective about whether the failure was a one-off, a symptom of a deeper architectural problem, or a foreseeable risk nobody flagged in time. An incident review needs to survive scrutiny from a board, a regulator, an insurer, or a court, which means it needs to come from somewhere with nothing to defend.
The process
Ten steps, in order
- Reconstruct the incident
- Preserve evidence and logs
- Build a timeline
- Identify the model and prompt version involved
- Examine the data and context in play
- Locate the point of failure
- Attribute cause: model, data, integration, user, process, or governance
- Assess impact
- Define prevention measures
- Set conditions for returning the system to service
Who commissions this
- Leadership needing a straight account before deciding how to respond publicly or contractually
- Legal or compliance teams who need a defensible record of what happened and why
- Boards and insurers who need an independent finding, not the vendor's own account of itself
- Engineering leadership that suspects the cause but needs it proven before committing to a fix
Something already went wrong?
The sooner logs and evidence are preserved, the more the investigation can recover.