AI Cheating Is Now the #1 Misconduct Issue at Work. Here's the Policy Gap Behind It.

If your company runs job interviews or accepts outside contributions to anything you ship, you have a policy decision to make this week, not eventually: how do you tell someone who used AI to prepare from someone who had AI do the work for them.

ISE data reported by The Neuron this month puts undisclosed AI use at the top of employers' misconduct list — 66% of companies now name it their most common problem in live assessments, and a separate analysis from Fabric flagged 38.5% of candidates for cheating behaviour. Google, Amazon, Cisco, and McKinsey have all reinstated in-person interview rounds specifically to counter it. The same week, the open-source GIS platform QGIS formally banned AI-assisted code contributions after a flood of low-quality pull requests overwhelmed its maintainers, and the technical-writing community The Consensus shipped a static-rule detector that filters AI-sounding articles out of its own digest. Its readers, it turned out, preferred bad human writing to good AI writing.

The pattern across all three: volume without quality control breaks faster than the output improves. Generating more with AI isn't the differentiator anymore — producing work that survives someone else's scrutiny is. If you manage people, that means drawing a written line between "used AI to prepare" and "had AI do it for you" before your next hiring round, not after a candidate gets caught. If you make things with AI's help — code, copy, reports — the line that matters is whether your output would survive a reviewer who's primed to look for the tells.

Take Elena, who runs hiring for a 120-person logistics software company. Her team's take-home coding exercise stopped being useful the day three candidates in one week submitted solutions that were technically correct and stylistically identical. She didn't ban AI use — her engineers use it on the job anyway — but she rewrote the exercise so half the score comes from a short live walkthrough where the candidate explains one decision they made and defends a change to it on the spot. The fix wasn't detection software. It was moving the real test from the artifact to the conversation about it.

Contrast that with Marcus, a freelance technical writer who pitches long-form explainers to three SaaS blogs. One editor started rejecting his drafts without explanation until he asked directly — her team had adopted an AI-tells checklist after readers complained about generic phrasing, and two of his pieces had tripped it despite being mostly his own writing. He didn't stop using AI to speed up research. He started checking his own drafts against the same three things the checklist flagged — hedge words, unsupported superlatives, and paragraphs that could describe any company — before he sent anything.

Neither fix required new software. Both required deciding, in writing, what "good enough to pass as yours" actually means before the test, the pull request, or the pitch lands.