AI for complaints and nonconformities: faster 8D at an automotive supplier
> Reading time: about 6 minutes · Who it is for: quality managers and engineers at automotive suppliers, IATF 16949 representatives, owners of manufacturers weighing up AI for complaint handling.
Context
Automotive suppliers work under one of the strictest quality regimes in industry. The [IATF 16949](https://www.iatfglobaloversight.org/) system standard and specific OEM requirements enforce discipline: every customer complaint and every internal nonconformity goes through a structured problem-solving process, usually the 8D method (eight disciplines, rooted in Ford's Team Oriented Problem Solving and today described in the [VDA QMC](https://vda-qmc.de/en/) materials and the [AIAG](https://www.aiag.org/) manual). On top of that come customer portals, response deadlines counted in days, and audits that check not only whether a problem was closed, but whether the root cause was established properly. This page describes one concrete workflow inside that reality: how AI grounded in a supplier's own history of reports shortens the path from a new complaint to a credible root-cause hypothesis, without taking the decision away from the quality engineer.
Problem
The 8D discipline forces order on a single case, but it does not make the company learn from the whole. Closed 8D reports land in an archive (a folder on a drive, a customer portal, a module in the quality system) and almost nobody goes back to them. As a result the same problems return in slightly different guises, and the team solves them from scratch. Three things hurt most. First, step D4, establishing the root cause, is the slowest and the most dependent on whoever happens to run the case. Second, the knowledge that „we have seen this before, it was about the profile supplier and the weld temperature” sits in the heads of two or three experienced people rather than in the system, so it leaves with their holiday or their notice. Third, with a high volume of reports it is hard even to notice that five separate complaints over three months are one recurring defect, not five independent events.
Solution
Instead of yet another tool for filling in 8D forms, AI gets one job: to turn the archive of closed cases into a source of hints for new ones. The model uses retrieval-augmented generation (RAG) over the company's own history of complaints, nonconformity reports and closed 8Ds. For a new report it does three things: it groups it with similar past cases, pulls the root causes and corrective actions established back then, and hands that to the quality engineer as a list of candidates to check, with links to specific historical 8Ds. The principle is the one we repeat in every sensible rollout: AI narrows, a person decides. The model does not close a complaint, does not send the customer response and does not approve the root cause. It only shortens the path to the first good hypothesis and makes sure the knowledge from earlier cases is not forgotten. The quality of the answer here rests on retrieval, not on the model alone. How to set granularity and avoid fabrication we broke down in [RAG without hallucinations](/en/k/rag/rag-bez-halucynacji-chunking-retrieval-jakosc).
How it works (workflow)
1. **A new report comes in.** A complaint from the customer portal or an internal nonconformity report enters the system. AI reads the defect description, the product, the process and everything the report contains. 2. **Classification and grouping.** The model assigns the report to a defect type and links it with similar past cases. This is where it becomes clear whether it is a one-off event or another occurrence of a known problem. 3. **Retrieval of similar 8Ds.** The system pulls the most related closed cases from the archive: what happened then, what root cause was established, which immediate (D3) and corrective (D5, D6) actions worked. 4. **A proposal for the quality engineer.** The model gives a list of likely root causes with links to specific historical 8Ds, plus a draft of containment actions. This is an input to step D4, not its closure. 5. **A person decides.** The quality engineer checks the hypotheses against the current case, discards false trails and picks the right path. The decision and the responsibility stay with the person. 6. **Closure feeds the base.** The finished 8D returns to the archive the model draws on, so the next similar case starts from an even better hint. The loop closes.
Why automotive complaints specifically
Because there is both rigour and data here. The IATF 16949 regime forces every case to be run properly and documented, so after a few years the company holds an archive of structured descriptions: defect, product, process, root cause, action. That is exactly the material retrieval works well on, because the cases follow a repeatable schema rather than loose prose. The paradox is that the better a company runs its 8Ds, the more valuable the archive it builds and the less it uses it.
What AI really does here
It groups. Out of the stream of reports it picks out those that are variants of the same problem, even when described in different words. This is the first moment „five complaints” turns into „one defect, five occurrences”.
It reminds. To a new case it adds specific historical 8Ds with the root cause and action set back then. The engineer does not start from a blank page but from „in three similar cases the cause was this, check there first”.
It drafts. Based on the cases found it proposes initial containment actions and a draft description the person edits. That is a saving on writing, not on thinking.
What AI does not do here (and should not)
It does not establish the root cause. It gives candidates, the verdict belongs to the engineer. A model can propose a cause that fits the words in the report rather than the physics of the process, and it will do so in the same confident tone as a correct hypothesis. That is why its output is a list to check, not a decision.
It does not understand context that is not in the data. If the real cause is a change at a sub-supplier that no 8D mentions, the model will not point to it. It learns only from what was written down.
It does not replace talking to the shop floor and measurement. An 8D without going to the line and without process data is guessing with better packaging. AI shortens the history analysis, it does not remove the duty to verify on site.
Preconditions
Two, without which there is nothing to discuss. The first is access to the archive of closed cases in a form the model can read and reasonably consistent. The second is a process in which every model output passes through a quality engineer before the customer response. It is the same foundation we described in managing service knowledge: without an orderly source no tool works sensibly. How large the set has to be for retrieval to have something to draw on depends on product variety, not on a single magic number, but the sizing intuition we showed in how much data an AI assistant needs.
How to start narrow
Not with „AI for all of quality”, but with one family of defects that returns most often and hurts most. Then the archive to search is smaller and more consistent, and the effect shows on the next few cases. In our practice with RAG on production documentation, a narrow, well-described scope always beats a broad, blurry one. Only after one family of defects works is it worth adding the next.
What this page does not cover
This is a description of one workflow and its limits, not a deployment guide or a tool comparison. We do not go into specific products, file formats or hardware requirements, and we do not settle on-prem versus cloud, though in automotive the requirement to keep data in house can be hard (a separate topic). We do not give numbers like „how much faster” or savings amounts, because they depend on your starting point. We treat the 8D method and IATF 16949 requirements functionally, as context, not as normative or audit advice.
Related
- RAG without hallucinations: chunking, retrieval and what decides answer quality
- RAG for technical documentation: how AI uses the technical manual and machine instructions
- AI for managing service knowledge: how to feed the system and where the limits are
- AI in technical documentation quality control: what it catches, what it misses
- How to choose an AI vendor for manufacturing: 10 questions before the RFP