Catalog / Science, Engineering & R&D / SCI-025

FMEA & 8D/CAPA quality-engineering assistant

An LLM grounded in past FMEAs, 8D/complaint reports, control plans and product structure drafts failure modes, causes and actions, proposes 8D/CAPA root causes and checks FMEA-control plan-8D consistency for quality engineers.

Quality engineers spend days in workshops and spreadsheets writing FMEAs, then re-type the same knowledge into control plans and 8D reports. An LLM grounded in the company's own past FMEAs, complaints, control plans and product structure drafts failure modes, causes and actions for AIAG-VDA design and process FMEAs, proposes root-cause hypotheses for 8D/CAPA, and flags inconsistencies between the documents. It accelerates the first draft and preserves lessons learned; the cross-functional team still judges severity, occurrence and detection.

Problem & value

  • Today: FMEAs are built in team workshops, often by copying a predecessor product's Excel file. Knowledge sits in thousands of rows nobody searches; the same failure modes are rediscovered after each field issue. 8D and CAPA reports are written under deadline pressure from customers, with shallow root-cause analysis ("operator error") and weak links back to the FMEA and control plan.
  • AI value: reuse of institutional knowledge (what failed on similar parts and processes), faster, more complete first drafts, better-quality root-cause analysis, and automatic detection of gaps (a failure mode in the 8D that never existed in the FMEA; a control-plan characteristic with no FMEA cause).
  • Evidence: established FMEA/quality-software vendors (APIS, PLATO, Siemens, Relyence) are adding AI features to their suites (vendor-reported; the scope of FMEA-specific AI varies, so check it in a demo) [2][3][4][5]. Published, independent time-saving figures are scarce; measure on your own baseline rather than rely on vendor claims.
  • Why distinct: it follows a fixed method (AIAG-VDA FMEA, IATF 16949, 8D) with structured data models, which generic RAG (KNOW-014) and report writing (LANG-003) do not cover.

Variants

  • Automotive supplier (IATF 16949): AIAG-VDA DFMEA/PFMEA with 7 steps, Action Priority (AP) instead of RPN, customer-specific requirements, 8D to OEM portals [1].
  • Medical devices & pharma: ISO 14971 risk management files, FMEA as a risk-analysis tool, CAPA under ISO 13485 / 21 CFR 820 and EU MDR; stricter documentation and validation.
  • Aerospace and machinery: AS9100 / FMECA, MIL-STD-1629-style criticality; functional-safety FMEA (ISO 26262, IEC 61508) is a separate, safety-critical use.
  • SMB job-shop / contract manufacturer: lightweight PFMEA and 8D from templates, supplier 8D review for incoming complaints.
  • Supplier-side 8D review: check supplier-submitted 8Ds for depth and plausibility (see ANOM-011).

How it works

  1. sources (FMEA files, QMS 8D/CAPA, control plans, BOM/PLM, PFD, field returns)
  2. parsing & normalisation to a structured FMEA model (structure tree, function, failure net)
  3. indexing: hybrid search + embeddings + knowledge graph (part/process ↔ failure ↔ cause ↔ control)
  4. generation: given new product structure/process steps, retrieve similar past rows, draft failure modes, effects, causes, controls, proposed S/O/D and AP, with citations to the source rows
  5. 8D/CAPA: complaint text + data
  6. containment, ranked root-cause hypotheses (5-Why, Ishikawa, is/is-not), corrective and preventive actions, FMEA/control-plan update proposals
  7. consistency checks (rules + LLM): FMEA ↔ control plan ↔ 8D ↔ work instructions
  8. human review in the FMEA tool/workshop
  9. approval
  10. write-back to QMS/PLM
  • Structured model first: the AIAG-VDA failure net (function → failure mode → failure effect/cause) is a graph; generating rows against that schema (structured outputs) is more reliable than free text.
  • Grounding: every suggestion cites the historical row or report it derives from; suggestions without a source are flagged as "model knowledge".
  • Rules layer: deterministic checks (AP calculated from S/O/D tables, every high-AP item has an action, every special characteristic has a control) are code, not LLM.
  • Human-in-the-loop: the team assigns S/O/D, accepts or rejects rows, and signs off 8D steps. Root-cause conclusions need physical verification (D4/D5), not just text plausibility.

Data preparation

The raw material is the company's own quality history: design and process FMEAs (usually Excel, sometimes tool exports or PDF), 8D/CAPA and complaint reports in the QMS, control plans, process flow diagrams, and BOM/product structure in PLM or ERP. In an SMB much of it sits on file shares and in mail attachments, partly as scanned customer 8Ds.

Typical gaps: every FMEA is a copy of a predecessor with its own column layout, wording and language; failure modes are free text with many synonyms; links between FMEA, control plan and 8D exist only by habit; scans without OCR; confidential customer content mixed with internal files; operator names in complaints.

