AI automation in manufacturing and automotive: start with a workflow you can verify

A useful first automation in a manufacturing plant helps a person collect records, compare documents and prepare a decision. Customer complaints and changes to customer requirements are good candidates. Each has an identifiable input, owner, output and evidence. An incorrect draft can be stopped before it affects production or shipment.

The ability to generate a report is not enough to justify a project. A quality manager needs to know which drawing revision defines the requirement, which batch a measurement covers and who accepted the action. Without these links, automation moves an existing information problem into a faster tool. The workflow below is Brillnet's implementation recommendation. Contractual requirements and applicable law must be established separately for the plant, product and customer.

Map one real case before selecting technology

Follow a completed complaint from the customer's first message to the check of corrective action effectiveness. Record where people search for documents, copy identifiers, resolve ownership or wait for missing information. This reveals whether the problem needs a language model, a form, a system connection or a change in working practice.

Ordinary software can check due dates reliably against recorded values. AI may help read an unstructured message and suggest a category. Accepting a deviation from a specification remains a decision for an authorised person. Separating these tasks limits both the integration effort and the opportunities for a model to introduce errors.

ISO identifies ISO 9001 as a quality management system standard. It does not certify an individual product or validate a model response. Check the applicable edition and certification arrangements before using an old template as the basis of a project. [1]

Automotive suppliers also need to establish the relevant customer requirements. The official IATF website publishes customer specific requirements for individual manufacturers, with distinct documents and effective dates. Keep the affected customers and sites visible rather than treating every document as one interchangeable automotive package. [2]

Choose an output with a clear boundary

For a first project, we recommend preparing a complaint information pack. Its output is a draft case record linked to the original documents. The scope ends before a response is sent to the customer, a cause is confirmed or material is released. Quality, operations and IT can understand this boundary without interpreting a broad promise of autonomous work.

Comparing two versions of a work instruction is another reasonable candidate. A tool can identify changed paragraphs and suggest which roles may be affected. The process owner checks whether the changes alter work, a form or only wording. The owner then decides what training or practical assessment is necessary.

Avoid defining the first project as automation of the entire quality department. That scope hides connection costs and makes responsibility harder to inspect. A single case record is something a reviewer can read, compare with the originals and reject. It provides enough evidence to decide whether a larger project is justified.

A minimal complaint data structure

Keep the customer's account separate from interpretation. A customer stating that a component cracked is an observation recorded from the message. A possible material defect is a hypothesis. A technically plausible sentence must not become the confirmed cause because a model has written it confidently.

Do not fill a missing field with the most likely value. A complaint without a batch number should show an unresolved gap and a request to establish the scope. Conflicting revisions should remain visible. A convenient interface helps people resolve uncertainty; it does not remove uncertainty from the record.

A fictional example: a metal component complaint

This example is fictional and illustrates the workflow. A plant manufactures sleeves for two customers. One customer reports a deviation in the internal diameter and attaches a photograph and measurement table. No batch number is supplied. The quality folder contains two similarly named drawings with different revisions.

The automation reads the complaint, retains its original attachments and produces a list of missing information. It does not select a drawing because its file was saved most recently. The case owner confirms the part number, applicable revision and affected delivery. Only then can the recorded results be compared with the confirmed specification.

Use conventional code to validate units and the conditions for comparison. A model can draft a description of the difference, but should not make a binding metrology assessment. If the table uses a different unit or omits the method, the result is referred for clarification. It does not receive an automatic compliant status.

An engineer prepares hypotheses for investigation, such as tool wear, operation setup or measurement practice. Each hypothesis identifies the evidence needed to evaluate it. Automation collects available records; the team establishes the cause. After an action is approved, due dates and subsequent verification results can be organised around that decision.

Track changes to customer requirements

A requirement can originate from a contract, drawing, specification, customer portal or CSR document. Record its source, effective date and assessment owner. Finding a new document does not establish that it already applies to the current delivery. That relationship needs confirmation before operational changes are made.

A useful comparison has three separate elements: the location in the previous document, the corresponding location in the new document and the proposed consequence. A changed recording frequency might affect a form and the way work is scheduled. This is an assessment for the process owner to approve, rather than an instruction to update a control plan automatically.

Check permitted processing before supplying paid or licensed standards to an AI service. Employee access to a standard does not necessarily authorise copying it into another service. A project can use requirement identifiers and customer documents without publishing the text of a licensed standard or assuming permission for further processing.

Training after a work instruction changes

A revised instruction needs to be understood at the workstation. A long document cannot establish whether a person will recognise a situation that requires work to stop. Prepare short scenarios about a new drawing revision, damaged measuring equipment, an unreadable label or missing authority to accept a deviation. Each scenario should lead to a specific action.

Separate reading a training material, demonstrating knowledge and demonstrating practical ability. A test result does not prove that someone can perform an operation independently. Authorisation should follow the plant's established method and the decision of its responsible person. A model does not acquire that authority by generating a quiz.

