AI server for automotive suppliers: 8D reports, PPAP packs and OEM requirements in-house

What an AI server does for an automotive supplier

An AI server for an automotive supplier runs language models on the company's own hardware for the paperwork of supplier quality: it drafts 8D reports from complaint data and earlier 8Ds, compares each OEM's customer-specific requirements with your own procedures, checks PPAP packs for missing or contradictory documents, and sorts warranty and field claims written in free text. The quality engineer verifies every cause and signs every document; the model writes drafts and lists. For a tier-1 or tier-2 supplier, the starting point we would propose is a server with two NVIDIA RTX PRO 6000 Blackwell Server Edition cards, and four cards let quality, engineering and sales share one platform.

We wrote this for the head of quality or the managing director who decides whether such a server is worth it, and for the IT team that runs it. The general side of AI in a quality management system, such as document control and audit preparation under ISO 9001, is in our guide to AI in quality management. This page stays with what carmakers ask of their suppliers. Engineering work on the OEM side, such as CFD and driving simulation, is covered in our guide to an AI server for automotive R&D.

Four jobs in supplier quality

Our description of the workflow; the 8D steps follow the VDA volume "Definition of Failure Cause Categories for 8D, Reporting" (1st edition, June 2017), read 25 October 2026.

All four are text work on data the company already holds, and they arrive in waves: around a complaint deadline, a new CSR version or a PPAP submission before the start of production. None of them keeps a large model busy all day, so they belong on a company AI server that also serves other departments.

8D reports with AI: drafts in the VDA structure

An 8D report documents how a supplier solves a problem that a customer has raised, in eight steps called disciplines. The VDA's volume on failure cause categories names them: D1 team, D2 problem description, D3 immediate measures, D4 failure causes, D5 planned corrective measures, D6 implemented corrective measures, D7 prevent a repeat of the failure, and D8 acknowledge the team's success. The volume describes 8D reporting as a tool for assessing the quality situation in a plan-do-check-act cycle. Its standard cause categories start at the top level with development, production and logistics, plus one for causes that are unfamiliar or unknown. The supplier assigns a category to each verified failure cause, and each cause "must lead back to an underlying defective process in all phases".

Most of an 8D is text built from data the company holds, which suits a language model. The model writes the D2 problem description from the customer's complaint, the inspection results and the part history. It searches earlier 8Ds for similar failures on the same part family or process, drafts the wording of the measures for D3, D5 and D6, and, once the team has verified a cause, proposes the matching category with its reason. Before the report goes out, it checks the text for gaps: a measure in D6 with no planned counterpart in D5, or a D7 that does not name the documents to update, such as the FMEA or the control plan.

D4 stays with people. A model proposes plausible causes, and the VDA volume defines a root cause as one that cannot be traced back any further. The team finds it at the part, the machine and in the data, attaches the evidence, and only then does the report name it as the cause. Our quality management guide applies the same rule to corrective actions in general.

For one draft, the model reads the complaint, the inspection data and three or four earlier 8Ds, a request of perhaps 10,000 to 20,000 tokens as our example value. Tokens are the pieces of words in which a model counts text; a request of 32K tokens leaves room for the answer.

IATF 16949 customer-specific requirements from each OEM

IATF 16949:2016 is the quality management standard that carmakers require of their suppliers, and each carmaker adds its own customer-specific requirements, or CSRs. The IATF's page of customer-specific requirements, read on 25 October 2026, lists documents for IATF 16949 from ten vehicle makers. Their dates run from April 2021 to July 2026; one maker's CSR and its separate PPAP requirements took effect on 15 June 2026, and two more makers are listed with CSRs under development.

The model turns each CSR into a table: every requirement in the OEM's words, its section, and the place in your procedures where you meet it, or a mark that you do not yet. When a new version appears, it compares the two versions and lists what changed, so the quality manager reviews the changes instead of rereading the whole document. The cross-reference to your procedures comes from retrieval over your released documents, as our guide to RAG on company data explains; only released versions belong in that index.