Preparation steps: (1) inventory and select one product family (see PREP-001, PREP-002); (2) export and convert files to a tidy table of function, failure mode, effect, cause, controls and ratings (PREP-011, PREP-007); OCR scanned 8Ds with Docling or Paperless-ngx (PREP-006); (3) build a controlled failure-mode and cause vocabulary with synonyms (PREP-015, PREP-019); (4) curate the best FMEAs as gold-standard examples and an evaluation set with quality engineers (PREP-016, PREP-018); (5) pseudonymise names and check access rights per customer (PREP-022, PREP-023).

Expect roughly half of total effort in this preparation, and ongoing upkeep of the vocabulary. With Path A, the vendor tool often forces the structured model, which shifts but does not remove this work. See also GUIDE-003.

Implementation paths

Which path for whom

  • SMB: Path A, because mature German FMEA/QMS suites (APIS, PLATO, both now part of the PeakAvenue group) are adding AI features at SMB prices and AIAG-VDA is a standard process.
  • Enterprise: Path B, because value comes from cross-checks across own QMS, PLM and ERP data, which standard add-ons rarely cover and which fit a shared internal AI platform.
  • Developer: Path C, because open-weight models plus Docling and a graph/vector store give full control for NDA-bound designs and custom consistency rules.
  • FMEA/quality suites with AI: APIS IQ-RM (Germany; FMEA reference tool, AI features to be checked with the vendor) [2], PLATO e1ns (Germany; PeakAvenue advertises AI features for language, search and problem-solving analytics) [3], Siemens Opcenter Quality (within the Xcelerator portfolio) [4], Relyence (US) [5]. Also Ansys Medini analyze (safety analysis), ETQ Reliance, Sphera/Intelex and MasterControl for QMS/CAPA.
  • QMS-embedded CAPA: Veeva Vault Quality, MasterControl, Greenlight Guru (med-device) increasingly add AI summaries and similar-case search.
  • EU vendors: APIS, PLATO, d.velop and other German QMS providers are attractive for data-residency; verify hosting and whether prompts go to a US model provider.
  • Choose A when: you already use one of these tools or have standard AIAG-VDA workflows; the vendor model sees your data with contractual protection.

Path B — Build on cloud APIs

  • Models: frontier LLMs with structured outputs (Claude, Gemini, GPT) or Mistral (EU provider), deployed in EU regions (Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt, Mistral La Plateforme).
  • Stack: parse Excel/PDF FMEAs (Docling or Azure Document Intelligence), embed (bge-m3 or provider embeddings) into pgvector/OpenSearch/Qdrant, add a graph layer (Neo4j) for structure-to-failure links, orchestrate with LangGraph or n8n, write back via QMS/PLM APIs.
  • Choose B when: you need custom checks across your own QMS, PLM (Teamcenter, Windchill) and ERP, and your FMEA tool offers no AI.

Path C — Self-host (open source)

  • Models: open-weight reasoning/LLM models (Qwen3, Mistral Small/Large, Llama, gpt-oss) served via vLLM; embeddings bge-m3 plus a reranker.
  • Stack: Docling, Qdrant/pgvector, Neo4j or Apache AGE, Langfuse for tracing.
  • Hardware: HW3 (one 48-80 GB GPU) for a ~30-70B model with several concurrent engineers; HW2 works for a smaller model with weaker causal reasoning.
  • Choose C when: FMEAs contain customer-confidential designs under NDA that may not leave the premises (common with OEM CSRs).

Path D — Custom training

Rarely needed at first. Fine-tune a small model or a classifier on the company's accepted/rejected suggestions to normalise failure-mode vocabulary or predict S/O/D, once a few thousand reviewed rows exist. Better first step: a controlled catalogue of failure modes and effects plus retrieval.

State of the art (2026)

  • Method alignment: the harmonised AIAG-VDA FMEA Handbook (2019) with seven steps and Action Priority is the reference; tools now model the failure net and enable AI at each step [1].
  • RAG over historic FMEAs is the dominant pattern; research on LLM-assisted FMEA reports useful draft quality and coverage but also hallucinated, generic or inconsistent causes and unreliable severity ratings, so ratings stay human.
  • Agentic 8D: assistants pull data (SPC, test results, MES traceability), run is/is-not and 5-Why dialogue and propose verification experiments; they are strongest as a structured interviewer.
  • Multimodal: vision-language models read defect photos and test curves attached to complaints (see VIS-001).
  • Limits: generic causes ("insufficient training"), invented standards references, over-confident S/O/D, copying wrong context from a predecessor product, and missing novel failure modes outside the training history. Treat output as a checklist stimulus, not a result.

