Citizen Developers in Regulated Industries: The New Model for GxP AI

Why the Model Is Appearing Now

Two things changed at once, and they compound.

The first is tooling. Low-code platforms moved from departmental curiosities to standard enterprise infrastructure. Gartner’s December 2022 forecast, as reported by InfoWorld, projected that developers outside formal IT departments would account for at least 80% of the user base for low-code development tools by 2026, up from 60% in 2021, and that low-code would account for 75% of new application development by 2026, up from 40% in 2021.¹² Whether those exact figures hold in any one company is not the point. The direction is not in dispute, and it is visible in every pharma IT estate we look at.

The second is generative AI. A person who could not previously write a script can now describe what they want in plain language and get working logic back. That collapses the remaining skill barrier. It also changes the shape of the risk, because the thing being built is no longer just a form and a workflow. It can be a component that summarizes, classifies, ranks, or drafts, and those are exactly the operations that produce GxP consequences when they go wrong.

Behind both of these is a structural fact that pharma IT leaders already know. The central development queue cannot absorb the demand. It never could. When a request for a small internal tool takes nine months to reach the top of a portfolio list, the requester does not wait nine months. They find another way, and now another way is genuinely available to them.

The demand does not disappear when you say no

This is the part that gets missed in governance discussions. A policy that forbids citizen development does not produce zero citizen development. It produces citizen development that nobody can see. The same survey reported above found that 51% of respondents had connected AI tools to work systems without IT approval, and that 63% considered using unapproved tools acceptable when no corporate option existed.⁴ That last figure is the one that should shape policy. People are not defying the rules for the sake of it. They are solving a problem the organization did not solve for them.

For a GxP company the practical conclusion is uncomfortable but simple. An enabled, registered, tiered citizen development program produces a list you can show an inspector. A prohibition produces a set of tools you will find during an investigation, in the worst possible circumstances, when someone is explaining how a number got into a batch record.

What the model actually is

Stated plainly: the people who understand the process build the tool, and IT and quality supply the guardrails, the platform, and the route to scale. The QA specialist knows what makes a deviation summary useful in a way no developer can learn in a requirements workshop. The manufacturing scientist knows which of the forty fields on the form actually get read. Putting the build in their hands removes an entire translation step, and translation steps are where requirements go wrong.

What changes in a regulated company is not that idea. It is that the guardrails have to be specific, written down, and connected to the quality system, because a tool built by a QA specialist is subject to exactly the same regulatory expectations as a tool built by a contractor, and the regulator will not care who typed it.

What Citizen Developers Actually Build in a GxP Company

It helps to be concrete, because abstract governance discussions tend to imagine either trivial toys or full manufacturing execution systems, and almost nothing real is either.

Notice the pattern. Almost all of these produce a draft, a flag, a shortlist, or a view. Very few of them produce a record. That distinction is not an accident of the examples. It is the natural shape of what domain experts build for themselves, because what they want is help with the work, not replacement of their judgment. The governance job is to keep that natural shape from drifting, and to have a clear rule for what happens when it does.

It is also worth being honest about the quality of what gets built. Research on low-code practice consistently finds that practitioners themselves hold conflicting views on the advantages and disadvantages of these platforms, and that maintenance, integration, and platform limitations generate real difficulty rather than disappearing.⁵⁶ A separate survey of low-code and no-code platforms in industry sets out the limitations of the approach alongside its benefits, which is a useful corrective to vendor material that presents only the second half.⁷ A program designed on the assumption that these tools are easy and stay easy will be surprised twice: first by maintenance, then by the audit.

The Boundary That Decides Whether the Model Works

Most citizen development policies fail at the same place. They try to define the boundary by tool, by data, or by department, and all three are the wrong axis.

By tool fails because the same platform builds a lunch-order form and a release decision aid. By data fails because a tool touching GxP data to display it is not the same as a tool touching GxP data to decide something, and a rule that treats them alike either stops useful work or waves through dangerous work. By department fails immediately, because quality departments build tools and IT departments build tools and neither fact tells you anything about risk.

The axis that works is the position of the human check relative to the record.

This framing does two things that a permissions list cannot. It survives new tooling, because it says nothing about the technology. And it gives the citizen developer a clear, non-negotiable statement of where their ownership ends, which is far more useful to them than a list of approved connectors.