Length matters here. A CSR of 30 pages at 400 words a page, our example value, has 12,000 words. Our article on tokens per word in EU languages quotes a mean of 1.23 tokens per word for English and 1.76 for German, so by our arithmetic the document is about 14,800 tokens in English and 21,100 in German. Either fits into one request together with the relevant procedures, and the 131,072-token context of gpt-oss-120b holds two versions side by side. The text of IATF 16949 itself is licensed material, and whether you may load it into an AI depends on your licence, as our guide to standards in a company AI sets out.

We supply the server and, through our Private AI/ML service, set up the model and the index over your procedures; send us the OEMs you deliver to and the number of 8Ds a month, and our team replies with a configuration.

PPAP documentation checked by AI before submission

PPAP, the Production Part Approval Process, is defined in the AIAG manual, currently in its 4th edition, second printing. AIAG calls it "the industry standard that defines the production part approval process": it shows that the supplier's manufacturing process meets the engineering design record and the specification requirements. A submission brings together results of the other core tools AIAG publishes, such as the FMEA (failure mode and effects analysis) and the measurement system analysis, with the drawing, the control plan and the test results. Which documents a submission needs follows from the manual and from the customer, and an OEM can add PPAP rules of its own, as the separate PPAP document in the IATF list shows.

The model checks consistency between documents. It lists each special characteristic on the drawing that is missing from the FMEA or the control plan, revision levels that differ between documents, results that refer to an older drawing revision, and documents the customer's requirements ask for that are not in the pack. Scanned reports and drawings first go through a vision-language model, a model that reads images, as our guide to vision-language models for document AI describes. Measured values are compared with their limits by rules in a script, never by the model's judgement. Material certificates are a related task, covered in our guide to EN 10204 certificates read and checked by AI. The quality engineer reviews the list and signs the submission.

Warranty claims: text analysis of free-text field reports

Returned parts and warranty claims come with short texts written by workshops, dealers and fleet customers, often in several languages and full of abbreviations. Read one by one, they hide the pattern; grouped, they show which failure repeats on which part and in which market. An embedding model turns each text into a vector, a list of numbers that places similar meanings close together, so that similar complaints form clusters whatever their language. Qwen3-Embedding-0.6B, under Apache 2.0, has 0.6B parameters, a 32K context and, by its model card, support for more than 100 languages; at 2 bytes per parameter it takes about 1.2 GB by our arithmetic, a small part of one card. The language model then names each cluster and summarises it with example claims, and the quality team checks the result against the returned parts. Our guide to an embedding and reranker server for RAG covers these models in detail.

Claims can contain names and contact details of vehicle owners, so the GDPR applies. Keep only the fields the analysis needs; your data-protection officer confirms the retention period.

TISAX, AI tools and where OEM data may be processed

TISAX is the automotive industry's shared framework for information security assessments. ENX, which runs it, bases it on the ISA catalogue that ENX maintains and the VDA publishes, used for assessments of "suppliers and service providers which are part of the automotive supply chain". The labels reflect assessment objectives such as information security, data protection or prototype protection, they are valid for three years, and the results are not public. On 1 July 2026 the VDA published ISA2027, and since 1 October 2026 ISA2027.1 has been available in German.

ENX's page does not say where data may be processed. That follows from your OEM contracts, the scope of your assessment and your information security management, and every new place where OEM drawings, prototype data or complaint data are processed has to be covered by them. A public AI service is such a place, and some OEM contracts restrict passing data to third parties. A server in your own server room, inside the network and the access rules your assessment already covers, keeps the data, the prompts and the logs where your existing controls apply. Your information security officer and your OEM contracts decide. Our guides to AI questions in customer audits and to trade secrets, NDAs and AI tools cover the evidence and the contract side. This is general information, not legal advice.

Configuration options by card count

A model has to fit into the memory of the graphics card, the GPU, and every request in progress needs extra memory for its context, the cache. Our users-per-card rule takes 90 per cent of the 95.6 GiB that the driver reports for a 96 GB card, less 3 GiB per card, less the weights: 83.0 GiB per card.

Reference configurations on our AI servers page; capacities by our users-per-card rule with a 16-bit cache: gpt-oss-120b 60.8 GiB and 1.125 GiB per 32K request, Qwen3.8-27B in FP8 28.75 GiB and about 2.1 GiB per 32K request (file lists and config.json on Hugging Face, read 25 October 2026); power by our estimate with the cards at 600 W, two processors and 15 per cent for the rest of the server, confirmed by a measurement on the delivered system.

