Google shipped a workplace AI agent and, in the same fortnight, published a guide to vibe coding. A plant person reads that pairing differently. The barrier to authoring software just fell to roughly zero, and an engineer on your line has already walked over it. I would put money on this: somewhere on a shared drive sits a working, genuinely useful dashboard, SPC calculator or test-report generator that your quality system cannot name, cannot version and cannot produce in an audit. And I am the wrong person to call a luddite – the AI orchestration platform I designed and built runs 63 models in parallel. Speed is not the enemy. Invisibility is.

The tool that worked until Tuesday

I have watched this pattern run twice – once at an automotive tier-one, once in a greenfield plant of nine hundred people, where I built the QA/QC department up from an empty building. Month three: an engineer writes a macro to pull Cpk straight from the measurement system, because changing the corporate tool takes a change request and six weeks. It works. It spreads. Month twelve: the daily quality meeting opens with its output. Month twenty: the failure-cost report, the escalation log and two launch decisions all rest on it – no owner, no revision control, no validation record. The filename ends in _final_v7_REAL.

Then the MES endpoint moves. Or a silently regenerated script shifts a rounding boundary by a fraction of a tolerance. Either way the tool keeps running – it just starts lying quietly. Every decision it shaped becomes unrecoverable, because nobody can reconstruct which version produced which number. We shut down uncontrolled die settings and uncalibrated gauges on sight. An unowned tool is the same animal: a process parameter nobody controls, wired straight into decision flow.

Software with no owner is not an asset – it is a rumour that computes.

Your perimeter assumed a vendor

Alongside the quality career I kept a serious foot in offensive security: a CEH, thirty-odd further certifications, and a place in T-Mobile's public bug-bounty Hall of Fame for a clickjacking flaw, responsibly disclosed. That is the lens I bring to a plant filling with overnight apps. It shows three things.

Apps polling MES and QMS endpoints with tokens pasted in plaintext, because the model suggested it and it worked first try. Read scopes wide enough to walk the entire production database. Imported content treated as trusted content – a dashboard ingesting supplier names, defect descriptions and free-text comments, then rendering them straight into the interface: the exact injection-and-clickjacking class of flaw I used to hunt in vendor code. And vendor code arrived through procurement, with a contract, a security questionnaire and a disclosure channel. These apps shipped from inside, written overnight by colleagues with good intentions, several of them pasting confidential defect data into consumer AI accounts along the way. The attack surface grew. No supplier ever signed for any of it.

Qualify your colleagues like suppliers

A ban is the reflex, and it is the wrong one – bans move the tools underground, and the tools are worth keeping; half the QRQC speed I ever delivered rode on something an engineer built ahead of the official system. Use the discipline you already run. IATF 16949 and VDA 6.3 taught me supplier qualification at Witte Automotive and across a multi-site organisation of two thousand people. An internal tool is simply a supplier that delivers into your process every day and invoices nothing. Qualify it like one, on a single page:

  • Named owner – a person who answers when it breaks, not a department.
  • Data sources and credentials – what it reads, what it writes, what scope it holds.
  • Validation evidence – a golden-file check: ten known batches in, outputs compared against hand-verified results, repeated on every change.
  • Change log and reaction plan – what was modified and when, plus what happens to every decision taken since the last verified run if the tool proves wrong.

Thirty minutes of control beats a week of firefighting – I have priced both. A mis-sorted Pareto once sent a QRQC team I supported after the wrong failure family for three weeks. Five figures in euros of engineering time, before you count the customer's patience. That one incident cost more than every qualification page I have ever signed. Desk-audit the register quarterly, the way you would sample a supplier, and re-run the golden file whenever the tool or its inputs change. The engineers lose a coffee break. You keep the audit trail.

Key takeaways

  • Keep a live register of every internal tool that touches quality records – owner, data sources, last validation date. What cannot be named cannot be defended in an audit or an incident.
  • Before any AI-built tool informs a decision, run it against known-good data: ten verified batches, outputs checked by hand, repeated after every change to the tool or its inputs.
  • Treat credentials like product: no plaintext tokens in home-grown apps, read-only scoped access where possible, and no quality data pasted into consumer AI accounts.
  • Write the reaction plan before the failure – containment for every decision taken since the last verified run, handled the same way as nonconforming product.

The trade press is celebrating AI on fighter-jet lines and in food plants, and one headline got the principle right: AI does not need trust, it needs a quality system. Extend that one step and it covers the software your own people are writing this week. A tool nobody knows exists is a failure mode you have not met yet. The quality system that learns to see home-grown software – name it, own it, validate it, plan its failure – will out-learn the one that bans it, and it will ship faster, because visible things can be trusted at speed. Internal AI-built software is an unqualified supplier delivering into your process every single day. Give it an owner, a validation record, change control and a reaction plan before it becomes load-bearing. Not after.