Shared resources & combinations

  • Shared stack (llm-general, embedding-text, vector-db, knowledge-graph): KNOW-014 (lessons learned), SCI-013 (MBSE/requirements: shared product structure and function models), LANG-003 (report drafting).
  • Data inputs: SCI-022 (test-data analytics), PRED-014 (virtual sensors), VIS-001 (inspection findings), OPT-009 (process parameters), DOC-019 (certificate verification), ANOM-011 (supplier risk).
  • Downstream: updated control plans feed inspection plans and SPC; CODE-010 shows the analogous incident-RCA pattern in IT.
  • One self-hosted LLM/RAG server (HW3) can serve this and the above use cases.

Effort, cost & KPIs

  • Path A: weeks to enable an AI add-on; licence cost per user/module.
  • Path B: 3-6 months including parsing of legacy FMEAs, evaluation set and QMS integration.
  • Path C: 4-8 months; GPU server plus MLOps effort.
  • Cost drivers: cleaning legacy FMEAs (inconsistent wording, languages), integration with PLM/QMS, expert time for evaluation.
  • KPIs: hours per FMEA/8D, share of suggestions accepted, recurrence of failure modes (repeat 8D), 8D cycle time and customer rejection rate of 8D, FMEA-to-field-failure coverage, inconsistency findings per audit.

People & change

Involve management early for budget and the AI policy, and the quality department lead as process owner. Quality engineers and 8D owners are the daily users: let them shape the evaluation set and the pilot. IT and IT security clear integration, hosting and prompt-injection risks; data owners release FMEA and QMS data, with customer NDA/CSR constraints checked by legal. The DPO is needed because complaints may name operators; run a DPIA if the tool evaluates individuals, and sign an AVV with every vendor.

Works council: depends. Where a works council exists, §87(1) no. 6 BetrVG applies if the system logs user activity or can link suggestions and 8D findings to individual workers (objective suitability suffices per BAG); §90(1) no. 3 requires timely information about AI-planned work processes. Agree that no individual performance evaluation is derived. In the public sector, the staff council applies.

Measures to support AI literacy (Art. 4 AI Act): short training on hallucinated causes, automation bias and citing sources. Communicate that the tool prepares drafts, while the team keeps S/O/D ratings, D4/D5 verification and sign-off. Start with one product family and a small pilot group of willing engineers, review rejected suggestions together, and address fears of deskilling by keeping the workshop brainstorm first.

Guides: GUIDE-004, GUIDE-008, GUIDE-009.

Risks, regulation & compliance

  • EU AI Act: typically minimal risk (internal engineering productivity); AI literacy (Art. 4) applies. Risk rises if the FMEA concerns a safety component of a regulated product (e.g. medical device, machinery) - the AI tool itself is not the safety component, but outputs entering a risk-management file need validation [6].
  • GDPR: complaints and 8Ds may contain employee names (operators) and customer data; pseudonymise, restrict access, and avoid blame-oriented profiling of individuals. Works-council co-determination in Germany if usage monitors workers.
  • Quality-system rules: IATF 16949, ISO 13485, ISO 14971, 21 CFR Part 11/820 require traceable, validated records; computer software assurance and audit trail of AI suggestions versus approved text are needed.
  • Confidentiality: customer designs under NDA/CSR - check provider terms, EU hosting, no training on inputs.
  • Risks and mitigations: automation bias (mandatory team review and citation requirement), hallucinated causes (grounding, verification step in D4), loss of FMEA team learning (use AI after, not instead of, the workshop brainstorm).

Getting started

  1. Inventory FMEAs, 8Ds and control plans; pick one product family with decent data and a clear structure.
  2. Convert 30-50 historic FMEAs into a structured table and build a small evaluation set of known failure modes.
  3. Test the AI feature of your existing tool (Path A) or a RAG prototype against the evaluation set; measure recall of known causes.
  4. Pilot in one real PFMEA update and one 8D, keeping an audit log of suggestions and decisions.
  5. Add automatic FMEA-control plan consistency checks, then expand to other product lines.

Sources

  1. AIAG & VDA — FMEA Handbook (1st ed. 2019), Failure Mode and Effects Analysis — https://www.aiag.org/
  2. APIS Informationstechnologien — APIS IQ-RM FMEA software — https://www.apis.de/en/
  3. PeakAvenue (PLATO, iqs, APIS) — PLATO e1ns FMEA / quality software — https://www.peakavenue.de/
  4. Siemens — Opcenter Quality — https://plm.sw.siemens.com/en-US/opcenter/quality/
  5. Relyence — FMEA software — https://relyence.com/products/fmea/
  6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  7. IATF — IATF 16949 automotive quality management standard — https://www.iatfglobaloversight.org/