In September 2026, QGIS core developer Nyall Dawson pushed QEP428 and turned the project’s “human in the loop” stance into a flat “NOT ALLOWED” for AI contributions. The reason wasn’t bad code. As maintainer Régis Haubourg put it, the AI stream is “a lot higher than what human review can take seriously,” leaving maintainers with either a growing pile of un-reviewed pull requests or code that got waved through. Generation was never the constraint. Review was.

That same math is already running inside your quality and operations teams. AI can draft the deviation report, the CAPA, the work instruction, the supplier audit summary, faster than any qualified person can verify it. This article breaks down what QGIS actually figured out, and how to write an AI contribution policy that protects review capacity instead of pretending it’s infinite.

QGIS Did Not Ban AI Over Code Quality, It Ran Out of Reviewers

Read the QEP discussion and you will notice nobody argues the submissions were wrong. The complaint is about load. Haubourg’s framing was blunt:

AI use from external contributors puts a massive and unbearable pressure on the shoulders of our maintainers, who already had a tough job before the era of LLM’s

The thread drew 88 thumbs-up against 27 thumbs-down, which tells you the maintainers doing the reviewing were not divided about this. The people writing contributions were.

That asymmetry is the whole story. Output scaled instantly. The verification layer, the senior engineer, the QA lead, the person who signs off, did not. Any team that rolled out AI tools without adding review capacity has already built the same imbalance into its deviation handling, its engineering change process, and its documentation queue.

What QEP428 Actually Changes, and Why ‘Human in the Loop’ Failed

The old QGIS rule was the one most organisations are writing right now: use AI if you want, disclose it, keep a human in the loop. QEP428 scraps that and replaces it with a prohibition. The policy did not get tightened. It got inverted.

Haubourg gave three reasons, and only one of them is about code. The first is load on maintainers. The second is throughput, review cannot keep pace with generation. The third is structural: QGIS is trusted because organisations know they can contribute back, hire contributors, and fund features. That human network is the asset, and it degrades when the queue fills with submissions nobody owns.

Why a disclosure-and-review rule collapsed under volume

A human-in-the-loop policy assumes the human has spare capacity. It works when AI output is occasional and the reviewer is a bottleneck nobody notices. Once generation gets cheap, the loop becomes the choke point, and you end up with the two outcomes QGIS named explicitly: a longer list of un-reviewed PRs, or code waved through without full review.

Disclosure does not solve this. Knowing a submission was AI-assisted tells a reviewer nothing about how much scrutiny it needs, and in practice it adds a step without removing any. That is the flaw in most AI contribution policy drafts sitting in your governance folder today. They regulate the input and say nothing about who absorbs the output.

The one AI use case QGIS deliberately left open

Haubourg did not close the door entirely. He flagged a separate topic he wants discussed at the user conference: LLM use for review, auditing and security. That carve-out matters more than the ban itself.

The distinction is where AI sits in the workflow. Pointed at generation, it multiplies the queue. Pointed at review, it expands the constraint. QGIS banned the first and kept the second on the table, which is the opposite of how most teams are deploying AI inside quality and operations functions right now.

The Review Bottleneck Shows Up in Quality and Operations Too

Swap pull requests for nonconformance reports and the picture is identical. AI drafts the deviation write-up, the CAPA, the work instruction revision, the supplier audit summary. Every one of those still needs a qualified human signature before it means anything.

A quality manager approving 40 AI-drafted NCRs a week is sitting exactly where a QGIS maintainer sits in front of the PR queue. The backlog grows, or sign-off becomes a formality. Both answers create audit exposure, and the second one is worse because it looks like compliance.

The generation-to-review ratio to measure before scaling

Before you expand an AI pilot, count two numbers. Items generated per week on one side. Hours of genuinely qualified review available per week on the other. Not total headcount hours, only the hours from people whose names can legitimately appear in the approval field.

Then look at your rejection rate over time. If it is falling, you have two possible explanations: the drafts got better, or scrutiny dropped. Sampling ten approved documents and re-reviewing them properly will tell you which. Most teams find the second answer and do not want to write it down.