The second axis: reach

The handoff test sets the ceiling. A second question sets the controls below that ceiling: how many people use it, and can they tell when it is wrong? A tool used by its builder is self-correcting, because the builder knows the data and notices when the answer is strange. The same tool used by forty people across three sites is not self-correcting, because most of those users have no way to sense a bad result. Reach is why a tier structure is needed at all rather than a single yes-or-no line.

Four Tiers: Who Approves, What Evidence, What the Register Says

Here is a working tier structure. It is deliberately short. A tier model with nine levels does not get used, and a tier model that requires a risk workshop to place a tool does not get used either. Placement should take a competent person about five minutes.

What each tier writes into the register

The tier does not just set approvals. It sets how much the register has to know. Registration burden should rise with tier, because a Tier 1 entry that demands twelve fields will produce shadow tools rather than register entries.

Two of these fields deserve comment. The date classified field matters because classification decays, and knowing when a judgment was last made tells you whether to trust it. The prompt and model version field matters because a generative component can change behavior without the application changing at all. Retraining and model change control are covered in depth elsewhere in this series; the register’s job is simply to make the current version knowable.

Placing a tool in a tier

The regulatory grounding for this proportionality is not new. WHO guidance on computerized system validation states that systems should be validated according to quality risk management principles, with the level of validation commensurate with the identified risks, complexity, and intended use.⁸ A tier model is simply that principle written down in advance, so that the risk judgment is consistent across two hundred small tools rather than reinvented each time.

The Register Is the Control

Everything above depends on one artifact. Without a register, the tiering is a document nobody applies, the training is untested, and the platform team is guessing. With a register, the program becomes something a leader can report on and an inspector can examine.

The register is not a new idea imported into pharma. It is the same control that appears in other regulated disciplines that have had to manage many small pieces of consequential logic. The Federal Reserve’s revised guidance on model risk management, issued in April 2026 and superseding its 2011 predecessor, describes maintaining a comprehensive set of information for models under development or in use, with the inventory carrying varying levels of information to reflect different levels of model complexity, and enough information to understand model risks both individually and in aggregate.⁹ That is a different industry with different obligations, but the underlying design point transfers: an inventory whose depth scales with the risk of the item, maintained so that the total picture is knowable and not only the individual entries.

Make the platform emit the register

The single most important design decision is that the register should not depend on people filling in a form. Registration forms produce partial registers, and a partial register is worse than none because it creates confidence that is not earned.

Modern low-code platforms can tell you what exists. Microsoft’s own guidance for Power Platform governance describes continuous monitoring of platform usage and regular compliance monitoring as core Center of Excellence responsibilities, alongside role-based access control and audit trails of who accessed or modified solutions and data.¹⁰ Platform-level data loss prevention policies further control which connectors a maker can combine, which is a technical control on what can be built rather than a promise about what should be.¹¹

The practical design is a two-part register. The discovered layer comes from the platform automatically: every application, flow, and agent that exists, with its owner, creation date, connectors, and usage. The declared layer is what the human adds: intended use, classification, the verification control, the reasoning. Anything in the discovered layer without a matching declared entry is an exception with an owner and a due date. That single reconciliation is the health measure for the whole program.

Review has to look at use, not the build

A periodic review that re-reads the original requirements and confirms the tool still works is close to useless for this class of asset. The build rarely goes wrong on its own. What changes is how people use the output. A review of a citizen-built tool should ask a short set of questions about the present: who uses it now, what do they do with the output, has anything downstream started depending on it, and does the original classification still describe reality. Those four questions catch nearly everything a longer technical review would miss.

Training and Qualification of Citizen Developers

In a GxP environment, training is not an enablement nicety. It is a regulatory requirement with an existing home in the quality system. US current good manufacturing practice regulations require that people engaged in the manufacture, processing, packing, or holding of a drug product have the education, training, and experience to perform their assigned functions, with training in the particular operations they perform and in current good manufacturing practice.¹² WHO guidance on computerized systems is explicit that the persons who must be appropriately trained and qualified include developers and end users, not only administrators.¹³

Building a tool that supports GxP work is an assigned function. It therefore needs a training record, and the citizen developer needs a qualification that is recorded the way any other qualification is recorded.

