A contamination complaint reaches the plant floor eight months after an AI quality system flagged a batch, cleared it, and released it to distribution. Legal calls the plant asking for the approval record. Three days of searching two systems and one former employee's inbox turns up nothing. The AI made the call. Nobody wrote down who let it.
A May 2026 Foley & Lardner legal series on AI in manufacturing and supply chains names this exact gap as a live category of risk: product liability and warranty exposure when AI drives quality or scheduling decisions, contractual risk allocation across the supply chain, and regulatory penalties tied to how well a company can document what its own AI did and who let it. The brief runs through eight risk categories in total. Nearly every one assumes the company can produce a record when asked. Most can't.
Regulators and courts increasingly expect something beyond a correct outcome from an AI-driven decision. They expect a litigation-ready audit trail: a record naming who approved the action, the exact timestamp, the data the approver saw, and an export format that survives a legal hold intact. Call it decision-grade documentation: proof of authorization, not just a log of activity.
Board conversations about AI governance still default to ROI: adoption speed, cost savings, competitive pressure. That's a CFO's question. The sharper question belongs to General Counsel, and it doesn't care whether the AI was right: if a regulator, an auditor, or opposing counsel demands the record behind a specific AI-driven action, can you produce it before the deadline a subpoena or a legal hold sets?
From the work
Written from 5+ manufacturing and distribution engagements, 2022–2026, where approval and audit-trail architecture were built into AI-driven ERP write actions. That's the same record structure a legal team would need to produce under discovery.
Correct isn't the same as defensible
An AI system that flags a credit hold correctly, schedules a production run correctly, or reroutes a shipment correctly has done its job operationally. None of that answers the question a deposition asks six months later: who reviewed this, and on what basis did they let it proceed? A correct outcome with no named approver leaves a gap in the record, and opposing counsel fills that gap with their own narrative.
This is the assumption most AI governance conversations skip. Teams evaluate AI deployments on accuracy, speed, and adoption. Legal teams evaluate them on a different axis entirely: can this decision be reconstructed, attributed, and defended after the fact, by someone other than the system that made it? A model can be 99% accurate and still leave a company exposed, because accuracy was never the question a subpoena asks.
What the eight risk categories mean for AI running on the shop floor
Three of the categories in the Foley & Lardner brief are direct governance-architecture problems: the kind a named-approver record actually closes. Liability from AI-driven operational decisions (predictive maintenance calls, quality releases, production scheduling) needs a documented chain of authorization to defend against a product liability or warranty claim. Vendor and supply chain contracts increasingly require audit rights and indemnification structured around who can prove what an AI agent did. Regulatory compliance works the same way: the EU AI Act's human oversight requirement under Article 14 for high-risk systems, and enterprise procurement's rising treatment of ISO 42001 certification as a purchase condition, are both documentation requirements wearing a compliance label.
The other categories in the brief aren't solved by an approval record, and it's worth saying so directly. Intellectual property disputes over AI-assisted invention, cybersecurity breach notification for shadow AI deployments, and data privacy compliance across legacy infrastructure need their own legal and security work. An audit trail doesn't replace outside counsel. It gives them something to work with instead of a shrug.
What a legal team needs from an AI audit trail under discovery
An operational log and a litigation-ready decision record look similar until someone asks a lawyer's question of them.
| Record field | Operational audit log | Litigation-ready decision record |
|---|---|---|
| Approver identity | System user ID or generic role account | Named individual, verified identity |
| Timestamp | Batch-logged, sometimes hours delayed | Captured at the moment of approval, to the second |
| Supporting data | Not retained past the transaction | Snapshot of the exact data the approver saw |
| Retention & export | Rolls off after a retention window, dashboard-only | Held on request, exportable to CSV or PDF for legal hold |
| What it answers | What happened | Who authorized it, and on what basis |
Four specific fields separate the two columns. A named approver: a specific person, not a system account. "Route Manager approved" holds up in front of a regulator or opposing counsel where "workflow auto-approved" doesn't. An exact timestamp, to the second, in a form that cross-references cleanly against other systems' logs. A supporting-data snapshot: the inventory count, quality reading, or credit exposure the approver actually saw, not what the ERP shows today. And an exportable record: CSV or PDF on demand, not a login-only view that disappears when the vendor contract ends or the one person who knew the login leaves the company.
How a named-approver audit trail meets a discovery request
OpsGrid requires explicit human approval before any consequential decision executes in Business Central: a credit hold release, a production order override, a supplier payment exception. The action doesn't write to the ERP until a named person approves it inside Microsoft Teams. That approval step generates the record automatically: identity, timestamp, the exact BC data shown at the moment of approval, and the action taken. The record stays retained and exportable on request.
That record was originally built to answer an operational question: who approved this, and why, during a Friday-night escalation. It answers a legal one just as directly. When a document request names the specific decision, legal exports the record instead of searching two systems and a departed employee's inbox for three days.
Frequently asked questions
What legal liability does ungoverned AI create in manufacturing operations?
Product liability and warranty exposure when an AI system drives quality, maintenance, or scheduling decisions; contractual risk allocation across the supply chain when an AI-driven action affects a supplier or customer commitment; and regulatory exposure under rules like the EU AI Act's human oversight requirements for high-risk systems. The common thread is a missing record: nobody can say who authorized the decision, when, or on what data.
What does an AI audit trail need to include to hold up in legal discovery?
Four things: a named individual approver, not a system account; a timestamp precise to the second; a snapshot of the exact data the approver saw at the moment of approval, not what the system shows today; and an export format (CSV or PDF) that survives a legal hold outside the vendor's own dashboard. An operational log that only shows what happened doesn't answer the discovery question, which is who authorized it, and on what basis.
Is "the AI approved it" a defensible answer to a regulator or auditor?
No. Under frameworks like the EU AI Act's Article 14 human oversight requirement, and under standard product liability and contract law, an automated approval with no named human accountable for it is closer to a finding against the company than a defense. Regulators and auditors are asking for the same thing opposing counsel asks for in discovery: a specific person who reviewed specific data and made a specific call.
How does human-in-the-loop AI governance reduce legal exposure for manufacturers?
By converting every consequential AI-recommended action into a decision with a named owner before it executes. The approval step itself generates the record a legal team needs: who approved it, when, what data supported it, and an exportable trail. This doesn't eliminate legal risk from AI deployment, but it converts an undocumented automated action into a documented human decision with an accountable name attached. That's what most of the liability categories in current legal guidance are actually asking for.
An AI system doesn't need to be wrong to create liability. It needs to be unaccountable. Accountability is a record problem, and the record is the part decision infrastructure is built to keep. For the broader architecture behind that claim, see decision infrastructure vs. decision intelligence.