AI w obsłudze reklamacji i niezgodności: szybsze 8D u dostawcy motoryzacyjnego
AI nie zamyka za was reklamacji ani nie pisze 8D „samo”. Robi jedną rzecz, która realnie skraca proces: dla nowego zgłoszenia przeszukuje historię waszych zamkniętych spraw i podaje inżynierowi jakości listę prawdopodobnych przyczyn źródłowych oraz akcji, które wcześniej zadziałały przy podobnym defekcie. Najwięcej czasu odzyskujecie w kroku D4 (ustalenie przyczyny źródłowej) i na tym, że powtarzalny problem widać jako jeden wzorzec, a nie pięć osobnych zgłoszeń. Warunek działa tylko wtedy, gdy macie uporządkowane archiwum 8D, a wynik modelu zawsze przechodzi przez człowieka, zanim trafi do klienta.
Dla kogo: kierownicy i inżynierowie jakości u dostawców motoryzacyjnych, pełnomocnicy IATF 16949, właściciele firm produkcyjnych rozważający AI w obszarze reklamacji.
Kontekst
Dostawcy motoryzacyjni pracują w jednym z najostrzejszych reżimów jakościowych w przemyśle. Standard systemowy [IATF 16949](https://www.iatfglobaloversight.org/) i wymagania konkretnych OEM narzucają dyscyplinę: każda reklamacja klienta i każda niezgodność wewnętrzna idzie przez ustrukturyzowany proces rozwiązywania problemów, najczęściej w metodyce 8D (osiem dyscyplin, z rodowodem w Fordowskim Team Oriented Problem Solving, dziś opisane m.in. w materiałach [VDA QMC](https://vda-qmc.de/en/) i podręczniku [AIAG](https://www.aiag.org/)). Do tego dochodzą portale klientów, terminy na odpowiedź liczone w dniach i audyty, które sprawdzają nie tylko czy problem zamknięto, ale czy przyczynę źródłową ustalono rzetelnie. Ta strona opisuje jeden konkretny workflow w tej rzeczywistości: jak AI wsparte historią własnych zgłoszeń skraca drogę od nowej reklamacji do wiarygodnej hipotezy przyczyny źródłowej, bez odbierania decyzji inżynierowi jakości.
Problem
Rygor 8D wymusza porządek na pojedynczej sprawie, ale nie sprawia, że firma uczy się z całości. Zamknięte raporty 8D trafiają do archiwum (folder na dysku, portal klienta, moduł w systemie jakości) i praktycznie nikt do nich nie wraca. W efekcie te same problemy wracają w nieco innym przebraniu, a zespół rozwiązuje je od zera. Trzy rzeczy bolą najbardziej. Po pierwsze, krok D4, czyli ustalenie przyczyny źródłowej, jest najwolniejszy i najbardziej zależny od tego, kto akurat prowadzi sprawę. Po drugie, wiedza „to już było, wtedy chodziło o dostawcę profilu i temperaturę na zgrzewie” siedzi w głowach dwóch, trzech doświadczonych osób, a nie w systemie, więc razem z ich urlopem albo odejściem znika. Po trzecie, przy dużym strumieniu zgłoszeń trudno w ogóle zauważyć, że pięć osobnych reklamacji z trzech miesięcy to jeden powtarzalny defekt, a nie pięć niezależnych zdarzeń.
Rozwiązanie
Zamiast kolejnego narzędzia do wypełniania formularzy 8D, AI dostaje jedno zadanie: zamienić archiwum zamkniętych spraw w źródło podpowiedzi dla spraw nowych. Model korzysta z retrieval-augmented generation (RAG) nad własną historią reklamacji, raportów niezgodności i zamkniętych 8D. Dla nowego zgłoszenia robi trzy rzeczy: grupuje je z podobnymi sprawami z przeszłości, wyciąga z nich ustalone wtedy przyczyny źródłowe i akcje korygujące, i podaje to inżynierowi jakości jako listę kandydatów do sprawdzenia razem z odnośnikami do konkretnych, historycznych 8D. Zasada jest ta sama, którą powtarzamy w każdym sensownym wdrożeniu: AI zawęża, człowiek rozstrzyga. Model nie zamyka reklamacji, nie wysyła odpowiedzi do klienta i nie zatwierdza przyczyny źródłowej. Skraca tylko drogę do pierwszej dobrej hipotezy i pilnuje, żeby wiedza z poprzednich spraw nie została zapomniana. Rdzeniem jakości odpowiedzi jest tu retrieval, nie sam model. Jak dobrać granulację i uniknąć zmyśleń, rozłożyliśmy w nocie [RAG bez halucynacji](/k/rag/rag-bez-halucynacji-chunking-retrieval-jakosc).
Jak to działa (workflow)
1. **Wpływa nowe zgłoszenie.** Reklamacja z portalu klienta albo wewnętrzny raport niezgodności trafia do systemu. AI czyta opis defektu, wyrób, proces i wszystko, co jest w zgłoszeniu. 2. **Klasyfikacja i grupowanie.** Model przypisuje zgłoszenie do typu defektu i łączy je z podobnymi sprawami z historii. Tu wychodzi na jaw, czy to jednostkowe zdarzenie, czy kolejne wystąpienie znanego problemu. 3. **Retrieval podobnych 8D.** System wyciąga z archiwum najbardziej pokrewne zamknięte sprawy: co się wtedy działo, jaką ustalono przyczynę źródłową, jakie zadziałały akcje natychmiastowe (D3) i korygujące (D5, D6). 4. **Propozycja dla inżyniera jakości.** Model podaje listę prawdopodobnych przyczyn źródłowych z odnośnikami do konkretnych historycznych 8D oraz szkic akcji zabezpieczających. To wejście do kroku D4, nie jego zamknięcie. 5. **Człowiek rozstrzyga.** Inżynier jakości weryfikuje hipotezy na tle bieżącej sprawy, odrzuca fałszywe tropy i wybiera właściwą ścieżkę. Decyzja i odpowiedzialność zostają po stronie człowieka. 6. **Zamknięcie zasila bazę.** Gotowy 8D wraca do archiwum, z którego korzysta model, więc następna podobna sprawa startuje z jeszcze lepszą podpowiedzią. Pętla się domyka.
Dlaczego akurat reklamacje w motoryzacji
Bo tu jest i rygor, i dane. Reżim IATF 16949 wymusza, że każda sprawa jest prowadzona porządnie i udokumentowana, więc firma po latach ma archiwum ustrukturyzowanych opisów: defekt, wyrób, proces, przyczyna źródłowa, akcja. To jest dokładnie ten materiał, na którym retrieval działa dobrze, bo sprawy są opisane w powtarzalnym schemacie, a nie luźną prozą. Paradoks polega na tym, że im lepiej firma prowadzi 8D, tym cenniejsze archiwum buduje i tym rzadziej z niego korzysta.
Co AI tu realnie robi
Grupuje. Z potoku zgłoszeń wyławia te, które są wariantami tego samego problemu, także jeśli opisano je innymi słowami. To pierwszy moment, w którym „pięć reklamacji” zmienia się w „jeden defekt, pięć wystąpień”.
Przypomina. Do nowej sprawy dokłada konkretne, historyczne 8D z ustaloną wtedy przyczyną i akcją. Inżynier nie zaczyna od pustej kartki, tylko od „w trzech podobnych przypadkach przyczyną było to i to, sprawdź najpierw tam”.
Szkicuje. Na bazie znalezionych spraw proponuje wstępne akcje zabezpieczające i draft opisu, który człowiek redaguje. To oszczędność na pisaniu, nie na myśleniu.
Czego AI tu nie robi (i nie powinno)
Nie ustala przyczyny źródłowej. Podaje kandydatów, werdykt należy do inżyniera. Model potrafi zaproponować przyczynę, która pasuje do słów w zgłoszeniu, a nie do fizyki procesu, i zrobi to tym samym pewnym tonem co trafną hipotezę. Dlatego jego wynik to lista do sprawdzenia, nie decyzja.
Nie rozumie kontekstu, którego nie ma w danych. Jeśli prawdziwa przyczyna to zmiana u poddostawcy, o której nie ma słowa w żadnym 8D, model jej nie wskaże. Uczy się tylko z tego, co zapisano.
Nie zastępuje rozmowy z produkcją i pomiaru. 8D bez wyjścia na halę i bez danych z procesu to zgadywanie z lepszą oprawą. AI skraca analizę historii, nie zdejmuje obowiązku weryfikacji na miejscu.
Warunki wstępne
Dwa, bez których nie ma o czym rozmawiać. Pierwszy to dostęp do archiwum zamkniętych spraw w formie, którą model odczyta, i w miarę spójnej. Drugi to proces, w którym każdy wynik modelu przechodzi przez inżyniera jakości przed odpowiedzią do klienta. To ten sam fundament, który opisaliśmy przy zarządzaniu wiedzą serwisową: bez uporządkowanego źródła żadne narzędzie nie zadziała sensownie. Jak duży musi być zbiór, żeby retrieval miał z czego korzystać, zależy od różnorodności wyrobów, a nie od jednej magicznej liczby, ale intuicję sizingu pokazaliśmy przy asystencie AI w biurze technicznym.
Jak zacząć wąsko
Nie od „AI do całej jakości”, tylko od jednej rodziny defektów, która wraca najczęściej i najbardziej boli. Wtedy archiwum do przeszukania jest mniejsze i bardziej spójne, a efekt widać na najbliższych kilku sprawach. W naszej praktyce z RAG na dokumentacji produkcyjnej wąski, dobrze opisany zakres zawsze wypada lepiej niż szeroki i rozmyty. Dopiero po tym, jak jedna rodzina defektów działa, warto dokładać kolejne.
Czego ta strona nie pokrywa
To jest opis jednego workflow i jego granic, nie instrukcja wdrożenia ani porównanie narzędzi. Nie wchodzimy w konkretne produkty, formaty plików ani wymagania sprzętowe, i nie rozstrzygamy on-prem kontra chmura, choć w motoryzacji wymóg zachowania danych u siebie bywa twardy (to osobny temat). Nie podajemy liczb typu „o ile krócej” ani kwot oszczędności, bo zależą od waszego punktu wyjścia. Metodykę 8D i wymagania IATF 16949 traktujemy funkcjonalnie, jako kontekst, a nie jako poradę normalizacyjną czy audytową.
Powiązane
- RAG bez halucynacji: chunking, retrieval i co decyduje o jakości odpowiedzi
- RAG do dokumentacji technicznej: jak AI korzysta z DTR i instrukcji maszyn
- AI do zarządzania wiedzą serwisową: jak zasilić system i gdzie są granice
- AI w kontroli jakości dokumentacji technicznej: co wychwytuje, czego nie
- Jak wybrać vendora AI dla produkcji: 10 pytań przed RFP