Picture a postdoc at 5 p.m. Beads are on the magnet, gloves are on, and the step in front of her doesn't quite fit her input amount. The user guide is a 60-page PDF on a laptop across the room. Her phone is in her pocket.
She isn't going to call your support line. She's going to ask a chatbot.
I spent about ten years building genomics tools at Qiagen, Bio-Rad, and Fluent BioSciences, and I read a lot of support cases that started with three sentences: the kit didn't work, here's the lot number, what happened? What those cases never included was the advice the scientist followed before things went wrong. Increasingly, some of that advice may come from a general AI tool, and the manufacturer never sees it.
Scientists already have a new search bar
AI use among researchers is climbing fast. An Elsevier survey of more than 3,200 researchers found that 58% now use AI tools in their work, up from 37% in 2024. Most of that use is literature search and summarizing, not bench work. But the habit is forming, and the bench is where questions are most urgent and the manual is least convenient.
I don't yet have data on how often scientists ask a general chatbot about a specific kit mid-protocol. That's something I'd like to measure. But anyone who has watched a trainee troubleshoot knows they reach for the fastest answer in the room.
A wrong-kit answer looks exactly like a right one
General-purpose models can produce fluent, confident answers that are false or unsupported. NIST's Generative AI Profile calls this risk confabulation. At the bench, it tends to show up in a few predictable ways:
- Version drift. The answer fits last year's kit revision, not the one on her bench.
- Borrowed parameters. A bead ratio or incubation time comes from another vendor's protocol for a similar workflow.
- Plausible math. A master mix scaled to 23 samples, with overage handled differently than your guide specifies.
- Improvised substitutions. "That polymerase should be fine," with no basis in your validation data.
None of these looks wrong on a phone screen. Any of them can cost a library, a precious sample, or a week.
When the run fails, the kit takes the blame
The scientist won't remember which step came from a chatbot. She'll remember that your kit didn't work. Sometimes she files a ticket. Sometimes she quietly switches workflows, and nobody on your team ever hears why.
Your support and applications teams can only fix what reaches them. When a case does arrive, it usually arrives late and without the run context needed to separate an execution problem from a product problem.
What a trustworthy answer looks like at the bench
Telling scientists not to use AI won't work. The better move is to make the right answer the easiest one to get. In my view, any answer system for a kit or instrument should do five things:
A trustworthy answer at the bench
- Know the product first. Identify the kit, version, and workflow before answering.
- Answer from your content. Use the manufacturer's approved protocols and technical notes, not the open web.
- Show the math. Display the calculation behind every scaled volume so the scientist can check it.
- Say "I don't know." When a question goes beyond approved content, stop and say so.
- Hand off with context. Escalate to your support team with the kit, step, and question attached, so an expert isn't starting from three sentences.
Your user guide is now an input
A user guide used to be a document someone read (or didn't). Now it's also source material that AI systems will pull from, well or badly. Version history, step-level structure, and clearly stated conditions ("if input is below X, do Y") matter more than layout.
There's an upside. Every question a scientist asks mid-protocol is a signal about where the guide, the kit, or the onboarding falls short. Captured with the right consent, those questions can show a product team which step confuses people, and how often, long before it shows up as a complaint trend.
Disclosure: I founded Adept Scientific, which builds protocol-specific guidance that manufacturers can ship with their kits and instruments. The five principles above are how I think any product-grounded system should be judged, including ours.