AI in the automotive industry is no longer only about the car. For OEMs and Tier 1 and Tier 2 suppliers, the quickest returns come from language models and agents that read and draft the documents behind every vehicle program: requirements, specifications and change notices, C/C++ and AUTOSAR code, 8D reports and warranty claims, PPAP and APQP files, supplier documents, plant SOPs and homologation evidence. Because much of that material is customer prototype data covered by TISAX, or evidence for UNECE R155 and R156 type approval, many companies run these models on infrastructure they control.
AI applications in the automotive industry, by function
Ask an automotive engineer where time goes and the answer is rarely the engineering itself. It is finding the current revision of a requirement, tracing which parts a change touches, assembling evidence for a customer audit and writing up a problem that has already been solved once in another plant. Those are document tasks, and across the automotive sector they are where language models are strongest. For the use of AI in the car industry’s engineering centres and plants, that makes documents a sensible starting point: the risk is lower than in a vehicle function, and the material already exists.
| Function | Document work that suits language models and agents | Work that stays with other tools |
|---|---|---|
| Systems and product engineering | Requirement search, specification comparison, change notice impact lists | CAD, simulation, requirements management databases |
| Software and E/E | Code explanation, unit test drafts, AUTOSAR configuration questions, review comments | Compilers, static analysis, hardware-in-the-loop testing |
| Quality | 8D drafts, warranty claim clustering, PPAP completeness checks, audit preparation | Statistical process control, measurement systems |
| Purchasing and supplier quality | Supplier contract and quality agreement review, deviation requests | Supplier scorecards and ERP data |
| Plants | Searchable SOPs and work instructions, shift handover summaries | Machine vision inspection, MES, predictive maintenance models |
| Homologation and compliance | Evidence indexes for type approval, cybersecurity and software update files | Test benches, certified test reports |
The rest of this guide takes each row in turn, then looks at the rules that decide where the models can run. The manufacturing AI use case hub collects the same patterns for other industrial sectors.
Engineering knowledge: requirements, specifications and change notices
A vehicle program accumulates tens of thousands of requirements from the OEM, regulators and internal standards, spread across requirement tools, PDFs, spreadsheets and email. Suppliers receive the OEM’s component specifications and performance standards, often in several revisions, and must show which clauses they meet.
A retrieval assistant over that corpus answers questions such as “which revision of the thermal specification applies to the 2027 platform” or “where do we already meet this corrosion requirement on a carry-over part”, with a citation to the clause. Three tasks pay back quickly:
- Specification comparison. Put two revisions side by side and list the changed clauses, so the engineer reviews ten lines rather than two hundred pages.
- Change notice impact. When an engineering change notice lands, find every drawing, work instruction, control plan and test plan that mentions the affected part number, and draft the impact list for the change board.
- Lessons learned search. Find past design reviews and test failures on similar parts, which keyword search misses because teams describe the same failure in different words.
The requirements tool stays the system of record. The model reads exports and links back to the source item, which matters for traceability audits. The engineering and R&D knowledge use case shows how this works with per-project access rules.
Code assistants for C/C++ and AUTOSAR teams on your own infrastructure
Automotive software teams maintain large C and C++ codebases for ECUs, AUTOSAR Classic configurations, AUTOSAR Adaptive services and the tooling around them. Code assistants help with the slow parts: explaining an unfamiliar module, drafting unit tests, suggesting fixes for static analysis findings, writing review comments and answering questions about how a configuration parameter is used across the codebase.
Three things make the automotive case different from a web team adopting a code assistant.
First, the code is often not entirely the supplier’s to share. Development agreements with OEMs usually restrict where source and specifications may be processed, and an assistant that sends context to an outside API needs that permission. Second, the process rules expect traceability. Automotive SPICE, maintained by the VDA Quality Management Center, assesses how software requirements, design, implementation and tests link together, and its 4.0 release added a machine learning engineering process group. Safety work under ISO 26262 and cybersecurity work under ISO/SAE 21434 add their own evidence needs. Generated code has to enter that chain like any other change: reviewed, tested, checked against MISRA rules by the usual static analysis and linked to a requirement. Third, the IATF has said that the next revision of IATF 16949 will strengthen quality assurance for embedded software, which points the same way.
A model served on the company’s own GPU servers, with retrieval over its own repositories, settles the first point and makes the second easier, because every suggestion, prompt and accepted change can be logged. The code intelligence and review use case describes the pattern for repository search and review assistance.
AI in automotive manufacturing: 8D, warranty claims and PPAP files
Quality departments in the automotive supply chain write a great deal. IATF 16949, the sector’s quality management standard, sits on top of ISO 9001 and adds customer-specific requirements from each OEM. Most of the paperwork follows the AIAG and VDA core tools: APQP for launch planning, PPAP for part approval, FMEA, control plans and structured problem solving such as 8D.
8D reports and root cause work
When a defect reaches a customer, the supplier has days to contain it and weeks to close the 8D. An agent can gather the complaint, the part’s process history, past 8D reports on similar failures, the current PFMEA and control plan, and draft the problem description and a list of candidate causes for the team to test. It does not decide the root cause; the team does, with data. The root cause analysis use case covers how such an agent cites every source it used.
Warranty claims analysis
Warranty claims arrive as structured codes plus dealer technician comments in many languages. Language models are good at reading the comments, grouping claims that describe the same symptom and flagging new patterns early. The output is a list of candidate clusters with example claims, which a field quality engineer confirms before anyone opens a problem case.
PPAP and APQP documentation
A PPAP submission bundles design records, process flow diagrams, PFMEAs, control plans, measurement system studies, capability studies and the part submission warrant. A checking agent can compare a supplier’s package against the customer’s requirements and the previous submission, list missing or inconsistent elements and draft the questions for the supplier. The supplier quality engineer still approves the part.
IATF published a stakeholder communiqué in July 2026 on the second edition of IATF 16949. It names five priorities: simplification, software quality assurance, Tier N supply chain management, launch management and customer-specific requirements. Publication is planned for mid-2027, with the transition aligned to the end of the ISO 9001 transition. Launch documentation and lower-tier supplier evidence look set to get more attention, which adds to the case for tools that keep that evidence searchable.
Supplier documents and plant SOPs
Purchasing and supplier quality teams manage supply agreements, quality assurance agreements, logistics agreements, tooling contracts and deviation requests for hundreds of suppliers. Typical questions are “which suppliers have agreed to our latest warranty cost-sharing clause” or “which agreements still reference the old packaging standard”. Retrieval with citations answers them across the contract base, and an extraction agent can build the comparison table. The supplier and contract document processing use case covers the extraction pattern.
In the plants, standard operating procedures and work instructions often exist in several versions, languages and formats. An assistant restricted to the released versions can answer an operator’s question at the line, in the operator’s language, with a link to the controlled document. It can also draft a new work instruction from an engineering change, for the process engineer to edit and release through document control. Shift handover notes, maintenance logs and andon records become searchable in the same way.
Homologation, cybersecurity and software update evidence
Type approval generates its own document set. Two UN regulations adopted under the UNECE World Forum for Harmonization of Vehicle Regulations matter most for software-heavy vehicles. UN Regulation No. 155 requires a certified cyber security management system, and UN Regulation No. 156 requires a software update management system. The UK Vehicle Certification Agency’s summary of the EU dates lists 6 July 2022 for new whole-vehicle type approvals and 7 July 2024 for existing approvals under R155 for M and N category vehicles, with R156 phasing in for further categories and cases up to July 2029.
The same summary notes that R155’s requirements map closely to ISO/SAE 21434, the road vehicle cybersecurity engineering standard, and names ISO 24089 as the closest standard for software updates. In practice, OEMs ask suppliers for 21434 work products such as threat analysis and risk assessment records, cybersecurity concepts and vulnerability handling evidence, so the documentation burden flows down the chain.
Language models help with the bookkeeping rather than the engineering:
- Evidence indexes. Map each regulatory requirement to the documents that answer it, and flag gaps before the technical service asks.
- Consistency checks. Compare the software versions, part numbers and vehicle variants named across a type-approval file.
- Supplier evidence intake. Read incoming 21434 work products and check them against the cybersecurity interface agreement.
Every one of these documents describes how a vehicle can be attacked or updated, which is exactly the information an OEM does not want leaving its control.
Why OEM data and prototype information push AI onto controlled infrastructure
TISAX and prototype protection
TISAX is the automotive industry’s shared assessment and exchange mechanism for information security, governed by the ENX Association and based on the VDA Information Security Assessment catalogue. Results are issued as labels covering information security, data protection or prototype protection, are valid for three years and are shared through the ENX portal rather than published. Many OEMs require a label before they share confidential or prototype information with a supplier.
ENX announced on 1 July 2026 that the VDA had published ISA2027, which applies to TISAX assessments ordered from 1 January 2027. In the prototype protection part, five control groups are merged into two domains, organisational requirements and physical and environmental security, with new controls for traceability and for the disposal, recycling or return of protected items. The catalogue also expects suppliers with very high protection needs to demonstrate adequate security through a TISAX label, an equivalent third-party assessment or a supplier audit.
A cloud AI service that processes prototype photos, unreleased specifications or test data becomes part of the scope that the assessment and the customer’s contract have to cover. Running the model inside the assessed environment keeps the scope where it already is.
The EU AI Act and type approval
Vehicles fall under the type-approval regulations listed in Section B of Annex I to the AI Act, including Regulations (EU) 2018/858 and 2019/2144. For those products, Article 2(2) limits which parts of the Act apply directly. Instead, the Act amended the vehicle regulations themselves; Article 109, for example, requires the Commission to take the Act’s high-risk requirements into account when adopting implementing acts on AI safety components under Regulation 2019/2144. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published on 24 July 2026 and entered into force on 27 July 2026. It moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
For the engineering and quality assistants in this guide, the Act’s direct reach is narrower. Searching specifications and drafting 8D reports is not a listed high-risk use, but using AI to screen job applicants or evaluate staff is. The AI literacy duty in Article 4 applies whichever use a company picks.
Customer contracts and export rules
Development contracts and non-disclosure agreements often name where data may be processed and by whom. Some vehicle technologies are also subject to export controls. Keeping models, indexes and logs in-house answers both questions with one design.
A governed architecture for OEMs and suppliers
| Layer | What sits there | AI design rule |
|---|---|---|
| Plant floor | PLCs, MES, vision systems, test benches | No direct AI connection; data leaves through approved interfaces |
| Engineering systems | PLM, requirements and ALM tools, source repositories | Read-only connectors first; write-back needs approval |
| Quality and supplier systems | CAQ, warranty database, supplier portal, contract repository | Retrieval respects each system’s permissions |
| Company data centre or private cloud | Model servers, retrieval index, agent platform, audit log | Local models for prototype, code and homologation data |
| Approved external models | Optional, for public or low-sensitivity work | Routed by policy, logged per call |
Four practices keep a rollout on track. Classify the data first and route by classification, not by user preference. Start agents with read access and add write actions one at a time. Log every prompt, retrieved document and tool call against a user and model version, so a TISAX assessor or customer auditor can see what happened. And treat model updates as software changes under the same change management as other engineering tools.
How VDF AI fits automotive OEMs and suppliers
VDF AI is a platform that an OEM or supplier installs on its own hardware: in a plant or corporate data centre, in a private cloud or on an air-gapped network. It can run on local open-weight models alone, so prompts, specifications, source code, retrieval indexes, chat history and logs remain within the company’s environment and inside the scope its TISAX assessment already covers. VDF AI carries no TISAX label or other certification of its own; it is assessed as part of the customer’s environment like any internal application.
The workflows in this guide become governed agents and multi-agent workflows. A warranty agent groups new claims and drafts a summary for the field quality engineer; an 8D agent collects the history and pauses at a human approval step before anything reaches the customer portal. Each role gets only the tools it needs, retrieval follows per-collection access rules, and the audit trail records who asked, which model answered, which sources it cited and which tools it called. VDF AI Router registers local models served through Ollama, vLLM or other OpenAI-compatible endpoints, and can add approved cloud models under policy for non-sensitive work, with budgets and per-call audit.
For on-premises sign-in, Microsoft Entra ID single sign-on works natively; Okta, Keycloak and other SAML or OIDC providers connect through an SSO-aware reverse proxy, and role-based access control is included on every plan. Licences come as seat bundles, and an automotive team can open with a three-month platform trial before committing a program.
Related pages: the manufacturing solution overview and the guide to private AI on plant networks. To see where your data, infrastructure and governance stand before choosing a first workflow, take the free AI readiness assessment.
The regulatory summary above supports planning only and is not legal advice.
Sources
Verified 25 October 2026.
- UK Vehicle Certification Agency, Cyber Security and Software Updating (UN R155 and R156 dates)
- ENX Association, TISAX overview
- ENX Association, VDA ISA2027 released (1 July 2026)
- IATF Stakeholder Communiqué SC-2026-005, IATF 16949 second edition status (July 2026)
- VDA QMC, Automotive SPICE
- UL Solutions, Automotive SPICE machine learning engineering processes
- Regulation (EU) 2024/1689, the AI Act, Article 2
- AI Act Article 109, amendment to Regulation (EU) 2019/2144
- Regulation (EU) 2026/1744, Digital Omnibus on AI, on EUR-Lex