gpt-oss-120b is published under Apache 2.0, with 117B parameters of which 5.1B are active per token, and its files take about 65 GB, 60.8 GiB. Its config.json gives 18 full-attention layers with 8 key/value heads of dimension 64, which by our arithmetic makes 36 KiB of 16-bit cache per token, 1.125 GiB for a request of 32K tokens. One card keeps 22.2 GiB for the cache and answers 19 such requests at the same moment. Qwen3.8-27B, a vision-language model under Apache 2.0, takes 30.9 GB in its FP8 version. With 16 full-attention layers it needs 64 KiB of 16-bit cache per token plus a fixed state of 144 MiB per request by our arithmetic, so the card that also holds the embedding model keeps room for 24 requests of 32K.

Two cards. The entry server has two RTX PRO 6000 Server Edition, two AMD EPYC processors, 384 GB of DDR5 ECC and two NVMe drives. One card runs gpt-oss-120b for 8D drafts, CSR comparisons and PPAP checks; the other reads scans and drawings and runs the embedding model for warranty texts. A request counts only while it is being answered, so far more people can use the assistant than the table shows, because most of the time they read and type.

Four cards. The inference node with 768 GB and four NVMe drives runs gpt-oss-120b as a tensor-parallel pair across two cards, which leaves 2 × 83.0 − 60.8 = 105.3 GiB for the cache, 93 requests of 32K. The third card reads documents, and the fourth is split by MIG into isolated instances for OCR, embeddings and tests, as our article on MIG profiles of the RTX PRO 6000 describes. This suits a supplier with several plants, or one that wants assistants for order entry, engineering and sales on the same platform.

The RTX PRO 6000 Max-Q is the workstation card, a 300 W blower card; in a rack it belongs only in a chassis whose maker lists it, and for continuous operation we recommend the Server Edition.

To plan a first step, describe one recent complaint and the 8D you wrote for it, and we propose a pilot and the server for it.

Notes for the IT team

1. Engine and API. vLLM serves both models through an OpenAI-compatible API. The gpt-oss-120b card states that the model "should only be used with the harmony format", so use an engine release that supports it, and put an LLM gateway with keys and a query log in front of the engines.
2. Sources. Read released procedures from the document management system, and complaints and 8Ds from the CAQ system, the quality software, through an export or its interface. Store the model's proposals in separate fields, so that the confirmed values stay the record; the model writes nothing back on its own.
3. Access. Filter every search by the user's rights, so that the documents and complaints of one OEM reach only the teams that work for that customer.
4. Network and versions. vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere, while routes such as /invocations and /metrics answer without the key (vLLM 0.32.0 security guide), so keep the engines on an internal network behind the gateway. Run a current vLLM release (0.32.0 of 18 October 2026 at the time of writing), the NVIDIA Container Toolkit 1.17.8 or later and a driver release that NVIDIA lists as fixed in its bulletin of 30 September 2026.
5. Logs and evaluation. Keep the query log for a period your information security sets. Before go-live, test the models with real 8Ds and CSR sections whose answers you know, and repeat the test after every model change, as our guide to LLM evaluation before model upgrades describes.
6. Software on delivery. The server arrives on request with the operating system, the NVIDIA driver, CUDA and a container runtime; our guide to RTX PRO Blackwell software support lists the engine versions for these cards.

Power and room

By our estimate, the two-card server draws about 1.8 kW at the wall with two EPYC 9135 processors and fits one 230 V 16 A feed, which carries 2.94 kW at 80 per cent. The four-card server draws about 3.4 kW with the cards at 600 W and needs 32 A or three-phase, or about 2.7 kW with the cards capped at 450 W. Both belong in a server room with cooling for that heat, as our guide to GPU server power on 16 A, 32 A and three-phase feeds explains. Without a server room of your own, our Private AI/ML service runs the same platform on dedicated hardware in a Tier-3 data centre in Lithuania, inside the EU; whether your OEM contracts allow that is a question for your information security officer.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build the servers to order with two, four or eight RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up the models, the index over your procedures and the connections to your quality systems. Our guide to buying a GPU server for LLMs lists every configuration.

FAQ