AI & Technology Limitations
AI & Technology Limitations
Technology fails in specific, describable ways. An institution that depends on it should say so plainly.
- Version
- 1.0
- Effective
- 16 September 2026
- Last updated
- 16 September 2026
- Status
- Establishment-stage policy — legal review pending
Why this document exists
This is not a disclaimer that shifts every risk onto the reader, and it does not ask anyone to simply accept technological error. It is the opposite: naming how systems actually fail, so that failures can be identified, challenged, and corrected rather than absorbed silently into an outcome.
Model error
AI systems can produce output that is confidently expressed and wrong. They can misread context, invent detail, miss what matters, and reflect bias in their training or design. Fluency is not accuracy, and an answer's tone carries no information about whether it is correct.
Software defects
Software contains defects. Logic can be wrong, edge cases unhandled, and a change can break something that previously worked. Testing reduces this; it does not eliminate it.
Availability failure
Systems become unavailable. A service being unreachable is not evidence about the underlying facts, and unavailability should never be silently converted into a substantive conclusion such as "not found", "unauthorized", or "nothing here".
Identity and provenance uncertainty
Evidence about which system acted, under whose authority, and when, can be incomplete, ambiguous, or contested. Knowing what a digital worker is does not establish what it was permitted to do. Provenance has limits, and those limits belong in the analysis rather than outside it.
Unexpected automated behaviour
Automation can act outside what its operator expected — through misconfiguration, an instruction interpreted more broadly than intended, or interaction between systems that were never designed to meet.
Incomplete or incorrect data
Records can be partial, stale, duplicated, or simply wrong. A confident conclusion drawn from incomplete data is still a conclusion drawn from incomplete data.
Communications and third-party dependencies
Messages are delayed, delivered out of order, or lost. Services DWRC does not control can fail, change behaviour, or withdraw. A dependency's failure is the institution's problem to handle, not the reader's to absorb.
Not only technology
Error is not exclusively technological. Human judgement, process design, communication, and data quality all contribute to mistakes and uncertainty. DWRC's purpose is fair examination — not an assumption that any one kind of participant, human or digital, is automatically right.
How DWRC responds to error
The institutional response to fallibility is procedural: establish what the evidence actually shows and where it is weak; make it possible to challenge a result; correct what turns out to be wrong; review where the stakes justify it; and escalate to human or external authority where that is appropriate. Recognizing that technology fails is not a reason to accept unfair outcomes — it is the reason to design for correction.
Contact
Questions about this document may be sent to [email protected].