# How to Add AI to ETQ Reliance or Another On-Prem QMS > Source: https://netray.co/erp-help/private-ai-layer-etq-reliance-qms-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A private AI layer for a QMS exposes NCR, CAPA, complaint, audit and controlled-document records to an assistant through the vendor's documented API or a read-only reporting copy, with attachments indexed locally. An open-weight model runs on your GPUs, QMS roles are carried into every call, and the assistant only drafts records for a quality professional to submit. ## Kind advanced ## System mfg-systems ## Erp ETQ Reliance and on-prem QMS ## Module NCR, CAPA, Audits, Document Control / Private AI layer ## Query how to add AI to an on-prem QMS like ETQ Reliance ## Alternate Queries - ETQ Reliance AI integration - QMS CAPA assistant local LLM - search NCR and CAPA records with AI on-premise ## Applies To ETQ Reliance and similar QMS platforms (for example Intelex, MasterControl or an in-house system) deployed on-prem or in a private environment. Interface details depend on product and version. ## Steps ### Add a private AI layer to the QMS **Items:** Choose use cases that quality engineers repeat: find similar past NCRs, draft a root cause summary from related records, check CAPA effectiveness evidence, and answer questions about controlled procedures. Find out what your edition offers: a documented REST or web service API, a reporting database or data export, and how attachments are stored. Ask the vendor in writing which are supported on-prem for your version. Build a read connector that pulls records and attachments on a schedule or via the API on demand, never with credentials that can edit or sign. Normalize records into a stable shape: type, number, status, dates, product or part, supplier, owner, site, text fields and attachments, with the QMS record permissions copied alongside. Index text and attachments locally with hybrid keyword and vector search and serve an open-weight model with vLLM or Ollama on your own GPUs. Expose approved tools through an MCP server, for example similar_ncrs, open_capas_by_owner and procedure_lookup, and apply the user's roles on every call. Log all activity. Start with read-only search, then add draft text the user can paste or submit, and only later narrow API-based record creation with a human click. ## Sections ### What data the QMS holds and how to reach it **Body:** A QMS is mostly semi-structured records: forms with fixed fields (status, dates, part, supplier, owner) and long text fields (problem description, containment, root cause, corrective action), plus attachments such as photos, 8D reports, audit evidence and supplier certificates. Controlled documents add versions, effective dates and approval history. The reliable access paths are the ones the vendor documents: a REST or web service API for reading and creating records, scheduled exports, and where licensed, a reporting database. Direct SQL against the application database is risky, because the data model is often generic or metadata-driven and the vendor may not support it. If you cannot get a supported read path, scheduled exports to a controlled folder are an acceptable starting point. Take the exact endpoints, authentication and field names from your own product documentation. The connector example below is a template, not a statement of a particular vendor route. **Code:** # connector.yaml for the QMS read connector (placeholders, take routes from your vendor API docs) source: base_url: https://qms.example.local auth: service-account-readonly record_types: - name: NCR list_route: fields: [number, status, opened, part, supplier, owner, site, description, root_cause] - name: CAPA list_route: fields: [number, status, opened, due, owner, actions, effectiveness_check] sync: mode: incremental # by modified date attachments: download-and-parse ### Reference architecture and air-gapped option **Body:** Read connector, normalized store, hybrid search index, tool server, local model, audit log. The normalized store matters because it decouples the assistant from vendor upgrades: when the QMS changes, you fix the connector, not every tool. Semantic search over NCR and CAPA text is where the value is. Engineers find the earlier failure that looks like today's by meaning, not keyword. Combine it with filters on part, supplier and process so results stay precise. In an air-gapped environment, the connector and index sit inside the same enclave as the QMS, the model weights are brought in by transfer, and no component calls out. That also fits defense and aerospace programs where quality records contain controlled technical data. ### Permissions and record-level access **Body:** QMS platforms restrict access by role, site, department and sometimes by individual record, for example confidential complaints or supplier-sensitive NCRs. Copy those permissions into the normalized store as access lists and filter before retrieval, so restricted text never reaches the model for a user who may not see it. If the QMS can be called as the end user through the API, prefer that for sensitive record types. Review the sync service account regularly: it is the single most powerful identity in the design. Test with a restricted user who tries to retrieve restricted records by paraphrasing, and keep that test in a recurring check. ### Write-back and regulated quality processes **Body:** QMS records carry signatures, approvals and audit trail that auditors rely on. The assistant should therefore only produce draft text: a problem statement, a 5-why outline, or a proposed action plan. A person reads it, edits it, and enters or submits it in the QMS under their own identity. If you later allow record creation through the API, keep it to a draft or initiated state, tie it to the human who clicked approve, and exclude anything that closes, approves or signs. Check that your quality procedures and any applicable regulation treat the assistant as a tool, not a decision-maker. ### Sizing, phases and limits **Body:** Most QMS deployments have fewer users than ERPs, often 50 to 500 named, with bursts around audits. One data-center GPU often suffices for a 14B to 32B class model, and the text corpus is small, typically under 100 GB with attachments. Use the calculator for your figures. Phases: first search and Q and A over records, then draft summaries and similar-case suggestions, then limited, approved record initiation. Allow six to twelve weeks for the first phase because connector work dominates. Limits: if your QMS vendor ships an assistant that you may use under your data rules, try it first. Poor record quality, such as empty root-cause fields, limits any assistant, and the model must never be the source of a quality conclusion. ## Pitfalls - Querying the QMS database directly when the vendor does not support it, then breaking on an upgrade. - Giving the sync account edit or sign rights it does not need. - Indexing confidential complaints or supplier-sensitive NCRs without access lists. - Letting the assistant close or approve records, which undermines signature integrity. - Assuming record text is clean: empty or copy-pasted root-cause fields produce misleading similarity results. ## Ai Angle Netray builds QMS assistants as custom work: a read connector, normalized store, local retrieval and open-weight model, with role mirroring. ERPray can then join quality findings to ERP lots, suppliers and work orders, so an NCR search can answer which production orders used the affected lot. ## Faq ### Does this work with ETQ Reliance specifically? **Answer:** The pattern does. The exact connection depends on the ETQ version and edition you run and what interfaces they license: a documented API, exports or a reporting database. Confirm those with ETQ before design. Other QMS products follow the same approach. ### Can the assistant write a CAPA for us? **Answer:** It can draft text for a CAPA, such as problem statement and proposed actions, based on similar records. A quality professional reviews, edits and submits in the QMS under their own identity. We recommend it never closes, approves or signs. ### How do we protect confidential records? **Answer:** Copy record-level permissions into the normalized store and filter retrieval before the model sees any text. Prefer user-scoped API calls for sensitive types, and run regular tests as restricted users. Prompt instructions are not a security control. ### Is this useful during audits? **Answer:** Yes, for finding evidence faster: which CAPAs for a supplier are overdue, where a procedure is referenced, which records relate to a clause. The auditor still reviews the underlying records. Treat the assistant as a finder, not as evidence. ## Search terms etq reliance ai, qms ai assistant on premise, capa search ai, ncr similar record search, etq reliance api integration, quality management system llm local, private ai quality records, air-gapped qms ai --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json