The customer's supplier quality engineer flew in on a Tuesday for a process audit, and by ten in the morning she had found the one thing every quality manager dreads. Three months earlier the plant had started using an AI vision system to grade a cosmetic surface on a bracket, and an AI assistant to help draft the disposition notes when a part was held. The auditor pulled a specific lot from the records, a lot that had a borderline call on it, and asked a simple question: "Who decided this part was acceptable, and on what basis?" The quality manager opened the file. There was the vision system's score. There was a disposition note that read cleanly and professionally. And there was nothing else. No record of which inspector reviewed the AI's call. No record of what the AI was actually shown. No record of whether a human agreed with the model or overrode it. The note had been drafted by the AI and pasted in, and it described the decision as if a person had reasoned it through, but no person had signed anything. The auditor wrote it up. Not because the part was bad. The part was fine. She wrote it up because the plant could not show its work. That is the failure this lesson exists to prevent. When AI touches a quality or maintenance decision, the record has to be able to answer one question completely: here is exactly what the AI did, and here is the human who approved it.

Why the Documentation Is the Real Deliverable

On the floor it is tempting to treat documentation as the paperwork you do after the real work is done. With AI in the loop, that framing is exactly backwards. The documentation is not the residue of the decision. The documentation is the decision, made auditable. A quality call that cannot be reconstructed later is, for the purposes of a customer audit or a regulatory review, a call that effectively did not happen in a defensible way.

This matters more with AI than it did before, for a structural reason. When a human inspector made a call the old way, the accountability chain was obvious: a named person looked at a part and signed a traveler (the paper or electronic record that travels with a part or lot through the process). The customer audits the plant, never the vendor, so the question was always answerable in principle, because there was a human and a signature. AI breaks that obviousness. The AI vision system produces a score. The AI assistant produces a fluent note. Both outputs look authoritative and complete. Neither one, by itself, tells you who is accountable, what the model was actually shown, or whether a human ever agreed. The fluency of AI output creates a false sense that the record is complete when the part that actually matters, the human accountability, is missing.

Quality management standards make this concrete. Under IATF 16949 (the automotive quality management standard) and AS9100 (the aerospace equivalent), the plant must maintain records that demonstrate conformity and the effective operation of its quality system, and those records must show who performed and who verified key activities. An 8D (the eight-discipline structured problem-solving and corrective-action report customers require after an escape) is only as good as its traceability. None of those standards were rewritten to bless "the AI decided." They still require a competent, identified human to own the decision. So the documentation standard for AI-assisted work is not a new burden invented for AI. It is the existing records requirement, applied honestly to a process where a machine now drafts part of the record.

With AI in the loop, the documentation is not paperwork about the decision. The documentation is the decision, and a call you cannot reconstruct is a call you cannot defend.

The Five Elements of an Audit-Grade AI Record

An audit-grade record for any AI-touched decision answers five questions completely. If a record is missing any one of them, it will not survive a determined auditor, and more importantly it will not let your own team reconstruct what happened when a customer calls about a part six months from now. Memorize these five. They apply equally to a vision call, a predictive-maintenance alert, an AI-drafted work instruction, and an AI-assisted root cause.

One: what the AI was given. The inputs. For a vision call, this is the actual image or images the model scored, the lighting conditions, the camera and station, and the inspection parameters in effect. For a predictive alert, the historian tags and the time window. For an AI-drafted document, the prompt and the source material the model was told to work from. You cannot judge whether an output was reasonable without knowing what the model was shown. An auditor who asks "what did the camera actually see" and gets a shrug has found a hole.

Two: what the AI produced. The raw output, captured verbatim, before any human editing. The vision score and its confidence. The model's draft disposition text. The predictive alert's risk number and the failure mode it named. This is the unedited model output, preserved separately from the final human-approved version, so that later you can see exactly what the machine said versus what the human decided.

Three: what the model is. The version. Which model and which version produced this output, and when it was last validated or retrained. This is the single element plants forget most often, and it is the one that bites hardest. When a vision model is retrained in March, every decision it made in February was made by a different model. If your record just says "AI vision system," you cannot tell an auditor which model graded the February lot, and you cannot investigate a pattern of escapes back to the model version that caused them. Version is not a technicality. It is the difference between a traceable system and a black box.