CrewShift, offered in Polish as Zmianowo, is developing training and tests from internal documents with human approval through early access. This direction may help prepare learning materials after an instruction changes. Completion must still be distinguished from qualification and permission to work. Confirm the intended workflow and available functions before adopting a tool.

Connect a limited workflow, not the whole plant

The first project does not require access to machine controllers. A designated document collection and a controlled operation to create a draft case record can be sufficient. Grant access for that operation. An account that reads complaints should not also be able to change specifications, delete source records and send customer responses.

An attachment may contain instructions that attempt to alter the model's behaviour. OWASP describes prompt injection, including attacks involving content from files and other external sources. Treat the complaint as material to analyse, without giving its text authority to control the integration. [4]

Our recommended design exposes a defined set of API or MCP operations. Application code checks identifiers, access scope and output structure. The model proposes parameters for an allowed operation, and the application validates those parameters again. Disabling automation should restore the ordinary case handling process while preserving its history and pending work.

Evaluate the result with a small, meaningful sample

Select completed complaints whose data you are permitted to use. Include complete cases and difficult examples: missing batches, conflicting revisions, unexplained photographs and duplicate messages. Establish the expected output from the case records before reviewing the tool's draft. Otherwise, a fluent narrative can be mistaken for a correct result.

Measure preparation time including corrections and compare it with the existing process. Record errors separately: an incorrect part number, an invented measurement, an omitted attachment or a wrongly assigned revision. A good average time does not compensate for an error that sends the team to investigate the wrong material.

NIST AI RMF is a voluntary framework for AI risk management rather than a plant certification obligation. [3] Our practical recommendation is to document the use context, possible harm, evaluation method and response owner. For a narrow project, a short working record is sufficient if those decisions actually guide operation and review.

Count review and maintenance in the cost

Case handling cost includes extracting inputs, calling a model, checking and correcting the result, and maintaining the connection. If checking a generated record takes longer than preparing it manually, change the scope. The pilot may show that a simple form is a more useful and less expensive solution.

Do not compare a quiet production week with a period of frequent complex complaints. Record the number and difficulty of cases. Measure time to a complete information pack, gaps found before the customer response and incorrect source assignments. The number of generated reports does not show whether decisions have improved.

Maintenance also covers document format changes, model updates and a process owner leaving the organisation. Identify the person who can disable the solution and restore manual handling. Retain the evaluation examples so the same relationships can be checked after a material change. Repeat checks because something changed, rather than turning the initial pilot into a permanent testing loop.

Handle exceptions without rewriting history

Two messages may concern one complaint, and the same attachment may be used in several cases. Define who confirms that records should be linked. Automation can highlight similar part numbers and descriptions, but should not delete the second report. Original identifiers help explain how and when information reached the team.

A corrected measurement needs its own date, author and explanation. Do not overwrite the original value so it disappears. Otherwise, it becomes difficult to explain why an earlier decision was made, especially if that decision determined the investigation scope or what the customer was told.

Prepare a simple fallback. If the model is unavailable, the employee must still see the complaint and attachments and prepare a record manually. Pending processing needs a visible status. Silently missing a complaint causes more harm than admitting that its automatic draft was not produced. The owner should find these cases without inspecting technical logs.

Prepare a pack the quality manager can review

Before starting, prepare one operation description, an example input, the expected output record and the responsibility boundary. Identify permitted documents, authorised users and rules for retaining records. Cover deletion from intermediate locations as well. This makes the proposed cost and risk concrete enough for a useful decision.

Pulsar GRC is developing the organisation of requirements, controls, risk, corrective actions and evidence using customer documents through early access. It is not an automatic interpretation service for every standard or a guarantee of compliance. Establish the specific process and confirm the required functions before selecting a product.

Brillnet also builds narrow tools and services with controlled API or MCP integrations. A reasonable first brief is to prepare a complaint pack with source links, handle missing data and keep approval with quality. The result can be inspected before the scope grows.

Describe a manufacturing workflow to Brillnet. Identify the task, owner and problem in the current process. Arrange an appropriate exchange method before sending confidential customer material. You can also explore the development direction of Pulsar GRC and CrewShift.

Sources and use of evidence

Verified on 2 October 2026. The workflow, table, measures and fictional example are Brillnet recommendations. The references support the stated facts about standards and AI risk; they do not establish a particular plant's compliance.

1. ISO, public ISO 9001 record, standard description and status: https://www.iso.org/standard/62085.html. Accessed 2026-10-02. Establish the applicable edition and transition arrangements for your certification; this article does not reproduce the standard.
2. International Automotive Task Force, Customer Specific Requirements: https://www.iatfglobaloversight.org/oem-requirements/customer-specific-requirements/. Accessed 2026-10-02. Official listing of individual manufacturers' documents.
3. NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework. Accessed 2026-10-02. Voluntary AI risk management framework.
4. OWASP Gen AI Security Project, LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/. Accessed 2026-10-02. Source for instructions embedded in untrusted input content.