What a rubber-stamped approval costs in an ISO or FDA audit

An auditor does not assess your AI. They assess whether your documented review step actually happened. A reviewer who approved 200 records in an afternoon has already answered that question, and the timestamps are sitting in your eQMS waiting to be pulled.

That turns a throughput problem into a systemic finding. Not one bad CAPA, but evidence that your approval control is not operating as described in your procedure. Remediation then covers every record that passed through the same broken step, which can mean months of retrospective review.

Haubourg’s third reason for QEP428 was structural trust, not code. The same logic applies to your quality system. Approval signatures are worth something only while they still mean someone looked, and your AI contribution policy has to protect that or it protects nothing.

Blanket Ban vs. Scoped Permission: Choosing the Right AI Policy

There are only two policy shapes that hold up under pressure. One forbids AI outright in a defined area. The other permits it inside named limits, with a named reviewer and a budget for the review. Everything in between (disclose it, use good judgement, keep a human in the loop) collapses the moment volume climbs, because it asks reviewers to absorb unbounded work without anyone paying for it.

Four questions decide which shape you need:

• Who bears the review cost: if the person generating the output is not the person checking it, and the checker has no say in volume, you have the QGIS problem.
• Is the output reversible: a draft email can be wrong twice. A released work instruction cannot.
• Will an auditor ask who approved it: if yes, the approval has to be real, named, and timed.
• Is volume bounded: anything that can be generated infinitely will be.

Where a hard ban is the correct engineering decision

Ban AI where contributions arrive from people outside your accountability chain and review is funded by goodwill. That is exactly the QGIS position: unpaid maintainers, anonymous contributors, no mechanism to slow the inflow. A ban costs nothing to enforce and needs no case-by-case judgement.

Inside a plant, the equivalent zones are supplier-submitted documentation, validated process changes, and anything feeding a regulatory submission. If you cannot staff verification at the rate submissions arrive, prohibition is the honest answer. A ban is not an anti-AI position. It says verification was never resourced.

How to write scoped permission that survives contact with reality

Scoped permission works when AI users are employees with job titles, outputs are traceable to a system of record, and someone has budgeted review hours. Write the scope as a list of named artefacts, not a principle. Name the reviewer role, the maximum weekly volume that role can absorb, and what happens when the queue exceeds it.

Then add the part most policies skip: a trigger to revoke scope. If review lag passes two weeks, the permission suspends automatically until capacity is added. Without that, your AI contribution policy is a wish.

Build Review Capacity Before You Scale AI Output

The teams that avoid a QEP428 moment are the ones that fund verification at the same time as generation. Automated pre-checks that reject malformed or incomplete output before a human opens it. Named accountability per output type. A hard cap on how many items one reviewer signs in a week. None of that is glamorous, and all of it is what keeps throughput honest.

The ROI framing matters here. Bandwidth freed by AI is only real if it is not immediately eaten by review and rework. If your quality engineer saves two hours drafting and loses three hours checking, you bought a loss and called it automation.

A tiered review model mapped to risk, not volume

Most teams review everything the same way, which means the trivial work and the regulatory work get identical attention. Split it instead. Low-risk output (internal summaries, meeting notes, first-draft training material) gets a spot check. Medium-risk output gets a single named reviewer. Anything touching a regulated record, a customer commitment, or a safety decision gets full human authorship with AI relegated to research only.

Tiering by risk rather than volume is what gives you room to scale. You can take ten times the low-risk output without adding a person, because the review cost per item is near zero. The high-risk tier stays deliberately small and deliberately slow. That is a feature.

The 30-day AI policy audit for quality and operations teams

Start with an inventory. List every output in your function that AI currently touches or plausibly could, and write a human name next to each one. Not a department. A person. Where the name is blank or shared, you have found your next incident.

Then measure review time per item for two weeks and compare it against generation time. Through 2026, more software projects, standards bodies, and regulated industries will publish their own AI contribution policy. Write yours from your own numbers before someone writes it for you.

Source: github.com