Four: who reviewed it and what they decided. The named human, their role, the timestamp, and crucially whether they agreed with the AI or overrode it. A record that shows the AI said "accept" and the inspector also said "accept" is one story. A record that shows the AI said "accept" and the inspector overrode to "reject" is a different and far more valuable story, because override data is how you learn whether your model can be trusted. The review element must capture the human's actual decision, not just the fact that a human glanced at the screen.

Five: what happened next. The action and its outcome. The part was shipped, scrapped, reworked, or held. The work order was created and the failure was averted, or it was not. The action closes the loop and lets you measure whether the AI-assisted decisions are actually producing good outcomes over time. A record that stops at the decision and never captures the result cannot tell you whether the system is working.

Put together, these five elements turn "we used AI" into "here is exactly what it did and who approved it." The auditor in the opening story wrote up the plant because the record had element two (the AI output) and a version of element five (the part shipped) but was missing one, three, and four entirely. The note read well, which fooled the plant into thinking the record was complete. Fluency is not completeness.

Separating the Model Output From the Human Decision

The most important discipline in AI documentation is also the least intuitive: you must keep the raw AI output and the final human-approved version as two distinct, separately preserved things. The natural workflow does the opposite. The AI drafts a disposition note, the inspector reads it, tweaks a word or two, and saves it. Now there is one document, and it is impossible to tell which sentences came from the model and which from the human. The model's contribution and the human's verification have been blended into a single record that hides exactly the boundary an auditor cares about.

Why does this boundary matter so much? Because the entire defensibility of AI-assisted work rests on a clear answer to "what did the machine do, and what did the human do about it." If the auditor cannot see that boundary, two bad things follow. First, the plant cannot prove the human actually reviewed the output rather than rubber-stamping it, because there is no before-and-after to compare. Second, if the AI output later turns out to have been wrong (a hallucinated torque spec, an invented procedure step, a confidently wrong root cause), the plant cannot show whether the error originated in the model or was introduced by the human, which it needs to know to fix the real problem.

The practical pattern is straightforward. The AI's raw output is captured and stored, locked, unedited. The human works from a copy. The final approved version is stored alongside the raw output, with the human's name and timestamp on it. The system, not the operator's memory, holds both. When an inspector overrides a vision call, the system records the AI score, the override, the inspector, and the reason. When an engineer accepts an AI-drafted work instruction, the system keeps the draft and the approved final separately. This is not extra work for the human; it is a workflow design choice in how the AI tool and the quality system are wired together. The human still just reviews and approves. The system does the preservation.

A worked example: the disposition that holds up

Return to the bracket from the opening. Done right, the record for that borderline lot reads as follows. The vision system, model version 4.2, last validated on the fifteenth of the prior month, scored the surface at a confidence of 0.71 against an accept threshold of 0.80, and flagged it for human review (element one and two and three). The AI assistant drafted a hold-and-review note. Inspector J. Ramirez, second shift, opened the part under the standard inspection light, compared it to the boundary sample, and decided the surface was within the cosmetic acceptance criteria, overriding the model's flag to accept, and recorded the reason: "surface mark is within zone-2 cosmetic limit per QA-117" (element four). The lot shipped, and the customer accepted it with no return (element five). That record costs the inspector perhaps ninety seconds more than pasting a note. When the auditor pulls that lot, every question she can ask is already answered, and the plant shows its work in under a minute. The ninety seconds per borderline call is cheap insurance against a single audit finding, which on a customer scorecard can cost far more than a year of those ninety-second increments.

Documentation That Holds Under Time Pressure

The cardinal threat to all of this is the same one that breaks every good practice on the floor: time pressure. End of quarter, two inspectors short, a queue of held parts, and the temptation is to let the AI's clean note stand in for a reviewed decision and move on. A documentation standard that only works on a slow day is not a standard. It is a wish. The design goal is a record that gets created correctly even when the shift is slammed, which means the burden on the human has to be small and the system has to do the heavy lifting.

Three design principles make documentation survive a bad day. First, capture by default, not by discipline. The system should record the inputs, the raw AI output, and the model version automatically, with no action required from the operator, because anything that depends on a busy human remembering to do it will be skipped under pressure. The only thing the human should have to actively do is the part only a human can do: review and decide. Second, make the human action one deliberate step, not a free-text afterthought. An explicit "agree" or "override, because" choice, captured with the name and timestamp, is faster than writing a paragraph and far more useful in an audit. Third, never let the AI's text auto-populate the final record as if a human wrote it. The draft is a draft until a named human approves it, and the system should make that approval an affirmative act, not a default that happens if the inspector does nothing.