What the curriculum actually has to contain

For tools with a generative component there is an additional obligation in the EU. Article 4 of the EU AI Act requires providers and deployers of AI systems to take measures to support the development of AI literacy among staff dealing with the operation and use of those systems, and that provision has applied since 2 February 2025.¹⁴ A citizen developer building an AI-assisted tool for their team is squarely within the population that provision has in mind.

Qualification, not just attendance

Training completion records prove attendance. Qualification proves capability, and for this population the difference matters, because the failure mode is a confident person building something they do not realize is Tier 3. A workable approach: the citizen developer builds one supervised tool end to end, including classification, requirements, independent testing, and a register entry, and a reviewer signs that they demonstrated the process correctly. That signature is the qualification. It is one afternoon of a reviewer’s time and it is worth considerably more than a completion certificate.

Volume, when the program is enabled properly, is not the problem people expect. Deutsche Bahn made more than 2,000 training sessions available in a year and they were fully booked within seven hours, with a maker community of 11,000 people attending workshops and showcases.³ That is not a pharma company and the regulatory context is different, but it is a published account of what demand looks like when a large organization actually opens the door.

What the Platform Team Owns

Citizen development without a platform team is not a model. It is an absence of a model. The platform team is what converts individual initiative into something with a shape.

The clearest published description of how this works at scale is Deutsche Bahn’s, which runs a Center of Excellence at two levels: a central function that defines guidelines and standardizes common components and services, and local functions at subsidiary level that handle implementation and include the subsidiary CIO. Citizen developers build in development and test environments, applications are staged while local expert teams evaluate them for business criticality, value, risk, and data protection, and only then are they deployed to production. The local expert teams coach the builders and approve applications for release.³ The person leading the central function described the reason for the two levels directly: he does not review every question from every citizen developer, only the ones local experts cannot resolve.

That structure translates well into pharma, with one addition. In a GxP company the local expert team is not only a technical reviewer. It is the point where quality participates, because the classification decision is a quality decision.

The five things the platform team has to provide

1. Environments with a route to production. Separate development, staging, and production environments, with a defined promotion path. Without this, every tool is built in production, and there is no place to test anything without touching live data.
2. Technical guardrails that do not rely on discipline. Data loss prevention policies restricting which connectors and data sources can be combined, access controls, and an approved list of platforms and models.¹¹ A guardrail a person can step over by accident is not a guardrail.
3. Templates and reusable components. Deutsche Bahn provisioned application templates carrying its own user experience style guides so builders start from a common base.³ In pharma the equivalent templates should also carry the standard logging, the standard access model, and the standard register hooks, so that a compliant starting point is the easiest starting point.
4. The register, maintained automatically. Discovery, reconciliation against declared entries, and an exception list with owners.
5. A named route for escalation. A tool that reaches Tier 4 needs somewhere to go. If the answer is a portfolio queue with a nine-month wait, builders will keep tools at Tier 3 by describing them creatively, and the model fails at exactly the point it matters most.

Four Failure Modes and How They Actually Happen

1. Sprawl, and a register that describes a company that no longer exists

The first failure is quantitative. Eighteen months in, there are four hundred tools and the register lists ninety. Nobody decided to stop registering. The form was long, the benefit was invisible to the builder, and the platform kept working whether or not the form was completed.

The fix is structural rather than motivational. Make the platform the source of the existence record, so that registration is a matter of adding meaning to something already discovered rather than declaring that something exists. Then make the difference between discovered and declared a reported metric with an owner. When that gap is on a monthly report, it gets closed. When it is not, it grows.

A second and less visible form of sprawl is duplication. Six teams build six versions of the same trend viewer because none of them could see the other five. A register with searchable purposes is the cheapest possible fix, and it converts sprawl from a risk into a reuse opportunity.

2. The builder leaves

This one is predictable and still catches most programs. A QA specialist builds a tool that forty people come to depend on, then moves to another site, another company, or another role. The tool keeps running. Nobody can change it, nobody knows how it works, and nobody is willing to turn it off because the forty people would notice.

Three controls handle this, and all three have to be in place because any one alone fails:

• A named backup owner from Tier 2 upward, recorded in the register, with actual access rather than nominal responsibility.
• Ownership transfer on the leaver checklist, alongside the equipment return and the system access removal. The register should be queryable by owner so that generating the list for a departing employee takes seconds.
• Automatic flagging of ownerless tools, with a defined period after which an unclaimed Tier 2 or Tier 3 tool is disabled. Disabling something that forty people use will generate a conversation, and that conversation is exactly the point. It surfaces the dependency while there is still someone to hand it to.

There is a related and less obvious version: the builder stays but stops using the tool themselves. A tool whose owner no longer uses it has lost the self-correction that made it safe. Periodic review should ask whether the owner is still a user.

3. The tool that became a GxP record without anyone deciding it

This is the most dangerous of the four, because nothing visibly goes wrong until an investigation. The classic shape: a scientist builds a working file to organize results while reviewing them. It is genuinely Tier 1. A colleague asks for a copy. Six months later a supervisor is reviewing a batch and finds the number in that file more convenient than the number in the source system, and starts using it. Twelve months later a figure from it appears in an investigation report.

The tool did not change. The use did. No change control was triggered because from the builder’s point of view nothing happened.

The evidence that this class of asset produces wrong answers is well established, and it long predates AI. Field audits of operational spreadsheets have repeatedly found errors in the large majority of the files examined, with research summarizing the literature reporting that spreadsheet error rates are consistent with human error rates in other cognitive tasks and that errors are difficult to detect after the fact.¹⁵¹⁶ The problem is not that people are careless. It is that small logic artifacts contain undetected mistakes at a predictable rate, and a review process that assumes otherwise is not a review process.

Regulators have been consistent that data integrity expectations follow the data rather than the system. The MHRA’s GXP data integrity guidance was developed to clarify minimum expectations across all the good practice areas, and was written to align with the corresponding documents from PIC/S, WHO, OECD, and EMA.¹⁷ None of those documents contain an exemption for a tool someone built themselves.

Three controls reduce this failure, none of which is a policy statement:

1. Reclassification triggers that are events, not judgments. A new user group, a new data source, an output appearing in a controlled document, or a request to expand access all trigger a re-look. Events are noticeable. “Use your judgment about whether this is now GxP” is not.
2. Review questions about the present, not the build. Ask who uses the output today and what they do with it. This finds drift; re-reading requirements does not.
3. Visible classification on the tool itself. A banner in the application stating its tier and that its output is not a GxP record removes the ambiguity at the moment of use, for the person about to copy a number out of it.

4. Model and prompt changes underneath a stable application

The fourth failure is specific to the generative era and it breaks a longstanding assumption. Traditionally, if the application did not change, its behavior did not change. With a hosted model behind the application, the version can change under a stable interface, and outputs can shift without any local change record.

The register field for prompt and model version is what makes this tractable, but the field only helps if something maintains it. The practical requirements are that the platform pins model versions rather than accepting whatever the service currently defaults to, that prompt text is stored as a versioned artifact rather than inside the application body where it cannot be diffed, and that a change in either is a change control event at Tier 3 and above. Retraining and model change control are treated in depth in the companion article in this series on building an AI change control decision tree; the point here is narrower. The register has to know what version is running, or none of the rest of the control set means anything.

Conclusion

The citizen development model is not a relaxation of GxP expectations, and companies that present it that way internally will find the position hard to defend. It is a redistribution of who does the building, held together by a boundary that everyone can state and a register that makes the whole arrangement visible. The domain expert builds, because they understand the process. Quality and IT define the classification rule, supply the platform, maintain the register, and own the handoff when a tool outgrows the model. The boundary is not about tools or departments. It is about whether a qualified person independently establishes the result before it becomes a record.

Our consistent observation working with pharma and biotech quality and IT teams is that the failure is almost never the tiering model itself. Companies write reasonable tiers. The failure is the two things underneath: a register that depends on people remembering to fill in a form, and no funded route for a tool that reaches Tier 4. Fix those two and the rest of the model holds up under questioning. Leave them and the tiers become a document that describes an intention rather than a practice.

Sakara Digital works with pharma and biotech organizations building governance for AI and digital tools inside GxP quality systems. If you are deciding what your domain experts should be allowed to build, and want an independent view on where the boundary belongs and what the register has to hold, we are happy to have that conversation.

For Further Reading