When the LLM Writes the Docs, Who Owns the Gap?

Large language models are now fluent enough to generate documentation that looks right, reads smoothly, and is wrong in ways that take hours to discover. As a technical writer at Red Hat and an open source contributor, I have watched this shift happen in real time and the question it raises is not "can AI write docs?" but "when it does, who is responsible for what it gets wrong?"
This talk is not an AI hype session. It is a field report from someone whose job is to own the accuracy of documentation at scale. When an LLM generates a getting-started guide, it has no context about the version a user is running, the edge case that was quietly fixed last quarter, or the warning that exists because three production systems went down without it. It produces text that passes a reading comprehension test but fails a trust test. And in open source, where documentation is already under-resourced and under-reviewed, that gap is dangerous.
We will walk through where AI-assisted documentation genuinely helps, boilerplate reduction, first drafts, translation scaffolding, and where it silently fails: hallucinated flags, outdated procedures presented as current, and accessibility structure that looks fine in a browser but falls apart under a screen reader. More importantly, we will talk about the review processes that actually catch these failures versus the ones that only look like they do.
The deeper question this talk asks is structural: in a world where text is cheap to generate but expensive to verify, what does it mean to "own" a piece of documentation? Who is accountable when an AI-assisted doc ships with a gap that breaks a user's workflow? What does that do to contributor motivation, to project trust, and to the commons that FOSS documentation is supposed to build?