There is a particular failure mode to name, because it is common and it is dangerous: the AI-drafted record that describes a human reasoning process that never occurred. The model writes "inspector evaluated the surface against the boundary sample and determined it acceptable" because that is the kind of sentence that appears in good disposition notes in its training data. If no inspector actually did that, the note is a fabrication, and a fabricated quality record is far worse than an honest gap. It is the kind of thing that turns an audit finding into a question about the integrity of the entire quality system. The rule is blunt: the record may describe only what actually happened. The AI may draft the language, but the human must verify that every factual claim in the note is true before approving it, the same verification discipline this program applies to every AI-touched spec, procedure, and root cause.

Retention, Versioning, and the Boundary You Cannot Cross

Two more disciplines complete the standard, and both are about the long memory a quality system needs.

Retention has to match the product, not the IT default. Quality records for many automotive and aerospace parts must be retained for years, sometimes for the life of the part plus a margin, and a customer or a recall investigation can reach back well beyond a single calendar year. AI records are quality records and inherit the same retention requirement. The trap is that AI tools and their logs often live on a vendor platform with its own, shorter retention default, so the raw model outputs and version history can quietly age out long before the quality system would have discarded them. The plant has to ensure the five elements are captured into a record store it controls and retains on the product's schedule, not left to expire on a vendor's server. A record you cannot retrieve in year three is no record at all.

Versioning is a register, not a footnote. Because element three (the model version) is the one teams forget, the plant needs a maintained register of which model versions were in production over which date ranges, with the validation evidence for each. When a customer asks "was this lot graded by the model that you later found had a problem," the version register answers it in minutes. Without it, the plant is reconstructing model history from memory, which is exactly the position the opening auditor put the plant in. The register is the institutional memory of the AI system itself.

Finally, documentation intersects the operational-technology boundary, the line between the OT side that runs the physical plant and the IT side that runs the business. Because most plants cannot fully see their OT network, with 78 percent lacking centralized monitoring, the documentation standard has a hard companion rule: AI stays advisory and out of direct control of anything that moves, and the record proves a human stood between the AI and the action. A documentation system that logged an AI making an autonomous change to a running line would be documenting a governance failure, not preventing one. The whole point of the human-review element is that there is always a human in the chain to name. If the AI acted alone, there is no one to put in element four, and the record itself becomes the evidence that the OT boundary was crossed. The documentation standard and the advisory-AI rule are two halves of the same accountability: a human decided, a human signed, and the record can prove it.

Key Takeaways

• With AI in the loop, the documentation is the decision made auditable. A quality or maintenance call you cannot reconstruct later is a call you cannot defend, no matter how good the part was. The customer audits the plant, not the AI vendor.
• Fluent AI output creates a false sense that a record is complete. A clean, professional disposition note that no human signed is missing the only part that matters: the human accountability.
• An audit-grade AI record answers five questions completely: what the AI was given (inputs), what it produced (raw output), what the model is (version and validation date), who reviewed it and what they decided (named human, agree or override, with reason), and what happened next (action and outcome).
• Keep the raw AI output and the final human-approved version as two separate, preserved things. Blending them hides the boundary an auditor cares about and makes it impossible to prove the human reviewed rather than rubber-stamped, or to trace whether an error came from the model or the human.
• Model version is the element teams forget most and the one that bites hardest. A model retrained in March made every February decision as a different model, so a version register mapping versions to date ranges is institutional memory the plant must maintain.
• Documentation must survive time pressure: capture inputs, raw output, and version automatically by default; make the human action one deliberate agree-or-override step; and never let AI text auto-populate the final record as if a human wrote it. A standard that only works on a slow day is a wish.
• An AI-drafted note that describes a human reasoning process that never happened is a fabricated quality record, far worse than an honest gap. The AI may draft the words, but a named human must verify every factual claim is true before approving, the same verify-everything discipline applied across the program. The worked bracket example showed this costs about ninety seconds per borderline call.
• AI records are quality records: retain them on the product's schedule in a store the plant controls, not on a vendor platform with a shorter default. And documentation is the companion to keeping AI advisory: every record must name the human who stood between the AI and the action, or the record itself proves the OT boundary was crossed.