Connect981 – Content Dev

RSC Cluster: Audit and Compliance Readiness (AS9100, LPAs and Process Audits)

The Audit and Compliance Readiness Cluster focuses on turning audit preparation into continuous evidence rather than episodic panic. It explains what auditors actually expect to see across training, revision control, traceability, and execution records. The content covers internal audits, layered process audits, and AS9100 expectations using real operational examples. This cluster helps organizations stay audit-ready by design, not by scramble.

  • audit-ready

    Core meaning

    In industrial and regulated manufacturing environments, **audit-ready** describes records, systems, or processes that can be presented immediately for formal review by regulators, customers, or internal auditors without additional reconstruction or cleanup.

    Audit-ready status means information is:

    – **Complete** – required data fields, documents, and approvals are present and not missing.
    – **Accurate** – entries reflect what actually happened, without backdating or retrospective changes that obscure history.
    – **Timely and contemporaneous** – recorded at or near the time of the activity, not recreated much later.
    – **Traceable** – linked to specific batches, lots, equipment, materials, people, and time stamps.
    – **Retrievable** – can be located and shown quickly in response to an audit query.
    – **Controlled** – managed under defined procedures, with version control and change history where applicable.

    The term can apply to:

    – **Data** (e.g., production parameters, quality test results, electronic batch records)
    – **Documents** (e.g., procedures, specifications, training records)
    – **Systems or processes** (e.g., an MES workflow that enforces required checks and signatures)

    Use in manufacturing workflows

    In operational workflows, a process or system is often called audit-ready when:

    – Production and quality records are captured in real time through MES, LIMS, or other OT/IT systems.
    – Electronic logs show who did what, when, and under which approved procedure.
    – Configuration changes to equipment, recipes, or software are logged and reviewable.
    – Standard queries and reports can be generated quickly to answer common audit questions (for example, full genealogy of a lot or device).

    Teams may design workflows, validation activities, or data models specifically so that the resulting evidence is audit-ready by default, rather than compiled manually just before an inspection.

    Boundaries and exclusions

    “Audit-ready” **does not** mean:

    – That any regulator or customer has formally accepted or certified the system.
    – That an audit will have no findings or observations.
    – That the process is optimized for cost or performance.

    It specifically refers to the **state of information and controls** relative to being examined, not to overall operational excellence or compliance status.

    Common confusion and misuse

    The term is sometimes used loosely to mean:

    – “We can probably assemble what an auditor needs if given time.” This is not strictly audit-ready; true audit-ready capability implies immediate or near-immediate availability without significant manual reconstruction.
    – “We have a validated system.” System validation can support audit readiness, but a validated system is not necessarily operating in an audit-ready manner if data capture, usage, or governance practices are weak.

    Related phrases include:

    – **Audit-ready evidence** – specific records and datasets that meet audit-ready criteria.
    – **Inspection-ready** – often used interchangeably, though sometimes with stronger emphasis on facility and shop-floor state in addition to data.

    Site context: audit-ready during high-change or high-rate operations

    During periods such as rate ramps, product transfers, or new line startups, being audit-ready typically emphasizes:

    – Maintaining contemporaneous, traceable records despite higher throughput and workload.
    – Ensuring configuration and recipe changes are logged and reviewable.
    – Avoiding after-the-fact data cleanup as the primary method of preparing for an audit.

    In this context, “audit-ready” reflects the ability of systems and processes to generate reliable evidence continuously, even under operational stress or rapid change.

  • assessment method

    An assessment method is a defined approach used to evaluate how well a control, system, process, or organization is performing against specified criteria or requirements. In regulated industrial and manufacturing environments, assessment methods provide structure for demonstrating that security, quality, safety, or compliance controls are implemented and operating as intended.

    Assessment methods are typically documented in procedures, standards, or frameworks and describe what will be checked, how it will be checked, and what evidence is needed. They can be applied to technical controls (for example, network access restrictions), procedural controls (for example, change control workflows), or operational processes (for example, batch record review).

    Common types of assessment methods

    In control and compliance assessments, several method types are commonly referenced:

    • Testing (or technical testing): Actively exercising a control or system to observe behavior and outcomes, such as trying to log in with invalid credentials or executing a backup and restore to verify it works as specified.
    • Examination (or document/record review): Reviewing documented information, such as procedures, system configurations, logs, or quality records, to verify that requirements are defined and evidence of execution exists.
    • Interviews: Speaking with personnel to understand how a control or process is carried out in practice and to confirm alignment with documented procedures.
    • Observation: Watching activities on the shop floor or in a control room to see how tasks are actually performed and whether controls are followed.

    Standards and frameworks, including cybersecurity and quality frameworks, often specify preferred assessment methods for different categories of controls. For example, a procedural control may rely more on interviews and examination, while an automated technical control may rely more on testing.

    Use in industrial and manufacturing environments

    In manufacturing operations, assessment methods are commonly applied to:

    • OT and IT security controls, such as user access management on control systems, patch and configuration management, or network segmentation.
    • Quality and process controls, such as adherence to standard operating procedures, batch release workflows, calibration and maintenance processes, and electronic record management.
    • MES/ERP and integration controls, such as validation of data interfaces, audit trails, and role-based permissions across interconnected systems.
    • Safety and risk controls, such as lockout/tagout procedures, alarm management practices, or safety interlocks.

    In these settings, assessment methods must often be tailored to legacy equipment, mixed levels of automation, and existing validation or qualification practices. The same high-level method type (for example, testing) may be implemented differently on a modern, fully automated line versus a brownfield line with older controls and manual steps.

    Relation to NIST SP 800-53A and similar frameworks

    Frameworks like NIST SP 800-53A describe standardized assessment methods and procedures for evaluating security and privacy controls. In that context, “assessment method” refers to the structured use of testing, examination, and interviews to determine whether a control is implemented, operating as intended, and producing required evidence.

    In industrial environments, these methods are often used as reference models. Organizations typically adapt them to integrate with manufacturing constraints, existing system architectures, and sector-specific validation or qualification requirements.

    Common confusion

    • Assessment method vs. assessment procedure: The method is the type or approach (for example, testing or examination), while the procedure is the detailed, step-by-step description of how the method is executed for a specific control or process.
    • Assessment method vs. audit: An audit is a formal event or program that uses one or more assessment methods. The methods themselves (testing, examination, interviews, observation) can also be applied outside of formal audits, such as during internal reviews or continuous monitoring.

  • regulatory requirements

    Regulatory requirements are mandatory rules, obligations, and constraints established by governmental or other recognized regulatory authorities that an organization must follow to operate legally and compliantly. In industrial and manufacturing environments, these requirements typically affect product design, production processes, facility operations, data handling, and documentation.

    What regulatory requirements include

    Regulatory requirements commonly refer to:

    • Applicable laws and regulations, such as those governing product safety, environmental impact, worker protection, data privacy, and export controls.
    • Binding rules from regulatory agencies, such as directives, rules, or guidance that are treated as mandatory within a jurisdiction.
    • Mandatory standards or technical regulations that have been referenced by law or regulation and therefore become compulsory.
    • Required approvals and licenses, including conditions attached to permits, product registrations, or operating licenses.

    In regulated manufacturing sectors (for example, pharmaceutical, medical device, food and beverage, aerospace, or automotive), regulatory requirements often define how products are developed, validated, produced, released, labeled, stored, and traced, as well as how records and electronic systems are controlled.

    Operational meaning in industrial and manufacturing systems

    In day-to-day operations, regulatory requirements are translated into internal processes and controls so that they can be implemented, monitored, and demonstrated during inspections or audits. This typically involves:

    • Requirements capture: Identifying all applicable regulations for a product, site, process, or IT/OT system, and documenting them in requirements specifications or risk assessments.
    • Procedures and work instructions: Converting regulatory rules into standard operating procedures (SOPs), digital work instructions, and system configurations.
    • System configuration: Implementing controls in MES, LIMS, SCADA, ERP, and quality systems so that electronic records, signatures, traceability, and access controls align with regulatory expectations.
    • Evidence and recordkeeping: Maintaining accurate, retrievable records that show regulatory requirements are being met, including batch records, deviation reports, change records, and validation documentation.
    • Change management: Assessing the impact of process, product, or system changes on regulatory requirements and updating documentation, validation, and training accordingly.

    Relationship to other types of requirements

    Within a requirements hierarchy, regulatory requirements are one category among several, which may include:

    • Customer requirements: Contractual or specification-based expectations from customers.
    • Internal requirements: Company policies, engineering standards, and procedural rules not mandated by a regulator.
    • Interface or technical requirements: Constraints driven by equipment, IT/OT integration, or standards for interoperability.

    Regulatory requirements are distinct in that they originate from external authorities and are not optional for compliant operation within a given jurisdiction.

    Common confusion

    • Regulatory requirements vs. standards: Many standards are voluntary, but they can become regulatory requirements if cited by law or regulation. Without that legal linkage, conformance to a standard is usually not a regulatory obligation.
    • Regulatory requirements vs. best practices: Industry best practices may align with regulatory expectations but are not themselves legal requirements unless embedded in regulations or binding guidance.
    • Regulatory requirements vs. quality requirements: Quality management systems often include both regulatory and non-regulatory requirements. Meeting internal quality targets does not guarantee that all regulatory obligations are satisfied.

    Tie-back to ISO 9000 “requirement” concept

    Within the ISO 9000 family, a “requirement” is a need or expectation that is stated, generally implied, or obligatory. Regulatory requirements are the subset of requirements that are obligatory because they arise from laws, regulations, or binding regulatory rules. In practice, organizations identify these requirements, integrate them into their quality and operational systems, and maintain traceability from the external regulation to internal controls, records, and changes.

  • OASIS database

    The OASIS database is an online information system managed by the International Aerospace Quality Group (IAQG) that centralizes key data related to aerospace quality management system certifications. It commonly refers to the database of approved certification bodies, auditors, and organizations certified to the AS9100-series and related aerospace quality standards.

    What the OASIS database includes

    In an aerospace and regulated manufacturing context, the OASIS database typically contains:

    • Records of organizations certified to AS9100-series and other IAQG-recognized aerospace quality standards
    • Details on certification scope, issuing certification body, and certification status
    • Information about accredited certification bodies and their approvals
    • Information about aerospace auditors and their qualifications and approvals
    • Audit-related entries and certification history maintained under IAQG rules

    The database is used by aerospace OEMs, primes, and suppliers to verify that trading partners hold recognized aerospace quality certifications and to review high-level certification details.

    How it is used in operations and supply chain

    Within industrial operations and manufacturing, the OASIS database commonly appears in:

    • Supplier qualification and onboarding: Checking whether a supplier is listed with an active AS9100-series certification and confirming the scope of approval.
    • Ongoing supplier management: Periodic verification that key suppliers maintain valid aerospace QMS certifications.
    • Customer and regulatory audits: Providing evidence that the organization itself, or its critical suppliers, hold recognized aerospace quality certifications.
    • Internal quality and compliance workflows: Referencing OASIS data in approval workflows, risk assessments, and supplier scorecards.

    The OASIS database is an external reference system. It is not a replacement for an internal QMS, MES, or ERP, but it may be referenced by these systems through manual processes or integrations to support compliance and supplier management.

    What the OASIS database is not

    • It is not a full quality management system (QMS) for an organization.
    • It is not a manufacturing execution system (MES) or production tracking tool.
    • It is not a general-purpose supplier portal for orders, forecasts, or commercial data.
    • It does not replace required internal records of audits, nonconformances, or corrective actions.

    Common confusion

    • OASIS database vs. internal quality databases: Internal systems hold detailed operational records (nonconformances, CAPA, process data). The OASIS database holds high-level certification and audit-related information managed under IAQG rules.
    • OASIS database vs. MES/ERP: MES and ERP manage day-to-day production, materials, and transactions. The OASIS database is a reference for aerospace quality certifications and approvals.

    Manufacturing-relevant example

    An aerospace manufacturer qualifying a new machining supplier may log into the OASIS database to confirm that the supplier holds a current AS9100-series certification with a scope covering precision machining of aerospace components. The manufacturer may then link that verification step into its supplier approval workflow or audit checklist.

  • recertification audit

    A recertification audit is a formal, scheduled assessment performed by an independent certification body to determine whether an organization continues to meet the requirements of a specific standard or regulation after the initial certification period has ended. It typically occurs at the end of a defined certification cycle and is required to renew or reissue the certificate.

    In industrial and regulated manufacturing environments, recertification audits commonly apply to management system standards (for example, quality, environmental, or information security) and to site or product certifications. The audit reviews how the system has been maintained and improved over the full certification cycle, rather than only checking recent changes.

    What a recertification audit includes

    While the exact scope depends on the standard and certification body, a recertification audit commonly includes:

    • A review of the full management system or certified scope, not only selected areas
    • Verification that processes, controls, and records still conform to the applicable standard
    • Review of performance trends, internal audit results, nonconformities, and corrective actions over the certification period
    • Confirmation that any changes in products, processes, sites, or systems are covered by documented change control and, where required, validation
    • Interviews with personnel and sampling of operational records, including production, quality, and maintenance data

    If the organization continues to meet the requirements, the certification body typically issues a renewed certificate for a new cycle, subject to any conditions defined by that body.

    Operational context in manufacturing

    In manufacturing, recertification audits interact closely with OT/IT systems, MES, ERP, and quality systems because:

    • Evidence of ongoing conformity is often stored in electronic systems, such as batch records, device history records, deviation/CAPA logs, and audit trails.
    • Changes to equipment, automation, software, or data flows may need to be documented, risk assessed, and validated before recertification.
    • Updates to the certified scope (for example, new production lines, new product families, or additional sites) are typically reviewed for inclusion during or before the recertification audit.

    Common confusion

    • Recertification audit vs. surveillance audit: A surveillance audit is an interim, usually annual or periodic, check during the certification cycle to confirm ongoing conformity. A recertification audit occurs at the end of the cycle and reassesses the system more comprehensively to renew the certificate.
    • Recertification audit vs. re-audit after nonconformity: A re-audit (or follow-up audit) may be performed to verify correction of significant nonconformities. It does not by itself reset the certification cycle, while a recertification audit is tied to renewing the certificate’s validity period.

    Relation to scope changes

    When an organization changes its certified scope during the certification cycle (for example, adding new products, processes, or sites), the certification body may conduct additional reviews or special audits. These scope changes are typically confirmed and fully integrated into the certificate during the next recertification audit, provided the supporting processes and records demonstrate conformity for the expanded scope.

  • IA9101 / 9101

    Meaning in industrial and regulated environments

    In industrial and regulated manufacturing contexts, **IA9101 / 9101** commonly refers to the aerospace quality management system (AQMS) audit standard published in the 9100‐series family (AS9101 / EN 9101 / JISQ 9101).

    It defines the **requirements for planning and conducting audits** of organizations that implement an aerospace quality management system based on 9100 (and related standards such as 9110 and 9120). It specifies the content and structure of audit reports, checklists, and objective evidence records used by auditors.

    In many organizations the shorthand **“9101”** is used informally, and **“IA9101”** may appear in internal documentation, training material, or tool names to denote processes, templates, or systems aligned to the 9101 audit model.

    What IA9101 / 9101 covers

    In the context of aerospace and other highly regulated manufacturing sectors, 9101 typically covers:

    – Criteria for conducting **quality management system audits**, including process-based auditing.
    – Required **audit documentation**, such as process evaluation forms and nonconformity reports.
    – Structure and content of **audit reports** submitted to certification bodies or oversight organizations.
    – Requirements for capturing **objective evidence** and assessing conformity to 9100-series requirements.
    – Rules for **grading nonconformities** and summarizing audit conclusions.

    The standard is used primarily by:

    – Third‑party certification bodies performing AQMS certification audits.
    – Second‑party (customer) auditors assessing suppliers.
    – Internal audit teams that choose to align their methods with the 9101 framework.

    Use in manufacturing workflows and systems

    Within industrial operations, IA9101 / 9101 shows up in workflows and systems as:

    – **Audit programs and schedules** that reference 9101 as the governing method for AQMS audits.
    – **Audit checklists and forms** embedded in quality management systems (QMS), MES, or audit-management tools.
    – **Supplier quality audits** where customer requirements mandate use of 9101-aligned reporting.
    – **Data structures and reports** in IT/OT systems that mirror 9101 fields (e.g., nonconformity grading, process effectiveness ratings).

    In integrated MES/ERP/QMS environments, 9101-related data may be used to:

    – Link audit findings to **corrective and preventive action (CAPA)** records.
    – Trace audit nonconformities to specific **processes, equipment, or product lots**.
    – Provide structured **evidence for regulatory or customer oversight**.

    Boundaries and exclusions

    IA9101 / 9101, in this sense:

    – **Is** an audit and reporting standard for quality management systems in the aerospace sector and related supply chains.
    – **Is not** the core QMS requirements standard itself (that role is covered by 9100, 9110, 9120, etc.).
    – **Does not** define product specifications, process parameters, or manufacturing methods.
    – **Does not** on its own guarantee compliance, approval, or certification; it only specifies how audits are to be planned, executed, and documented.

    Organizations outside aerospace sometimes reference 9101 methods as a model for structured, process-based auditing, but formal use is typically tied to aerospace and defense quality programs.

    Common confusion and alternate uses

    The designation **“9101”** can be ambiguous because similar number formats exist in:

    – **Other standards families**, such as ISO, IEC, or sector-specific documents.
    – **Internal company codes**, like procedure IDs or IT project numbers (for example, an internal application named “IA9101”).

    In the context of regulated manufacturing and quality systems, the **most common meaning** remains the **AS/EN/JISQ 9101 aerospace audit standard**. When documentation simply says “9101” without context, it is good practice to confirm whether it refers to the aerospace AQMS audit standard or an unrelated internal code.

    Site-context application

    On a site focused on industrial operations, OT/IT integration, and regulated environments, IA9101 / 9101 is relevant as:

    – A **reference model for audit structure and data capture** in QMS and MES-integrated audit modules.
    – A **driver for how quality and audit records are stored**, linked, and reported in enterprise systems in aerospace and defense manufacturing.
    – A **constraint on system design**, where audit trails, nonconformity management, and reporting must support the specific fields and grading required by 9101-aligned audits.

    Understanding IA9101 / 9101 helps teams align digital quality and audit tools with the expectations of aerospace customers and certification bodies, especially when integrating shop-floor, QMS, and ERP data for audit purposes.

  • How early should audit preparation start for major certifications?

    For most major certifications, audit preparation should start months in advance, not weeks. A reasonable planning window is often 6 to 12 months before the audit, with longer lead time if you have significant process changes, new software, weak document control, site expansion, high turnover, or known gaps from prior audits.

    If the organization is already disciplined, records are current, and internal audits are working, the timeline can be shorter. If evidence is fragmented across paper, spreadsheets, MES, ERP, PLM, QMS, and email, preparation usually takes longer because the real issue is not the audit date. It is whether the underlying system is consistently operating and traceable.

    What should happen early

    • Confirm scope, sites, products, processes, and applicable requirements.

    • Review prior findings, overdue CAPA, repeat issues, and open risk items.

    • Run internal audits early enough to correct root causes, not just clean up records.

    • Check training, approvals, revision control, equipment status, and record retention.

    • Test whether evidence can be retrieved quickly and consistently across systems.

    • Stabilize major process or system changes before the audit where possible.

    What usually drives a longer timeline

    • Recent ERP, MES, PLM, QMS, or document management changes

    • Brownfield integrations with weak data mapping or inconsistent master data

    • Paper-to-digital transitions that are not fully adopted on the floor

    • Poor closure discipline for deviations, NCRs, CAPA, or training records

    • Multi-site operations with local workarounds and inconsistent procedures

    • High personnel turnover or reliance on tribal knowledge

    In regulated and long-lifecycle environments, late preparation is risky because many gaps cannot be solved quickly without creating new problems. Rewriting procedures, changing workflows, or replacing systems close to an audit can introduce validation burden, retraining needs, new failure modes, and questions about whether the process is mature or merely staged for the audit.

    This is also why full replacement strategies often fail as an audit-readiness tactic. In brownfield plants, ripping out legacy MES, ERP, PLM, or QMS platforms before a major audit usually increases risk due to integration complexity, downtime constraints, qualification effort, and the need to preserve traceability and change control across long equipment lifecycles. Coexistence and targeted remediation are often more realistic than wholesale replacement.

    The practical goal is not to “prepare for the audit” as a short-term event. It is to make sure the operating system, records, and evidence trail can withstand normal scrutiny. If preparation only starts when the auditor is scheduled, the organization is usually too late for meaningful corrective action and left with superficial fixes.

    So the short answer is: start as soon as the audit becomes likely, and ideally treat audit readiness as a continuous discipline. For a major certification, 6 to 12 months is common. More time may be necessary if your processes, systems, or evidence trail are not stable.

  • Can sites still adapt processes locally with MES?

    Short answer: yes, but with tighter guardrails than paper or spreadsheets

    Most MES implementations allow some degree of local process adaptation, but the latitude is typically much narrower than in paper-based or ad‑hoc digital systems. What a site can change locally depends on configuration options, governance, and the level of regulatory scrutiny. In many regulated plants, local changes are limited to parameters (like limits, sequences, resources) within approved templates rather than complete workflow redesign. This is intentional: it trades local freedom for consistency, traceability, and controlled risk. If your organization expects the MES to be both a rigid standard and a playground for local experimentation, there will be friction.

    What usually *can* be adapted locally in an MES

    In most brownfield environments, sites can locally adjust master data and configuration elements that are explicitly exposed as parameters. This often includes things like routing variants, resource assignments, work center calendars, and shift patterns that reflect local capacity and layout. Sites may also adjust work instructions, checklists, and data collection points, as long as the changes stay within controlled templates and approved content libraries. Limits, sampling frequencies, and inspection points can sometimes be tuned locally, especially when they are driven by risk assessments or product-family rules. However, each of these types of changes is normally subject to role-based access and a formal change process, not free-form shop-floor editing.

    In practice, this connects to shop floor execution control when teams need to turn the answer into repeatable execution habits.

    What usually *cannot* be freely adapted at site level

    Major structural changes to the process model are often restricted or centralized. Examples include altering the fundamental routing logic, removing critical data collection points, or bypassing electronic signatures. Cross-system flows that impact ERP, QMS, or serialization are usually locked down because they affect finance, compliance, and downstream traceability. Many multi-site MES deployments deliberately prevent local sites from forking core templates, since divergent models are expensive to validate, support, and audit. In highly regulated sectors, attempting to maintain dozens of local variants of validated workflows is rarely sustainable. This leads to a model where sites can propose changes but cannot independently rewire core process logic.

    Tradeoffs: standardization vs local agility

    MES is usually introduced to reduce uncontrolled local variation, which directly conflicts with the idea of unconstrained local adaptation. Tighter standardization simplifies training, audit readiness, deviation analysis, and master data maintenance, but it can make local continuous improvement slower. Allowing more local autonomy can accelerate problem solving and innovation, but it drives up validation overhead and complicates comparisons across plants. In regulated environments, leaders often accept slower local changes to protect consistency of data and evidence. The pragmatic compromise is to standardize the backbone flows and allow flexible configuration of parameters, prompts, and decision rules within that structure.

    Change control, validation, and why “just let sites change it” is risky

    Every non-trivial MES change that affects GMP, FAA, or similar-relevant records potentially requires impact assessment, regression testing, and documentation. If each site makes structural changes on its own, the organization inherits a large and often invisible validation burden. Over time, this leads to multiple, slightly different MES behaviors that are hard to qualify, re-test, and support during upgrades. When auditors or customers ask for evidence of control, explaining dozens of uncontrolled local variants is difficult. For this reason, many organizations centralize the change control process and require that site-level adaptations go through defined workflows with clear approvals and traceability.

    Coexistence with legacy systems and local workarounds

    In brownfield plants, MES often coexists with spreadsheets, local access databases, or niche tools that historically enabled very local process tweaks. After MES deployment, some of those tools persist as unofficial workarounds when MES is too rigid or change cycles are too long. This creates data fragmentation and can undermine the authoritative record expected from MES. Leaders need to be explicit about what is allowed locally and what must be in MES, and then align change control to make that realistic. If local adaptations are blocked in MES but tolerated in shadow systems, you get the worst of both worlds: fake standardization on paper and uncontrolled variation in practice.

    Practical patterns to enable safe local adaptation

    Many organizations adopt a tiered model: corporate or global engineering owns core process templates, while sites can configure bounded options and parameters. This can be implemented via feature flags, parameter tables, or site-specific configuration layers that do not break the underlying validated logic. Some teams also define “safe change” categories where sites can act quickly under local procedures, and “high-risk change” categories that require cross-functional review and potentially revalidation. Periodic configuration audits and configuration baselines help ensure that local adaptations remain visible and supportable. None of this removes the need for governance, but it can give plants meaningful room to adapt without fragmenting the entire MES landscape.

    Connecting this to continuous improvement and problem solving

    For continuous improvement and root cause analysis to be effective, sites must be able to close the loop by changing how work is executed, not just documenting issues. In a meshed MES–QMS landscape, that often means translating corrective actions into controlled MES changes: new checks, different sequencing, or adjusted limits. When the MES is overly centralized with long lead times, local teams will naturally push fixes into informal workarounds or training-only changes, which are fragile. Designing the MES governance so that well-justified, risk-assessed local adaptations can be implemented within reasonable timeframes is critical. Otherwise, MES becomes a barrier to improvement rather than an enabler.

  • What documentation should I keep to support audits of AI in production?

    You should keep a traceable evidence package that shows how the AI system was selected, configured, validated, monitored, changed, and governed in actual production use. In most regulated manufacturing environments, auditors will not be looking for one document. They will be looking for a coherent record set across quality, engineering, operations, and IT.

    The exact package depends on what the AI is doing. A scheduling assistant, a vision model used for inspection support, and a model that proposes process parameter changes do not carry the same risk. The more the system can influence product quality, release decisions, traceability records, or operator actions, the more rigorous the documentation usually needs to be.

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    Core documentation to retain

    • Intended use and scope
      Document the business purpose, process boundaries, users, decision rights, inputs, outputs, and any prohibited uses. Be explicit about whether the AI is advisory, semi-automated, or allowed to trigger actions.

    • Risk assessment
      Keep a documented assessment of failure modes, foreseeable misuse, data quality risks, model drift risks, cybersecurity considerations, and impact on product quality, traceability, and operations. Include the controls you rely on to reduce those risks.

    • System architecture and data flow
      Maintain records showing where data originates, how it is transformed, what systems exchange data, what identifiers are used, and where outputs are stored. In brownfield plants, this often means documenting MES, ERP, PLM, QMS, historian, SCADA, document control, and local spreadsheets or operator stations that still participate in the process.

    • Data lineage and data readiness evidence
      Retain source datasets, data definitions, inclusion and exclusion criteria, labeling or annotation methods if used, preprocessing rules, known gaps, and any data quality checks. If training or tuning used historical plant data, you should be able to show what period, what equipment, and what process conditions were represented.

    • Model and configuration records
      Keep versioned records of the model type, vendor or internal build, prompts or system instructions if relevant, tuning parameters, thresholds, business rules, confidence limits, and any fallback logic. For vendor systems, you may not get full internal model details, so document what is actually available and note the limitation.

    • Validation and verification evidence
      Keep test protocols, acceptance criteria, test results, exception handling, re-test results, and sign-offs. Validation should be tied to intended use, not just generic vendor claims. If performance depends on local data, operators, or integration quality, your records should say that clearly.

    • Human review and operating procedures
      Document who reviews AI outputs, what they are expected to check, when they can override the system, when escalation is required, and how the review is recorded. This matters especially when AI recommendations affect inspection, routing, maintenance, scheduling, or quality events.

    • Change control
      Keep formal records for model updates, prompt changes, rules changes, retraining events, connector changes, interface changes, and master data changes that could alter behavior. In regulated environments, undocumented tuning is a recurring audit problem.

    • Access control and security records
      Retain evidence showing who can configure, approve, run, override, and administer the system, along with authentication, authorization, logging, and incident response practices. If technical data or controlled information is involved, document how access boundaries are enforced.

    • Audit trails and operational logs
      Keep timestamped records of inputs, outputs, user actions, approvals, exceptions, overrides, and downstream actions taken. If the AI contributes to a production record, you should be able to reconstruct what happened for a specific lot, serial number, work order, or event.

    • Monitoring and periodic review
      Retain evidence of ongoing performance review, drift checks where applicable, false positive or false negative trends, complaint signals, NCR or CAPA linkages, and trigger conditions for revalidation.

    • Deviation, incident, and CAPA records
      When the AI behaves unexpectedly or contributes to a process issue, keep the investigation, containment, root cause work, corrective actions, and effectiveness checks linked back to the system version and affected records.

    • Training records
      Document training for operators, engineers, reviewers, and administrators, including what they were trained to trust, what they were trained not to trust, and how exceptions are handled.

    • Supplier and service documentation
      For third-party AI tools, retain contracts, service descriptions, release notes, support commitments, data handling terms, and vendor change notifications. If you cannot obtain needed evidence from the supplier, that gap should be acknowledged and addressed through compensating controls where possible.

    What auditors usually want to see in practice

    Most audits are less about the phrase AI and more about whether you can demonstrate control. In practice, that usually means you can answer these questions with records:

    • What exactly is this system allowed to do?

    • What data does it rely on, and is that data trustworthy enough for the intended use?

    • How was it validated in your environment, not just by the vendor?

    • Who approves changes, and how do you know what version was active at a given time?

    • How are users prevented from treating suggestions as automatic truth?

    • How do you detect bad outputs, integration errors, drift, or silent failures?

    • Can you reconstruct the system’s role in a specific production event or quality decision?

    Brownfield reality

    In many plants, the documentation is spread across existing systems rather than stored in one AI repository. That is normal. The challenge is not only creating documents, but linking them. Your evidence may live across QMS records, change requests, MES transaction history, ERP master data approvals, document control, validation binders, SIEM logs, and vendor tickets.

    That is also why full replacement strategies often fail. Replacing MES, QMS, ERP, and plant integrations just to make AI governance cleaner usually creates more qualification burden, validation cost, downtime risk, and traceability disruption than most regulated operations can absorb. A more realistic approach is to define an evidence map that shows which system is the system of record for each control.

    Common gaps

    • Using pilot documentation in production without updating intended use, risks, and approvals.

    • Keeping model test results but not the production configuration that was actually deployed.

    • Logging outputs without logging who reviewed them or what downstream action was taken.

    • Assuming vendor documentation is enough for local validation.

    • Failing to document prompts, thresholds, business rules, or retrieval sources because they seemed operational rather than validated.

    • Not linking AI incidents to NCR, deviation, or CAPA processes.

    Minimum practical structure

    If you need a starting point, keep at least these controlled record groups:

    1. AI inventory with owner, intended use, risk level, interfaces, and current version.

    2. Validation package tied to intended use and site conditions.

    3. Change history with approvals and effective dates.

    4. Operational logs and audit trail retention rules.

    5. Periodic review records with performance and incident trends.

    6. Training and access authorization records.

    If those six areas are weak, audit support will usually be weak as well.

    The main constraint is that documentation quality cannot compensate for poor process control, weak integrations, or unvalidated use. If the AI depends on unstable source data, informal operator workarounds, or undocumented system changes, those weaknesses will surface during an audit even if the document set looks complete.